I have played with two sets of bindings for OpenGL, known here as
open-g-l. One binding preserved the studly caps:
(glMatrixMode GL_PROJECTION)
...and come to think of it went with another C convention, all caps for
constants. The CL-SDL crowd is Lispy on this:
(gl:matrix-mode gl:+protection+)
Note the neat use of the package qualifier to get the prefix in there.
Unfortunately, the ":+" sequence to do that with constants grates a little.
Anyway, Cello will have some new bindings done in native UFFI. (CL-SDL
is UFFI-ized thru the miracles of macros, if I understand what I am
looking at.)
So what to do? When in Rome, do-as-romans-do. But when you are at the
Chinese embassy in Rome... romansGoHome?
i think a deciding factor might be that the OpenGL doc of course shows
glMatrixMode.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton wrote:
> I have played with two sets of bindings for OpenGL, known here as
> open-g-l. One binding preserved the studly caps:
>
> (glMatrixMode GL_PROJECTION)
Part of this studly caps style comes from C where you do not packages.
The initial "gl" is much better rendered as a package.
>
> ...and come to think of it went with another C convention, all caps for
> constants. The CL-SDL crowd is Lispy on this:
>
> (gl:matrix-mode gl:+protection+)
>
> Note the neat use of the package qualifier to get the prefix in there.
> Unfortunately, the ":+" sequence to do that with constants grates a little.
>
> Anyway, Cello will have some new bindings done in native UFFI. (CL-SDL
> is UFFI-ized thru the miracles of macros, if I understand what I am
> looking at.)
>
> So what to do? When in Rome, do-as-romans-do. But when you are at the
> Chinese embassy in Rome... romansGoHome?
When in Rome.... even the chines should adapt.
On top of that, using studly caps may break some packages in a non
trivial way
even if you are cereful. Using studly caps implies that you
must have set you readtable and print case appropriately, and that is
something that IMHO you should *not* rely on because it is too error prone.
That is just me, but I feel that until the case issue goes away, you are
better off avoiding the studly caps.
>
> i think a deciding factor might be that the OpenGL doc of course shows
> glMatrixMode.
>
That is a non problem, provided that the translation is
well defined. I can always find `glMatrixMode' given
gl:matrix-mode
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti wrote:
> Part of this studly caps style comes from C where you do not packages.
> The initial "gl" is much better rendered as a package.
heh-heh. my code is full of fm-this and mg-that, even though I also have
all those things in their own packages. am i having trouble letting go? :)
> On top of that, using studly caps may break some packages in a non
> trivial way
> even if you are cereful. Using studly caps implies that you
> must have set you readtable and print case appropriately, and that is
> something that IMHO you should *not* rely on because it is too error prone.
Both those sound substantive, but I do not understand either of them. :)
Unless we are talking case-senstive Lisp, does it matter? Are we?
To be clear, I am thinking about going with glMatrixMode, but only when
I type. I know Lisp will throw the s/c away. i might even type glpush if
i am lazy.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
On Sat, Dec 07, 2002 at 03:54:42PM +0000, Kenny Tilton wrote:
> I have played with two sets of bindings for OpenGL, known here as
> open-g-l. One binding preserved the studly caps:
>
> (glMatrixMode GL_PROJECTION)
>
> ...and come to think of it went with another C convention, all caps for
> constants. The CL-SDL crowd is Lispy on this:
>
> (gl:matrix-mode gl:+protection+)
Well, CL uppercases symbols so capitalization turns to mush. Then there
is the ``Modern'' Allegro which takes capitalization much more seriously
(eq 'A 'a) => NIL
And I also think CamelCase is unsightly, but that's just my opinion.
I prefer to stick to lower-case-names-with-dashes, particularly in a
cross-platform, and presumably widely-used library.
> Note the neat use of the package qualifier to get the prefix in there.
> Unfortunately, the ":+" sequence to do that with constants grates a little.
I agree, but it does seem easier to read...
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Kenny Tilton <·······@nyc.rr.com> writes:
> So what to do? When in Rome, do-as-romans-do. But when you are at the
> Chinese embassy in Rome... romansGoHome?
My vote would be for do-as-romans-do (or Do-As-Romans-Do if you really
want capital letters on your screen). :)
> i think a deciding factor might be that the OpenGL doc of course shows
> glMatrixMode.
Will the users of your package have that hard a time translating between
glMatrixMode and gl:matrix-mode?
Gabe Garza
Gabe Garza wrote:
> Will the users of your package have that hard a time translating between
> glMatrixMode and gl:matrix-mode?
It will be the easiest thing in the world. But! Going back to the
Gabriel thread, I have had more luck with software since I started
worrying about these little Messages From God(tm), so...
(1) why introduce psychological friction?
(2) string searches of mixed Lisp and C projects won't work
(3) the anti-studly-caps crowd did not come with anything substantive
when I put it to them recently. I accept and will follow the /Lisp/
standard naming convention, but we did not write OpenGl and we did not
create the names. Isn't it a bit self-absorbed to rename library
functions in glue routines just to preserve a sacred cow? (no offense
intended to those who did. <g>)
Sounds like I just made up my mind..... nah, polls are still open.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton wrote:
>
>
> Gabe Garza wrote:
>> Will the users of your package have that hard a time translating between
>> glMatrixMode and gl:matrix-mode?
>
> It will be the easiest thing in the world. But! Going back to the
> Gabriel thread, I have had more luck with software since I started
> worrying about these little Messages From God(tm), so...
>
> (1) why introduce psychological friction?
>
> (2) string searches of mixed Lisp and C projects won't work
>
> (3) the anti-studly-caps crowd did not come with anything substantive
> when I put it to them recently. I accept and will follow the /Lisp/
> standard naming convention, but we did not write OpenGl and we did not
> create the names. Isn't it a bit self-absorbed to rename library
> functions in glue routines just to preserve a sacred cow? (no offense
> intended to those who did. <g>)
IMHO Studlycaps are just plain unreadable. This is even more so if they get
uppercased internally by the Lispreader. I prefer using an API that looks
like it is a part of Lisp.
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
[gl-matrix-mode vs. glMatrixMode]
> I prefer using an API that looks like it is a part of Lisp.
Amen. If you design a Lisp API, make it look like Lisp. It may look
unfamiliar to people having used GL with other languages, but so will
the rest of Lisp, and they have to get used to it anyway. For Lispers,
there is no value in having the API look like the C++ version - if
they liked C++ so much, they wouldn't use the bindings.
Regards
Henrik
[not picking on Henrik especially, just jumping in here...]
Wow, the "source search" objection to gl:matrix-mode is so powerful no
one will even address it!
:)
OK, the answer is that soon everyone will be using CL and all the source
will be in CL. Then someone will do an opensoucre open-g-l bottom up.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton wrote:
> [not picking on Henrik especially, just jumping in here...]
>
> Wow, the "source search" objection to gl:matrix-mode is so powerful no
> one will even address it!
>
> :)
Well - I thought the "source search" objection is nonsense and therefore did
not address it.
- I would not use mixed sources when using a GL binding for Lisp
- Even if I would search them seperate most of the time because they should
be separate modules
- Even if I want to search for both at the same time it would not be so
difficult that I could stand endless annoyance through _very_ badly chosen
names in my code.
In addition to that - other systems I use already use a gl-matrix-mode
naming scheme (for example the OpenGL module that comes with LispWorks).
So I have actually three reasons why I would not like a sTuDlYcApS naming
scheme:
- It looks butt ugly and is unreadable
- It does not fit well with the other lisp libraries
- It is different to what there is already there
Well I actually see no single good reason to choose sTuDlYcApS.
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt wrote:
> Kenny Tilton wrote:
>
>
>>Wow, the "source search" objection to gl:matrix-mode is so powerful no
>>one will even address it!
>>
> Well - I thought the "source search" objection is nonsense and therefore did
> not address it.
>
> - I would not use mixed sources when using a GL binding for Lisp
> - Even if I would search them seperate most of the time because they should
> be separate modules
I was thinking more about stealing OPC, and if you check this wonderful
site you will find DL-able versions of the tutorials in C, C++, Java,
Python, VB, and Assembler ferChrisSake, but no Lisp.
But CL-SDL has a bunch of them done, god bless 'em:
http://cl-sdl.sourceforge.net/
Speaking of which, in answer to the question, How can we make Lisp even
more perennially popular (perpetual?)? what if one of you guys dashed
off CL versions of those tutorials? (The danger here is that I'll start
on it and never do Cello; 3D gives me a... oh never mind.)
Anyway, I expect to be searching a lot of code not in CL.
> - Even if I want to search for both at the same time it would not be so
> difficult that I could stand endless annoyance through _very_ badly chosen
> names in my code.
_OK_!
>
> In addition to that - other systems I use already use a gl-matrix-mode
> naming scheme (for example the OpenGL module that comes with LispWorks).
oh, thx, didn't know that.
>
> So I have actually three reasons why I would not like a sTuDlYcApS naming
> scheme:
>
> - It looks butt ugly and is unreadable
> - It does not fit well with the other lisp libraries
> - It is different to what there is already there
>
> Well I actually see no single good reason to choose sTuDlYcApS.
becauseThatIsHowTheyAreSpelled? :)
hey, thx for the detailed response.
follow-up Q. do we give a damn about the poor sods who might want to
switch from C++ to CL for OpenGL and gl:slam-head-on-into-push-matrix?
Anyone answering that the difference between glPopMatrix and
gl-pop-matrix should not bother anyone wins.
:)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton wrote:
>
>
> Jochen Schmidt wrote:
>> Kenny Tilton wrote:
>>
>>
>>>Wow, the "source search" objection to gl:matrix-mode is so powerful no
>>>one will even address it!
>>>
>> Well - I thought the "source search" objection is nonsense and therefore
>> did not address it.
>>
>> - I would not use mixed sources when using a GL binding for Lisp
>> - Even if I would search them seperate most of the time because they
>> should
>> be separate modules
>
> I was thinking more about stealing OPC, and if you check this wonderful
> site you will find DL-able versions of the tutorials in C, C++, Java,
> Python, VB, and Assembler ferChrisSake, but no Lisp.
You mean that using a "OpenGL with C++" tutorial with Lisp would be easier
if we don't use names like gl-matrix-mode? I don't think that it would be
very difficult to explain the mapping to newbies.
>
> But CL-SDL has a bunch of them done, god bless 'em:
>
> http://cl-sdl.sourceforge.net/
>
> Speaking of which, in answer to the question, How can we make Lisp even
> more perennially popular (perpetual?)? what if one of you guys dashed
> off CL versions of those tutorials? (The danger here is that I'll start
> on it and never do Cello; 3D gives me a... oh never mind.)
I don't think that I would like a perennially popular CL that got changed in
all parts that might disturb newbies. Newbie-optimizing CL does not give me
any warm feelings.
On the topic of you never doing Cello: It might be interesting to know for
you that I would be more open to a successful opensource CLIM (e. g.
McCLIM). I think that there are opportunities to enhance and extend what is
CLIM today into a modern and useful UIMS.
>> In addition to that - other systems I use already use a gl-matrix-mode
>> naming scheme (for example the OpenGL module that comes with LispWorks).
>
> oh, thx, didn't know that.
>
>>
>> So I have actually three reasons why I would not like a sTuDlYcApS naming
>> scheme:
>>
>> - It looks butt ugly and is unreadable
>> - It does not fit well with the other lisp libraries
>> - It is different to what there is already there
>>
>> Well I actually see no single good reason to choose sTuDlYcApS.
>
> becauseThatIsHowTheyAreSpelled? :)
I know that ;-) - but that is not really more readable to me...
> follow-up Q. do we give a damn about the poor sods who might want to
> switch from C++ to CL for OpenGL and gl:slam-head-on-into-push-matrix?
>
> Anyone answering that the difference between glPopMatrix and
> gl-pop-matrix should not bother anyone wins.
To me it is a difference if I have to use glPopMatrix or gl-pop-matrix in my
code. OpenGL bindings for Lisp are done for Lispers and not for C++ people
that _might_ switch if we choose their ugly naming scheme...
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt wrote:
> Kenny Tilton wrote:
>>I was thinking more about stealing OPC, and if you check this wonderful
>>site you will find DL-able versions of the tutorials in C, C++, Java,
>>Python, VB, and Assembler ferChrisSake, but no Lisp.
>
>
> You mean that using a "OpenGL with C++" tutorial with Lisp would be easier
> if we don't use names like gl-matrix-mode? I don't think that it would be
> very difficult to explain the mapping to newbies.
No, I mean I will have in my source tree all the C++ sample code I can
search for help with glpopmatrix but not gl-pop-matrix.
> I don't think that I would like a perennially popular CL that got changed in
> all parts that might disturb newbies.
changed in all parts?! I am talking about /not/ changing the names in
the OpenGL API.
> On the topic of you never doing Cello: It might be interesting to know for
> you that I would be more open to a successful opensource CLIM (e. g.
> McCLIM). I think that there are opportunities to enhance and extend what is
> CLIM today into a modern and useful UIMS.
I have asked here before about CLIM. Not much enthusiasm. I looked at
CLIM. Didn't light my fire. That's OK, CLers should have alternatives.
> OpenGL bindings for Lisp are done for Lispers ...
fair enough. well, I could always use grep with replace to convert all
the c++ code.
btw, I had already started down the renaming route before reconsidering.
since I was doing the bindings by hand, i wanted to be able to get
what I wanted with as little editing as possible of C declarations.
(defun lisp-fn (n$ &aux ln)
(dotimes (n (length n$) (intern (coerce (nreverse ln) 'string)))
(let ((c (elt n$ n)))
(when (and (upper-case-p c)
(or (lower-case-p (elt n$ (1- n)))
(lower-case-p (elt n$ (1+ n)))))
(push #\- ln))
(push (char-upcase c) ln))))
> (lisp-fn "sTuDlYcApS")
S-TU-DL-YC-AP-S
Hey! Was that a straw man? here is what my uffi-izer maco does:
> (macroexpand
'(dff :void "glGetDoublev" (GLenum pname GLdouble *params )))
(PROGN (DEF-FUNCTION ("glGetDoublev" GL-GET-DOUBLEV)
((PNAME GLENUM) (*PARAMS (* GLDOUBLE))) :RETURNING
:VOID :MODULE
"gl")
(DEFPACKAGE :OPENGL (:EXPORT GL-GET-DOUBLEV)))
That "v" suffix, one of many to show the expected parameter types, would
be hard to hypenate as I would be tempted to do by hand. But the studly
names just trail them off undifferentiated so I am at least no worse off.
Now let me go switch print case to lowercase...
:)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
On Sat, 07 Dec 2002 21:12:54 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> follow-up Q. do we give a damn about the poor sods who might want to
> switch from C++ to CL for OpenGL and gl:slam-head-on-into-push-matrix?
Holy bit! Do you mean that C++ programmers may be scared by symbols like
gl:slam-head-on-into-push-matrix, but they would feel perfectly comfortable
with dynamic typing, s-exps, CLOS, macros and other Common Lisp features?
Bringing Lisp to the C++ masses was so simple, and nobody realized about it
before :) Now that I think about it, Greenspun's Tenth Rule of Programming
may well be some sort of conspiracy to lure Lispers to other languages.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso wrote:
> On Sat, 07 Dec 2002 21:12:54 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>follow-up Q. do we give a damn about the poor sods who might want to
>>switch from C++ to CL for OpenGL and gl:slam-head-on-into-push-matrix?
>
>
> Holy bit! Do you mean that C++ programmers may be scared by symbols like
> gl:slam-head-on-into-push-matrix, but they would feel perfectly comfortable
> with dynamic typing, s-exps, CLOS, macros and other Common Lisp features?
rofl, but...
i was obscure. i should have said "OpenGLers coming from C/C++" seeing
/their/ language sacrificed to a frivolous Lisp naming convention.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
>>>>> "Kenny" == Kenny Tilton <·······@nyc.rr.com> writes:
Kenny> Gabe Garza wrote:
>> Will the users of your package have that hard a time translating
>> between glMatrixMode and gl:matrix-mode?
Kenny> It will be the easiest thing in the world. But! Going back
Kenny> to the Gabriel thread, I have had more luck with software
Kenny> since I started worrying about these little Messages From
Kenny> God(tm), so...
Kenny> (1) why introduce psychological friction?
Seems to me there is more psychological friction in not following the
local (i.e. Lisp) conventions. The users of this code are going to be,
by definition, Lisp programmers. And it's more likely that they are in
fact going to be Lisp programmers who happen to need this
functionality rather than C programmers who for some reason are
trapped in a Lisp project. (Doesn't seem to be a lot of the latter
going around.)
Kenny> (2) string searches of mixed Lisp and C projects won't work
Well, there's grep -i and Emacs searches case-insensitive by default
so all *my* tools are covered. ;-) And since there aren't a lot of
C/Lisp IDE's out there it's unlikely you're going to be doing your
searches in some limited tool that *doesn't* support case-insensitve
searches. Also, if you break from Lisp convention other kinds of
ad-hoc searches across your Lisp code might break--not that any of
these are a good idea in a rigorous sense, but folks may have little
scripts that search for things in their lisp code assuming that things
are named in a lispy way. (No, I can't come up with a good example but
I haven't been doing Lisp programming enough to have built up my own
bag of tricks.)
Kenny> (3) the anti-studly-caps crowd did not come with anything
Kenny> substantive when I put it to them recently.
There is (IMHO) no "substantive" argument for *or* against StudlyCaps,
whimpyCaps, names-with-dashes, or names_with_underscores. But what's
the "substantive" argument for breaking with Lisp style?
FWIW, speaking as a pretty experienced Java programmer who's perfectly
happy using StudlyCaps and doesn't consider them unreadable at all, if
I was looking for a Lisp library to do something and the first thing I
saw when I opened up the docs or example code was a bunch of
nonLispyLookingNames I'd probably pass on that library and look
elsewhere just because I'd figure that whoever wrote it was off on
some weird tangent away from the rest of the Lisp community. Which, is
probably a shallow way to look at the world but life *is* short.
Kenny> I accept and will follow the /Lisp/ standard naming
Kenny> convention, but we did not write OpenGl and we did not
Kenny> create the names. Isn't it a bit self-absorbed to rename
Kenny> library functions in glue routines just to preserve a
Kenny> sacred cow? (no offense intended to those who did. <g>)
Seems to me translations should be into an idiomatic version of the
target language. (That's true of natural language and programming
language translations.) How things are named is just part of the local
idiom.
My $.02.
-Peter
--
Peter Seibel
·····@javamonkey.com
* Kenny Tilton
| (3) the anti-studly-caps crowd did not come with anything substantive when
| I put it to them recently.
Has it not yet dawned on you that you can mechanically translate between
the two conventions? When you type these things in, just type - instead
of the shift key.
One reason to prefer the Lisp style is that you type a-s-c M-tab and get
anti-studly-caps. I have yet to see any abbreviation mode that takes BSC
and returns BogusStudlyCaps. This is, of course, because the retarded
studly-caps convention is /ambiguous/ in its use of case.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
On Sat, 07 Dec 2002 16:39:41 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> when I put it to them recently. I accept and will follow the /Lisp/
> standard naming convention, but we did not write OpenGl and we did not
> create the names. Isn't it a bit self-absorbed to rename library
The CLX authors didn't write Xlib either. As for your poll, I'm Italian, so
do as Romans do.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Kenny Tilton <·······@nyc.rr.com> writes:
> I have played with two sets of bindings for OpenGL, known here as
> open-g-l. One binding preserved the studly caps:
>
>
> (glMatrixMode GL_PROJECTION)
>
> ...and come to think of it went with another C convention, all caps
> for constants. The CL-SDL crowd is Lispy on this:
>
>
> (gl:matrix-mode gl:+protection+)
I think #2 is better, more consistant with existing lisp practices.
One thing I would like to avoid is the need to relearn my intuition on
a per package basis. I guess it is the user or vendor ease of use
argument, I vote for me the user.
Anyway thanks for doing this.
marc
Kenny Tilton wrote:
> Anyway, Cello will have some new bindings done in native UFFI. (CL-SDL
> is UFFI-ized thru the miracles of macros, if I understand what I am
> looking at.)
I forgot to add:
Isn't UFFI great? http://uffi.b9.com/
This little hack could really open the doors to a CL open source fest.
Kudos to Kevin Rosenberg.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> I have played with two sets of bindings for OpenGL, known here as
> open-g-l. One binding preserved the studly caps:
>
> (glMatrixMode GL_PROJECTION)
[2]> (glMatrixMode)
*** - EVAL/APPLY: too few arguments given to GLMATRIXMODE
^^^ - yuk.
We don't just put those dashes in for the hell of it.
> ...and come to think of it went with another C convention, all caps
> for constants. The CL-SDL crowd is Lispy on this:
>
> (gl:matrix-mode gl:+protection+)
If you've gone to the trouble to make it constant, why put the plusses
around it? If you happen to forget that it's constant, the compiler
will remind you. The only reason I can think of is to avoid
cluttering up the namespace, but in that case it might be better to
simply pick a better name for globals than, say, "protection".
*snip*
> So what to do? When in Rome, do-as-romans-do. But when you are at the
> Chinese embassy in Rome... romansGoHome?
Why not both? Don't worry about the paint until you've designed the
chassis and drivetrain.
> i think a deciding factor might be that the OpenGL doc of course shows
> glMatrixMode.
As long as your names are all unique, and derived in some consistent
manner from the names in the documentation, this should be a
non-issue.
-Tim
Tim Daly, Jr. wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>I have played with two sets of bindings for OpenGL, known here as
>>open-g-l. One binding preserved the studly caps:
>>
>> (glMatrixMode GL_PROJECTION)
>
>
> [2]> (glMatrixMode)
>
> *** - EVAL/APPLY: too few arguments given to GLMATRIXMODE
> ^^^ - yuk.
You actually /read/ error messages?! <g> Actually, that's another Good
Sign for Lisp. It's the only place where error messages tell me what
went wrong.
>> (gl:matrix-mode gl:+protection+)
>
>
> If you've gone to the trouble to make it constant, why put the plusses
> around it?
Just copying someone else. I thought it was a Lisp convention I had
missed out on. I /do/ like constants to stand out, though.
> in that case it might be better to
> simply pick a better name for globals than, say, "protection".
No can do, it's in the "C" library header: GL_PROJECTION (I mistyped).
>
> *snip*
>
>>So what to do? When in Rome, do-as-romans-do. But when you are at the
>>Chinese embassy in Rome... romansGoHome?
>
>
> Why not both?
scary. i like it. :)
> Don't worry about the paint until you've designed the
> chassis and drivetrain.
Hey, I'm doing these by hand and the carpal tunnel syndrome this month
has my wrists in braces, so I don't want todo this over. :)
But, hey, folks, someone answer this: what about multi-file searches
where one can expect multiple languages? What's the grep that finds
both matrix-mode and glMatrixMode? "[mM]+atrix[-]*[mM]+ode"?
:)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
In article <··············@nyc.rr.com>, Kenny Tilton wrote:
> But, hey, folks, someone answer this: what about multi-file
> searches where one can expect multiple languages? What's the
> grep that finds both matrix-mode and glMatrixMode?
> "[mM]+atrix[-]*[mM]+ode"?
Actually, I'd probably try "grep -i matrix.*mode" at first, then
move on to "grep -i matrix-*mode" if that found too many, then
move on to "grep [Mm]atrix-?[Mm]ode".[1]
Hey, here's you chance: rewrite grep to accept a closure which
varies the searched-for expression depending on the language of
the file searched.
-- Larry
[1] The "?" assumes I can use GNU grep, of course, or possibly a
Perl one-liner.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
On Sat, 07 Dec 2002 17:23:43 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> But, hey, folks, someone answer this: what about multi-file searches
> where one can expect multiple languages? What's the grep that finds
> both matrix-mode and glMatrixMode? "[mM]+atrix[-]*[mM]+ode"?
^ ^
Aren't the `+'s redundant? Doesn't `[mM]' already match a single occurrence
of `m' or `M'?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso wrote:
> On Sat, 07 Dec 2002 17:23:43 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>But, hey, folks, someone answer this: what about multi-file searches
>>where one can expect multiple languages? What's the grep that finds
>>both matrix-mode and glMatrixMode? "[mM]+atrix[-]*[mM]+ode"?
>
> ^ ^
> Aren't the `+'s redundant? Doesn't `[mM]' already match a single occurrence
> of `m' or `M'?
oh god, it was almost ten years ago in Think C when I last used grep in
anger. it was a doozey, too, not just finding but also replacing.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
In article <··············@bob.intern>, ···@tenkan.org (Tim Daly, Jr.)
wrote:
> > (gl:matrix-mode gl:+protection+)
>
> If you've gone to the trouble to make it constant, why put the plusses
> around it? If you happen to forget that it's constant, the compiler
> will remind you. The only reason I can think of is to avoid
> cluttering up the namespace, but in that case it might be better to
> simply pick a better name for globals than, say, "protection".
This is a style convention. It is used for example in
CLIM. The purpose is to make it clear for a human,
reading code, that the symbol names a constant.
See for example:
http://www.lisp.org/table/style.htm#readability
From: Kenny Tilton
Subject: And the winner is... [Re: Poll: StudlyChallenge]
Date:
Message-ID: <3DF2DB6C.2050407@nyc.rr.com>
Tim Daly, Jr. wrote:
> Why not both?
I was thinking anyway that it would be nice to check glError after each
ogl call, and in the doc at least one place I saw "...argument must be
GL_FRONT or GL_BACK", and I thought it would be nice to have my
binding-generating macro accept a block of code to be executed before
the API call, so... I can expand into a raw binding that has the
sameStudlyName and also a defun that-does-not and which adds the extras
(which will be conditionalized with #+cello-opengl-safeguards or some
such to avoid a performance hit. I can also coerce parameters values to
the proper type, something I mistakenly thought FFIs took care of.
The tide of C++ers switching over will get the world they know (spelling
and absence of safeguards) but discover CLers using something else and
probably just get on board. If we dis their culture up front it could
make the fur fly, this way it is up to them, no one is forcing anything
on them.
As for my searching-OPC problem, well, duhhhh. All the code will be in C
or C++, I search on the camelCase spelling.
:)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
>
> I was thinking anyway that it would be nice to check glError after
> each ogl call, and in the doc at least one place I saw "...argument
> must be GL_FRONT or GL_BACK", and I thought it would be nice to have
> my binding-generating macro accept a block of code to be executed
> before the API call, so... I can expand into a raw binding that has
> the sameStudlyName and also a defun that-does-not and which adds the
> extras (which will be conditionalized with #+cello-opengl-safeguards
> or some such to avoid a performance hit. I can also coerce
> parameters values to the proper type, something I mistakenly thought
> FFIs took care of.
I did something similar once, coincidentally for another 3D graphics
API.
I ran into some similar naming issues. The API had functions with
names like Q3Vector3D_Cross. I figured if I turned that into
q3-vector-3d-cross it would be both (i) aesthetically consistent with
lisp and (ii) mechanically derivable from the original API function
and therefore easily guessable by someone using reference materials
for C programmers. The latter was not as important to me as the
former.
(I've gone back and forth on whether it was a mistake to include the
q3- prefix as part of the function names even though they were already
in the Q3 package. I mostly think it was OK, just because it feels
good to me. It helps that these functions were rarely needed once I
built a higher-level API on top of them; the q3-prefix always made it
very clear that something primitive was going on in code that used
them.)
I also did what you are thinking of and made these functions wrappers
that added a little extra functionality around the raw API calls. I
defined several macros to do most of the work in generating the
wrappers.
Here's an example:
(def-q3-returns-status q3-light-set-brightness ((light #$kQ3ShapeTypeLight) (brightness float))
#_Q3Light_SetBrightness)
That form defines a wrapper function that
* Checks that the first arugment is a pointer to a Q3ShapeTypeLight
object (the API had its own pretty nice little type system). These
type checks could be turned off if speed were an issue. It never
was.
* Coerces the second argument to a float, if possible.
* Calls the shared library entry point Q3Light_SetBrightness.
* Checks the return value and signals a lisp error on failure, using
some other API calls to get information about what went wrong.
I had a few other wrapper-defining macros to handle functions that
were predicates, register allocated objects for finalization, etc.
It all worked out pretty well.
John Wiseman
From: Kenny Tilton
Subject: Re: And the winner is... [Re: Poll: StudlyChallenge]
Date:
Message-ID: <3DFAF590.7060003@nyc.rr.com>
John Wiseman wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>>I was thinking anyway that it would be nice to check glError after
...
> I did something similar once, coincidentally for another 3D graphics
> API.
QuickDraw3D. I played with your stuff many moons ago under MCL.
>
> I ran into some similar naming issues. The API had functions with
> names like Q3Vector3D_Cross. I figured if I turned that into
> q3-vector-3d-cross it would be both (i) aesthetically consistent with
> lisp and (ii) mechanically derivable from the original API function
> and therefore easily guessable by someone using reference materials
> for C programmers. The latter was not as important to me as the
> former.
<grumble> i am definitely not having fun deleting hyphens from names so
I can search C/C++ example code. :)
>
> (I've gone back and forth on whether it was a mistake to include the
> q3- prefix as part of the function names even though they were already
> in the Q3 package.
I still have prefixes in. Not worrying about it now, worrying more about
getting up to speed on ogl. :)
I mostly think it was OK, just because it feels
> good to me. It helps that these functions were rarely needed once I
> built a higher-level API on top of them; the q3-prefix always made it
> very clear that something primitive was going on in code that used
> them.)
Boy does ogl scream out for a higher-level api.
>
> I also did what you are thinking of and made these functions wrappers
> that added a little extra functionality around the raw API calls. I
> defined several macros to do most of the work in generating the
> wrappers.
>
> Here's an example:
>
> (def-q3-returns-status q3-light-set-brightness ((light #$kQ3ShapeTypeLight) (brightness float))
> #_Q3Light_SetBrightness)
>
> That form defines a wrapper function that
>
> * Checks that the first arugment is a pointer to a Q3ShapeTypeLight
> object (the API had its own pretty nice little type system). These
> type checks could be turned off if speed were an issue. It never
> was.
>
> * Coerces the second argument to a float, if possible.
>
> * Calls the shared library entry point Q3Light_SetBrightness.
>
> * Checks the return value and signals a lisp error on failure, using
> some other API calls to get information about what went wrong.
>
> I had a few other wrapper-defining macros to handle functions that
> were predicates, register allocated objects for finalization, etc.
>
> It all worked out pretty well.
I can imagine. I'm well on the way along those lines over here. It is
such a joy to type 0 instead of 0f0 or 0d0 and worrying if I have it
right. And tonight while going crazy over what I thought was a poor
understanding of ogl geometry I decided to investigate those "benign"
errors coming out of my pop-matrix calls. oops.
I do not know how many people are out there playing with 3D graphics,
but I started thinking this might be a "killer app" for Lisp. There are
so many opportunities to provide higher level constructs. especially
with-style macros. There is so much boiler-plate code to be automated. I
also see many opportunities to trap programmer errors, besides just
casting the argument types.
Then we take it to the next level: scene graph management powered by
CLOS (and modelling powered by Cells). OpenRM, move over. :)
Speaking of which, Cello may get renamed soon. I just noticed the
apparently dead Fahrenheit scene graph project SGI and MS started on.
Now I'm thinking... Celsius?
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
From: Larry Clapp
Subject: Re: And the winner is... [Re: Poll: StudlyChallenge]
Date:
Message-ID: <drufta.505.ln@127.0.0.1>
In article <················@nyc.rr.com>, Kenny Tilton wrote:
> <grumble> i am definitely not having fun deleting hyphens from
> names so I can search C/C++ example code. :)
Seriously, why don't you write a script or Emacs (or whatever)
function to do that for you? Highlight the name, press a key,
and presto.
-- L
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Kenny Tilton <·······@nyc.rr.com> writes:
[SNIP]
> Speaking of which, Cello may get renamed soon. I just noticed the
> apparently dead Fahrenheit scene graph project SGI and MS started
> on. Now I'm thinking... Celsius?
Why not "Anders"? Slightly more obscure, possibly, but it suggests
combining things in a way that "Celsius" doesn't.
//Ingvar
--
Self-referencing
Five, seven, five syllables
This haiku contains
Kenny Tilton <·······@nyc.rr.com> writes:
> I have played with two sets of bindings for OpenGL, known here as
> open-g-l. One binding preserved the studly caps:
>
> (glMatrixMode GL_PROJECTION)
>
> ...and come to think of it went with another C convention, all caps for
> constants. The CL-SDL crowd is Lispy on this:
>
> (gl:matrix-mode gl:+protection+)
I greatly prefer the latter. My brain can parse both, and in both
cases, it parses them as:
|gl| |Matrix Mode|
and
|gl| |protection|
(btw, you wrote "projection" in one, and "protection" in the other)
The "gl" part is the package. In CL, it's nice to not have to clutter
my code with package prefixes when I'm using the package a lot. Are
you planning on having OpenGL:glMatrixMode as the symbol? That's kind
of redundant, don't you think?
The difference between MatrixMode and matrix-mode is pretty important,
I think. In the context of Lisp, MatrixMode seems foreign, it seems
not on par with the contents of the CL package, or the contents of all
of my modules. As someone who writes in lowercase-with-dashes, I
don't like it. I wouldn't want those symbols in my code, and they're
hard to type. More shifting = sad wrists.
So, if I were to use ytour StudlyOpenGLModule, the first thing I would
do is create a lisp-naming-convention-opengl-package, then use that.
Now, let's try the reverse. Let's say I write my code with
StudlyCaps. Presumably[*], I don't write using StudlyCL, which is
much like CL, but with all the dashes removed. Thus, my code probably
looks like this:
(Defun EvensOnly (list)
(Remove-If #'Oddp list))
or even:
(Defun Evens-Only (list)
(Remove-If #'Oddp list))
This means that I'm using either Lispy-Studly-Caps, or at least my eye
doesn't rate Lispy-Studly-Caps symbols as second-class citizens next
to TrueStudlyCaps ones. Thus, I would be fine writing Matrix-Mode or
MatrixMode. Either one is fine.
My conclusion? StudlyLispers, Lispy-Studs, and quiet-lispers would
all be able to use your OpenGL module with no issues, were it written
by a Lispy-Stud or a quiet-lisper. However, quiet-lispers and some
Lispy-Studs would be at minimum somewhat nonplussed to have to use the
same module written by a StudlyLisper. Using dashes to delimit words
give the users of your package the most flexibility in choosing what
style they want to use.
The other issues (is :+ attrocious? what about grep?) come second, in
my mind, to the question of whether the module author's style will be
antisocial, or whether it will degrade gracefully in a social context.
Finally, the minor issues:
* grep? You know how to program, right? ;-) If your transformation
from StudlyCaps to lispy-dashes uses well-defined rules, then you
can apply those rules to your regexp's. Make them reversable, and
you can feed your thin-grep-wrapper either style of regexp.
> Note the neat use of the package qualifier to get the prefix in there.
> Unfortunately, the ":+" sequence to do that with constants grates a little.
So, if you don't like it, don't use it. Use gl:CONSTANT, and then I
can use gl:constant or gl:Constant or whatever. Claim cl:pi as your
source of inspiration.
> i think a deciding factor might be that the OpenGL doc of course shows
> glMatrixMode.
Yes, but it also defines everything in terms of the C language, right?
If you define a simple, straight-forward rule for transforming the
names, your users will be able to look at glMatrixMode (foo, bar) and
think (gl:matrix-mode foo bar) or (matrix-mode foo bar) or
(gl:Matrix-Mode foo bar) or whatever.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> The "gl" part is the package. In CL, it's nice to not have to clutter
> my code with package prefixes when I'm using the package a lot.
Ah, good, I forgot to ask if folks preferred gl-matrix-mode or
gl:matrix-mode.
thx for the input. i think i have the perfect compromise, hyphenated
wrappers around camelCase raw ffi genned fns. i am remembering now i've
always had the policy of wrapping api's, Just In Case we get a 100k LOC
into a project and discover every call to thisOrThat needs some
housekeeping or logging or whatever. this way we get that, and the diff
spelling advertises "this is not the API call, but close or the names
would not be effectively the same".
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·················@nyc.rr.com...
> I have played with two sets of bindings for OpenGL, known here as
> open-g-l. One binding preserved the studly caps:
>
> (glMatrixMode GL_PROJECTION)
>
> ...and come to think of it went with another C convention, all caps for
> constants. The CL-SDL crowd is Lispy on this:
>
> (gl:matrix-mode gl:+protection+)
I vote for this version, my reasons have been well expressed already (s/c
names are unreadable in the debugger and that roman thing)
> i think a deciding factor might be that the OpenGL doc of course shows
> glMatrixMode.
That takes so few brain-cells to map to gl:matrix-mode that it is a
non-issue, IMACO ("In My Always Correct Opinion" :)
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Kenny Tilton <·······@nyc.rr.com> writes:
> I have played with two sets of bindings for OpenGL, known here as
> open-g-l. One binding preserved the studly caps:
>
>
> (glMatrixMode GL_PROJECTION)
>
> ...and come to think of it went with another C convention, all caps
> for constants. The CL-SDL crowd is Lispy on this:
>
>
> (gl:matrix-mode gl:+protection+)
>
Usually when you have to interface to foreign code you have to do
funky things to the arguments to make the foreign code happy. When I
write a foreign API, I write two levels: a `raw' API that takes and
recieves arguments in the form expected by the foreign code, and a
`user' API that takes and recieves arguments in a lisp-like manner.
So in your example, noting that C++ ENUMs are poor-man's symbols, I'd
define a matrix-mode type as a member of a set of symbols. The
user-level API would deal with these. When passing the symbol to the
raw API, I'd lookup the appropriate ENUM value, call the raw api,
check the return value and throw an error if necessary, and convert
the result (probably an INT, right?) to the appropriate value.
The convention I've always used is that `glMatrixMode' is the name of
the `raw' foreign function and `matrix-mode' is the name of the
corresponding lisp function.
> Usually when you have to interface to foreign code you have to do
> funky things to the arguments to make the foreign code happy. When I
> write a foreign API, I write two levels: a `raw' API that takes and
> recieves arguments in the form expected by the foreign code, and a
> `user' API that takes and recieves arguments in a lisp-like manner.
Yes, my policy, too, and it saves the day because it also gives me an
oppurtunity to satisfy hypen-happy Lispers by spelling the user api as
they wish.
>
> So in your example, noting that C++ ENUMs are poor-man's symbols, I'd
> define a matrix-mode type as a member of a set of symbols.
I see Nils has implicitly seconded this. I am scratching my head, though
to see what this accomplishes over defconstant. Validation? ie, they
cannot get away with a raw 42, they have to supply a known enum? ie,
we're kinda doing type safety here? If so, cool, I like it!
but then that means they have to type:
(gl:matrix-mode 'gl:+projection+)
with a single-quote, yes? starting to look like perl. :)
well, matrix-mode could be a macro, then I could spare them specifying
the package /and/ type check at...wait for it...compile time!
:)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> but then that means they have to type:
>
> (gl:matrix-mode 'gl:+projection+)
>
> with a single-quote, yes? starting to look like perl. :)
>
> well, matrix-mode could be a macro, then I could spare them specifying
> the package /and/ type check at...wait for it...compile time!
Not if you do as I suggested:
(setq gl:+projection+ 'gl:+projection+)
will spare you the quote and
(setf (get gl:+projection+ 'gl::c-value) 42)
will spare you a global hash table.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche <······@cartan.de> writes:
> Not if you do as I suggested:
>
> (setq gl:+projection+ 'gl:+projection+)
>
> will spare you the quote and
>
> (setf (get gl:+projection+ 'gl::c-value) 42)
>
> will spare you a global hash table.
And since GL:+PROJECTION+ is no longer a constant, you can lose the
surrounding + characters and spare some typing.
"Carl Shapiro" <·············@panix.com> wrote in message
····················@panix3.panix.com...
> Nils Goesche <······@cartan.de> writes:
>
> > Not if you do as I suggested:
> >
> > (setq gl:+projection+ 'gl:+projection+)
> >
> > will spare you the quote and
> >
> > (setf (get gl:+projection+ 'gl::c-value) 42)
> >
> > will spare you a global hash table.
>
> And since GL:+PROJECTION+ is no longer a constant, you can lose the
> surrounding + characters and spare some typing.
Once you have a symbol that evaluates to itself, is there any reason why you
wouldn't use a keyword symbol, rather than intern it in the gl package?
Could you not reduce this down to
(setf (get :projection 'gl::c-value) 42) ?
GB
"Glenn Burnside" <·········@austin.rr.com> writes:
> "Carl Shapiro" <·············@panix.com> wrote in message
> ····················@panix3.panix.com...
> > Nils Goesche <······@cartan.de> writes:
> >
> > > Not if you do as I suggested:
> > >
> > > (setq gl:+projection+ 'gl:+projection+)
> > >
> > > will spare you the quote and
> > >
> > > (setf (get gl:+projection+ 'gl::c-value) 42)
> > >
> > > will spare you a global hash table.
> >
> > And since GL:+PROJECTION+ is no longer a constant, you can lose
> > the surrounding + characters and spare some typing.
Well, you could do (defconstant gl:+projection+ 'gl:+projection+)
Makes it visually apparent that gl:+projection+ is just some constant
flag and not something more complicated.
> Once you have a symbol that evaluates to itself, is there any reason
> why you wouldn't use a keyword symbol, rather than intern it in the
> gl package? Could you not reduce this down to
>
> (setf (get :projection 'gl::c-value) 42) ?
You could but why lose the additional information that PROJECTION is a
GL constant? And you could get rid of GL:+PROJECTION+ by doing
(delete-package "GL") when you don't need it anymore.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>but then that means they have to type:
>>
>> (gl:matrix-mode 'gl:+projection+)
>>
>>with a single-quote, yes? starting to look like perl. :)
>>
>>well, matrix-mode could be a macro, then I could spare them specifying
>>the package /and/ type check at...wait for it...compile time!
>
>
> Not if you do as I suggested:
>
> (setq gl:+projection+ 'gl:+projection+)
>
> will spare you the quote
doh! (slowly coming up to speed)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Joe Marshall <···@ccs.neu.edu> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > (gl:matrix-mode gl:+protection+)
>
> So in your example, noting that C++ ENUMs are poor-man's symbols, I'd
> define a matrix-mode type as a member of a set of symbols. The
> user-level API would deal with these. When passing the symbol to the
> raw API, I'd lookup the appropriate ENUM value, call the raw api,
> check the return value and throw an error if necessary, and convert
How about
CL-USER 100 > (setf gl:+protection+ 'gl:+protection+
(get 'gl:+protection+ 'gl::c-value) 42)
42
CL-USER 101 > gl:+protection+
GL:+PROTECTION+
CL-USER 102 > (get 'gl:+protection+ 'gl::c-value)
42
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0