Re: [ANN] shadow-pgsql: PostgreSQL without JDBC
This makes me wonder if it would make sense to create a Postgresql plugin that adds a keyword type and other similar types, that would allow for a more precise roundtrip between Clojure and Postgres. Jason On Sat, Aug 23, 2014 at 11:23 AM, Thomas Heller wrote: > Hey Kyle, > > thanks for the Feedback. Appreciate it. > > I think you misunderstood the meaning of a "type" in shadow-psql. A "type" > is merely the format of how a given value is represented on the wire since > the backend needs to understand what we send it. Postgres supports 2 > different Wire Formats: Text and Binary. While Text is considered the > "default", binary is usually a lot more efficient. pgjdbc for example only > supports the text format. I try to be binary first, which works for most > types so far. (Numeric is giving me trouble, but I'll eventually figure that > out). I allow overwriting the "types" cause not everything I store in > postgres is understood by it (EDN, Keywords, ...). By hooking directly into > the encode/decode code I can efficiently do the transformation on-the-fly. > In my completely unscientific preliminary benchmark I cut the query time > from pgjdbc 650ms to shadow-pgsql 200ms and that is for very simple types > (50k rows) with no optimizations done yet. I expect the difference to be > much larger if you use a timestamp, timestamptz or bytea for example, as the > text format for those types carries a bit more overhead. But once everything > is stable I will do some real benchmarks. Better performance was not the > reason I wrote this, just a pleasant side-effect. > > As for the amount of work: its pretty much done. Some more exotic features > need to be implemented, but those were never available via JDBC anyways (eg. > COPY). I think its stable enough that I will begin moving my projects > "soon", when I release everything to production I'll probably release a > 1.0.0-RC. shadow-pgsql can not be layered on top of JDBC, well technically > thats what I did for the last 2 years > (https://gist.github.com/thheller/de7ecce0db58130ae6b7) BUT it required some > ugly reflection calls since the PGJDBC does not expose all the information I > needed. In the end I decided that I'd feel better to rewrite everything from > scratch as the documentation is quite good and the protocol is simple. > > Since the non-Java world does just fine without JDBC, I think we can do too. > ;) Also, the "Illusion" JDBC provides that you can just switch databases if > you feel like it only holds until you start using postgres-specific > features. Not all databases have arrays, hstore or json types. > > Regards, > /thomas > > > On Saturday, August 23, 2014 5:12:30 PM UTC+2, Kyle Cordes wrote: >> >> On Thursday, August 21, 2014 at 1:00 PM, Thomas Heller wrote: >> > Hey Clojure Folk, >> > >> > I'm close to releasing the first alpha version of >> > https://github.com/thheller/shadow-pgsql a "native" interface to PostgreSQL >> > I wrote. >> > >> > Its an implementation of the native binary protocol without any intent >> > to ever support JDBC. Mostly because that provides a bunch of features I >> > never use, but no support for features I wanted. It is mostly Java but I >> > will probably only use it from Clojure so that is my primary goal going >> > forward. I think the Java bits are close to stable. >> > >> > I'm looking for interested beta testers and feedback. I'm bad at writing >> > docs cause I never know where to start since there are so many features and >> > differences to JDBC. >> > >> >> >> As a user of both Postgres and Clojure, I find this very interesting. It’s >> helps with a couple of pain points around JDBC, such the fact that any >> nonstandard feature ends up hidden behind a untyped interface passing >> strings around. But I also have a couple of bits of feedback that are a >> little more skeptical: >> >> First, the amount of work it will take to get this to a complete enough >> state that large projects could safely switch to it, could be substantial. >> It makes me wonder if, instead, this could be built as a layer up on top of >> the Postgres JDBC driver. This would not be as elegant because it would not >> strip out as much unnecessary code, but it may be quite a lot less work. >> >> Second, it seems to most effectively target people who are both very type >> oriented, yet are using Java or Clojure. It seems to me that folks who are >> so concerned with types that they would step away from the standard way of >> talking to databases generically, might be found over in the community of >> people using more rigidly typed languages like Haskell etc. >> >> Third, although I like the idea of leveraging the features of the tool you >> are using (like Postgres), at the same time experiences taught me that, the >> more firmly a project seems destined to never switch to a different brand of >> database, the more likely some future unexpected opportunity will come up >> where that is exactly what is needed. I suppose this is just
Re: Clojure + jarjar to avoid dependency conflicts
+1 Any clojure users have any luck with jarjar? On Tuesday, 6 March 2012 15:27:52 UTC-8, nathanmarz wrote: > > I've been playing around with the "jarjar" tool ( > http://code.google.com/p/jarjar/ > ) in order to package my jar to avoid dependency conflicts with other > libs. It doesn't seem to work though with Clojure-created classfiles, > even when using aot compilation. At runtime, when doing a require/use > it still tries to load the old classname and not the new classname > substituted by jarjar. Has anyone had success with jarjar/clojure? -- -- 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/groups/opt_out.
Re: Lexer and parser generator in Clojure
This is a really great project. If you add LR1, you may want to retain ~LR0 as an option. My understanding is most grammars today are designed for LALR1. On Sun, May 20, 2012 at 4:26 AM, Christophe Grand wrote: > On Sat, May 19, 2012 at 9:44 PM, Jason Jackson wrote: > >> In retrospect, I would have tried >> https://github.com/cgrand/**parsley<https://github.com/cgrand/parsley> afaik >> it has ~LR1 performance characteristics. >> > > Parsley is closer to LR(0) (but I'd like to make it LR(1) using Pager's > lane tracing algorithm or IELR) however some ambiguities of LR(0) can be > lifted in parsley thanks to the contextual tokenizer. > > Christophe > > -- > 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 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: Lexer and parser generator in Clojure
I didn't read the part about clojure/clojurescript interop. Also, you could write a parser by hand in clojure[script], which takes a parse table as input. The parse table can be generated with from any language. On Saturday, 19 May 2012 15:44:28 UTC-4, Jason Jackson wrote: > > I wrote a compiler in Clojure for a 4th year course. > > For parsing I used this combinator parser library: > https://github.com/jasonjckn/clarsec which is modeled after haskell's > parsec. > However the performance was kind of bad, combinator parsers in general can > be pretty slow. > > In retrospect, I would have tried https://github.com/cgrand/parsley afaik > it has ~LR1 performance characteristics. > > Beyond the above options, there's many LR1/LL1 parsers written in Java > that are perfectly fine options. If you're parsing with a grammar file, you > don't gain anything if the parser was written in Clojure versus Java. > > For lexing, I just used clojure's regular expression implementation. Not > sure what libraries exist. > > -Jason > > On Friday, 18 May 2012 08:46:19 UTC-4, Alexsandro Soares wrote: >> >> Hi, >> >> I'm trying to build a compiler using Clojure. Is there any tools >> like flex and bison generating Clojure code? >> I'm interested in a lexer/parser in pure Clojure because I think >> in use the same code with Javascript (via ClojureScript) and Java (via >> Clojure). >> I already know isolated tools like Jflex, JavaCup and Bison generating >> Java and >> Jison, JS/CC and friends for Javascript, but I am just interested in a >> pure Clojure solution. >> >> Thanks in advance for any answer. >> >> Cheers, >> Alex >> > -- 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: Lexer and parser generator in Clojure
I wrote a compiler in Clojure for a 4th year course. For parsing I used this combinator parser library: https://github.com/jasonjckn/clarsec which is modeled after haskell's parsec. However the performance was kind of bad, combinator parsers in general can be pretty slow. In retrospect, I would have tried https://github.com/cgrand/parsley afaik it has ~LR1 performance characteristics. Beyond the above options, there's many LR1/LL1 parsers written in Java that are perfectly fine options. If you're parsing with a grammar file, you don't gain anything if the parser was written in Clojure versus Java. For lexing, I just used clojure's regular expression implementation. Not sure what libraries exist. -Jason On Friday, 18 May 2012 08:46:19 UTC-4, Alexsandro Soares wrote: > > Hi, > > I'm trying to build a compiler using Clojure. Is there any tools > like flex and bison generating Clojure code? > I'm interested in a lexer/parser in pure Clojure because I think > in use the same code with Javascript (via ClojureScript) and Java (via > Clojure). > I already know isolated tools like Jflex, JavaCup and Bison generating > Java and > Jison, JS/CC and friends for Javascript, but I am just interested in a > pure Clojure solution. > > Thanks in advance for any answer. > > Cheers, > Alex > -- 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: Core.logic, dynamically generated goals
Are you trying to see if a person meets multiple requirements? Here's how:
(defrel grade person course g)
(fact grade 'Bob 'Algebra 'B)
(fact grade 'Bob 'Art 'C)
(fact grade 'John 'Algebra 'A)
(fact grade 'John 'Art 'A)
(fact grade 'Ricky 'Algebra 'D)
(fact grade 'Ricky 'Art 'A)
(defn meets-requirements [person [k & nowledge]]
(if-let [{:keys [course g]} k]
(all
(grade person course g)
(meets-requirements person nowledge))
succeed))
#_ (run* [person]
(meets-requirements
person
[{:course 'Algebra :g 'B}
{:course 'Art :g 'C}]))
On Saturday, 19 May 2012 15:07:47 UTC-4, Alex Robbins wrote:
>
> Hmm, I didn't explain it very well. What if I had more knowledge?
> Maybe I knew two grades sometimes. That could cut down on the list of
> possible students (assuming there are more than the three in my
> example).
>
> How could I write a function that worked for both of these cases?
> (matches [{:course 'Algebra :g 'B}])
> (matches [{:course 'Algebra :g 'B} {:course 'Art :g 'C}])
>
>
> On Sat, May 19, 2012 at 2:02 PM, David Nolen
> wrote:
> > I don't think you need to generate goals for something as
> straightforward as
> > this:
> >
> > (defrel grade person course g)
> > (fact grade 'Bob 'Algebra 'B)
> > (fact grade 'Bob 'Art 'C)
> > (fact grade 'John 'Algebra 'A)
> > (fact grade 'John 'Art 'A)
> > (fact grade 'Ricky 'Algebra 'D)
> > (fact grade 'Ricky 'Art 'A)
> >
> > (defn matches [{:keys [course g]}]
> > (run* [q]
> > (fresh [p]
> > (grade p course g)
> > (== q [p course g]
> >
> > (matches {:course 'Algebra :g 'B})
> >
> > On Sat, May 19, 2012 at 2:12 PM, Alex Robbins
> > wrote:
> >>
> >> I'm just getting started with logic programming, and it is entirely
> >> possible I'm just approaching this incorrectly.
> >>
> >> Is it possible to use dynamically generated goals in run* ?
> >>
> >> For example,
> >>
> >> (defrel grade person course g)
> >> (fact grade 'Bob 'Algebra 'B)
> >> (fact grade 'Bob 'Art 'C)
> >> (fact grade 'John 'Algebra 'A)
> >> (fact grade 'John 'Art 'A)
> >> (fact grade 'Ricky 'Algebra 'D)
> >> (fact grade 'Ricky 'Art 'A)
> >>
> >> (def knowledge
> >> {:course 'Algebra :g 'B})
> >>
> >> (defn generate-goals [knowledge]
> >> (map
> >>(fn [{:keys [course g]}] (list 'grade 'person course g))
> >>knowledge))
> >>
> >> I want to do something like this (but valid clojure):
> >> (run* [person]
> >> ~@(generate-goals knowledge))
> >>
> >> It should give me back a list of people who match my current
> >> knowledge. If I have more knowledge about the person, it will generate
> >> more conditions, less knowledge fewer conditions. However, since run*
> >> and run are macros, I can't apply them to a list. I can't splice in
> >> because I'm not in a quotes list. Any ideas?
> >>
> >> Thanks!
> >>
> >> --
> >> 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 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 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: Clojure beginner in search of peer-induced enlightenment
This might not sound glamorous, but reading books, and reading great code, and code reviews is a great way to get up to speed. The explanations found in the Joy of Clojure, and other books have been highly edited and refined; if I ever paired up with someone, I doubt my ad-hoc verbal explanations would ever approach that degree of excellence. On Monday, 14 May 2012 10:10:14 UTC-4, James wrote: > > PS. My last post wasn't clearly formulated, so let me re-phrase that: > > I think that paying clojure/core to pair up is a perfectly legit > solution if one wants to jump ahead of the curve. My point was that I > wish the "sweeping the dojo" model was more widespread (one does > whatever other work there is while learning a skill one currently > lacks). > > / James > > > On May 14, 3:32 pm, James wrote: > > Hi Jay,- > > > > I agree, paying to sweep someone's dojo does sound a bit strong. > > > > / James > > > > On May 14, 3:24 pm, Jay Fields wrote: > > > > > > > > > > > > > > > > > James, > > > For learning, I'd recommend 4clojure.com and compare your solutions > with > > > solutions submitted by other people. Also, if you have the cash, you > could > > > pay clojure/core to pair with you. Unfortunately, I've never heard of > > > anyone doing that kind of thing as a mutually beneficial situation - > (you > > > learn from them, you help them with their work) > > > > > Cheers, Jay > > > > > On Mon, May 14, 2012 at 7:45 AM, James wrote: > > > > When a new technology (a programming language) comes out, initially > > > > there are very few people who are really proficient in it. One can > > > > learn by one's own, but tremendous learning acceleration can be > gained > > > > if one pairs with more experienced devs than oneself. > > > > > > So I'd like to ask: is there any place in the world where I can pair > > > > with more experienced people on Clojure as a beginner? Put very > > > > shortly, I have: decent Ruby skills; some Rails experience; very > good > > > > OO, TDD, and business modeling skills; a mastery of web standards, > and > > > > experience with Responsive Web Design. I'm into web as platform, > > > > HTML5, apps, and that kind of stuff. > > > > > > I'm currently based in Denmark but am flexible with moving. > > > > > > Cheers, > > > > James > > > >http://jamesabbottdd.com/ > > > > > > -- > > > > 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 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: notes on Mathematica pattern transformation & Clojure predicate dispatch
"But this exposes a bigger problem: when doing interactive development, you will end up with old definitions sticking around. You are debugging one case of your function, and change the pattern a little. " Personally, I suffer from interactive development problems even with merely using def/defn. This is especially true if you're eval'ing snippets, and not the entire file C-cC-k. You could solve these problems by creating a new editor specifically for clojure interactive development which is aware of when you're updating code vs inserting new code vs deleting code, and change the interactive session accordingly. I'm sure there's a lot more you could add to such an editor. (or maybe emacs mode is sufficient dunno). On Feb 20, 9:56 pm, kovas boguta wrote: > Mathematica implements a version of open and order-independent > dispatch, so I wanted to add some points to the discussion. > > The design of Mathematica's pattern matching is tightly coupled to the > language's computational model, as well as with all other aspects of > the system. So a lot of it would get lost in translation to Clojure, > and not give you as much mileage as it does in Mathematica. So I'm > mostly gonna focus on some pitfalls rather than the upside. > > The biggest problem for the developer is understanding the state of > the rules system, especially during interactive development. > > Mathematica tries it's best to insert new function definitions in the > "right" order, trying to figure out if pattern X if a subcase of > pattern Y, etc. Of course, there are ambiguous cases, particular since > the pattern language is rich. You solve this problem by either making > your pattern more specific, changing the order in which definitions > are loaded, or attaching the definition another symbol that has higher > precedence. > > So debugging the pattern ordering is something you end up needing to > know how to do. > > But this exposes a bigger problem: when doing interactive development, > you will end up with old definitions sticking around. You are > debugging one case of your function, and change the pattern a little. > The old pattern is still there, potentially shadowing the new one. So > anytime you see unexpected output while debugging, you need to wonder > about the state of the definitions and if you should reinitialize > them. > > You can also get a function that works at the repl, but its broken in > source. The way this happens is, you enter definitions in arbitrary > order at the repl, but they are in a different order in source. So in > cases where order matters, this can get you too. > > I've pretty much had every possible situation happen. > > In Mathematica, it's possible to manually specific the order of the > definitions, but it's too cumbersome to use in source code. > > In Clojure, the situation is simpler, and that helps. The pattern > language (or versions that we've seen of it) is simpler, and > destructuring is not part of its mission. (Changes to destructuring > are a common source of this shadowing issue.) There is also the > core.logic engine to do more deduction about the patterns themselves. > > Still, I still see the two problems of 1. debugging the ordering, and > then 2. dealing with the state of the definitions during debugging and > interactive development. > > On 1, the best thing is if you look at the source and immediately > understand what the ordering will be. So when you are writing code, > you just have this simple mental model, and spotting mistakes is easy. > For example, if the system does no "intelligent" ordering for you, its > obvious what the order at runtime will be, and you don't have to fight > anything to get things into the desired order. > > On 2, this is more tooling support, in rough order of importance > -- which case is called for input X, and why > -- debugging a specific case independent of all others (suppress the > other cases) > -- various operations for comparing and testing patterns > -- ide support for displaying / editing the ordering of definitions > > I've spent a ton of time debugging this stuff; its really important to > have a quick way to find out why something happened in these open > matching systems, and then have a convient way to patch the behavior. > Its just not as easy as changing a cond case in a single place in > source. > > The great thing about pattern matching in Mathematica is that it is so > deeply integrated with all kinds of other primitives, from string > manipulation, data manipulation, math stuff, the equivalent of Map, > the equivalent of macros. So my question is can clojure-style pattern > matching and predicate dispatch be equally as powerful and pervasive, > but it it's own way. > > One thought I had is about the relationship with program querying. > With predicate dispatch, you'll have greater runtime control over your > program, can swap things in and out at a finer granularity. And with > this idea of program querying that Rich talked abo
