Re: meta-questions - [clojure] in front of Subject line
On Mon, Jun 18, 2012 at 8:46 PM, Andy Coolware wrote: > Managing subfolders is out a question for me since I use multiple > clients over IMAP. That would be a mess. I wish Thunderbird and gmail > have an option to split the traffic by group in some automated fashion I'm a bit surprised to hear this - I get about 1,000 emails a day from dozens of mailing lists, across six different email accounts, and have them all automatically filed into subfoders via rules based on the to/from address. I read those emails on my netbook, my iMac desktop, my iPhone and my iPad... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: Wildcards in Leiningen Dependencies Versions
Phil Hagelberg writes: >> Does leiningen support wildcards in dependencies version numbers ? I >> would usually like to use the latest version for some library, and it >> would be nice if I can indicate it by using a wildcard, so tat I dont >> need to keep checking if a new version has been released. > > You can do this, but it's not a good idea: > https://github.com/technomancy/leiningen/wiki/Repeatability I did use that, and as Phil points out ran into maven dependency issues. My motivation was mainly that it's convenient when you get dependency updates "for free", and I am pretty optimistic that my stuff usually won't break if foobar-0.1.0 is updated to foobar-0.2.0. Because of the dependency issues I stopped using version ranges, and in the meantime I discovered the leiningen outdated plugin at https://github.com/ato/lein-outdated Using that, running "lein outdated" tells you what dependencies have received updates (on maven central, clojars, whatever you use), and you can easily adjust versions and check if your project works with the new versions, too. That's about as convenient as version ranges, and it has the added benefit of you knowing exactly what you've updated in case an update really breaks something. Bye, Tassilo -- 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: Doseq, map-style
The protocol profile describes the data items, their attributes and where they fit in the overall structure. The DSL is there to encode the representation from a human readable format It's not per se specific to the medical field, the same trick could be used for other standard business protocol. It has no notion of what is a medical record, only the significant attributes like the field relative position, its data type, a human readable description, its name and its position in the structure, The multiple representations serve different needs: A) string representation is to provide an HL7/DICOM message acceptable to end points that only support this exchange mechanism. Only HL7 fields acceptable to the end device are retained. If necessary, rules are applied to marshall the ouput from the profile and the data at hand. Reason: several implementations of HL7. In fact we apply an endpoint specific profile to make the data backward compatible. Then we may apply rules (allowed field sizes may vary, sometimes fields have to be swapped, ...) B) the full representation is a merge of profile information and data, it allows some processing that require navigation in the message structure. Having it merged is easier (you can use zippers, compare differences, ...) C) the light weight one is a serialization format, we use to this to pass messages internaly (this runs on a small cluster to provide full redondancy) It's merelly imbricated vectors with minimal information so the receiving end can decode this back to B using of course the same profile. Empty fields are represented as empty vectors. D) the api to create a message is based on collection imbrications. The profile is then used to place data in it's rightful spot in the structure. We choose between a,b,c at runtime using Clojure protocols to extend the String class and some of Clojure's persistent structures and yes we pass the profile either by name or as a structure when calling these protocols. D) is a convenience to shrink the code when creating messages, it's also easier to write generic code with this approach. It's pretty dumb, [name value] pairs imbricated (can be any collection type) and no predefined order has to respected by the caller. The profile knows where to insert this stuff. To summarize, the profile drives the data in and out with the help of a small amount of code. Some end points are actually using maps to associate data entities in the messages from the profile to database equivalents. We need to make some improvement here but we should be able to drive this with generic code and push back in this associative map the mapping of relations and fields as data, not as code. We could add any other attributes in the profile, load sensitive stuff are better handled near the end points. Some of these are not message based (database queries or worse) and some are load sensitive. Luc > On Jun 18, 2012, at 5:35 PM, Softaddicts wrote: > > > Lets talk a bit about my world here. > > > > We created a product to link medical equipments > > using a variety of protocols, some talk HL7, DICOM, others have proprietary > > means to > > access data from various places. > > > > From the start we chose the richest data representation, some of it came > > from > > a few medical standards and another part is our own creation to carry stuff > > that is outside the scope of the business field (non medical data). > > > > We did not define specific records, instead we factored out the protocol > > definition (the contract) from the representation(s) and created its > > definition using > > persistent data structures and Clojure protocols > > > > The profile is being augmented often, new fields are added to keep up with > > support of new devices, new standards,... > > > > We never remove stuff from protocol definitions and we always aim to > > generate > > fully populated messages from the data available at a specific end point. > > > > It's all data (above 10k lines for as profile using our custom DSL) and > > less than > > 500 lines of code to define and handle. > > > > We have three message representations more or less equivalent, one is > > string based > > (HL7-enabled devices accept this representation), another one is > > for serialization and the last one is a "full" representation with each data > > component populated with all its attributes from the profile (name, relative > > position, ...) > > > > All the above representation allow you to switch from one to the other. > > We even have a pretty print so we can decipher message when investigating > > bugs. > > > > We also have a DSL to create messages from code to promoto some > > brevity when creating messages and lax us fro having to precisely order > > fields when writing code. > > Couldn't one say that a dsl is yet another more domain specific > representation of the medical record? Why did you code against the
Re: Wildcards in Leiningen Dependencies Versions
One thing I would like to see is something like the tiddle-wakka in Ruby Gemfiles, ie, gem 'foo', '~> 1.2.3' would match 1.2.x where x > 3, and so on for the most precise specified version number (major, minor, patch) It's super effective. On Jun 18, 2012 8:32 PM, "Phil Hagelberg" wrote: > On Mon, Jun 18, 2012 at 5:20 PM, Murtaza Husain > wrote: > > Does leiningen support wildcards in dependencies version numbers ? I > would > > usually like to use the latest version for some library, and it would be > > nice if I can indicate it by using a wildcard, so tat I dont need to keep > > checking if a new version has been released. > > You can do this, but it's not a good idea: > https://github.com/technomancy/leiningen/wiki/Repeatability > > -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 -- 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: meta-questions - [clojure] in front of Subject line
Hi, thx a lot for all viewpoints. I am personally a bit torn. On one hand, when I open my gmail I have hard time to distinguish between all groups I am subscribed too. When you get tens of threads updated daily, this is really handy. However, I hate to have a redundant information in Subject and headers as it was pointed out. And even if that prefix is added, the solution is not perfect since all my original posts are missing prefix too. Managing subfolders is out a question for me since I use multiple clients over IMAP. That would be a mess. I wish Thunderbird and gmail have an option to split the traffic by group in some automated fashion ... Cheers, Andy -- 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
Boston area Architect
I wanted to post this job because it's still open at my company and it would be a great way to "sneak" Clojure in. A new project is starting up with an eye toward big data, and whoever takes the architect position will set the direction. http://www.bullhornreach.com/job/231982_principal-software-architect-boston-ma?utm_campaign=v1 Serious applicants can feel free to channel their resume through me. -- 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: Wildcards in Leiningen Dependencies Versions
On Mon, Jun 18, 2012 at 5:20 PM, Murtaza Husain wrote: > Does leiningen support wildcards in dependencies version numbers ? I would > usually like to use the latest version for some library, and it would be > nice if I can indicate it by using a wildcard, so tat I dont need to keep > checking if a new version has been released. You can do this, but it's not a good idea: https://github.com/technomancy/leiningen/wiki/Repeatability -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: Doseq, map-style
On Jun 18, 2012, at 5:35 PM, Softaddicts wrote: > Lets talk a bit about my world here. > > We created a product to link medical equipments > using a variety of protocols, some talk HL7, DICOM, others have proprietary > means to > access data from various places. > > From the start we chose the richest data representation, some of it came from > a few medical standards and another part is our own creation to carry stuff > that is outside the scope of the business field (non medical data). > > We did not define specific records, instead we factored out the protocol > definition (the contract) from the representation(s) and created its > definition using > persistent data structures and Clojure protocols > > The profile is being augmented often, new fields are added to keep up with > support of new devices, new standards,... > > We never remove stuff from protocol definitions and we always aim to generate > fully populated messages from the data available at a specific end point. > > It's all data (above 10k lines for as profile using our custom DSL) and less > than > 500 lines of code to define and handle. > > We have three message representations more or less equivalent, one is string > based > (HL7-enabled devices accept this representation), another one is > for serialization and the last one is a "full" representation with each data > component populated with all its attributes from the profile (name, relative > position, ...) > > All the above representation allow you to switch from one to the other. > We even have a pretty print so we can decipher message when investigating > bugs. > > We also have a DSL to create messages from code to promoto some > brevity when creating messages and lax us fro having to precisely order > fields when writing code. Couldn't one say that a dsl is yet another more domain specific representation of the medical record? Why did you code against the medical record rather than the dsl? My assumption is that the dsl is just a subset but just curious. > > None of the above uses defrecord or deftype. We use > Clojure's persistent structures and protocols to implement how to handle > these various formats. Roughly we do this in less than 1000 lines splitted > in 4 namespaces. This code never refers to a specific piece of data by its > name. A bit confused. So you have profile that describes how to convert from the medical record to the preferred internal representation which allows you to support multiple medical record representations? How might you handle the situation where a new medical record contains an abbreviation or medical code but you need the full value and to get the complete value you need to perform a web service query, so you want to avoid this unless the value is required... Ideally, the internal representation would know that the value is expensive and to request it only if necessary. So This would probably change the contract, but for your boss needs this to process this non-standard record format tomorrow if the client likes what he sees youll have time to support it properly, if not then you can just rip the code put. How would you go about this change 1 if you needed it functional tomorrow and 2 the ideal/best way? > > It's all data driven, the contract is data in our internal protocol profile > definition. > Validation, searching the metadata of the profile, ... is done within the > profile definition. > So do you have one function that takes the profile, record and desired property? > The name spaces allowing us to support the different representations all > rely on the > profile definition. They never refer to specific data items. > > Some devices do not support all the fields or are using older versions > of protocols compared to what we implemented internally. > > We have a rule engine and rules attached to specific device profiles to > alter the common format message so we can spit out a valid message that > can be understood by the device. We implemented a Clojure protocol that lets > us manipulate a message using Clojure generic fns to strip items, > swap items from one spot to the other, > > These rules are applied on top of a generic message just before sending or > just > after receiving to/fro the device. We do not have to recode messages for > each device > type. This is the only place aside from message generation that will ever > refer > to specific data items. > > > What about maintenance ? Why remove a data item from the profile ? > If ever necessary, we can flag it as unusable and the rest will carry on. > > Any attempt to refer to it will trigger an exception. > Searching the code base to find references to it is no more difficult than > finding getters. And we know it's a required change. Either it disappeared or > the data item changed. We can remove it somewhere in the future, no need > rushing. > > It eases the maintenance of the device specific rules, if they do not > refer to the disabled data item, t
Wildcards in Leiningen Dependencies Versions
Hi, Does leiningen support wildcards in dependencies version numbers ? I would usually like to use the latest version for some library, and it would be nice if I can indicate it by using a wildcard, so tat I dont need to keep checking if a new version has been released. Thanks, Murtaza -- 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
The reverse operation of juxt
; ## Can this be considered an essential function?
(defn scat
"Returns a function taking a seq on which f is applied.
To [scat]ter is an antonym of to [juxt]apose."
[f]
(partial apply f))
; # A motivating use case from clojurescript:
(def to-js
"Makes a js object from a map"
(comp (scat js-obj) (scat concat)))
; # Or even:
(defn compply
"Composes functions, that take multiple args and produce a seq"
[& fns]
(apply comp (map scat fns)))
(def to-js
"Makes a js object from a map"
(compply js-obj concat))
(to-js
{"regards" "kind"})
--
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: clojurescript - accessing `window` from a browser repl
same error happens in ClojureScriptOne as well. On Monday, June 18, 2012 7:58:13 PM UTC-4, Dustin Getz wrote: > > i'm using lein-cljsbuild advanced example project[1], which seems to be > the simplest way to get a working clojurescript dev env with browser repl. > > from the browser-based cljs repl, `window` isn't defined, and third-party > javascript code using window fails: > > ClojureScript:cljs.user> (Ext.Msg.alert "hello" "world") > > > "Error evaluating:" (Ext.Msg.alert "hello" "world") :as > "Ext.Msg.alert.call(null,\"hello\",\"world\");\n" > > # > > > TypeError: Object [object Window] has no method 'show' > > > at > http://localhost:3000/extjs-4.1.0/ext-all-debug-w-comments.js:154023:21 > > what is going on under the scenes, why doesn't `window` exist, and what i > need to do to access `window`? how could i have figured out the answer on > my own? > > [1] https://github.com/dustingetz/cljs-bootstrap/tree/sencha > -- 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
clojurescript - accessing `window` from a browser repl
i'm using lein-cljsbuild advanced example project[1], which seems to be the simplest way to get a working clojurescript dev env with browser repl. from the browser-based cljs repl, `window` isn't defined, and third-party javascript code using window fails: ClojureScript:cljs.user> (Ext.Msg.alert "hello" "world") "Error evaluating:" (Ext.Msg.alert "hello" "world") :as "Ext.Msg.alert.call(null,\"hello\",\"world\");\n" # TypeError: Object [object Window] has no method 'show' at http://localhost:3000/extjs-4.1.0/ext-all-debug-w-comments.js:154023:21 what is going on under the scenes, why doesn't `window` exist, and what i need to do to access `window`? how could i have figured out the answer on my own? [1] https://github.com/dustingetz/cljs-bootstrap/tree/sencha -- 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: Doseq, map-style
Lets talk a bit about my world here. We created a product to link medical equipments using a variety of protocols, some talk HL7, DICOM, others have proprietary means to access data from various places. >From the start we chose the richest data representation, some of it came from a few medical standards and another part is our own creation to carry stuff that is outside the scope of the business field (non medical data). We did not define specific records, instead we factored out the protocol definition (the contract) from the representation(s) and created its definition using persistent data structures and Clojure protocols The profile is being augmented often, new fields are added to keep up with support of new devices, new standards,... We never remove stuff from protocol definitions and we always aim to generate fully populated messages from the data available at a specific end point. It's all data (above 10k lines for as profile using our custom DSL) and less than 500 lines of code to define and handle. We have three message representations more or less equivalent, one is string based (HL7-enabled devices accept this representation), another one is for serialization and the last one is a "full" representation with each data component populated with all its attributes from the profile (name, relative position, ...) All the above representation allow you to switch from one to the other. We even have a pretty print so we can decipher message when investigating bugs. We also have a DSL to create messages from code to promoto some brevity when creating messages and lax us fro having to precisely order fields when writing code. None of the above uses defrecord or deftype. We use Clojure's persistent structures and protocols to implement how to handle these various formats. Roughly we do this in less than 1000 lines splitted in 4 namespaces. This code never refers to a specific piece of data by its name. It's all data driven, the contract is data in our internal protocol profile definition. Validation, searching the metadata of the profile, ... is done within the profile definition. The name spaces allowing us to support the different representations all rely on the profile definition. They never refer to specific data items. Some devices do not support all the fields or are using older versions of protocols compared to what we implemented internally. We have a rule engine and rules attached to specific device profiles to alter the common format message so we can spit out a valid message that can be understood by the device. We implemented a Clojure protocol that lets us manipulate a message using Clojure generic fns to strip items, swap items from one spot to the other, These rules are applied on top of a generic message just before sending or just after receiving to/fro the device. We do not have to recode messages for each device type. This is the only place aside from message generation that will ever refer to specific data items. What about maintenance ? Why remove a data item from the profile ? If ever necessary, we can flag it as unusable and the rest will carry on. Any attempt to refer to it will trigger an exception. Searching the code base to find references to it is no more difficult than finding getters. And we know it's a required change. Either it disappeared or the data item changed. We can remove it somewhere in the future, no need rushing. It eases the maintenance of the device specific rules, if they do not refer to the disabled data item, they are still working. We get a uniform way of dealing with messages, choosing the most efficient representation when needed, having uniform naming and a firewall preventing us from specifying invalid data items without writing a single internal line of code referring to specific data elements. It's mostly done with data definitions...the key is using proper data abstractions. I agree, if none exist, you have to create them but this is where the secret of the sauce is. Refrain from writing tons of code lines if your data abstractions are not well defined. Experiment and tune them before hand. Before this era, we used to have classes wrapping data items and so forth. It was a pain in the ass to navigate and modify this stuff each time we needed to enrich our data model with all these wrappers around us not withstanding dependency management. Now, the contract is the data. End of story. Luc P. > > > On Monday, June 18, 2012 8:01:47 AM UTC-6, tbc++ wrote: > > > > > Isnt that just creating an api? Everywhere the old model exists you need > > to > > > call a function to create the desired data structure and this adds > > another > > > layer of complexity that needs maintained. Not all conversions are > > straight > > > forward, may require additional context of whatever introducing the need > > for > > > deferred computation. > > > > Can you provide a concrete example (with code perhaps)? I guess I'
Re: clojure.inspector.inspect-table gives up when first element is nil...
On Mon, Jun 18, 2012 at 3:12 PM, Jim - FooBar(); wrote: > how is it verified at the moment? I didn't see any unit tests for clojure.inspector... > Unfortunately i don't have a CA! Sounds like a good opportunity to fill one out and send it in! http://clojure.org/contributing -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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.inspector.inspect-table gives up when first element is nil...
ooops!!! I misunderstood! you meant how to verify that it is actually showing everything up on screen! sorry my bad...how is it verified at the moment? I mean whatever unit test exists now will perfectly do the job with my modified version...remember...I just changed (first data) to (some #(when-not (nil? %) %) data) it should work like a charm! Unfortunately i don't have a CA! Jim On 18/06/12 22:58, Jim - FooBar(); wrote: First of all thanks both of you...As far as the tests go It is ridiculously easy to reproduce the 'bad behaviour' simply by passing a seq of maps (or records) where the first element is nil...my addition simply looks for the first element that is not nil and uses that instead of 'first'. if none is found then the original behaviour (empty table) will occur but this time is not 'bad' - is indeed correct (there is no data)... I'm not really expecting quick turnarounds from core...I'm already using the modified version of old-table-model in my namespace...btw, since I didin't modify 'inspect-table' I don't really need it in my namespace I only need the modified table-model...how can I :require or :use clojure.inspector (so i can call 'inspect-table') but have my modified table-model overwrite the one in clojure.inspector? I was expecting to be done automatically cos I've seen the "var is being replaced" warning in core.logic...however for the inspector it throws an exception "var already refers to clojure.inspector/old-table-model"...any ideas? Will it work if I exclude that var? Jim On 18/06/12 21:30, Andy Fingerhut wrote: Agreed with everything Sean said, except I wanted to point out that making a unit test for functions that create GUI windows might be a little bit out of the beaten path of the existing unit tests. There may be a way to create a unit test that calls inspect-table with arguments that make it throw an exception with the current version, and doesn't with Jim's proposed new version, but not sure about that. Also, Jim, don't expect a quick turnaround on changes to Clojure core. They can take a while to get in. If you really like using your improved version of inspect-table and want to use it, put it in your own local library and use it (or make your own local modified version of Clojure for your own use). Andy On Jun 18, 2012, at 12:07 PM, Sean Corfield wrote: JIRA - http://dev.clojure.org/jira/browse/CLJ (since this is a "core" Clojure namespace). If you have a CA on file, you can create a patch and attach it to the ticket. If you don't have a CA on file, you can outline what you think needs to be done (as you have below) and someone with a CA on file can create a patch based on your suggestions, along with additional unit tests to show that the behavior would be correct (should be easy to create a test that fails now but would pass after this change?). Sean On Mon, Jun 18, 2012 at 11:22 AM, Jim - FooBar(); wrote: the very first let binding in clojure.inspector/old-table-model should be: row1 (some #(when-not (nil? %) %) data) instead of row1 (first data) simply because it will fail if the (first data) returns nil... where do we submit minor improvements like this? -- 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.inspector.inspect-table gives up when first element is nil...
First of all thanks both of you...As far as the tests go It is ridiculously easy to reproduce the 'bad behaviour' simply by passing a seq of maps (or records) where the first element is nil...my addition simply looks for the first element that is not nil and uses that instead of 'first'. if none is found then the original behaviour (empty table) will occur but this time is not 'bad' - is indeed correct (there is no data)... I'm not really expecting quick turnarounds from core...I'm already using the modified version of old-table-model in my namespace...btw, since I didin't modify 'inspect-table' I don't really need it in my namespace I only need the modified table-model...how can I :require or :use clojure.inspector (so i can call 'inspect-table') but have my modified table-model overwrite the one in clojure.inspector? I was expecting to be done automatically cos I've seen the "var is being replaced" warning in core.logic...however for the inspector it throws an exception "var already refers to clojure.inspector/old-table-model"...any ideas? Will it work if I exclude that var? Jim On 18/06/12 21:30, Andy Fingerhut wrote: Agreed with everything Sean said, except I wanted to point out that making a unit test for functions that create GUI windows might be a little bit out of the beaten path of the existing unit tests. There may be a way to create a unit test that calls inspect-table with arguments that make it throw an exception with the current version, and doesn't with Jim's proposed new version, but not sure about that. Also, Jim, don't expect a quick turnaround on changes to Clojure core. They can take a while to get in. If you really like using your improved version of inspect-table and want to use it, put it in your own local library and use it (or make your own local modified version of Clojure for your own use). Andy On Jun 18, 2012, at 12:07 PM, Sean Corfield wrote: JIRA - http://dev.clojure.org/jira/browse/CLJ (since this is a "core" Clojure namespace). If you have a CA on file, you can create a patch and attach it to the ticket. If you don't have a CA on file, you can outline what you think needs to be done (as you have below) and someone with a CA on file can create a patch based on your suggestions, along with additional unit tests to show that the behavior would be correct (should be easy to create a test that fails now but would pass after this change?). Sean On Mon, Jun 18, 2012 at 11:22 AM, Jim - FooBar(); wrote: the very first let binding in clojure.inspector/old-table-model should be: row1 (some #(when-not (nil? %) %) data) instead of row1 (first data) simply because it will fail if the (first data) returns nil... where do we submit minor improvements like this? -- 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.inspector.inspect-table gives up when first element is nil...
if you are printing tables using Clojure, you should checkout doric: http://github.com/joegallo/doric On Mon, Jun 18, 2012 at 11:22 AM, Jim - FooBar(); wrote: > the very first let binding in clojure.inspector/old-table-model should be: > > row1 (some #(when-not (nil? %) %) data) > > instead of > > row1 (first data) > > simply because it will fail if the (first data) returns nil... > > where do we submit minor improvements like this? > > Jim > > > > On 16/06/12 13:26, Jim - FooBar(); wrote: > > It would be nice to have the option to supply the keys to 'inspect-table' > just in case the first element is nil...this is exactly the behaviour of > 'clojure.pprint.print-table' where providing the keys is indeed an option. > Both will fail when the first element is nil but at least 'print-table' > allows us to provide the keys in advance... > > Jim > > > -- > 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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.inspector.inspect-table gives up when first element is nil...
On Mon, Jun 18, 2012 at 1:30 PM, Andy Fingerhut wrote: > Agreed with everything Sean said, except I wanted to point out that making a > unit test for functions that create GUI windows might be a little bit out of > the beaten path of the existing unit tests. Oops, I didn't even check what that function did... From playing around in the REPL I think you could run just old-table-model and call .getColumnCount on the result to test the patch? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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.inspector.inspect-table gives up when first element is nil...
Agreed with everything Sean said, except I wanted to point out that making a unit test for functions that create GUI windows might be a little bit out of the beaten path of the existing unit tests. There may be a way to create a unit test that calls inspect-table with arguments that make it throw an exception with the current version, and doesn't with Jim's proposed new version, but not sure about that. Also, Jim, don't expect a quick turnaround on changes to Clojure core. They can take a while to get in. If you really like using your improved version of inspect-table and want to use it, put it in your own local library and use it (or make your own local modified version of Clojure for your own use). Andy On Jun 18, 2012, at 12:07 PM, Sean Corfield wrote: > JIRA - http://dev.clojure.org/jira/browse/CLJ (since this is a "core" > Clojure namespace). > > If you have a CA on file, you can create a patch and attach it to the > ticket. If you don't have a CA on file, you can outline what you think > needs to be done (as you have below) and someone with a CA on file can > create a patch based on your suggestions, along with additional unit > tests to show that the behavior would be correct (should be easy to > create a test that fails now but would pass after this change?). > > Sean > > On Mon, Jun 18, 2012 at 11:22 AM, Jim - FooBar(); > wrote: >> the very first let binding in clojure.inspector/old-table-model should be: >> >> row1 (some #(when-not (nil? %) %) data) >> >> instead of >> >> row1 (first data) >> >> simply because it will fail if the (first data) returns nil... >> >> where do we submit minor improvements like this? -- 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: How to speed up Clojure Training for New Recruitment
Start a meetup group. The people who show up more than a few times with no up front promise of a job opportunity will likely be the kind of people you want to hire. (Don't tell recruiters that though, please.) In addition, it gives you an opportunity to talk to potential hires in a relaxed setting without a lot of the BS that normally goes along with a formal recruiting process. Cheers, '(Devin Walters) On Monday, June 18, 2012 at 10:22 AM, Jay Fields wrote: > > > On Mon, Jun 18, 2012 at 3:11 AM, Murtaza Husain > mailto:murtaza.hus...@sevenolives.com)> > wrote: > > Hi, > > > > Just wanted to get pointers on how do you manage the training of recruits. > > It is difficult to find clojure talent, and we are located in India, where > > it is close to impossible. Also the non availability of talent becomes a > > hard sell to management too while introducing clojure projects. How can the > > learning curve, and training time be reduced for new recruits ? Also how do > > you pitch it to the management ? > > I'd read this for inspiration on how to talk to mgmt. Perhaps I'd even > suggest they read it. http://www.paulgraham.com/avg.html > Related: http://www.paulgraham.com/icad.html > > As far as actually finding people, I'd look in the Ruby community. Many of > those people are fine with functional style and not too attached to a > specific language. And, do what Bill recommended. > > 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 > (mailto: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 > (mailto: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: Converting String to Hashmap
Thank you. That solution worked for me. @Tassilo: haha, yeah a nerd
should definedly deserves an own gender ;D
On 18 Jun., 18:44, Jay Fields wrote:
> first of all, what gender is "n"? =)
>
> http://blog.jayfields.com/2011/03/clojure-eval-ing-string-in-clojure
>
> On Mon, Jun 18, 2012 at 11:18 AM, Antix wrote:
>
>
>
>
>
>
>
> > Hi Guys,
> > I'm very new to clojure and searching for a way to convert a given
> > String to a Hashmap as far as this is possible.
> > I thought already about the use of a macro, but all the different
> > quotes are a little bit confusing for me.
>
> > Is it possible to create a Hashmap or some similar structure by using
> > a given String.
>
> > My Input-String is something like: :Name "John", :age 20, :gender
> > "n"
> > Is it possible to convert this to a hashmap similar to this:
> > (def hashm {:Name "John", :age 20, :gender "n" }) ?
>
> > --
> > 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.inspector.inspect-table gives up when first element is nil...
JIRA - http://dev.clojure.org/jira/browse/CLJ (since this is a "core" Clojure namespace). If you have a CA on file, you can create a patch and attach it to the ticket. If you don't have a CA on file, you can outline what you think needs to be done (as you have below) and someone with a CA on file can create a patch based on your suggestions, along with additional unit tests to show that the behavior would be correct (should be easy to create a test that fails now but would pass after this change?). Sean On Mon, Jun 18, 2012 at 11:22 AM, Jim - FooBar(); wrote: > the very first let binding in clojure.inspector/old-table-model should be: > > row1 (some #(when-not (nil? %) %) data) > > instead of > > row1 (first data) > > simply because it will fail if the (first data) returns nil... > > where do we submit minor improvements like this? -- 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: Compiler error messages
On Mon, Jun 18, 2012 at 11:44 AM, Brandon Bickford wrote: > I was wondering if anyone was working on improving compiler error messages? > For instance in a case just now when I used an undeclared variable "host" I > received an opaque hundred line traceback. I think it would be nice if it > printed the error message, the file, the line number and the source code > context instead of a traceback through the compiler. wait a second. was this email lost since 2007? "what net lag?" -- 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: Converting String to Hashmap
Jay Fields writes: > first of all, what gender is "n"? =) *N*erd! What else could it be?! Bye, Tassilo -- 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.inspector.inspect-table gives up when first element is nil...
the very first let binding in clojure.inspector/old-table-model should be: row1 (some #(when-not (nil? %) %) data) instead of row1 (first data) simply because it will fail if the (first data) returns nil... where do we submit minor improvements like this? Jim On 16/06/12 13:26, Jim - FooBar(); wrote: It would be nice to have the option to supply the keys to 'inspect-table' just in case the first element is nil...this is exactly the behaviour of 'clojure.pprint.print-table' where providing the keys is indeed an option. Both will fail when the first element is nil but at least 'print-table' allows us to provide the keys in advance... Jim -- 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: Doseq, map-style
On Monday, June 18, 2012 8:01:47 AM UTC-6, tbc++ wrote: > > > Isnt that just creating an api? Everywhere the old model exists you need > to > > call a function to create the desired data structure and this adds > another > > layer of complexity that needs maintained. Not all conversions are > straight > > forward, may require additional context of whatever introducing the need > for > > deferred computation. > > Can you provide a concrete example (with code perhaps)? I guess I'm > not seeing where the problems arise. In this situation I normally > either, 1) create a new "fetch" function to create a new map of data > in the new format 2) provide duplicate data in the map that's computed > differently, 3) update the old code to the new map. > > Here at work we have a 20 year old application that is almost 100% > backwards compatible (the server can talk to much older clients). And > it does so by using pure data. The server has setup contracts saying > "this is what Project data looks like, this is what Company Data looks > like" and those contracts never change. The 3D Software Blender > (blender.org) operates on this same principle. After almost a decade, > their latest software can open 1.0 .blend files, and vice versa. All > these applications work off of unchanging data contracts. > > So I'm interested in seeing concrete examples of how your application > differs. > Its not the external contracts that are changing but the internal contracts between namespaces... as I add features I add new requirements clarify my understanding and decide to replace them with new ones. I wish I could say just don't change them, but the internal contracts are "implementation details" no one uses them but me. If I decide to change them stuff breaks and that would be true in OO too, but in I know how to go about these refactorings incrementally in OO until the old abstractions fall away and become dead code, in clojure new abstractions mean lots of breaking changes and nothing works until everything works. I wouldn't mind sitting down with someone in the Denver area and getting some feedback on my code, eventually I would like to open source the code but I don't expect that to happen anytime in the near future. > > Timothy > -- 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: Doseq, map-style
I did not know about lazy map either… This might be exactly what I was needed. Maps with referentially transparent properties rather than fields. A way to make minor changes to map representation without adding an api in advance, introducing breaking changes, redundant properties, or converters and still work with the clojure core apis. This might make the simple refactoring a bit easier. On Monday, June 18, 2012 8:48:37 AM UTC-6, Vinzent wrote: > > Yeah, I'm waiting for concrete example too. > > By the way, if you really need to change :area from value to deferred > computation then you can just change your data structure implementation > from hash-map to lazy map (i.e. a map whose values are delays deref'd on > access). This would require changing code only in one place. > -- 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: Converting String to Hashmap
first of all, what gender is "n"? =)
http://blog.jayfields.com/2011/03/clojure-eval-ing-string-in-clojure.html
On Mon, Jun 18, 2012 at 11:18 AM, Antix wrote:
> Hi Guys,
> I'm very new to clojure and searching for a way to convert a given
> String to a Hashmap as far as this is possible.
> I thought already about the use of a macro, but all the different
> quotes are a little bit confusing for me.
>
> Is it possible to create a Hashmap or some similar structure by using
> a given String.
>
> My Input-String is something like: :Name "John", :age 20, :gender
> "n"
> Is it possible to convert this to a hashmap similar to this:
> (def hashm {:Name "John", :age 20, :gender "n" }) ?
>
> --
> 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
Converting String to Hashmap
Hi Guys,
I'm very new to clojure and searching for a way to convert a given
String to a Hashmap as far as this is possible.
I thought already about the use of a macro, but all the different
quotes are a little bit confusing for me.
Is it possible to create a Hashmap or some similar structure by using
a given String.
My Input-String is something like: :Name "John", :age 20, :gender
"n"
Is it possible to convert this to a hashmap similar to this:
(def hashm {:Name "John", :age 20, :gender "n" }) ?
--
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: How to go about finding a Clojure job
Or send me yours. We're a full-on clojure shop in Charlottesville, VA. On Saturday, June 16, 2012 10:49:00 AM UTC-4, tbc++ wrote: > > I'm about to begin the process of looking for a new job, and would > like to find one that focuses on Clojure. Can anyone suggest some good > ways to go about this? It seems like posting my resume on this mailing > list would be a bit off-topic. > > As far as location goes, I'm looking in the Denver, CO area, but am > also open to 100% telecommute. > > > Thanks, > > Timothy Baldridge > -- 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 Sticker
+1 -- 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: meta-questions - [clojure] in front of Subject line
On Mon, Jun 18, 2012 at 6:05 AM, Jay Fields wrote: > this is also true of the ActionScript solution... Actually, no (depending on exactly how you do it in AppleScript). At least one of the possible AppleScript solutions changes the subject for your display but does not actually change it in the message itself, so when you reply, it uses the original subject... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: How to speed up Clojure Training for New Recruitment
On Mon, Jun 18, 2012 at 3:11 AM, Murtaza Husain < murtaza.hus...@sevenolives.com> wrote: > Hi, > > Just wanted to get pointers on how do you manage the training of recruits. > It is difficult to find clojure talent, and we are located in India, where > it is close to impossible. Also the non availability of talent becomes a > hard sell to management too while introducing clojure projects. How can the > learning curve, and training time be reduced for new recruits ? Also how do > you pitch it to the management ? > I'd read this for inspiration on how to talk to mgmt. Perhaps I'd even suggest they read it. http://www.paulgraham.com/avg.html Related: http://www.paulgraham.com/icad.html As far as actually finding people, I'd look in the Ruby community. Many of those people are fine with functional style and not too attached to a specific language. And, do what Bill recommended. 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: Doseq, map-style
I wan't aware of LazyMap! My solution so far was to attach functions instead of values in maps. You 're still deferring the computation to the underlying fn...in a sense it is a getter isn't it? and you can also pass the map around to effectively get polymorphic behaviour on the fns that accept the map and execute fns from within it... LazyMap looks cool though... :-) Jim On 18/06/12 15:48, Vinzent wrote: Yeah, I'm waiting for concrete example too. By the way, if you really need to change :area from value to deferred computation then you can just change your data structure implementation from hash-map to lazy map (i.e. a map whose values are delays deref'd on access). This would require changing code only in one place. -- 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: Doseq, map-style
Yeah, I'm waiting for concrete example too. By the way, if you really need to change :area from value to deferred computation then you can just change your data structure implementation from hash-map to lazy map (i.e. a map whose values are delays deref'd on access). This would require changing code only in one place. -- 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: Doseq, map-style
On Mon, Jun 18, 2012 at 3:37 PM, Kurt Harriger wrote: > > Representations are values in Clojure, they are not mixed with behaviors > like in mainstream OO. It follows that, if your representation need to > change, you can write a converter function (or two if you want to convert > from and to the old representation), that's easy, easier than writing an > adapter class in Java because the adapter class must implement new > behaviors on top of old ones (or the other way round). > > > Isnt that just creating an api? Everywhere the old model exists you need > to call a function to create the desired data structure and this adds > another layer of complexity that needs maintained. Not all conversions are > straight forward, may require additional context of whatever introducing > the need for deferred computation. > It is creating a new API (as data). To me this discussion is about managing (API) change. Data as API won't solve all problems but it's easier to version/write/test compatibility layer for data than functions (methods) as API. When you start to refactor your data, you are effectively introducing a change in API and converters help you delimit the boundaries of the refactored module so that your changes don't ripple through the whole application. Inside: new format, outside old format. Each module can even have its own specialized data representation (optimized for its needs) and convert from and to a more "canonical" representation. This allows for more decoupling between modules. In this perspective functional accessors which you are advocating are micro-managing API changes at the field level: you expect your code (and thus algorithms) to stay the same no matter how the data is represented, while specialized representations would allow for better algorithms. 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
Re: Doseq, map-style
> Isnt that just creating an api? Everywhere the old model exists you need to > call a function to create the desired data structure and this adds another > layer of complexity that needs maintained. Not all conversions are straight > forward, may require additional context of whatever introducing the need for > deferred computation. Can you provide a concrete example (with code perhaps)? I guess I'm not seeing where the problems arise. In this situation I normally either, 1) create a new "fetch" function to create a new map of data in the new format 2) provide duplicate data in the map that's computed differently, 3) update the old code to the new map. Here at work we have a 20 year old application that is almost 100% backwards compatible (the server can talk to much older clients). And it does so by using pure data. The server has setup contracts saying "this is what Project data looks like, this is what Company Data looks like" and those contracts never change. The 3D Software Blender (blender.org) operates on this same principle. After almost a decade, their latest software can open 1.0 .blend files, and vice versa. All these applications work off of unchanging data contracts. So I'm interested in seeing concrete examples of how your application differs. Timothy -- 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: Doseq, map-style
On Jun 18, 2012, at 2:09 AM, Christophe Grand wrote: On Sun, Jun 17, 2012 at 8:59 PM, Kurt Harriger wrote: > > Data structure is an implementation detail... >> > > It's not. Not in clojure. It is in OO, but clojure is not an OO language, > so it's not an implementation detail in clojure. > > > That is my point, representations SHOULD be considered implementation > details, because representations change... if you treat them as contracts > your code will break everywhere, if you wrap them with abstractions your > code will only need to change in one place... > Representations are values in Clojure, they are not mixed with behaviors like in mainstream OO. It follows that, if your representation need to change, you can write a converter function (or two if you want to convert from and to the old representation), that's easy, easier than writing an adapter class in Java because the adapter class must implement new behaviors on top of old ones (or the other way round). Isnt that just creating an api? Everywhere the old model exists you need to call a function to create the desired data structure and this adds another layer of complexity that needs maintained. Not all conversions are straight forward, may require additional context of whatever introducing the need for deferred computation. 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: meta-questions - [clojure] in front of Subject line
this is also true of the ActionScript solution... let's get back on topic, tabs or spaces? On Mon, Jun 18, 2012 at 9:02 AM, Tassilo Horn wrote: > Dave Kincaid writes: > > >> [Automatic insertion of [clojure] depending on user preference] > > > > Seems like a great enhancement that Google could make. Give each > > subscriber this as an option. Then each of us can choose whether to > > add this or not to messages we see. > > No, that's actually not a very good idea. As soon as you follow up to > some message, your personal preferences shine through for all to see. > > Re: [clojure] the real subject > > For me, it'll look like you've changed the subject (well, you actually > did). > > Bye, > Tassilo > > -- > 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: meta-questions - [clojure] in front of Subject line
Dave Kincaid writes: >> [Automatic insertion of [clojure] depending on user preference] > > Seems like a great enhancement that Google could make. Give each > subscriber this as an option. Then each of us can choose whether to > add this or not to messages we see. No, that's actually not a very good idea. As soon as you follow up to some message, your personal preferences shine through for all to see. Re: [clojure] the real subject For me, it'll look like you've changed the subject (well, you actually did). Bye, Tassilo -- 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
London Clojurians Talks & Dojos
Fellow Clojurians, The London Clojurians are starting a series of regular meetings (talks in addition to our usual dojos) in London to try to make it easier for people to come and visit us. Our talks will be on the 1st Tuesday of the month (3 July, 7 August, 4 September) Our next talk at Skill Matter is Functional Web Architecture with James Reeves on 3 July. The sign up is here: http://skillsmatter.com/event/ajax-ria/functional-web-architecture The dojos are on the *last* Tuesday of the month (31 July, 28 August, 25 September) URLs with sign ups will be announced on the London Clojurians google group and the main clojure google group. http://groups.google.com/group/london-clojurians/ https://groups.google.com/group/clojure/ Our calendar of events, including occasional hack days around the web, Incanter and Overtone is here: https://www.google.com/calendar/embed?src=otfrom.com_pkatmn3n1ff8l5bvls3cnc0...@group.calendar.google.com&ctz=Europe/London&gsessionid=OK I hope you all get a chance to come and visit us. We have a lot of fun and it is great when people come to visit. You can also keep up to date on our new web site. The URL for that is http://londonclojurians.org I hope I've given everyone enough URLs. ;-) cheers, Bruce -- CTO & co-founder @MastodonC mastodonc.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
Re: meta-questions - [clojure] in front of Subject line
Seems like a great enhancement that Google could make. Give each subscriber this as an option. Then each of us can choose whether to add this or not to messages we see. Personally, I only read these groups on the web and seeing [clojure] in the subject of every message would be really annoying. I already know I'm looking at the Clojure group. It's added noise that I really don't need. On Monday, June 18, 2012 7:42:29 AM UTC-5, Jay Fields wrote: > > Personally, I'd like to have [] as well, but I've recently been educated > on the opposing point of view - and I concede that your personal workflow > determines what you prefer - and, it's all preferences at the end of the > day (no right or wrong answer). My personal workflow would benefit from [], > Phil's wouldn't, there's not really much more to say about that. > > A possible compromise? - [clj] > > It's short, so it doesn't take up as much space for mobile readers, and > it's enough to note it's from a mailing list. > > On Mon, Jun 18, 2012 at 8:04 AM, Jim - FooBar(); wrote: > >> On 18/06/12 11:50, Lee Spector wrote: >> >> On Jun 18, 2012, at 3:02 AM, Tassilo Horn wrote: >> >> There's really no need to obscure subjects. For all your filtering >> needs, there's the List-ID header: >> >> List-ID: >> >> Here's a SIEVE snippet you can install somehow to your IMAP server to >> move messages to this list to some special group. (Most providers have a >> web GUI for easily writing such rules.) >> >> Sigh. >> >> I believe that the OP's interest (certainly mine in supporting him) was to >> have the list identified in the subject line so that we can see it, with our >> eyeballs, in the subject lines, in interfaces that list messages by subject. >> Like we can do with most other mailing lists, since including list names in >> subject lines is a pretty widely adopted practice. We know full well that >> the source of the message is available elsewhere in the header, and that >> this can be used to move messages (as I do for mail from various other >> lists, etc.), but the point isn't to move messages -- it is to have the list >> name actually in the subject. Depending on how you read your mail this can >> be handy. >> >> If most people are reading their email on tiny devices and the extra >> characters are really a hassle then fine, but all of these replies about >> ways to move messages are irrelevant. >> >> Sean Corfield's idea of using AppleScript to actually change the subject >> lines automatically IS to the point, although its almost comically >> complicated and this isn't a big enough deal for me to resort to that sort >> of duct tape and glue (although I appreciate the effort and the cleverness >> of the approach!). >> >> -Lee >> >> >> >> >> I do agree... every other mailing list I've subscribed to does >> this...even [ccw] does this...I was wondering a long time ago why this >> group doesn't do it...Personally I've learnt to filter clojure discussions >> by the *absence* of subject-line!!! >> >> Jim >> >> -- >> 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: meta-questions - [clojure] in front of Subject line
Personally, I'd like to have [] as well, but I've recently been educated on the opposing point of view - and I concede that your personal workflow determines what you prefer - and, it's all preferences at the end of the day (no right or wrong answer). My personal workflow would benefit from [], Phil's wouldn't, there's not really much more to say about that. A possible compromise? - [clj] It's short, so it doesn't take up as much space for mobile readers, and it's enough to note it's from a mailing list. On Mon, Jun 18, 2012 at 8:04 AM, Jim - FooBar(); wrote: > On 18/06/12 11:50, Lee Spector wrote: > > On Jun 18, 2012, at 3:02 AM, Tassilo Horn wrote: > > There's really no need to obscure subjects. For all your filtering > needs, there's the List-ID header: > > List-ID: > > Here's a SIEVE snippet you can install somehow to your IMAP server to > move messages to this list to some special group. (Most providers have a > web GUI for easily writing such rules.) > > Sigh. > > I believe that the OP's interest (certainly mine in supporting him) was to > have the list identified in the subject line so that we can see it, with our > eyeballs, in the subject lines, in interfaces that list messages by subject. > Like we can do with most other mailing lists, since including list names in > subject lines is a pretty widely adopted practice. We know full well that the > source of the message is available elsewhere in the header, and that this can > be used to move messages (as I do for mail from various other lists, etc.), > but the point isn't to move messages -- it is to have the list name actually > in the subject. Depending on how you read your mail this can be handy. > > If most people are reading their email on tiny devices and the extra > characters are really a hassle then fine, but all of these replies about ways > to move messages are irrelevant. > > Sean Corfield's idea of using AppleScript to actually change the subject > lines automatically IS to the point, although its almost comically > complicated and this isn't a big enough deal for me to resort to that sort of > duct tape and glue (although I appreciate the effort and the cleverness of > the approach!). > > -Lee > > > > > I do agree... every other mailing list I've subscribed to does this...even > [ccw] does this...I was wondering a long time ago why this group doesn't do > it...Personally I've learnt to filter clojure discussions by the *absence*of > subject-line!!! > > Jim > > -- > 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: meta-questions - [clojure] in front of Subject line
I'm wasn't saying filtering into folders was superior, I was saying having the option to filter by sender was superior to merely having the option to filter by subject. But it sounds like you already have the option, and that just isn't your workflow. Sorry that I misunderstood. I don't read the messages in a folder, I primarily follow the list from my BlackBerry and the messages can be viewed mixed into my global or individual inbox depending on my entry point. My gmail rule auto labels and archives the messages so I don't have to deal with them twice. -Original Message- From: Brian Marick Sender: clojure@googlegroups.com Date: Sun, 17 Jun 2012 23:31:22 To: Reply-To: clojure@googlegroups.com Subject: Re: meta-questions - [clojure] in front of Subject line On Jun 17, 2012, at 7:23 PM, Peter Buckley wrote: > I know mac products are designed for non-technical people and leave out most > common options, but can't they do something so simple and 1980's-esque as > filter on a field other than subject? > > I've been using gmail and have had a rule for the clojure group since I > signed up. I expect most other folks are likewise all set. No need to > inconvenience the N>>1 people who chose to use superior technology. I sent my first email 35 years ago. I know about filtering into folders. I find it suboptimal for mailing lists I want to follow closely. I'm annoyed that you say filtering into folders is "superior". It's a choice you make, a choice that is not prevented by a subject-line tag that helps people who make a different choice. If you're reading with gmail folders, your objection to the proposed change is aesthetic. My objection to the current change is functional. In something as mundane as email, I privilege the functional over the aesthetic. The complaint about reading the mailing list on phones is valid. I do wonder how many people use phones as their main, workaday interface, and how much an extra inconvenience 9 characters is when they're already trying to view the world through a keyhole. - Brian Marick, Artisanal Labrador Now working at http://path11.com Contract programming in Ruby and Clojure Occasional consulting on Agile -- 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: How to speed up Clojure Training for New Recruitment
Thanks Bill !! On Monday, June 18, 2012 5:19:06 PM UTC+5:30, Bill Caputo wrote: > > > On Jun 18, 2012, at 6:37 AM, Murtaza Husain wrote: > > > Bill that is very interesting. So how do you make them learn. > > Haha, I don't make anyone do *anything* on my team (I'm not exaggerating). > My first (and more or less last) directive as team-lead is to declare it a > team of peers. We ask people to join us who want to do what's needed for us > to succeed. At most we will explain that the team uses clojure (and > javascript and ruby, and something new when we need it) and if they aren't > *eager* to learn new things to solve problems (and that's obvious in about > 30 seconds of interviewing), there's no point in wasting our time. > > > Do you pair them up with someone who knows on some task? I mean how do > you structure learning ? > > If this stuff was reducible to rules, you wouldn't need learners, you > could do the whole training bit - maybe even write a program to write code > for you. Hire people who like to learn, put them on the team. That's it. > The team figures it out from there (i.e. different in each case, based on > personalities, languages, tasks, goals, current deadlines, etc.) > > > Bcoz as you mentioned that put them into a team where everyone likes to > share, however everyone may be working on things above them, > > If getting this person up to speed is important for team's success, there > is nothing above them... there is only velocity. If velocity is more > important than learning, the ramp-up time will be longer... if the wider > organization values speed over competence, you'll get shitty code (that's > not a learning clojure issue). > > > and they may not be able to grasp, and they may also not have time. > > If either of these are true - and we made the mistake of asking them to > join our team - they wouldn't be around long enough for it to matter. > > bill > > > -- 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/java.jdbc: MySQL problem "NoRouteToHostException Cannot assign requested address"
Ok, I found the problem. It's not related to the Clojure JDBC API, but to the number of ports opened on localhost in a very short period of time. Linux has a TIME_WAIT configuration for connections opened, and default TIME_WAIT period is set to 60s. The maximum number of open connections is limited on a system, and if within a minute to many connections are made to a machine, the TIME_WAIT setting can block any new connections to the system. I could work around this problem by setting net.ipv4.tcp_tw_recycle=1 in /etc/sysctl.conf, but that setting might cause TCP problems as I've read. With that setting, inserting 100.000 items into the table just ran through without any problems/exceptions. Here's a blog post describing some performance tuning settings for Ubuntu, for anyone running into a similar problem: http://samiux.blogspot.de/2011/04/howto-performance-tuning-on-ubuntu.html Or just use c3p0 with clojure.java.jdbc. - Raju -- 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: meta-questions - [clojure] in front of Subject line
On 18/06/12 11:50, Lee Spector wrote: On Jun 18, 2012, at 3:02 AM, Tassilo Horn wrote: There's really no need to obscure subjects. For all your filtering needs, there's the List-ID header: List-ID: Here's a SIEVE snippet you can install somehow to your IMAP server to move messages to this list to some special group. (Most providers have a web GUI for easily writing such rules.) Sigh. I believe that the OP's interest (certainly mine in supporting him) was to have the list identified in the subject line so that we can see it, with our eyeballs, in the subject lines, in interfaces that list messages by subject. Like we can do with most other mailing lists, since including list names in subject lines is a pretty widely adopted practice. We know full well that the source of the message is available elsewhere in the header, and that this can be used to move messages (as I do for mail from various other lists, etc.), but the point isn't to move messages -- it is to have the list name actually in the subject. Depending on how you read your mail this can be handy. If most people are reading their email on tiny devices and the extra characters are really a hassle then fine, but all of these replies about ways to move messages are irrelevant. Sean Corfield's idea of using AppleScript to actually change the subject lines automatically IS to the point, although its almost comically complicated and this isn't a big enough deal for me to resort to that sort of duct tape and glue (although I appreciate the effort and the cleverness of the approach!). -Lee I do agree... every other mailing list I've subscribed to does this...even [ccw] does this...I was wondering a long time ago why this group doesn't do it...Personally I've learnt to filter clojure discussions by the *absence* of subject-line!!! Jim -- 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/java.jdbc: MySQL problem "NoRouteToHostException Cannot assign requested address"
Thanks, Sean, here's simplified test which shows the behavior:
Project dependencies:
:dependencies [[org.clojure/clojure "1.3.0"]
[org.clojure/java.jdbc "0.2.2"]
[mysql/mysql-connector-java "5.1.6"]
Code:
(ns jdbc-test.core
(:require [clojure.java.jdbc :as sql])
(:import (java.text SimpleDateFormat)
(java.util Date)))
;; MySQL connection configuration
(def mysql-db
{:classname "com.mysql.jdbc.Driver"
:subprotocol "mysql"
:user "root"
:password "root"
:subname "//localhost/clojurejdbc"})
;; Table definition
(defn add-row-to-table
[label datetime]
(sql/with-connection mysql-db
(sql/insert-records :inserttest
{:id 0 :label label :created datetime})))
(defn generate-entries
[no]
(let [date-formatter (SimpleDateFormat. "-MM-dd HH:mm:ss")]
(loop [counter 1
datetime (.format date-formatter (Date.))]
(if (= 0 (mod counter 1000))
(println (str counter " rows added")))
(add-row-to-table (str "Line #" counter) datetime)
(if (< counter no)
(recur (inc counter) datetime)
The MySQL database and table definition:
CREATE DATABASE clojurejdbc;
USE clojurejdbc;
CREATE TABLE inserttest (
id INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY (id),
label CHAR(255),
created DATETIME
);
I call the function generate-entries like this:
(generate-entries 100)
On my machine, the program stops after 34000+ rows have been added to the table:
...
32000 rows added
33000 rows added
34000 rows added
NoRouteToHostException Cannot assign requested address
java.net.PlainSocketImpl.socketConnect (PlainSocketImpl.java:-2)
The problem is probably the high number of connections kept open to
the localhost port, but that's just a guess:
http://stackoverflow.com/questions/1572215/how-to-avoid-a-noroutetohostexception
"netstat -a" shows a lot of TIME_WAIT entries
tcp0 0 localhost:mysql *:* LISTEN
tcp0 0 localhost:mysql localhost:46850 TIME_WAIT
tcp0 0 localhost:mysql localhost:46737 TIME_WAIT
tcp0 0 localhost:mysql localhost:46340 TIME_WAIT
(long list continued)
So this is not Clojure/JDBC specific, but a general problem with Java
and MySQL executing many queries to localhost. I'll investigate more
later.
Thanks,
Raju
--
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: How to speed up Clojure Training for New Recruitment
On Jun 18, 2012, at 6:37 AM, Murtaza Husain wrote: > Bill that is very interesting. So how do you make them learn. Haha, I don't make anyone do *anything* on my team (I'm not exaggerating). My first (and more or less last) directive as team-lead is to declare it a team of peers. We ask people to join us who want to do what's needed for us to succeed. At most we will explain that the team uses clojure (and javascript and ruby, and something new when we need it) and if they aren't *eager* to learn new things to solve problems (and that's obvious in about 30 seconds of interviewing), there's no point in wasting our time. > Do you pair them up with someone who knows on some task? I mean how do you > structure learning ? If this stuff was reducible to rules, you wouldn't need learners, you could do the whole training bit - maybe even write a program to write code for you. Hire people who like to learn, put them on the team. That's it. The team figures it out from there (i.e. different in each case, based on personalities, languages, tasks, goals, current deadlines, etc.) > Bcoz as you mentioned that put them into a team where everyone likes to > share, however everyone may be working on things above them, If getting this person up to speed is important for team's success, there is nothing above them... there is only velocity. If velocity is more important than learning, the ramp-up time will be longer... if the wider organization values speed over competence, you'll get shitty code (that's not a learning clojure issue). > and they may not be able to grasp, and they may also not have time. If either of these are true - and we made the mistake of asking them to join our team - they wouldn't be around long enough for it to matter. bill -- 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: How to speed up Clojure Training for New Recruitment
Bill that is very interesting. So how do you make them learn. Do you pair them up with someone who knows on some task? I mean how do you structure learning ? Bcoz as you mentioned that put them into a team where everyone likes to share, however everyone may be working on things above them, and they may not be able to grasp, and they may also not have time. On Monday, June 18, 2012 5:01:45 PM UTC+5:30, Bill Caputo wrote: > > > On Jun 18, 2012, at 2:11 AM, Murtaza Husain wrote: > > > Hi, > > > > Just wanted to get pointers on how do you manage the training of > recruits. It is difficult to find clojure talent, > > I don't hire based on knowledge, I hire based on ability/desire to > *learn*. For senior people I also want the same ability/desire to share > what they've learned with others. > > > How can the learning curve, and training time be reduced for new > recruits ? > > Put them on teams full of people who like to learn and to teach and tell > them their 1st job is to learn, not to ship code so get cracking. Oh, and I > also believe training is mostly a waste of resources. Training is pushing > information. Learning is a self-directed activity. I look for people who > would be bored stiff in training (a good sign is if they work ahead of the > trainer and otherwise "break" the class). > > > Also how do you pitch it to the management ? > > Point out how well the other ways have been working out for the industry. > > bill -- 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: How to speed up Clojure Training for New Recruitment
On Jun 18, 2012, at 2:11 AM, Murtaza Husain wrote: > Hi, > > Just wanted to get pointers on how do you manage the training of recruits. It > is difficult to find clojure talent, I don't hire based on knowledge, I hire based on ability/desire to *learn*. For senior people I also want the same ability/desire to share what they've learned with others. > How can the learning curve, and training time be reduced for new recruits ? Put them on teams full of people who like to learn and to teach and tell them their 1st job is to learn, not to ship code so get cracking. Oh, and I also believe training is mostly a waste of resources. Training is pushing information. Learning is a self-directed activity. I look for people who would be bored stiff in training (a good sign is if they work ahead of the trainer and otherwise "break" the class). > Also how do you pitch it to the management ? Point out how well the other ways have been working out for the industry. bill -- 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: meta-questions - [clojure] in front of Subject line
On Jun 18, 2012, at 3:02 AM, Tassilo Horn wrote: > > There's really no need to obscure subjects. For all your filtering > needs, there's the List-ID header: > > List-ID: > > Here's a SIEVE snippet you can install somehow to your IMAP server to > move messages to this list to some special group. (Most providers have a > web GUI for easily writing such rules.) Sigh. I believe that the OP's interest (certainly mine in supporting him) was to have the list identified in the subject line so that we can see it, with our eyeballs, in the subject lines, in interfaces that list messages by subject. Like we can do with most other mailing lists, since including list names in subject lines is a pretty widely adopted practice. We know full well that the source of the message is available elsewhere in the header, and that this can be used to move messages (as I do for mail from various other lists, etc.), but the point isn't to move messages -- it is to have the list name actually in the subject. Depending on how you read your mail this can be handy. If most people are reading their email on tiny devices and the extra characters are really a hassle then fine, but all of these replies about ways to move messages are irrelevant. Sean Corfield's idea of using AppleScript to actually change the subject lines automatically IS to the point, although its almost comically complicated and this isn't a big enough deal for me to resort to that sort of duct tape and glue (although I appreciate the effort and the cleverness of the approach!). -Lee -- 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: How to speed up Clojure Training for New Recruitment
When it comes to new graduates, they'll probably latch onto Clojure just as quickly as to Java or anything else. At EuroClojure, Jon Pither and Hakan Raberg mentioned that in their mixed Java/Clojure ecosystem they train new hires on Clojure, which eventually makes them better Java programmers! Cheers, Chris On 18 June 2012 08:11, Murtaza Husain wrote: > Hi, > > Just wanted to get pointers on how do you manage the training of recruits. > It is difficult to find clojure talent, and we are located in India, where > it is close to impossible. Also the non availability of talent becomes a > hard sell to management too while introducing clojure projects. How can the > learning curve, and training time be reduced for new recruits ? Also how do > you pitch it to the management ? > > Thanks, > Murtaza > > > > -- > 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: Doseq, map-style
On Sun, Jun 17, 2012 at 8:59 PM, Kurt Harriger wrote: > > Data structure is an implementation detail... >> > > It's not. Not in clojure. It is in OO, but clojure is not an OO language, > so it's not an implementation detail in clojure. > > > That is my point, representations SHOULD be considered implementation > details, because representations change... if you treat them as contracts > your code will break everywhere, if you wrap them with abstractions your > code will only need to change in one place... > Representations are values in Clojure, they are not mixed with behaviors like in mainstream OO. It follows that, if your representation need to change, you can write a converter function (or two if you want to convert from and to the old representation), that's easy, easier than writing an adapter class in Java because the adapter class must implement new behaviors on top of old ones (or the other way round). 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
How to speed up Clojure Training for New Recruitment
Hi, Just wanted to get pointers on how do you manage the training of recruits. It is difficult to find clojure talent, and we are located in India, where it is close to impossible. Also the non availability of talent becomes a hard sell to management too while introducing clojure projects. How can the learning curve, and training time be reduced for new recruits ? Also how do you pitch it to the management ? Thanks, Murtaza -- 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: meta-questions - [clojure] in front of Subject line
Brian Marick writes:
>> I have been subscribed to a couple of groups as well as other stuff
>> and find it useful to have a Subject line prefix indicating the
>> source of conversation.
>
> +1
-1!
There's really no need to obscure subjects. For all your filtering
needs, there's the List-ID header:
List-ID:
Here's a SIEVE snippet you can install somehow to your IMAP server to
move messages to this list to some special group. (Most providers have a
web GUI for easily writing such rules.)
if header :contains ["List-ID"] "" {
fileinto "INBOX.mailinglists.clojure"; # whatever you like
stop;
}
Bye,
Tassilo
--
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
