Job Opportunity - Clojure coder + QA experience
There is an opening in my QA department at Red Hat. Note, the posting below is a somewhat generic and does not mention Clojure, but I can tell you that Clojure is already being used extensively by our group, and that you would be using it regularly. http://jobs.redhat.com/jobs/descriptions/principal-quality-assurance-engineer-cloudforms-system-engine-raleigh-north-carolina-job-1-3484969 The role is "Software Engineer in Test", where finding bugs is the top-level goal, but automated tests and tooling are the majority of the work. All the code we work with (including the product, the test tools, and the tests themselves) is open source. Feel free to contact me for further details - jweiss at redhat dotcom -- -- 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, send email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Printing non-serializable data that can be read back in
I am using clojure for functional testing ('functional' as opposed to unit
testing, I don't mean in the FP sense).
My tests write a clojure-formatted file containing all the test results.
Each result may include:
1) The code of the test
2) Parameters of a data-driven test
3) Trace of a failed test
The problem I'm having is when I go to analyze the results, I cannot simply
call read on the file, because it's full of
non-serializable #< ... > values, and also #'s and "..."s for print-level
and print-length being exceeded. Usually those are nested deep in the
parameters or the trace.
In every case, I don't *need* the missing data, it doesn't need to be truly
serializable. An informative placeholder would do fine. I'm not doing
computations on the trace, I just like it to be there so I can read it
myself to see what what happening.
So how do I solve this? I know I can replace the defmethod print-method
for java.lang.Object to just print a readable string. That would solve the
#< ... >. What about the #'s from the nesting level being exceeded? Or
"..." from print-length being exceeded? (I cannot turn off the limits for
print-length, since I trace functions that return infinite seq's).
Or should I approach it from the other direction, and modify the reader to
accept this input somehow? And I suppose on another level I should ask,
why isn't a readable placeholder the default behavior?
Any suggestions appreciated,
Jeff
--
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: (constantly)
I wish there was a built-in for this as well. I don't know that (constantly) is a good name for it though. I couldn't think of a good name, apparently a "null function" means the same as "identity function" so that doesn't work. On Monday, April 2, 2012 2:39:31 PM UTC-4, Jay Fields wrote: > > I often tend to define the following in my apps > > (def no-op (fn [& _])) > > The other day I noticed constantly > ( > http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/constantly > ), > which is basically the same thing - except I would have to say > (constantly nil). What do you all think about allowing constantly to > take no args and constantly return nil? > > Or, is there another function that does that and I've just overlooked it? > > Cheers, Jay > > -- 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: Source code as metadata
I believe the latest code does capture closures properly. I haven't tested all kinds of crazy corner cases, but it does work for all my closures. >From browsing git, it looks like the project.clj version hasn't been incremented in 7 months, and the fix for closures came in after that. If you're using serializable.fn from a maven repo, it is out of date, AFAICT. -jeff On Friday, March 30, 2012 3:07:53 PM UTC-4, Phil Hagelberg wrote: > > Nathan Matthews writes: > > > I wanted to serialise functions and send them over the network. The > > problem with serializable-fn is that it doesn't capture closures. > > It's designed to capture closures; if it doesn't that would be an > (unsurprising) bug. > > -Phil > > -- 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: Pretty print defn
I use serializable.fn pretty extensively, and it's been working great for me. I think at this point, the only fix I put in that Phil didn't is that my serialized fn's print with an unqualified "fn" symbol, instead of "serializable.fn/fn". I did that so it's more readable, the tradeoff is that if you want your fn's to be re-serializable (which I don't think you do), you have to spell out which fn you're using. https://github.com/weissjeffm/serializable-fn Another caveat is that it does not work with defn, just fn. So you would have to do (def qw (fn [] (inc 2)) A serializable.fn/defn would be really nice to have, I am not sure how difficult it would be to write, without having tried it. -jeff On Friday, March 2, 2012 10:19:56 PM UTC-5, Phil Hagelberg wrote: > > Mark Rathwell writes: > > > (clojure.repl/source-fn 'qw) will give you the source. > > You can also use serializable-fn to create a function that will carry > its source around with it in metadata: > > https://github.com/technomancy/serializable-fn > > But it's not very well tested. > > -Phil > > -- 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
