Hi,
I'm just wondering if there is no predefined synonym for
(defun t-p (x) (eq t x))?
Andreas
P.S.
CL-USER 41 > (t-p t)
T
CL-USER 42 > (t-p nil)
NIL
CL-USER 43 > (t-p :any-key)
NIL
On 26 Gen, 15:34, "Andreas Thiele" <······@nospam.com> wrote:
> Hi,
>
> I'm just wondering if there is no predefined synonym for
>
> (defun t-p (x) (eq t x))?
>
I don't think so.
AS
On Jan 26, 2:34 pm, "Andreas Thiele" <······@nospam.com> wrote:
> Hi,
>
> I'm just wondering if there is no predefined synonym for
>
> (defun t-p (x) (eq t x))?
>
I don't think so. It's not nearly as useful as NULL since you
generally want to know if something is false or true, and any non-NIL
object is true, not just T.
I think it should be TP not T-P.
"Tim Bradshaw" <··········@tfeb.org> schrieb im Newsbeitrag ·····························@v33g2000cwv.googlegroups.com...
> On Jan 26, 2:34 pm, "Andreas Thiele" <······@nospam.com> wrote:
>> ...
>> (defun t-p (x) (eq t x))?
>>
>
> I don't think so. It's not nearly as useful as NULL since you
> generally want to know if something is false or true, and any non-NIL
> object is true, not just T.
> ...
Generally yes, but I just had library function returning either t, :read-only or nil. I was only interested in the t case.
OK, for not being obscure I stick to (eq t x) ;-)
Andreas
Andreas Thiele wrote:
> "Tim Bradshaw" <··········@tfeb.org> schrieb im Newsbeitrag ·····························@v33g2000cwv.googlegroups.com...
>
>>On Jan 26, 2:34 pm, "Andreas Thiele" <······@nospam.com> wrote:
>>
>>>...
>>>(defun t-p (x) (eq t x))?
>>>
>>
>>I don't think so. It's not nearly as useful as NULL since you
>>generally want to know if something is false or true, and any non-NIL
>>object is true, not just T.
>>...
>
>
> Generally yes, but I just had library function returning either t, :read-only or nil. I was only interested in the t case.
Similarly, my algebra operands highlight themselves if their operator's
highlight-code is t, but not :optr-only. I guessed that that would
survive more refactoring than testing for not-eq.
>
> OK, for not being obscure I stick to (eq t x) ;-)
I had such great hopes for TP. :(
kzo
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
On Sat, 27 Jan 2007 00:33:22 +0100, Andreas Thiele <······@nospam.com>
wrote:
>
> "Tim Bradshaw" <··········@tfeb.org> schrieb im Newsbeitrag
> ·····························@v33g2000cwv.googlegroups.com...
>> On Jan 26, 2:34 pm, "Andreas Thiele" <······@nospam.com> wrote:
>>> ...
>>> (defun t-p (x) (eq t x))?
>>>
>>
>> I don't think so. It's not nearly as useful as NULL since you
>> generally want to know if something is false or true, and any non-NIL
>> object is true, not just T.
>> ...
>
> Generally yes, but I just had library function returning either t,
> :read-only or nil. I was only interested in the t case.
>
> OK, for not being obscure I stick to (eq t x) ;-)
>
> Andreas
>
or just (when x ..)
Some frown at this and prefer (when (not (null x)) ..),
but I like generalised boolean.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"John Thingstad" <··············@chello.no> schrieb im Newsbeitrag ······················@pandora.upc.no...
>> ...
>> Generally yes, but I just had library function returning either t,
>> :read-only or nil. I was only interested in the t case.
>> ...
>
> or just (when x ..)
> Some frown at this and prefer (when (not (null x)) ..),
> but I like generalised boolean.
> ...
CL-USER 1 > (not (null t))
T
CL-USER 2 > (not (null :read-only))
T
CL-USER 3 > (eq t t)
T
CL-USER 4 > (eq t :read-only)
NIL
?
Andreas
Hi,
> Indeed (typep :name T) -> T
> That is generalized boolean.
Ummm... _All_ objects are instances of type T, no? What does that
prove?
Mata ne,
Matthias
Matthias Benkard wrote:
> Hi,
>
>
>>Indeed (typep :name T) -> T
>>That is generalized boolean.
>
>
> Ummm... _All_ objects are instances of type T, no?
Yes. I remember early on being stumped that a fellow newby was getting
away with t instead of otherwise in a typecase.
k
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
"John Thingstad" <··············@chello.no> schrieb im Newsbeitrag ······················@pandora.upc.no...
>> ...
>> CL-USER 3 > (eq t t)
>> T
>>
>> CL-USER 4 > (eq t :read-only)
>> NIL
>> ...
> Indeed (typep :name T) -> T
> That is generalized boolean.
> I take it you want binary boolean?
häääh ?!? NO - just needed the above behaviour (eq t variable) ...
> ... I just had library function returning either t,
> :read-only or nil. I was only interested in the t case.
... and wasn't sure if I missed something like null, not, zerop, plusp et. al..
Nothing more!
Andreas
P.S. (not (null x)) is *not* equivalent to (eq t x)!
+ Madhu <·······@meer.net>:
| (ecase x
| ((t) ... )
| ((nil) ... )
| (:read-only ...))
|
| But there is a subtlety about testing for literal T and NIL in the
| ECASE test clauses - which is why I put T and NIL in singleton lists.
For that reason, as a matter of style I avoid the single selector in
case/ecase clauses like the plague, always inserting the parentheses.
Thus ((:read-only) ...). I consider the other form as legacy syntax
that must remain in the language for compatibility reasons only.
Am I the only one?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
In article <···············@news.t-online.com>,
"Andreas Thiele" <······@nospam.com> wrote:
> "Tim Bradshaw" <··········@tfeb.org> schrieb im Newsbeitrag
> ·····························@v33g2000cwv.googlegroups.com...
> > On Jan 26, 2:34 pm, "Andreas Thiele" <······@nospam.com> wrote:
> >> ...
> >> (defun t-p (x) (eq t x))?
> >>
> >
> > I don't think so. It's not nearly as useful as NULL since you
> > generally want to know if something is false or true, and any non-NIL
> > object is true, not just T.
> > ...
>
> Generally yes, but I just had library function returning either t, :read-only
> or nil. I was only interested in the t case.
This type of use isn't so common that it deserved a built-in function.
T isn't nearly as special as NIL or 0.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: robert maas, see http://tinyurl.com/uh3t
Subject: Re: Is there any eq t test in Common Lisp?
Date:
Message-ID: <rem-2007jan29-004@yahoo.com>
> From: "Andreas Thiele" <······@nospam.com>
> I just had library function returning either t, = :read-only or
> nil. I was only interested in the t case.
IMO it's bad programming practice to rely on somebody else's module
to always produce the same range of values forever. Whenever you
import data from an outside source, even a library you "trust", you
should check that data to make sure it still produces only the
values your software has been validated to process correctly.
In this case, instead of this code:
(if (eq t (callLibrary))
DoSomethingAppropriateForT
DoSomethingAppropriateForNilOrReadonly)
I recommend this:
(case (callLibrary)
((T) DoSomethingAppropriateForT)
((NIL :READ-ONLY) DoSomethingAppropriateForNilOrReadonly)
(otherwise ThrowException)
That's called "fail soft". If some assumption is wrong, like your
assumption that the library call will *always* return exactly one
of those three known values, your software will give a nice clear
indication at the earliest possible point where something went
wrong and why, rather than executing inappropriate code as if
nothing was wrong and generating wrong results, or crashing at some
later point with really obscure exception not apparently related to
the actual cause of the problem, without the slighest clue what
really went wrong or how to even begin to fix it.
If your module will be installed in customer software, you should
indicate in the exception text message clearly that it's a program
bug, not a user mistake, and it should indicate both which
company's customer support should be contacted and what specific
info about name of module and location within module the user
should tell customer support in order to direct the bugfix-request
to the correct party (not to you personally by name, because at the
time the library changes causing your old code to break you might
no longer be assigned to maintaining that module, or even working
for the same company).
·······@yahoo.com (robert maas, see http://tinyurl.com/uh3t) writes:
>> From: "Andreas Thiele" <······@nospam.com>
>> I just had library function returning either t, = :read-only or
>> nil. I was only interested in the t case.
>
> IMO it's bad programming practice to rely on somebody else's module
> to always produce the same range of values forever. Whenever you
> import data from an outside source, even a library you "trust", you
> should check that data to make sure it still produces only the
> values your software has been validated to process correctly.
> In this case, instead of this code:
> (if (eq t (callLibrary))
> DoSomethingAppropriateForT
> DoSomethingAppropriateForNilOrReadonly)
> I recommend this:
> (case (callLibrary)
> ((T) DoSomethingAppropriateForT)
> ((NIL :READ-ONLY) DoSomethingAppropriateForNilOrReadonly)
> (otherwise ThrowException)
> That's called "fail soft". If some assumption is wrong, like your
> assumption that the library call will *always* return exactly one
> of those three known values, your software will give a nice clear
> indication at the earliest possible point where something went
> wrong and why, rather than executing inappropriate code as if
> nothing was wrong and generating wrong results, or crashing at some
> later point with really obscure exception not apparently related to
> the actual cause of the problem, without the slighest clue what
> really went wrong or how to even begin to fix it.
>
> If your module will be installed in customer software, you should
> indicate in the exception text message clearly that it's a program
> bug, not a user mistake, and it should indicate both which
> company's customer support should be contacted and what specific
> info about name of module and location within module the user
> should tell customer support in order to direct the bugfix-request
> to the correct party (not to you personally by name, because at the
> time the library changes causing your old code to break you might
> no longer be assigned to maintaining that module, or even working
> for the same company).
Well.
You cannot program defensively for all kind of changes in foreign
code.
(defun library:fun (x)
"return t when (c1-p x), nil otherwise"
(not (not (c1-p x))))
(defun your-code (x)
(case (library:fun x)
((t) ; assume (c1-p x)
(print 'c1))
((nil)
; assume (not (c1-p x))
(print '(not c1)))
(otherwise
(error "LIBRARY:FUN returned an unexpected value."))))
and in a later version:
(defun library:fun (x)
"return t when (c2-p x), nil otherwise"
(not (not (c2-p x))))
So your-code is still happy, but now gives wrong results.
You'd want the functions to return along with the raw data, some meta
information that would explain what it means, so you can check that
the meaning the library function gives to the returned value matches
yours.
The basic case, is units along with magnitudes.
(defun ariane-4:rocket-rotation ()
(values (/ (ariane-4::get-raw-angle-change) (ariane-4::*delta-t*))
'(:range (-16383 16383)
:units (/ (* 234670.0L0 radiant) second))))
So you can process the second value, and use it to convert the encoded
result to some meaningful data, and check whether it is within range
and of the expected units. You can use the symbolic unit expression
to convert it to other (compatible) units if needed by other software
component. But overall, when you get integrated with a similar
routine such as:
(defun ariane-5:rocket-rotation ()
(values (/ (ariane-5::get-raw-angle-change) (ariane-5::*delta-t*))
'(:range (-65535 65535)
:units (/ (* 187744.0L0 radiant) second))))
you don't burn your budget in fireworks... Of course, to make it
practical, you need some more processing power, like the one you get
with multicore processors, and you need a programming language that
allows you to do symbolic meta-processing at the same time as
numerical processing, like lisp.
Then you could write things like:
(defun library:fun (x)
"return t when (c2-p x), nil otherwise"
(values (not (not (c2-p x)))
'(:type (member nil t)
:meaning (with-arguments (x)
(nil --> (not (c2-p x)))
(t --> (c2-p x))))))
(defun your-code (x)
(multiple-value-bind (value meta-value) (library:fun x)
(cond
((compatible-with (c1-p x) value meta-value) (print 'c1))
((compatible-with (not (c1-p x)) value meta-value) (print '(not c1)))
(otherwise
;; we'd still have to decide what it means, according to the
;; logic we want if neither c1-p nor (not c1-p) is true...
;; It might be possible, it might be an error in the library,
;; or it might be an error in the rest of the software.
;; But now, we can process it more "intelligently".
))))
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
"Andreas Thiele" <······@nospam.com> writes:
> Hi,
>
> I'm just wondering if there is no predefined synonym for
>
> (defun t-p (x) (eq t x))?
No. Probably because it is so compact to write directly. After all,
you only save a single character with
(t-p x)
vs.
(eq t x)
so it hardly seems worth the effort, especially since the convention in
Lisp is that any non-NIL value is interpreted as TRUE.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> "Andreas Thiele" <······@nospam.com> writes:
>
>
>>Hi,
>>
>>I'm just wondering if there is no predefined synonym for
>>
>>(defun t-p (x) (eq t x))?
>
>
> No. Probably because it is so compact to write directly. After all,
> you only save a single character with
>
> (t-p x)
Jeez, do you people have no respect for Common Lisp? Or hyphen inertia?
That should be tp. Or t? in kCL.
hth,kzo
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
On Fri, 26 Jan 2007 22:59:51 +0100, Ken Tilton <·········@gmail.com> wrote:
>
>
> Thomas A. Russ wrote:
>> "Andreas Thiele" <······@nospam.com> writes:
>>
>>> Hi,
>>>
>>> I'm just wondering if there is no predefined synonym for
>>>
>>> (defun t-p (x) (eq t x))?
>> No. Probably because it is so compact to write directly. After all,
>> you only save a single character with
>> (t-p x)
>
> Jeez, do you people have no respect for Common Lisp? Or hyphen inertia?
> That should be tp. Or t? in kCL.
>
> hth,kzo
>
Funny.. I thought the rule was to be inconsistent. ;)
like reverse and nreverse
so remove and nremove then? nop remove and delete
null not nullp
for that matter both p and -p are used..
defun, defclass, defstruct but define-compiler-macro and define-condition.
Well you get the picture..
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"Ken Tilton" <·········@gmail.com> schrieb im Newsbeitrag ·······················@newsfe10.lga...
>> ...
>> (t-p x)
>
> Jeez, do you people have no respect for Common Lisp? Or hyphen inertia?
> That should be tp. Or t? in kCL.
> ...
Damn, just a short time ago hyphenation has been discussed. Sorry didn't remember the rules.
So (tp x) is even two characters less than (eq t x) :))
Andreas
On Jan 26, 6:34 am, "Andreas Thiele" <······@nospam.com> wrote:
> Hi,
>
> I'm just wondering if there is no predefined synonym for
>
> (defun t-p (x) (eq t x))?
This would be just as silly as
#define TRUE 1
#define ISTRUE(X) (X == TRUE)
in C. (See comp.lang.c FAQ's 9.2 and 9.3). Believe it or not, there are
some programmers who do this. (And I'm not talking about the lack of
parentheses in the expansion of X either; I left that bug in just to
make the example a more realistic depiction of real-world stupidity,
which is rarely found in nature as a free element, because it's
frequently compounded).
Just like the way any non-zero (or non-null) value in C serves as true,
in Common Lisp anything that isn't NIL serves as true. That's how
``generalized booleans'' work in Common Lisp, and therefore comparing a
boolean value to T is a bug.
The correct definition of T-P should be:
(defun t-p (x) (not (null x)))
But it it useful? All of the situations in which you need to
selectively evaluate something based on a boolean value can just take
the generalized boolean directly, rather than a predicate expression
which reduces it to T. For example, you'd never write (when (t-p var)
...) but rather (when var ...). You might call it var-p to highlight
that it's a boolean. Even the (null ...) test can often be elided by
structuring the code appropriately and making use of things like
UNLESS.
(when (null x) ...) ==> (unless x ...)
(when (t-p expr) ...) ==> (when expr ...)
(if (null x) consequent alternate) ==> (if x alternate consequent)
Yet, T-P isn't entirely useless.
- One possible application is to avoid holding references on objects
that are only being evaluated as booleans. That is to say, if the only
attribute of an object that you care about, in some situation, is
whether or not it's NIL, and you need to hang on to that evaluation,
then by normalizing the object to T you avoid holding a reference to
it, which would otherwise prevent it from being garbage-collected.
- Another possible application is in producing output. Consider:
(format t "node has parent: ~a~%" (parent node))
The problem is that want to just produce T or NIL in the output, not
actually see the printed representation of the parent.
(format t "node has parent: ~a~%" (t-p (parent node)))
And so now I must leave you to fall into the abyss, since I've grasped
for all the available straws.
I think
(defun tp (x) (eq t x))
makes a little sense in some rare cases when you need to test for t. On purpose I didn't call it true or truep or true-p. It doesn't test for true it tests for the symbol t. It tests for the exact value of t because I had the requirement to test for that value. A library function I'm using (LispWorks capi:text-input-pane-enabled) returns either t, :read-only or nil. Only the t case is interesting for me. :read-only must be excluded! In this case I only see one sensible solution (when (eq t x) ...).
Andreas
Andreas Thiele wrote:
> I think
>
> (defun tp (x) (eq t x))
>
> makes a little sense in some rare cases when you need to test for t.
> ..snip... A library function I'm using (LispWorks
> capi:text-input-pane-enabled) returns either t, :read-only or nil.
[aside] and it makes little sense for an input pane to be at once
enabled and read-only.
kzo
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
From: Wade Humeniuk
Subject: Re: Is there any eq t test in Common Lisp?
Date:
Message-ID: <o5Kuh.4328$Y6.1724@edtnps89>
Ken Tilton wrote:
>
>
> Andreas Thiele wrote:
> > I think
> >
> > (defun tp (x) (eq t x))
> >
> > makes a little sense in some rare cases when you need to test for t.
> > ..snip... A library function I'm using (LispWorks
> > capi:text-input-pane-enabled) returns either t, :read-only or nil.
>
> [aside] and it makes little sense for an input pane to be at once
> enabled and read-only.
>
It does if you do not want the default greyed-out-default ugliness
for a text-input-pane when you disable it (at least on windows).
You can barely see the text when that happens. Also a quote
from the relevant CAPI Reference Manual
<quote>
If enabled is nil , the pane is disabled. If enabled is :read-only ,
then the pane shows the text and allows it to be selected without it
being editable. In this case the visual appearance varies between window
systems, but often the text can be copied and the caret position altered
If enabled is any other true value, then the pane is fully enabled.
The default value of enabled is t .
</quote>
I am glad that LW has implemented this as I have had to enforce to
implement this behaviour in the past.
Wade
Wade Humeniuk wrote:
> Ken Tilton wrote:
>
>>
>>
>> Andreas Thiele wrote:
>> > I think
>> >
>> > (defun tp (x) (eq t x))
>> >
>> > makes a little sense in some rare cases when you need to test for t.
>> > ..snip... A library function I'm using (LispWorks
>> > capi:text-input-pane-enabled) returns either t, :read-only or nil.
>>
>> [aside] and it makes little sense for an input pane to be at once
>> enabled and read-only.
>>
>
> It does if you do not want the default greyed-out-default ugliness
> for a text-input-pane when you disable it (at least on windows).
> You can barely see the text when that happens.
Well /that/ sounds wrong, but...
> Also a quote
> from the relevant CAPI Reference Manual
>
> <quote>
> If enabled is nil , the pane is disabled. If enabled is :read-only ,
> then the pane shows the text and allows it to be selected without it
> being editable.
..ah yes, that makes sense. The Right Thing then is that enabled stops
being a flag and becomes a "code" called enabled-for or
allowed-operations, :rw (much better self-doc than merely t), :r, and
nil. (I was too lazy to do that in my code, but when the list expands
from t,nil, and :optr-only to include something else I will, well, Do
the Right Thing.
kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
On Sat, 27 Jan 2007 15:20:52 GMT, Wade Humeniuk
<··················@telus.net> wrote:
>Ken Tilton wrote:
>>
>>
>> Andreas Thiele wrote:
>> > I think
>> >
>> > (defun tp (x) (eq t x))
>> >
>> > makes a little sense in some rare cases when you need to test for t.
>> > ..snip... A library function I'm using (LispWorks
>> > capi:text-input-pane-enabled) returns either t, :read-only or nil.
>>
>> [aside] and it makes little sense for an input pane to be at once
>> enabled and read-only.
>>
>
>It does if you do not want the default greyed-out-default ugliness
>for a text-input-pane when you disable it (at least on windows).
>You can barely see the text when that happens. Also a quote
>from the relevant CAPI Reference Manual
>
Are you aware that you can change the background color by catching
WM_CTLCOLOREDIT for an active edit control, or WM_CTLCOLORSTATIC for a
disabled or read-only edit control? For a rich edit control you can
send EM_SETBKGNDCOLOR.
The problem with portable GUI libraries is they only do half the job
(or less) on any particular platform. A lot of thought was put into
the native Windows, Mac and X APIs. If you actually use them, you
find you seldom need complicated workarounds to get the desired
result.
George
--
for email reply remove "/" from address
"George Neuner" <·········@comcast.net> schrieb im Newsbeitrag ·······································@4ax.com...
> On Sat, 27 Jan 2007 15:20:52 GMT, Wade Humeniuk
> <··················@telus.net> wrote:
> ...
> The problem with portable GUI libraries is they only do half the job
> (or less) on any particular platform. A lot of thought was put into
> the native Windows, Mac and X APIs. If you actually use them, you
> find you seldom need complicated workarounds to get the desired
> result.
> ...
Is there any non-portable Windows GUI library out there for LispWorks?
(a quick browse of cliki didn't reveal any)
Andreas
On Sun, 28 Jan 2007 11:40:49 +0100, Andreas Thiele <······@nospam.com>
wrote:
>
> "George Neuner" <·········@comcast.net> schrieb im Newsbeitrag
> ·······································@4ax.com...
>> On Sat, 27 Jan 2007 15:20:52 GMT, Wade Humeniuk
>> <··················@telus.net> wrote:
>> ...
>> The problem with portable GUI libraries is they only do half the job
>> (or less) on any particular platform. A lot of thought was put into
>> the native Windows, Mac and X APIs. If you actually use them, you
>> find you seldom need complicated workarounds to get the desired
>> result.
>> ...
>
> Is there any non-portable Windows GUI library out there for LispWorks?
> (a quick browse of cliki didn't reveal any)
>
> Andreas
>
Yep. Comes with LispWorks for Windows.
Look at the LispWorks Reference Manual chapter 17 - The WIN32 Package
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"John Thingstad" <··············@chello.no> schrieb im Newsbeitrag ······················@pandora.upc.no...
> On Sun, 28 Jan 2007 11:40:49 +0100, Andreas Thiele <······@nospam.com>
> wrote:
>> ...
>> Is there any non-portable Windows GUI library out there for LispWorks?
>> (a quick browse of cliki didn't reveal any)
>> ...
>
> Yep. Comes with LispWorks for Windows.
> Look at the LispWorks Reference Manual chapter 17 - The WIN32 Package
> ...
LOL - Great!
This part of the manual describes latest DDE technology plus 4 (four) Win32 symbols.
" Note: the WIN32 package is not a supported implementation of the Win32 API. Define your own interfaces to Windows functions as you need - see the LispWorks Foreign Language Interface User Guide and Reference Manual for details."
OK, I understand, just a few FFI(FLI) definitions and I got it.
Andreas
From: Wade Humeniuk
Subject: Re: Is there any eq t test in Common Lisp?
Date:
Message-ID: <%44vh.5056$Fd.1627@edtnps90>
George Neuner wrote:
> On Sat, 27 Jan 2007 15:20:52 GMT, Wade Humeniuk
> <··················@telus.net> wrote:
>
>> Ken Tilton wrote:
>>>
>>> Andreas Thiele wrote:
>>> > I think
>>> >
>>> > (defun tp (x) (eq t x))
>>> >
>>> > makes a little sense in some rare cases when you need to test for t.
>>> > ..snip... A library function I'm using (LispWorks
>>> > capi:text-input-pane-enabled) returns either t, :read-only or nil.
>>>
>>> [aside] and it makes little sense for an input pane to be at once
>>> enabled and read-only.
>>>
>> It does if you do not want the default greyed-out-default ugliness
>> for a text-input-pane when you disable it (at least on windows).
>> You can barely see the text when that happens. Also a quote
>>from the relevant CAPI Reference Manual
>
> Are you aware that you can change the background color by catching
> WM_CTLCOLOREDIT for an active edit control, or WM_CTLCOLORSTATIC for a
> disabled or read-only edit control? For a rich edit control you can
> send EM_SETBKGNDCOLOR.
>
Yes, I am aware of that. However the mod to make a text-input-pane
was simpler that hooking in a callback handle the event. The guts
of CAPI are hidden. If one had the source code, the time and the
will, then sure. But putting a change-callback on the pane and
undoing any changes made to make it read-only was good
enough. Now CAPI has that ability built in somehow.
Though I find the CAPI api somewhat deficient for fine
grained control of its look and feel, its good enough if I
voluntarily restrict my use of it.
> The problem with portable GUI libraries is they only do half the job
> (or less) on any particular platform. A lot of thought was put into
> the native Windows, Mac and X APIs. If you actually use them, you
> find you seldom need complicated workarounds to get the desired
> result.
>
I have done things like that,
(defmethod initialize-instance :after ((obj badge-image) &rest initargs)
(declare (ignore initargs))
(hcl:flag-special-free-action obj))
(defun clean-up-badge-image-instance (obj)
(when (and (typep obj 'badge-image)
(memory-dc obj))
(winapi::|DeleteDC| (memory-dc obj))))
(defvar *special-free-actions* (hcl:add-special-free-action 'clean-up-badge-image-instance))
(defun create-compatible-memory-dc (hdc width height)
(let* ((hcdc (winapi::|CreateCompatibleDC| hdc))
(hbitmap (winapi::|CreateCompatibleBitmap| hdc width height)))
(winapi::|SelectObject| hcdc hbitmap)
(values hcdc hbitmap)))
(defun create-badge-image-dc (gp badge-image)
(with-slots (color0 color1 field-color width height corner-radius) badge-image
(let* ((hdc (gdi::hdc gp))
(color0-pen (winapi::|CreatePen| winapi::PS_SOLID 1 color0))
(color1-pen (winapi::|CreatePen| winapi::PS_SOLID 1 color1))
(color1-brush (winapi::|CreateSolidBrush| color1))
(black-pen (winapi::|GetStockObject| winapi::black_pen))
(black-brush (winapi::|GetStockObject| winapi::black_brush))
(field-brush (winapi::|CreateSolidBrush| field-color)))
(multiple-value-bind (image-dc image-bitmap)
(create-compatible-memory-dc hdc width height)
(gdi::with-gdi-objects (image-dc black-pen black-brush)
(winapi::|Rectangle| image-dc 0 0 width height))
(gdi::with-gdi-objects (image-dc field-brush color0-pen)
(winapi::|RoundRect| image-dc 0 0 width height corner-radius corner-radius))
(gdi::with-gdi-objects (image-dc color0-pen color1-brush)
(winapi::|Rectangle| image-dc 0 0 8 height))
(winapi::|DeleteObject| color0-pen)
(winapi::|DeleteObject| color1-pen)
(winapi::|DeleteObject| color1-brush)
(winapi::|DeleteObject| field-brush)
(values image-dc image-bitmap)))))
(defmethod pixblt-image (badge (image badge-image))
(with-slots (width height memory-dc image-bitmap) image
(if memory-dc
(winapi::|TransparentBlt| (gdi::hdc badge) 0 0 width height
memory-dc 0 0 width height
rgb-black)
(progn
(multiple-value-setq (memory-dc image-bitmap)
(create-badge-image-dc badge image))
(pixblt-image badge image)))))
"Ken Tilton" <·········@gmail.com> schrieb im Newsbeitrag ·······················@newsfe10.lga...
> ...
> [aside] and it makes little sense for an input pane to be at once
> enabled and read-only.
> ...
Like Wade mentioned: I do it so the user can select and copy the content.
Andreas
+ "Andreas Thiele" <······@nospam.com>:
| "Ken Tilton" <·········@gmail.com> schrieb im Newsbeitrag ·······················@newsfe10.lga...
|> ...
|> [aside] and it makes little sense for an input pane to be at once
|> enabled and read-only.
|> ...
|
| Like Wade mentioned: I do it so the user can select and copy the content.
Indeed, this is one of those things that really bother the hell out of
me with GUIs: That diagnostics and error messages always come up in a
monologue box [*] with no way to copy the text. So you're reduced to
copying the error message by hand, or (horrors!) taking a snapshot of
the screen to send off to someone with knowledge to diagnose the
problem. Been there, done that. Kudos to anybody who has the good
sense to oppose this stupidity.
*flame off*
[*] Monologue box: "Dialogue" box with only one button, usually labelled
"OK" though stronger language is usually more appropriate. Also used
about boxes with two buttons ("OK" and "Cancel") where both buttons
perform the same action (i.e., closing the window).
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Is there any eq t test in Common Lisp?
Date:
Message-ID: <1170068446.11824.6.camel@qrnik>
Dnia 27-01-2007, sob o godzinie 19:48 +0100, Harald Hanche-Olsen
napisał(a):
> Indeed, this is one of those things that really bother the hell out of
> me with GUIs: That diagnostics and error messages always come up in a
> monologue box [*] with no way to copy the text.
In Linux, both in GNOME and KDE, you can copy text from such windows.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Mark Hurd
Subject: Re: Copying from message boxes (was Re: Is there any eq t test in Common Lisp?)
Date:
Message-ID: <45bd61b8_1@news.iprimus.com.au>
"Harald Hanche-Olsen" <······@math.ntnu.no> wrote in message
····················@shuttle.math.ntnu.no...
> [*] Monologue box: "Dialogue" box with only one button, usually
> labelled
> "OK" though stronger language is usually more appropriate. Also used
> about boxes with two buttons ("OK" and "Cancel") where both buttons
> perform the same action (i.e., closing the window).
Just FYI: since Win2K message boxes copy their text to the clipboard on
Ctrl+C. (There is still a beep as if it was rejected, and the text looks
like it was some sort of debugging feature that someone forgot to turn
off, but it's still there in WinXP.)
--
Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)
"Kaz Kylheku" <········@gmail.com> writes:
> On Jan 26, 6:34 am, "Andreas Thiele" <······@nospam.com> wrote:
>> Hi,
>>
>> I'm just wondering if there is no predefined synonym for
>>
>> (defun t-p (x) (eq t x))?
>
> This would be just as silly as
>
> #define TRUE 1
> #define ISTRUE(X) (X == TRUE)
>
> in C. (See comp.lang.c FAQ's 9.2 and 9.3). Believe it or not, there are
> some programmers who do this. (And I'm not talking about the lack of
> parentheses in the expansion of X either; I left that bug in just to
> make the example a more realistic depiction of real-world stupidity,
> which is rarely found in nature as a free element, because it's
> frequently compounded).
>
> Just like the way any non-zero (or non-null) value in C serves as true,
> in Common Lisp anything that isn't NIL serves as true. That's how
> ``generalized booleans'' work in Common Lisp, and therefore comparing a
> boolean value to T is a bug.
Indeed, (eq t x) is silly.
If you want to know if x is the symbol t, then you should write (eq 't x).
----- -------------------------
() an empty list in source code.
'() the empty list in data
nil false
'nil the symbol named "NIL".
t some value that is not false, that is, true.
't the symbol named "T".
:true another value that is true.
0 yet another true value.
----- -------------------------
--
__Pascal Bourguignon__ http://www.informatimago.com/
"A TRUE Klingon warrior does not comment his code!"
Pascal Bourguignon wrote:
> "Kaz Kylheku" <········@gmail.com> writes:
>
>> On Jan 26, 6:34 am, "Andreas Thiele" <······@nospam.com> wrote:
>>> Hi,
>>>
>>> I'm just wondering if there is no predefined synonym for
>>>
>>> (defun t-p (x) (eq t x))?
>> This would be just as silly as
>>
>> #define TRUE 1
>> #define ISTRUE(X) (X == TRUE)
>>
>> in C. (See comp.lang.c FAQ's 9.2 and 9.3). Believe it or not, there are
>> some programmers who do this. (And I'm not talking about the lack of
>> parentheses in the expansion of X either; I left that bug in just to
>> make the example a more realistic depiction of real-world stupidity,
>> which is rarely found in nature as a free element, because it's
>> frequently compounded).
>>
>> Just like the way any non-zero (or non-null) value in C serves as true,
>> in Common Lisp anything that isn't NIL serves as true. That's how
>> ``generalized booleans'' work in Common Lisp, and therefore comparing a
>> boolean value to T is a bug.
>
>
> Indeed, (eq t x) is silly.
> If you want to know if x is the symbol t, then you should write (eq 't x).
The constant variable t is specified to return the symbol t, (eq t x)
and (eq 't x) are guaranteed to behave the same.
It is indeed the case that it can be useful to distinguish between being
"just true" and "true with additional information". For example, one
case where this pops up in ANSI CL itself is when you want to define
methods for shared-initialize and have to distinguish the three cases
for its second argument.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
"Pascal Costanza" <··@p-cos.net> schrieb im Newsbeitrag ····················@mid.individual.net...
"Pascal Bourguignon" <···@informatimago.com> schrieb im Newsbeitrag ···················@thalassa.informatimago.com...
>> ...
>> Indeed, (eq t x) is silly.
>> If you want to know if x is the symbol t, then you should write (eq 't x).
> ...
I already wondered about my code working, and ...
> The constant variable t is specified to return the symbol t, (eq t x)
> and (eq 't x) are guaranteed to behave the same.
... pooh, this brings me on the lucky side ;)
Pascal Costanza schrieb:
>> Indeed, (eq t x) is silly. If you want to know if x is the symbol t,
>> then you should write (eq 't x).
>
> The constant variable t is specified to return the symbol t, (eq t x)
> and (eq 't x) are guaranteed to behave the same.
I think (the other) Pascal was aware of this. To me it more looked like
a good style suggestion.
Andr�
--
"André Thieme" <······························@justmail.de> schrieb im Newsbeitrag ·················@registered.motzarella.org...
> Pascal Costanza schrieb:
>
>>> Indeed, (eq t x) is silly. If you want to know if x is the symbol t,
>>> then you should write (eq 't x).
>>
>> The constant variable t is specified to return the symbol t, (eq t x)
>> and (eq 't x) are guaranteed to behave the same.
>
> I think (the other) Pascal was aware of this. To me it more looked like
> a good style suggestion.
>
>
> André
> --
Mmmm,
I don't know if it is really good style writing 't if t definitely does the job.
OK it's just one character, but I appreciate succintness :)
Andreas
Andreas Thiele wrote:
> "Andr� Thieme" <······························@justmail.de> schrieb im Newsbeitrag ·················@registered.motzarella.org...
>> Pascal Costanza schrieb:
>>
>>>> Indeed, (eq t x) is silly. If you want to know if x is the symbol t,
>>>> then you should write (eq 't x).
>>> The constant variable t is specified to return the symbol t, (eq t x)
>>> and (eq 't x) are guaranteed to behave the same.
>> I think (the other) Pascal was aware of this. To me it more looked like
>> a good style suggestion.
>>
>> Andr�
>> --
>
> Mmmm,
>
> I don't know if it is really good style writing 't if t definitely does the job.
> OK it's just one character, but I appreciate succintness :)
I think this falls in the same category as the question whether one
writes (lambda ...) or #'(lambda ...). That is, it is a matter of taste...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Tue, 30 Jan 2007 13:30:45 +0100, Pascal Costanza <··@p-cos.net> wrote:
> Andreas Thiele wrote:
>> "Andr� Thieme" <······························@justmail.de> schrieb im
>> Newsbeitrag ·················@registered.motzarella.org...
>>> Pascal Costanza schrieb:
>>>
>>>>> Indeed, (eq t x) is silly. If you want to know if x is the symbol
>>>>> t, then you should write (eq 't x).
>>>> The constant variable t is specified to return the symbol t, (eq t x)
>>>> and (eq 't x) are guaranteed to behave the same.
>>> I think (the other) Pascal was aware of this. To me it more looked like
>>> a good style suggestion.
>>>
>>> Andr�
>>> --
>> Mmmm,
>> I don't know if it is really good style writing 't if t definitely
>> does the job.
>> OK it's just one character, but I appreciate succintness :)
>
> I think this falls in the same category as the question whether one
> writes (lambda ...) or #'(lambda ...). That is, it is a matter of
> taste...
>
>
> Pascal
>
>
t and (lambda
works for me. Why add extra line noise?
For the record (as you know):
(quote t) evals to t
t also evals to t
No diference there then.
lambda evals to (function (lambda
so no difference there either.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad schrieb:
> t and (lambda
> works for me. Why add extra line noise?
Is it noise or extra information?
Some people see that as documentation of their code.
--
Andr�