Re: clojure.contrib.sql = clojure.java.jdbc - looking for feedback!
On Fri, Apr 22, 2011 at 10:32 PM, Shantanu Kumar kumar.shant...@gmail.com wrote: Listed below: Thank you! 1. Allow _ (underscore) in field names This already seems to work. I just tested the following - can you elaborate: (deftest test-create (jdbc/with-connection (worldsingles-db) (jdbc/create-table :jdbcTestTable [:id :int] [:name_first varchar(32)] [name_last varchar(32)]))) It created the following table: mysql desc jdbcTestTable; ++-+--+-+-+---+ | Field | Type| Null | Key | Default | Extra | ++-+--+-+-+---+ | id | int(11) | YES | | NULL| | | name_first | varchar(32) | YES | | NULL| | | name_last | varchar(32) | YES | | NULL| | ++-+--+-+-+---+ 3 rows in set (0.00 sec) I agree that translating - / _ would be more idiomatic. I'm not sure it needs to be more sophisticated than that tho'... 2. Provide a mechanism to show the SQL being executed (configurable, so that it can be turned off) Good idea. Even better, a way to access statistics about the prepared statement after execution - timing etc? 3. Allow users to flexibly convert from Clojure name to DB entity name Right now you can specify :name or name in arguments. Records come back with entity names as keywords. Could you elaborate on what you'd want to see here, beyond the - / _ translation mentioned above? 4. Allow users to flexibly convert from DB entity name to Clojure name (this affects resultset-seq) As per 3. could you give an example use case? I saw what your library provides but I'm not entirely sure how many folks would need that flexibility. What do others think? 5. Provide a mode to prevent write operations Interesting idea but isn't that better handled by grants on the user accessing the database? 6. An INSERT function that returns the generated key(s) The current clojure.java.jdbc does this (I added a first cut of it as part of the initial new version but it needs some streamlining). I was disappointed the original c.c.sql just returned nil from insert operations so I changed it to return a sequence of vector pairs containing update counts and the resultset-seq map from the generated keys. It's ugly right now so I'm looking for input there. * Do we need the update counts? * Do we need the map? * Or just the key values? * For multiple inserts, do we want to return a sequence of generated keys, one per insert? * Should there be a specific method to insert (one set of values | one record) that returns keys? * Or should it simply default to that for insert operations that have a (single set of values | single record). My personal feeling is that it should return just the key values, in a vector, one per inserted record, with an option to turn it off, per insert operation). Maybe as a convenience, if you only insert one record, you get back just a key, rather than a vector of one key? 7. The function for creating tables is non-portable across databases -- make it known in the docstring Or work hard to make it more portable :) To me, a bigger problem is that c.j.j doesn't strop the entity names so you can't have, e.g., columns named like SQL keywords. That will definitely get fixed because the application I'm working on has such column names. Of course stropping varies across database vendors... I am sure others will have additional points to share. I would suggest the configuration aspect be split into a separate library from c.c.sql. Even more importantly, I think it needs a certain degree of incubation before being promoted to clojure.java.jdbc. Could you elaborate on the deficiencies you see in the configuration part of c.j.j? I think your library provides some nice syntactic sugar on creating the DB spec but since most projects do it only once per application, I'm not sure that needs to be in standard library? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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: closed maps / reducing runtime errors due to mistyped keywords
Thanks for all of your answers, but I think for my use cases the approach proposed by Justin looks most promising. I'll implement my own closed map. Another idea that come to my mind was that a closed map is actually a Java Bean without behaviour. Perhaps the closed map could be implemented by dynamically creating an immutable bean at run-time somehow along the lines of this article: http://blogs.sun.com/adventures/entry/dynamic_java_beans The advantage would be that other JVM languages could more easily take advantage of such objects, e.g. rule engines like drools or complex even processing engines like esper. Are there any disadvantages you would see? I would imagine that clojure's compiler already has most of what is needed for such an approach. Could somebody give me a good entry point where to start my analysis of the clojure internals to create dynamically beans at runtime? In the past clojure seems to have had a gen-and-load-class feature, which disappeared. I could not find references that would explain the reasons why it was taken out. The following post from 2008 basically would already do what I have in mind but it uses the gen-and-load-class feature: http://groups.google.com/group/clojure/browse_thread/thread/79e4cb66a05c8ce9 -- 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: Feedback Request
Cool. Have you seen https://github.com/stuartsierra/cljque ? They might be nice to use with Swing events. I figured you could turn a string into a label, button or textbox depending on if it's wrapped in an atom, observer or not at all. But that is just more blabla, I need to make some time to look at the source and try some stuff myself. On Apr 19, 6:20 pm, Dave Ray dave...@gmail.com wrote: Thanks. At the moment Seesaw has a ToWidget protocol which it uses to implicitly convert things to Swing components (String - JLabel, Action - JButton, etc). So it should be pretty extensible beyond the default conversions that are supplied. Dave On Tue, Apr 19, 2011 at 10:41 AM, pepijn (aka fliebel) pepijnde...@gmail.com wrote: I'll look at it more closely later, but the idea of a Swing wrapper DSL is awesome. It occurred to me that Lisp is data as code, and that every object can transform itself into something printable (toString). So why don't objects support toSwing? With the aid of metadata, I'm sure it could work. On Apr 19, 12:57 am, Dave Ray dave...@gmail.com wrote: Hi, For the last few weeks, I've been working on a Clojure Swing wrapper called Seesaw. I've learned a lot about Clojure so far, but I think it's time to ask for some feedback. If I wait 'til it's perfect or complete, ... well, then no one would ever hear from me. The code can be found on github here: https://github.com/daveray/seesaw I guess I'm looking for two kinds of feedback: 1) Is something like this useful or interesting to anybody? As someone who spends a lot of time programming Swing, it's useful to me, but if some tweaks or changes would help others, I'd like to know. 2) How bad am I abusing Clojure and what could I do to improve it? It's not particularly functional, but I'm currently using Swing's insanely imperative style as an excuse for that. Thanks! Dave -- 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.contrib.sql = clojure.java.jdbc - looking for feedback!
1. Allow _ (underscore) in field names
This already seems to work. I just tested the following - can you elaborate:
Yes, I tested this and it seems to work now. Not sure where I noticed
earlier where it was not working. My bad.
I agree that translating - / _ would be more idiomatic. I'm not sure
it needs to be more sophisticated than that tho'...
2. Provide a mechanism to show the SQL being executed (configurable,
so that it can be turned off)
Good idea. Even better, a way to access statistics about the prepared
statement after execution - timing etc?
Yes, that would be an add-on value to show how are the queries
performing.
3. Allow users to flexibly convert from Clojure name to DB entity name
Right now you can specify :name or name in arguments. Records come
back with entity names as keywords. Could you elaborate on what you'd
want to see here, beyond the - / _ translation mentioned above?
4. Allow users to flexibly convert from DB entity name to Clojure name
(this affects resultset-seq)
As per 3. could you give an example use case? I saw what your library
provides but I'm not entirely sure how many folks would need that
flexibility. What do others think?
Some databases (under certain configuration) work only with case-
sensitive entity names. Converting them to all lowercase breaks under
those situations. Also see related problems reported by others:
http://osdir.com/ml/clojure/2010-10/msg00290.html (sorry, can't find
it on the group.)
5. Provide a mode to prevent write operations
Interesting idea but isn't that better handled by grants on the user
accessing the database?
The intention here is to proactively prevent errors from a development
standpoint. And then, some databases do not support permissions --
however, the notion of read-only vs writes is common in database
development and can be useful to have.
6. An INSERT function that returns the generated key(s)
The current clojure.java.jdbc does this (I added a first cut of it as
part of the initial new version but it needs some streamlining). I was
disappointed the original c.c.sql just returned nil from insert
operations so I changed it to return a sequence of vector pairs
containing update counts and the resultset-seq map from the generated
keys. It's ugly right now so I'm looking for input there.
* Do we need the update counts?
* Do we need the map?
* Or just the key values?
* For multiple inserts, do we want to return a sequence of generated
keys, one per insert?
* Should there be a specific method to insert (one set of values | one
record) that returns keys?
* Or should it simply default to that for insert operations that have
a (single set of values | single record).
My personal feeling is that it should return just the key values, in a
vector, one per inserted record, with an option to turn it off, per
insert operation). Maybe as a convenience, if you only insert one
record, you get back just a key, rather than a vector of one key?
Some databases allow multiple auto-generated columns in a table.
Inserts to such tables generates multiple keys - it probably makes
sense to return them as a map. So, my suggestion: return a map {column
= generated-value} per `insert`, and for `update-or-insert` it should
return just an empty map {} when it's actually an update. Again, batch-
inserts do not return generated keys on all JDBC drivers (notable
exception is MySQL, on which it does).
7. The function for creating tables is non-portable across databases
-- make it known in the docstring
Or work hard to make it more portable :)
How? :) Lowest common-denominator is not what a customer would pay the
database vendor for, and it's difficult to incorporate syntaxes for
major-if-not-all databases (which would still be non-portable).
Probably a reasonable set of types that map respectively to different
databases? What about indexes, primary keys, constraints etc? This
calls for a separate, dedicated library IMHO.
I am sure others will have additional points to share. I would suggest
the configuration aspect be split into a separate library from
c.c.sql. Even more importantly, I think it needs a certain degree of
incubation before being promoted to clojure.java.jdbc.
Could you elaborate on the deficiencies you see in the configuration
part of c.j.j? I think your library provides some nice syntactic sugar
on creating the DB spec but since most projects do it only once per
application, I'm not sure that needs to be in standard library?
The point here is to setup a generic configuration mechanism for
database libraries beyond c.j.j so that they can hook up their own
functions and intercept when necessary. As long as the configuration
can be contained in a map, I think it can serve libraries as well. Not
sure if the configuration mechanism should always be accompanied with
c.j.j hence my suggestion -- please consider it more of food for
thought rather than recommendation.
Start Clojure programs from Eclipse
Hi, I would like to start two progams from Eclipse. One is a server and the other one is a client. I use Load Clojure file in REPL from Eclipse menu. When I start the server it never ends because the server has endless loop where it waits for clients. Now when I start the client programs it never evaluates because REPL is busy with server program. I suppose it works as I described. Maybe I am wrong I am not sure. Any ideas to overcame this situation are welcome. Thanks Zlaja -- 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: Start Clojure programs from Eclipse
Sorry. My oversight. Run as from menu works just fine. Zlaja On Sat, Apr 23, 2011 at 11:12 AM, Zlatko Josic zlatko.jo...@gmail.comwrote: Hi, I would like to start two progams from Eclipse. One is a server and the other one is a client. I use Load Clojure file in REPL from Eclipse menu. When I start the server it never ends because the server has endless loop where it waits for clients. Now when I start the client programs it never evaluates because REPL is busy with server program. I suppose it works as I described. Maybe I am wrong I am not sure. Any ideas to overcame this situation are welcome. Thanks Zlaja -- 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: Two types of special symbol
Thanks -- interesting, especially the bit about the design notes on a compiler rewrite. On Thu, Apr 21, 2011 at 22:23, Kevin Downey redc...@gmail.com wrote: the current compiler doesn't namespace qualify special forms (forms which are built into the compiler) but somethings that the documentation lists as special forms are infact macros defined in clojure.core based on the real special forms provided by the compiler. macros are namespace qualified so unless you use the fully qualified name(clojure.core/let) or :use/use them then they aren't available. this difference is kind of unfortunate, and the design notes on a compiler rewrite mention changing things so the forms directly supported by the compiler are also namespace qualified and live in clojure.core On Thu, Apr 21, 2011 at 12:24 PM, Simon Katz nomisk...@gmail.com wrote: Hi. (In case it makes a difference, I'm using Clojure 1.2.) If one creates a new namespace using in-ns, the new namespace does not refer to clojure.core, as explained at http://clojure.org/namespaces. I noticed one can use certain special forms in a namespace created using in-ns, but not others: _ | | user (in-ns 'my-new-ns) | #Namespace my-new-ns | | my-new-ns (quote a) | a | | my-new-ns (def x 42) | #'my-new-ns/x | | my-new-ns (let [a 42] a) | ;; Evaluation aborted. Unable to resolve symbol: let in this context | | my-new-ns (fn [] 42) | ;; Evaluation aborted. Unable to resolve symbol: fn in this context |_ That puzzled me. In the process of trying to understand, I came across a mention of clojure.lang.Compiler/specials (a map with symbols as its keys) at http://stackoverflow.com/questions/3159836/is-there-a-way-to-get-a-collection-of-clojure-special-forms-programatically _ | | user (keys clojure.lang.Compiler/specials) | ;; = (deftype* new quote var set! monitor-enter recur . |case* clojure.core/import* reify* do fn* throw |monitor-exit letfn* finally let* loop* try catch if |def) |_ So it seems that there are two kinds of special symbol. I'll refer to them as implementation specials and documented specials: - implementation specials those that are keys in the clojure.lang.Compiler/specials map - documented specials those that are documented as being special at http://clojure.org/special_forms. (Note that some symbols are of both kinds.) I assume that documented specials that are not implementation specials are implemented as macros. (And the post I mentioned above at stackoverflow.com says so.) Here's some investigation of these two kinds of special symbol: _ | | user (def implementation-specials |(keys clojure.lang.Compiler/specials)) | #'user/implementation-specials | | user (def documented-specials |'(def if do let quote var fn loop recur throw try | monitor-enter monitor-exit . new set!)) | #'user/documented-specials | | user (defn symbol-info [symbol] | [(special-symbol? symbol) | (= (resolve symbol) nil) | symbol]) | #'user/symbol-info | | user (pprint (map symbol-info implementation-specials)) | ([true true deftype*] | [true true new] | [true true quote] | [true true ] | [true true var] | [true true set!] | [true true monitor-enter] | [true true recur] | [true true .] | [true true case*] | [true true clojure.core/import*] | [true true reify*] | [true true do] | [true true fn*] | [true true throw] | [true true monitor-exit] | [true true letfn*] | [true true finally] | [true true let*] | [true true loop*] | [true true try] | [true true catch] | [true true if] | [true true def]) | nil | | user (pprint (map symbol-info documented-specials)) | ([true true def] | [true true if] | [true true do] | [false false let] | [true true quote] | [true true var] | [false false fn] | [false false loop] | [true true recur] | [true true throw] | [true true try] | [true true monitor-enter] | [true true monitor-exit] | [true true .] | [true true new] | [true true set!]) | nil |_ There are a few interesting things here: - special-symbol? returns true for implementation specials (actually not surprising when you look at the implementation of special-symbol?, but perhaps surprising if you have only read http://clojure.org/namespaces and the documentation of special-symbol? which says Returns true if [the argument] names a special form). - Calling resolve on an implementation special gives nil. - In a namespace created using
Re: Emacs 23 issues.
Thanks a lot Vincent. At least now I can run Emacs with Clojure, otherwise I was stuck at the very first step :) Thx again. Manoj. On Apr 21, 8:06 pm, Vincent Liard vincent.li...@free.fr wrote: Hi Manoj, unreadable message: (:emacs-rex (swank:autodoc (quote (d swank:: %cursor-marker%)) :print-right-margin 132) user :repl-thread 4) exception in read loop java.lang.RuntimeException: java.lang.Exception: Invalid token: swank:: I have experienced a similar (or the same) problem. I can't find back the appropriate reference, but there is a bug with autodoc in swank-clojure. Try adding (setq slime-use-autodoc-mode nil) to your .emacs Vincent -- 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: Start Clojure programs from Eclipse
On Sat, Apr 23, 2011 at 5:12 AM, Zlatko Josic zlatko.jo...@gmail.com wrote: Hi, I would like to start two progams from Eclipse. One is a server and the other one is a client. I use Load Clojure file in REPL from Eclipse menu. When I start the server it never ends because the server has endless loop where it waits for clients. Now when I start the client programs it never evaluates because REPL is busy with server program. I suppose it works as I described. Maybe I am wrong I am not sure. Any ideas to overcame this situation are welcome. Have the server spawning function (or both, if the client is GUI) just start a separate thread and immediately return. (In fact, servers normally are multithreaded anyway, aren't they, to be able to handle multiple concurrent incoming requests.) -- 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.contrib.sql = clojure.java.jdbc - looking for feedback!
One snag I ran into recently with c.c.sql: it creates structmaps for returning query results, which means you can't subsequently dissoc one of the keys without converting to a regular map. In general, c.c.sql is inconsistent about using tuples of column values versus maps of column=value pairs. Both are useful, and I'd like to see versions of all the core functions that support both modes. Thanks for taking this on! -Stuart Sierra clojure.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: clojure.contrib.sql = clojure.java.jdbc - looking for feedback!
I'm going to be working on clojure.java.jdbc, with Steve Gilardi, and I'd like to get people's feedback on what you like / what you don't like / what you need changed or added in clojure.contrib.sql so that clojure.java.jdbc can become what the community wants for 1.3.0. What I would like to see added is a global connection mechanism like in ClojureQL and Lobos. We could even add a connection pool behind the scene. Then there's support for quoted identifiers, maybe something like: (with-quoted-identifiers \ ...) And for qualified identifiers we could let c.j.j accept vectors of identifiers so that [:some_schema :a_table] would become some_schema.a_table. I could provide an implementation if you'd like. -- 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
Aw: Re: Emacs 23 issues.
Hi, the problem is, that Clojure does not accept the symbol name %cursor-marker% while common lisp does. The autodoc feature of slime uses that symbol to tell the backend where the cursor was when the user asked for completion or documentation. There was a long discussion on the SLIME mailing list quite some while ago. IIRC the name of the thread was something like SLIME REPL broken. Regards, Stefan -- 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 performance optimization
Hi, all I fix some discussed details. Please review my code at https://github.com/mgoblin/GCS-puzzles/wiki/42-puzzle -- 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.contrib.sql = clojure.java.jdbc - looking for feedback!
I've added an issue for getting access to generated SQL and possibly
execution statistics.
On Sat, Apr 23, 2011 at 1:38 AM, Shantanu Kumar
kumar.shant...@gmail.com wrote:
Some databases (under certain configuration) work only with case-
sensitive entity names. Converting them to all lowercase breaks under
those situations.
It might have converted entities to lowercase at some point but it
doesn't seem to now, at least as far as the SQL is concerned - but see
next comment.
Also see related problems reported by others:
http://osdir.com/ml/clojure/2010-10/msg00290.html (sorry, can't find
it on the group.)
Yes, resultset-seq does lowercase the column names and it doesn't
translate between - / _ either. But that's not part of c.j.j so,
whilst I may agree with the criticisms of it, I can't actually fix
that :)
Perhaps someone from Clojure/core could speak to resultset-seq's behavior?
Some databases allow multiple auto-generated columns in a table.
Inserts to such tables generates multiple keys - it probably makes
sense to return them as a map. So, my suggestion: return a map {column
= generated-value} per `insert`, and for `update-or-insert` it should
return just an empty map {} when it's actually an update.
The current c.j.j behavior is to return a seq of vectors; each vector
contains the update count and, if 0, a map of the generated keys. If
I restrict returning generated keys to single inserts, then I can just
return a map of keys. If I allow for multiple inserts, I have to keep
the update counts because if one of the set of inserts does not
generate keys, you would need a way to detect that. Overall, I think
simplicity leans toward only returning generated keys, as a simple
map, for a single insert operation.
Then the only question is whether inserts should automatically attempt
to return a map of generated keys when there is a single insert. I'd
lean to making that the default and, if people care, providing an
optional argument to suppress it. Thoughts?
7. The function for creating tables is non-portable across databases
-- make it known in the docstring
Or work hard to make it more portable :)
How? :) Lowest common-denominator is not what a customer would pay the
database vendor for, and it's difficult to incorporate syntaxes for
major-if-not-all databases (which would still be non-portable).
Well, create-table does minimal transformation on its arguments so you
can specify:
(create-table adminUser
[
[id int(11) not null auto_increment]
...
[primary key (id)]])
And that will generate:
CREATE TABLE adminUser (
id int(11) not null auto_increment,
...,
primary key (id)
)
What you cannot do is provide any options after the columns specs -
that's definitely a weakness. I've added an issue for that.
I'd definitely be interested in suggestions for cleaner ways to
specify column specs (although I'm more concerned with general queries
than DDL operations).
Probably a reasonable set of types that map respectively to different
databases? What about indexes, primary keys, constraints etc? This
calls for a separate, dedicated library IMHO.
It may be a good idea to separate out the DDL operations into a
sub-library. Thoughts from others? clojure.java.jdbc.ddl perhaps?
The point here is to setup a generic configuration mechanism for
database libraries beyond c.j.j so that they can hook up their own
functions and intercept when necessary. As long as the configuration
can be contained in a map, I think it can serve libraries as well. Not
sure if the configuration mechanism should always be accompanied with
c.j.j hence my suggestion -- please consider it more of food for
thought rather than recommendation.
If such a mechanism were added for c.j.j, I think it would have to be
in effect for resultset-seq too since one of the behaviors I think
people will want to modify is the mapping to / from entity names,
right?
I guess I need to see a more concrete example before I really grok
what you're suggesting here.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.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.contrib.sql = clojure.java.jdbc - looking for feedback!
On Sat, Apr 23, 2011 at 10:01 AM, Stuart Sierra the.stuart.sie...@gmail.com wrote: One snag I ran into recently with c.c.sql: it creates structmaps for returning query results, which means you can't subsequently dissoc one of the keys without converting to a regular map. That's down to resultset-seq - should c.j.j stop relying on that function and have its own, more flexible version? In general, c.c.sql is inconsistent about using tuples of column values versus maps of column=value pairs. Both are useful, and I'd like to see versions of all the core functions that support both modes. I agree. As I was working with the functions early on I bumped into that a few times. I'll have a think about how to make that more consistent and ask for feedback on it. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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.contrib.sql = clojure.java.jdbc - looking for feedback!
On Sat, Apr 23, 2011 at 10:13 AM, Nicolas Buduroi nbudu...@gmail.com wrote: What I would like to see added is a global connection mechanism like in ClojureQL and Lobos. We could even add a connection pool behind the scene. Thanx. I'll take a look at those. Then there's support for quoted identifiers, maybe something like: Agreed. And for qualified identifiers we could let c.j.j accept vectors of identifiers so that [:some_schema :a_table] would become some_schema.a_table. Should [:some-schema :a-table] become some_schema.a_table? How do people want to handle mixed case entity names? Do we want something like Hibernate Naming Strategies? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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: Start Clojure programs from Eclipse
On 23 April 2011 17:31, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 5:12 AM, Zlatko Josic zlatko.jo...@gmail.com wrote: Hi, I would like to start two progams from Eclipse. One is a server and the other one is a client. I use Load Clojure file in REPL from Eclipse menu. When I start the server it never ends because the server has endless loop where it waits for clients. Now when I start the client programs it never evaluates because REPL is busy with server program. I suppose it works as I described. Maybe I am wrong I am not sure. Any ideas to overcame this situation are welcome. Have the server spawning function (or both, if the client is GUI) just start a separate thread and immediately return. (In fact, servers normally are multithreaded anyway, aren't they, to be able to handle multiple concurrent incoming requests.) Well, Java servers probably are yes, but traditional Unix servers would normally fork a new process for each incoming connection. There are various ways of doing it. A separate process per client connection; a separate thread per client connection; a single process/thread handling multiple clients with select()/poll()/etc. and combinations or variations on these. e.g. starting a pool of processes to avoid the startup time of a new process when a new client connects. -- Michael Wood esiot...@gmail.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: clojure.contrib.sql = clojure.java.jdbc - looking for feedback!
On Sat, Apr 23, 2011 at 1:37 PM, Nicolas Buduroi nbudu...@gmail.com wrote: After rethinking about quoted identifiers, I realized they would probably need an extra argument to escape the quotes found inside an identifier if there are some. Well, not all DB stropping approaches are simply (str q ident q) - there's also select [name] from [table] style quoting and that part is DB vendor specific I believe? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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: Two types of special symbol
http://dev.clojure.org/display/design/Compiler+in+Clojure On Sat, Apr 23, 2011 at 3:37 AM, Simon Katz nomisk...@gmail.com wrote: Thanks -- interesting, especially the bit about the design notes on a compiler rewrite. On Thu, Apr 21, 2011 at 22:23, Kevin Downey redc...@gmail.com wrote: the current compiler doesn't namespace qualify special forms (forms which are built into the compiler) but somethings that the documentation lists as special forms are infact macros defined in clojure.core based on the real special forms provided by the compiler. macros are namespace qualified so unless you use the fully qualified name(clojure.core/let) or :use/use them then they aren't available. this difference is kind of unfortunate, and the design notes on a compiler rewrite mention changing things so the forms directly supported by the compiler are also namespace qualified and live in clojure.core On Thu, Apr 21, 2011 at 12:24 PM, Simon Katz nomisk...@gmail.com wrote: Hi. (In case it makes a difference, I'm using Clojure 1.2.) If one creates a new namespace using in-ns, the new namespace does not refer to clojure.core, as explained at http://clojure.org/namespaces. I noticed one can use certain special forms in a namespace created using in-ns, but not others: _ | | user (in-ns 'my-new-ns) | #Namespace my-new-ns | | my-new-ns (quote a) | a | | my-new-ns (def x 42) | #'my-new-ns/x | | my-new-ns (let [a 42] a) | ;; Evaluation aborted. Unable to resolve symbol: let in this context | | my-new-ns (fn [] 42) | ;; Evaluation aborted. Unable to resolve symbol: fn in this context |_ That puzzled me. In the process of trying to understand, I came across a mention of clojure.lang.Compiler/specials (a map with symbols as its keys) at http://stackoverflow.com/questions/3159836/is-there-a-way-to-get-a-collection-of-clojure-special-forms-programatically _ | | user (keys clojure.lang.Compiler/specials) | ;; = (deftype* new quote var set! monitor-enter recur . | case* clojure.core/import* reify* do fn* throw | monitor-exit letfn* finally let* loop* try catch if | def) |_ So it seems that there are two kinds of special symbol. I'll refer to them as implementation specials and documented specials: - implementation specials those that are keys in the clojure.lang.Compiler/specials map - documented specials those that are documented as being special at http://clojure.org/special_forms. (Note that some symbols are of both kinds.) I assume that documented specials that are not implementation specials are implemented as macros. (And the post I mentioned above at stackoverflow.com says so.) Here's some investigation of these two kinds of special symbol: _ | | user (def implementation-specials | (keys clojure.lang.Compiler/specials)) | #'user/implementation-specials | | user (def documented-specials | '(def if do let quote var fn loop recur throw try | monitor-enter monitor-exit . new set!)) | #'user/documented-specials | | user (defn symbol-info [symbol] | [(special-symbol? symbol) | (= (resolve symbol) nil) | symbol]) | #'user/symbol-info | | user (pprint (map symbol-info implementation-specials)) | ([true true deftype*] | [true true new] | [true true quote] | [true true ] | [true true var] | [true true set!] | [true true monitor-enter] | [true true recur] | [true true .] | [true true case*] | [true true clojure.core/import*] | [true true reify*] | [true true do] | [true true fn*] | [true true throw] | [true true monitor-exit] | [true true letfn*] | [true true finally] | [true true let*] | [true true loop*] | [true true try] | [true true catch] | [true true if] | [true true def]) | nil | | user (pprint (map symbol-info documented-specials)) | ([true true def] | [true true if] | [true true do] | [false false let] | [true true quote] | [true true var] | [false false fn] | [false false loop] | [true true recur] | [true true throw] | [true true try] | [true true monitor-enter] | [true true monitor-exit] | [true true .] | [true true new] | [true true set!]) | nil |_ There are a few interesting things here: - special-symbol? returns true for implementation specials (actually not surprising when you look at the implementation of special-symbol?, but perhaps surprising if you have only read http://clojure.org/namespaces and the documentation of special-symbol? which says Returns true if [the
Re: Start Clojure programs from Eclipse
On Sat, Apr 23, 2011 at 5:30 PM, Michael Wood esiot...@gmail.com wrote: On 23 April 2011 17:31, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 5:12 AM, Zlatko Josic zlatko.jo...@gmail.com wrote: Hi, I would like to start two progams from Eclipse. One is a server and the other one is a client. I use Load Clojure file in REPL from Eclipse menu. When I start the server it never ends because the server has endless loop where it waits for clients. Now when I start the client programs it never evaluates because REPL is busy with server program. I suppose it works as I described. Maybe I am wrong I am not sure. Any ideas to overcame this situation are welcome. Have the server spawning function (or both, if the client is GUI) just start a separate thread and immediately return. (In fact, servers normally are multithreaded anyway, aren't they, to be able to handle multiple concurrent incoming requests.) Well, Java servers probably are yes, but traditional Unix servers would normally fork a new process for each incoming connection. Poor man's threads. Although the insulation of each one against crashes in the others might be useful when you're coding in a language with memory management tools as primitive as C's. ;) There are various ways of doing it. A separate process per client connection; a separate thread per client connection; a single process/thread handling multiple clients with select()/poll()/etc. For the first one, the JVM startup time is prohibitive; for the third you need nonblocking socket I/O, which might be in Java 7 or something but isn't available to us JVM-6 users. starting a pool of processes to avoid the startup time of a new process when a new client connects. With small lightweight C processes and some suitable system for IPC, this can work. With JVMs, not so much, unless you have RAM coming out of your ears. JVM processes tend to be fairly large; it wouldn't take many 64MB java.exe jobs to start the pagefile thrashing. Even with an 8GB server, you start paging at 128 simultaneous connections in that case, and you certainly can't handle thousands. If you have any kind of complex shared state at all, multiple threads in a single JVM, plus Clojure's STM, will be much nicer. :) -- 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: Start Clojure programs from Eclipse
On Sat, 23 Apr 2011 19:41:28 -0400 Ken Wesson kwess...@gmail.com wrote: Well, Java servers probably are yes, but traditional Unix servers would normally fork a new process for each incoming connection. Poor man's threads. Although the insulation of each one against crashes in the others might be useful when you're coding in a language with memory management tools as primitive as C's. ;) Or your tools for handling concurrency are as poor as C's (which is unfortunately most popular languages), or you live in a universe where cosmic rays can flip bits and other sources of hardware hiccups exist. starting a pool of processes to avoid the startup time of a new process when a new client connects. With small lightweight C processes and some suitable system for IPC, this can work. With JVMs, not so much, unless you have RAM coming out of your ears. JVM processes tend to be fairly large; it wouldn't take many 64MB java.exe jobs to start the pagefile thrashing. Even with an 8GB server, you start paging at 128 simultaneous connections in that case, and you certainly can't handle thousands. I would have expected large chunks of the JVM processes to be shared between parent and child - especially before the first accept returns. In particular, the VM implementation and the compiled JVM bytecodes should all be shared. Data structures JIT'ed code - well, it will depend on a variety of implementation details, but they all start on shared pages with a COW bit set. Of course, if you're using threads in the parent for other things, then forking to create new processes creates a bunch of interesting things to deal with. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Start Clojure programs from Eclipse
On Sat, Apr 23, 2011 at 8:13 PM, Mike Meyer m...@mired.org wrote: On Sat, 23 Apr 2011 19:41:28 -0400 Ken Wesson kwess...@gmail.com wrote: Well, Java servers probably are yes, but traditional Unix servers would normally fork a new process for each incoming connection. Poor man's threads. Although the insulation of each one against crashes in the others might be useful when you're coding in a language with memory management tools as primitive as C's. ;) Or your tools for handling concurrency are as poor as C's (which is unfortunately most popular languages) But not Clojure. or you live in a universe where cosmic rays can flip bits and other sources of hardware hiccups exist. Software crashes caused by non-software-bug-triggered memory corruption seem to me to be exceedingly rare, and they could as easily strike critical parts of the operating system as a multithreaded server program (and a large batch of independent C jobs will occupy more memory and have a correspondingly larger cross section as a target for such things). The best recourse if the server gets hit by something like that is going to be to reboot it. starting a pool of processes to avoid the startup time of a new process when a new client connects. With small lightweight C processes and some suitable system for IPC, this can work. With JVMs, not so much, unless you have RAM coming out of your ears. JVM processes tend to be fairly large; it wouldn't take many 64MB java.exe jobs to start the pagefile thrashing. Even with an 8GB server, you start paging at 128 simultaneous connections in that case, and you certainly can't handle thousands. I would have expected large chunks of the JVM processes to be shared between parent and child - especially before the first accept returns. That happens forking C programs. It won't happen starting up separate, independent JVM processes, and I don't know how a JVM will handle it if a native method calls fork() but I somehow doubt it will all just work peachily. In particular, the VM implementation and the compiled JVM bytecodes should all be shared. Data structures JIT'ed code - well, it will depend on a variety of implementation details, but they all start on shared pages with a COW bit set. Again, that presumes you manage to call fork() and the JVM doesn't bat an eye at being duplicated in mid-execution in that manner. Separately-started JVM processes won't have that parent-child relationship. Of course, if you're using threads in the parent for other things, then forking to create new processes creates a bunch of interesting things to deal with. If you ask me, fork() is a dinosaur, a relic of the C age and indeed of the time before pthreads. -- 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: Start Clojure programs from Eclipse
On Apr 23, 4:41 pm, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 5:30 PM, Michael Wood esiot...@gmail.com wrote: On 23 April 2011 17:31, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 5:12 AM, Zlatko Josic zlatko.jo...@gmail.com wrote: Hi, I would like to start two progams from Eclipse. One is a server and the other one is a client. I use Load Clojure file in REPL from Eclipse menu. When I start the server it never ends because the server has endless loop where it waits for clients. Now when I start the client programs it never evaluates because REPL is busy with server program. I suppose it works as I described. Maybe I am wrong I am not sure. Any ideas to overcame this situation are welcome. Have the server spawning function (or both, if the client is GUI) just start a separate thread and immediately return. (In fact, servers normally are multithreaded anyway, aren't they, to be able to handle multiple concurrent incoming requests.) Well, Java servers probably are yes, but traditional Unix servers would normally fork a new process for each incoming connection. Poor man's threads. Although the insulation of each one against crashes in the others might be useful when you're coding in a language with memory management tools as primitive as C's. ;) There are various ways of doing it. A separate process per client connection; a separate thread per client connection; a single process/thread handling multiple clients with select()/poll()/etc. For the first one, the JVM startup time is prohibitive; for the third you need nonblocking socket I/O, which might be in Java 7 or something but isn't available to us JVM-6 users. http://download.oracle.com/javase/1.5.0/docs/api/java/nio/channels/package-summary.html#multiplex Non-blocking socket IO has been around since 1.5, maybe even 1.4. It only gets used for very heavy stuff because the API is unwieldy and threads are simpler, but it's absolutely there. -- 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: Start Clojure programs from Eclipse
On Sat, Apr 23, 2011 at 11:26 PM, Alan a...@malloys.org wrote: On Apr 23, 4:41 pm, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 5:30 PM, Michael Wood esiot...@gmail.com wrote: On 23 April 2011 17:31, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 5:12 AM, Zlatko Josic zlatko.jo...@gmail.com wrote: Hi, I would like to start two progams from Eclipse. One is a server and the other one is a client. I use Load Clojure file in REPL from Eclipse menu. When I start the server it never ends because the server has endless loop where it waits for clients. Now when I start the client programs it never evaluates because REPL is busy with server program. I suppose it works as I described. Maybe I am wrong I am not sure. Any ideas to overcame this situation are welcome. Have the server spawning function (or both, if the client is GUI) just start a separate thread and immediately return. (In fact, servers normally are multithreaded anyway, aren't they, to be able to handle multiple concurrent incoming requests.) Well, Java servers probably are yes, but traditional Unix servers would normally fork a new process for each incoming connection. Poor man's threads. Although the insulation of each one against crashes in the others might be useful when you're coding in a language with memory management tools as primitive as C's. ;) There are various ways of doing it. A separate process per client connection; a separate thread per client connection; a single process/thread handling multiple clients with select()/poll()/etc. For the first one, the JVM startup time is prohibitive; for the third you need nonblocking socket I/O, which might be in Java 7 or something but isn't available to us JVM-6 users. http://download.oracle.com/javase/1.5.0/docs/api/java/nio/channels/package-summary.html#multiplex Non-blocking socket IO has been around since 1.5, maybe even 1.4. Oh? Then why was there a recent thread here about how it's finally made it into Java 7 via JSR something-or-other? -- 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: Start Clojure programs from Eclipse
On Sat, Apr 23, 2011 at 11:28 PM, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 11:26 PM, Alan a...@malloys.org wrote: On Apr 23, 4:41 pm, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 5:30 PM, Michael Wood esiot...@gmail.com wrote: On 23 April 2011 17:31, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 5:12 AM, Zlatko Josic zlatko.jo...@gmail.com wrote: Hi, I would like to start two progams from Eclipse. One is a server and the other one is a client. I use Load Clojure file in REPL from Eclipse menu. When I start the server it never ends because the server has endless loop where it waits for clients. Now when I start the client programs it never evaluates because REPL is busy with server program. I suppose it works as I described. Maybe I am wrong I am not sure. Any ideas to overcame this situation are welcome. Have the server spawning function (or both, if the client is GUI) just start a separate thread and immediately return. (In fact, servers normally are multithreaded anyway, aren't they, to be able to handle multiple concurrent incoming requests.) Well, Java servers probably are yes, but traditional Unix servers would normally fork a new process for each incoming connection. Poor man's threads. Although the insulation of each one against crashes in the others might be useful when you're coding in a language with memory management tools as primitive as C's. ;) There are various ways of doing it. A separate process per client connection; a separate thread per client connection; a single process/thread handling multiple clients with select()/poll()/etc. For the first one, the JVM startup time is prohibitive; for the third you need nonblocking socket I/O, which might be in Java 7 or something but isn't available to us JVM-6 users. http://download.oracle.com/javase/1.5.0/docs/api/java/nio/channels/package-summary.html#multiplex Non-blocking socket IO has been around since 1.5, maybe even 1.4. Oh? Then why was there a recent thread here about how it's finally made it into Java 7 via JSR something-or-other? It was JSR 203 and the thread was agent action queueing is asynchronous?. André Caron said: Basically, I can't block on Selector.select(), so I have to poll. Can't wait for JSR203 (http://www.jcp.org/en/jsr/detail?id=203) to be approved as part of Java 7. The implication is clear: you can select on a socket, which blocks, or you can do some sort of busy-loop polling, but there is no nonblocking callback-based socket API pre-JSR203, and JSR203 certainly wasn't in Java back in 1.5, let alone 1.4. If that information is incorrect I suggest you take it up with André. -- 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: Start Clojure programs from Eclipse
On Sat, 23 Apr 2011 23:19:53 -0400 Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 8:13 PM, Mike Meyer m...@mired.org wrote: On Sat, 23 Apr 2011 19:41:28 -0400 Ken Wesson kwess...@gmail.com wrote: or you live in a universe where cosmic rays can flip bits and other sources of hardware hiccups exist. Software crashes caused by non-software-bug-triggered memory corruption seem to me to be exceedingly rare, and they could as easily strike critical parts of the operating system as a multithreaded server program (and a large batch of independent C jobs will occupy more memory and have a correspondingly larger cross section as a target for such things). The best recourse if the server gets hit by something like that is going to be to reboot it. While it might be exceedingly rare on a per-cpu-second basis, if your application runs 7x24 on enough cpus, you can expect to see them at regular intervals. In which case the best recourse - if you want a stable, robust application - is to restart the smallest set of processes that might have been affected by the problem. In some cases, that is the server. In others, it's a single process. In still others, it's the set of servers participating in a distributed application. starting a pool of processes to avoid the startup time of a new process when a new client connects. With small lightweight C processes and some suitable system for IPC, this can work. With JVMs, not so much, unless you have RAM coming out of your ears. JVM processes tend to be fairly large; it wouldn't take many 64MB java.exe jobs to start the pagefile thrashing. Even with an 8GB server, you start paging at 128 simultaneous connections in that case, and you certainly can't handle thousands. I would have expected large chunks of the JVM processes to be shared between parent and child - especially before the first accept returns. That happens forking C programs. It won't happen starting up separate, independent JVM processes, and I don't know how a JVM will handle it if a native method calls fork() but I somehow doubt it will all just work peachily. Ah, good point. I don't think in Java, so forget that it doesn't necessarily have access to all the facilities of the underlying OS. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Start Clojure programs from Eclipse
On Sat, Apr 23, 2011 at 11:35 PM, Mike Meyer m...@mired.org wrote: On Sat, 23 Apr 2011 23:19:53 -0400 Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 8:13 PM, Mike Meyer m...@mired.org wrote: On Sat, 23 Apr 2011 19:41:28 -0400 Ken Wesson kwess...@gmail.com wrote: or you live in a universe where cosmic rays can flip bits and other sources of hardware hiccups exist. Software crashes caused by non-software-bug-triggered memory corruption seem to me to be exceedingly rare, and they could as easily strike critical parts of the operating system as a multithreaded server program (and a large batch of independent C jobs will occupy more memory and have a correspondingly larger cross section as a target for such things). The best recourse if the server gets hit by something like that is going to be to reboot it. While it might be exceedingly rare on a per-cpu-second basis, if your application runs 7x24 on enough cpus, you can expect to see them at regular intervals. In which case the best recourse - if you want a stable, robust application - is to restart the smallest set of processes that might have been affected by the problem. In other words, all of them, since the operating system might have been affected by such a problem and if it was, everything else is probably affected too. In still others, it's the set of servers participating in a distributed application. With distributed applications that share data, you need some sort of verification. That might be a master DB they all talk to that is ACID and has various consistency constraints set; it might be farming out jobs to multiple machines and using a majority-rules mechanism to decide which one(s) returned the correct answer (in the case of using DC to speed up a pure-functional computation). For many applications, occasional hiccups are non-fatal so long as crucial disk files don't get trashed (e.g. web servers); then, having the hard drives backed up regularly is the main defense against disasters that can't be fixed by rebooting one machine, whether the server is a single machine or a load-balanced (i.e. distributed) server farm. -- 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: Start Clojure programs from Eclipse
On Apr 23, 8:28 pm, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 11:26 PM, Alan a...@malloys.org wrote: On Apr 23, 4:41 pm, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 5:30 PM, Michael Wood esiot...@gmail.com wrote: On 23 April 2011 17:31, Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 5:12 AM, Zlatko Josic zlatko.jo...@gmail.com wrote: Hi, I would like to start two progams from Eclipse. One is a server and the other one is a client. I use Load Clojure file in REPL from Eclipse menu. When I start the server it never ends because the server has endless loop where it waits for clients. Now when I start the client programs it never evaluates because REPL is busy with server program. I suppose it works as I described. Maybe I am wrong I am not sure. Any ideas to overcame this situation are welcome. Have the server spawning function (or both, if the client is GUI) just start a separate thread and immediately return. (In fact, servers normally are multithreaded anyway, aren't they, to be able to handle multiple concurrent incoming requests.) Well, Java servers probably are yes, but traditional Unix servers would normally fork a new process for each incoming connection. Poor man's threads. Although the insulation of each one against crashes in the others might be useful when you're coding in a language with memory management tools as primitive as C's. ;) There are various ways of doing it. A separate process per client connection; a separate thread per client connection; a single process/thread handling multiple clients with select()/poll()/etc. For the first one, the JVM startup time is prohibitive; for the third you need nonblocking socket I/O, which might be in Java 7 or something but isn't available to us JVM-6 users. http://download.oracle.com/javase/1.5.0/docs/api/java/nio/channels/pa... Non-blocking socket IO has been around since 1.5, maybe even 1.4. Oh? Then why was there a recent thread here about how it's finally made it into Java 7 via JSR something-or-other? I don't know what to tell you. SocketChannel has a configureBlocking(boolean) method; Selector.selectNow is a non- blocking selector across non-blocking channels. -- 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: Start Clojure programs from Eclipse
On Sat, 23 Apr 2011 23:42:23 -0400 Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 11:35 PM, Mike Meyer m...@mired.org wrote: On Sat, 23 Apr 2011 23:19:53 -0400 Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 8:13 PM, Mike Meyer m...@mired.org wrote: On Sat, 23 Apr 2011 19:41:28 -0400 Ken Wesson kwess...@gmail.com wrote: or you live in a universe where cosmic rays can flip bits and other sources of hardware hiccups exist. Software crashes caused by non-software-bug-triggered memory corruption seem to me to be exceedingly rare, and they could as easily strike critical parts of the operating system as a multithreaded server program (and a large batch of independent C jobs will occupy more memory and have a correspondingly larger cross section as a target for such things). The best recourse if the server gets hit by something like that is going to be to reboot it. While it might be exceedingly rare on a per-cpu-second basis, if your application runs 7x24 on enough cpus, you can expect to see them at regular intervals. In which case the best recourse - if you want a stable, robust application - is to restart the smallest set of processes that might have been affected by the problem. In other words, all of them, since the operating system might have been affected by such a problem and if it was, everything else is probably affected too. Let me guess - you're one of these people who reboots systems every couple of days just in case? Sure, a hardware glitch that affects the OS means you should reboot the system. Of course, if it affects some user process, it may have affected the OS without leaving evidence of doing so. Then again, it may not have. While you could reboot everything just in case, you could also have a hardware glitch affect the OS without leaving evidence in any process, so you might as well reboot even though nothing is wrong just in case. Nah, hardware glitches are either localized, in which case restarting just the address spaces that failed is sufficient (and has proven so in practice for years), or they're systemic, in which case you'll have failures throughout the system. It's pretty easy to tell the difference between the two and deal with them appropriately. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Start Clojure programs from Eclipse
On Sun, Apr 24, 2011 at 12:01 AM, Mike Meyer m...@mired.org wrote: On Sat, 23 Apr 2011 23:42:23 -0400 Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 11:35 PM, Mike Meyer m...@mired.org wrote: On Sat, 23 Apr 2011 23:19:53 -0400 Ken Wesson kwess...@gmail.com wrote: On Sat, Apr 23, 2011 at 8:13 PM, Mike Meyer m...@mired.org wrote: On Sat, 23 Apr 2011 19:41:28 -0400 Ken Wesson kwess...@gmail.com wrote: or you live in a universe where cosmic rays can flip bits and other sources of hardware hiccups exist. Software crashes caused by non-software-bug-triggered memory corruption seem to me to be exceedingly rare, and they could as easily strike critical parts of the operating system as a multithreaded server program (and a large batch of independent C jobs will occupy more memory and have a correspondingly larger cross section as a target for such things). The best recourse if the server gets hit by something like that is going to be to reboot it. While it might be exceedingly rare on a per-cpu-second basis, if your application runs 7x24 on enough cpus, you can expect to see them at regular intervals. In which case the best recourse - if you want a stable, robust application - is to restart the smallest set of processes that might have been affected by the problem. In other words, all of them, since the operating system might have been affected by such a problem and if it was, everything else is probably affected too. Let me guess - you're one of these people who Ah, I get it. You're arguing because you have some kind of *personal* issue, rather than for any logical reason. Sure, a hardware glitch that affects the OS means you should reboot the system. And assuming you can even detect that such a glitch has occurred at all (what if one hits the code doing the detecting, or the memory that it uses -- or the operating system, in a way that affects that code?) can you detect whether or not it hit the operating system? Of course, if it affects some user process, it may have affected the OS without leaving evidence of doing so. Then again, it may not have. While you could reboot everything just in case, you could also have a hardware glitch affect the OS without leaving evidence in any process, so you might as well reboot even though nothing is wrong just in case. Obviously there's little point in rebooting absent *some* evidence that something is wrong. Of course, some process segfaulting doesn't mean much if it's a typical C program. On the other hand, if you have a rock-solid JVM and kernel and various JVM bytecodes running, and the JVM faults, the likelihood of a problem like this is higher than if a random other program faulted -- indeed, either it's a JVM bug, an OS bug, or a glitch of the type being discussed, since arbitrary bytecode on a bug-free JVM shouldn't cause the JVM to fault. (Native methods complicate things somewhat though.) Nah, hardware glitches are either localized, in which case restarting just the address spaces that failed is sufficient (and has proven so in practice for years), or they're systemic, in which case you'll have failures throughout the system. It's pretty easy to tell the difference between the two and deal with them appropriately. Easy for who? The system administrator? I thought we were considering automated means of recovering faulting systems here. -- 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
