On 10 April 2011 22:24, Ken Wesson wrote:
> On Sun, Apr 10, 2011 at 1:37 PM, James Reeves wrote:
>> By adding error messages to predicates, we tightly couple the
>> validation error with the predicate, which in general is considered
>> bad. However, this might be a valid compromise, but only if i
On Mon, Apr 11, 2011 at 3:09 AM, James Reeves wrote:
> On 10 April 2011 22:24, Ken Wesson wrote:
>> On Sun, Apr 10, 2011 at 1:37 PM, James Reeves
>> wrote:
>>> By adding error messages to predicates, we tightly couple the
>>> validation error with the predicate, which in general is considered
>
On 11 April 2011 08:31, Ken Wesson wrote:
>> So your not-int-in-range? function is a compound function, made up of
>> four simple functions.
>
> So? This whole discussion arose because some of them have
> preconditions, like at-least 1 not making sense for blank or
> non-integer input.
Yes, but r
On Mon, Apr 11, 2011 at 4:12 AM, James Reeves wrote:
> On 11 April 2011 08:31, Ken Wesson wrote:
>>> So your not-int-in-range? function is a compound function, made up of
>>> four simple functions.
>>
>> So? This whole discussion arose because some of them have
>> preconditions, like at-least 1 n
Hi,
On 11 Apr., 10:43, Ken Wesson wrote:
> What is your basis for this?
Because the phantasy of the average human being is quite limited.
While a missed "this is allowed" might cause trouble, it doesn't
compromise the system. A missed "this is not allowed" however will.
Solutions are not always
Hi,
On 11 Apr., 11:16, Ken Wesson wrote:
>> Just for illustration: Who designs a system, which starts an atomic
>> war on a bitflip in a test message? (Yeah, this happened and we are
>> only alive because of the gut feeling of an operator.
>
> Petrov?
This was on the russian side. But it also h
On Mon, Apr 11, 2011 at 5:07 AM, Meikel Brandmeyer wrote:
>> What is your basis for this?
>
> Because the phantasy of the average human being is quite limited.
?
> While a missed "this is allowed" might cause trouble, it doesn't
> compromise the system. A missed "this is not allowed" however wil
Hi,
On 11 Apr., 12:04, Ken Wesson wrote:
> So, similar incidents happened on both sides.
And to illustrate this point:
>> Because the phantasy of the average human being is quite limited.
>
> ?
No one obviously imagined what happens when there is a malfunction in
the hardware which might caus
On Mon, Apr 11, 2011 at 5:29 AM, Meikel Brandmeyer wrote:
> Hi,
>
> On 11 Apr., 11:16, Ken Wesson wrote:
>
>>> Just for illustration: Who designs a system, which starts an atomic
>>> war on a bitflip in a test message? (Yeah, this happened and we are
>>> only alive because of the gut feeling of a
On Mon, Apr 11, 2011 at 6:27 AM, Meikel Brandmeyer wrote:
> Although not every system launches the Rockets, I'd prefer systems
> with robustness and fault tolerance as default. Even if it's only the
> egg clock gadget.
But you must admit that the mission-criticalness of robustness and
fault toler
Hi,
On 11 Apr., 12:45, Ken Wesson wrote:
> But you must admit that the mission-criticalness of robustness and
> fault tolerance varies from one application to the next.
I do. And I also admit, that I think that someone not able to write a
simple, non-critical application in a robust and fault t
> I do. And I also admit, that I think that someone not able to write a
> simple, non-critical application in a robust and fault tolerant way
> per default is a able to write a complex, critical application in a
> robust and fault tolerant way.
Bleh. ... that I *don't* think ...
--
You received
Exercising the code below with (f "ab") produces:
A: a
ANY: a
ANY: b
Which implies (at least to me) that - alt seems to match "a" twice once
against the lit and once against anything. Any suggestions would be
appreciated.
fnparse v: 2.2.7
clojure v: 1.2.0
---
(use 'name.choi.joshua.fnparse)
Do protocols respect namespace rewriting? For instance:
We define a protocol in a namespace:
(ns a)
(defprotocol P
(p [this]))
(defn g[] )
This works:
(ns b
On 6 abr, 00:02, Stuart Sierra wrote:
> You can omit clojure.core/first from your namespace like this:
>
> (ns your.namespace
First , very thanks for you reply and very detailed explaining about
"refer".
in fact refer-clojure is variant of (refer 'clojure.core). what
clojureql does is refer clojure exclude distinct, conj and etc, and
redefine a itself version of distinct in which refer clojure/distinct.
you can read it's
I'm having trouble avoiding name collisions with protocols. A third-
party librery defines:
(ns a)
(defprotocol PA
(fa [this ...])
(ga [this ..])
(ha [this ..])
.)
And i want to be able to use some of this protocol for a type I'm
defining. So I do
(ns b
(:use a :as mya))
(d
Hi,
On 11 Apr., 16:29, limux wrote:
> Why some warning of conflit be reported in the cmd of win when
> the lein run myoa/core.clj? and when I refresh the browser the system
> will failed with lots of error messsage?
The conflict is not in clojureql, but your namespace. You probably
":use" cloju
That's because of the order of the definitions of foobar and let.
Thus:
guik.evil=> (macroexpand '(foobar 10))
(let* [a__44__auto__ 10] (clojure.core/+ a__44__auto__ a__44__auto__))
But defining let before foobar:
guik.evil=> (macroexpand-1 '(let))
(guik.evil/let*)
guik.evil=> (macroexpand-1 (ma
Hi,
On 11 Apr., 16:35, babui wrote:
> (ns b
> (:use a :as mya))
You want require here, not use. (ns b (:require [a :as mya]))
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@google
Your "semantics" have side effects. The parser shouldn't be printing
to stdout, because it's still in the middle of backtracking and
deciding what matches. Instead the semantics should be more like (fn
[x] (str "ANY: " x)); then you won't see any results unless a complete
parse happens.
On Apr 11,
It has worked like a charm.
Thanks.
Juan Manuel
On 11 abr, 16:45, Meikel Brandmeyer wrote:
> Hi,
>
> On 11 Apr., 16:35, babui wrote:
>
> > (ns b
> > (:use a :as mya))
>
> You want require here, not use. (ns b (:require [a :as mya]))
>
> Sincerely
> Meikel
--
You received this message bec
On 11 April 2011 09:43, Ken Wesson wrote:
> On Mon, Apr 11, 2011 at 4:12 AM, James Reeves wrote:
>> Yes, but remember that I said I was looking for non-compound
>> solutions. In my view, simple functions are more idiomatic Clojure.
>
> Mine were built up starting from very simple functions.
Sure
Can it be used as an inference (rule) engine ?
On Apr 9, 2:27 pm, David Nolen wrote:
> Logos is finally in good enough shape to be worth publishing to Clojars.
> There are really too many changes to enumerate here, but if you're familiar
> with Prolog, Logos is now far enough along that you can
On Mon, Apr 11, 2011 at 2:01 PM, Vagif Verdi wrote:
> Can it be used as an inference (rule) engine ?
If you mean in the same way that you can build inference (rule) engines in
Prolog - I don't see why not.
However there is a bit of work to be done in order to make building
efficient rule engin
I'd like to provide :
private void writeObject(java.io.ObjectOutputStream out)
throws IOException
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException;
methods on a gen-classed class to handle my own serialisation.
I can get around the immu
On Mon, Apr 11, 2011 at 7:17 AM, Meikel Brandmeyer wrote:
>
>> I do. And I also admit, that I think that someone not able to write a
>> simple, non-critical application in a robust and fault tolerant way
>> per default is a able to write a complex, critical application in a
>> robust and fault tol
On Mon, Apr 11, 2011 at 1:09 PM, James Reeves wrote:
> On 11 April 2011 09:43, Ken Wesson wrote:
>> On Mon, Apr 11, 2011 at 4:12 AM, James Reeves
>> wrote:
>>> Yes, but remember that I said I was looking for non-compound
>>> solutions. In my view, simple functions are more idiomatic Clojure.
>>
On 11 April 2011 21:26, Ken Wesson wrote:
> On Mon, Apr 11, 2011 at 1:09 PM, James Reeves wrote:
>> If you already have a, b, and c, then compounding them into one
>> function, only to then use a map to split them up again doesn't seem a
>> good solution.
>
> The preconditions have to be checked.
On Mon, Apr 11, 2011 at 7:09 PM, James Reeves wrote:
> On 11 April 2011 21:26, Ken Wesson wrote:
>> On Mon, Apr 11, 2011 at 1:09 PM, James Reeves
>> wrote:
>>> If you already have a, b, and c, then compounding them into one
>>> function, only to then use a map to split them up again doesn't see
Write a Java interface with these two methods and have your gen'ed
class implement it. The gen'ed methods won't have a throws clause but
will work with the serialization mechanism all the same.
On Apr 11, 12:50 pm, Jules wrote:
> I'd like to provide :
>
> private void writeObject(java.io.ObjectO
On 12 April 2011 01:41, Ken Wesson wrote:
> On Mon, Apr 11, 2011 at 7:09 PM, James Reeves wrote:
>> You wouldn't necessarily need to explicitly verify each precondition,
>> but it might be the case that the same string is parsed multiple
>> times. However, I'm unsure why you think this is a probl
On Mon, Apr 11, 2011 at 10:23 PM, James Reeves wrote:
> On 12 April 2011 01:41, Ken Wesson wrote:
>> On Mon, Apr 11, 2011 at 7:09 PM, James Reeves
>> wrote:
>>> You wouldn't necessarily need to explicitly verify each precondition,
>>> but it might be the case that the same string is parsed mult
32 matches
Mail list logo
