Feeling the bits between your toes?

  • Permalink
  • submit to reddit
  • Email
  • Follow


I once read a quotation something like "I like Lisp. It lets you feel 
the bits between your toes."  When I first read it, I thought "huh?", 
and I haven't had any flashes of enlightenment since.

Digging for material, I found Drew McDermott on 2003/10/20: "I think I 
was regretting the demise of the facility in many Lisps that let you 
coerce a fixnum to a pointer and back again (just like C!). It was at a 
talk given by Steele about what Common Lisp was shaping up to be like, 
and I said that one nice thing about pre-Common Lisps was that 'you 
could feel the bits between your toes' when you programmed in them. I 
now think I was wrong." <-- This quote is taken out of context, so don't 
beat up on Drew.

Ray Dillinger, a few days ago:

> Lisp presents an abstract machine that has to be considered as a mathematical 
> entity, driven by theory; you can make it do anything, in its own terms, but 
> its relationship to the physical entity (sequential memory machine, register 
> CPU, etc) on your desk is at best tenuous and ill-defined.  I wind up feeling 
> clumsy, like I've got padded gloves on.  It's just a perception; Lisp is 
> still the best language there is for describing operations on _information_.  
> But there's something unsatisfying about it, I guess, in that it doesn't 
> describe operations on _the_machine_.
> 
> I guess that was part of the reason I set out to implement my own Lisp; 
> I wanted to have that feeling of precise control back, I wanted to know 
> exactly what machine code and what byte representation every lisp operation 
> and datum had.  Instead, I can't shake the feeling that I just know more and
> more about the gloves I'm wearing that make me feel clumsy.

So Drew's quote gives me a bit of a clue: the pre-Common Lisps 
apparently had a lot more "stuff" in them for low level programming.

I suffer from a bit of a (nah, a HUGE) mental disconnect when I read 
about Lisp Machines with operating systems written entirely in Lisp, 
perhaps because I've been trying to visualize just CL with, say, 
primitives for reading and writing absolute memory locations and the CPU 
interrupt flag. I think it would be a real bear (sorry Ray!) to write an 
operating system with that for a tool. But I recognize that I'm coming 
to this from a Linux kernel hacker's perspective, and that a Lisp 
operating system would be a lot different.

What can I read to understand more about LispOS implementations and the 
special features of the Lisps that helped them?


-- 
Cameron MacKinnon
Toronto, Canada

0
Reply nn9925 (361) 4/7/2004 8:45:20 PM

See related articles to this posting


Cameron MacKinnon wrote:
> I once read a quotation something like "I like Lisp. It lets you feel 
> the bits between your toes."  When I first read it, I thought "huh?", 
> and I haven't had any flashes of enlightenment since.
> 
> Digging for material, I found Drew McDermott on 2003/10/20: "I think I 
> was regretting the demise of the facility in many Lisps that let you 
> coerce a fixnum to a pointer and back again (just like C!). It was at a 
> talk given by Steele about what Common Lisp was shaping up to be like, 
> and I said that one nice thing about pre-Common Lisps was that 'you 
> could feel the bits between your toes' when you programmed in them. I 
> now think I was wrong." <-- This quote is taken out of context, so don't 
> beat up on Drew.
> 
> Ray Dillinger, a few days ago:
> 
>> Lisp presents an abstract machine that has to be considered as a 
>> mathematical entity, driven by theory; you can make it do anything, in 
>> its own terms, but its relationship to the physical entity (sequential 
>> memory machine, register CPU, etc) on your desk is at best tenuous and 
>> ill-defined.  I wind up feeling clumsy, like I've got padded gloves 
>> on.  It's just a perception; Lisp is still the best language there is 
>> for describing operations on _information_.  But there's something 
>> unsatisfying about it, I guess, in that it doesn't describe operations 
>> on _the_machine_.
>>
>> I guess that was part of the reason I set out to implement my own 
>> Lisp; I wanted to have that feeling of precise control back, I wanted 
>> to know exactly what machine code and what byte representation every 
>> lisp operation and datum had.  Instead, I can't shake the feeling that 
>> I just know more and
>> more about the gloves I'm wearing that make me feel clumsy.
> 
> 
> So Drew's quote gives me a bit of a clue: the pre-Common Lisps 
> apparently had a lot more "stuff" in them for low level programming.
> 
> I suffer from a bit of a (nah, a HUGE) mental disconnect when I read 
> about Lisp Machines with operating systems written entirely in Lisp, 
> perhaps because I've been trying to visualize just CL with, say, 
> primitives for reading and writing absolute memory locations and the CPU 
> interrupt flag. I think it would be a real bear (sorry Ray!) to write an 
> operating system with that for a tool. But I recognize that I'm coming 
> to this from a Linux kernel hacker's perspective, and that a Lisp 
> operating system would be a lot different.
> 
> What can I read to understand more about LispOS implementations and the 
> special features of the Lisps that helped them?

You can read the links at

http://fare.tunes.org/LispM.html

to get some information. If you are intent of reading and feel like you 
can afford it, you can order _Lisp Lore: A Guide to Programming the Lisp 
Machine_.

http://tinyurl.com/2rngd

But I think nothing really does the job like actually sitting down to an 
actual LispM and screwing with it for a while.

For what it's worth, you can get some (attenuated) idea by writing LAP 
code routines in lisps that have LAPs (Lisp Assembler Programs). I 
worked on SK8 at Apple for a while; it had some nontrivial parts at a 
certain point written in LAP, mostly by David Vronay, whose chief stated 
reason for liking Lisp was that he could write arbitrary functions in 
assembler.
0
Reply mikel1001 (232) 4/7/2004 9:03:04 PM

Cameron MacKinnon <cmackin+nn@clearspot.net> writes:
> What can I read to understand more about LispOS implementations and
> the special features of the Lisps that helped them?

Here's a recent paper:
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/submissions/Fjeld.pdf

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/
0
Reply lars.spam (356) 4/8/2004 6:32:28 AM

Cameron MacKinnon <cmackin+nn@clearspot.net> writes:

> I suffer from a bit of a (nah, a HUGE) mental disconnect when I read
> about Lisp Machines with operating systems written entirely in Lisp,
> perhaps because I've been trying to visualize just CL with, say,
> primitives for reading and writing absolute memory locations and the
> CPU interrupt flag. I think it would be a real bear (sorry Ray!) to
> write an operating system with that for a tool. But I recognize that
> I'm coming to this from a Linux kernel hacker's perspective, and that
> a Lisp operating system would be a lot different.
> 
> What can I read to understand more about LispOS implementations and
> the special features of the Lisps that helped them?
> 

Sounds like this might be interesting to you then:

http://www.common-lisp.net/project/movitz/
http://www.cs.uit.no/~frodef/los0/

-- 
We learn from history that we do not learn from history.
-- Georg Friedrich Wilhelm Hegel
0
Reply hall.cj (19) 4/8/2004 11:21:59 AM

Cameron MacKinnon  <cmackin+nn@clearspot.net> wrote:
+---------------
| I once read a quotation something like "I like Lisp. It lets you feel 
| the bits between your toes."  When I first read it, I thought "huh?", 
| and I haven't had any flashes of enlightenment since.
| 
| Digging for material, I found Drew McDermott on 2003/10/20: "I think I 
| was regretting the demise of the facility in many Lisps that let you 
| coerce a fixnum to a pointer and back again (just like C!). ...
+---------------

Actually, I'll bet you'll still find such functions under the hoods
of almost all current Common Lisps' FFI facilities. For example, see
CMUCL's ALIEN:SAP-ALIEN and ALIEN:ALIEN-SAP macro/function (resp.):

    SAP-ALIEN converts SAP (a system area pointer see section 6.5)
    to an Alien value with the specified TYPE. TYPE is not evaluated.

    ALIEN-SAP returns the SAP which points to ALIEN-VALUE's data.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607

0
Reply rpw3 (2314) 4/8/2004 11:42:59 AM

Lars Brinkhoff wrote:
> Cameron MacKinnon <cmackin+nn@clearspot.net> writes:
> 
>>What can I read to understand more about LispOS implementations and
>>the special features of the Lisps that helped them?
> 
> Here's a recent paper:
> http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/submissions/Fjeld.pdf

I was aware of Movitz, but hadn't read much more than the website intro 
and the changelog. Lazy of me! I was somewhat concerned that since the 
history (presumably) went:

LispM Lisps -> (toes amputated) -> CL -> (just enough functionality 
added) -> Movitz

....I wouldn't really get an idea of what programming a LispM OS would be 
like just looking at Movitz. Yes, I know, a shameful number of 
unwarranted assumptions. OK, guesses. And not saying I was aware of 
Movitz in my OP was inexcusable.

Anyway, now I've read about Movitz (great work, Frode!) and am 
confidently predicting that Cello will run on it this time next year. 
It's already at the level where you can write a driver for your 
favourite network card in Lisp.

Does anybody who still feels those phantom toes have any more pointers?

Thanks,

-- 
Cameron MacKinnon
Toronto, Canada

0
Reply nn9925 (361) 4/8/2004 5:56:38 PM

Cameron MacKinnon <cmackin+nn@clearspot.net> writes:

> Anyway, now I've read about Movitz (great work, Frode!) and am
> confidently predicting that Cello will run on it this time next year. 
> It's already at the level where you can write a driver for your
> favourite network card in Lisp.

*chuckle*

Then again. Lisp is good at AI (!), so maybe Kenny will write some code
to reverse-engineer the interfaces for any possible 3d accelerator cards.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/17/2004 10:51:59 PM


Rahul Jain wrote:
> Cameron MacKinnon <cmackin+nn@clearspot.net> writes:
> 
> 
>>Anyway, now I've read about Movitz (great work, Frode!) and am
>>confidently predicting that Cello will run on it this time next year. 
>>It's already at the level where you can write a driver for your
>>favourite network card in Lisp.
> 
> 
> *chuckle*
> 
> Then again. Lisp is good at AI (!), so maybe Kenny will write some code
> to reverse-engineer the interfaces for any possible 3d accelerator cards.

Cards? Kenny does not do hardware. Well, there was that regrettable 
incident with a Cherry 2000...

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/18/2004 12:11:06 AM

Kenny Tilton <ktilton@nyc.rr.com> writes:

> Cards? Kenny does not do hardware.

Hmm, maybe that's why he requires special hardware to be able to use his
library.

> Well, there was that regrettable incident with a Cherry 2000...

Do a talk about it at the next Lispnycs meeting!

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/18/2004 3:42:19 AM


Rahul Jain wrote:
> Kenny Tilton <ktilton@nyc.rr.com> writes:
> 
> 
>>Cards? Kenny does not do hardware.
> 
> 
> Hmm, maybe that's why he requires special hardware to be able to use his
> library.

I do not know which is funnier, hearing OpenGL-compatible cards 
described as special hardware or you not knowing about:

    http://www.mesa3d.org/

kenny

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/18/2004 5:51:17 AM

Kenny Tilton <ktilton@nyc.rr.com> writes:

> Rahul Jain wrote:
>> Kenny Tilton <ktilton@nyc.rr.com> writes:
>>
>>>Cards? Kenny does not do hardware.
>> Hmm, maybe that's why he requires special hardware to be able to use
>> his
>> library.
>
> I do not know which is funnier, hearing OpenGL-compatible cards
> described as special hardware

Well, it's not available on any random computer you can find (maybe you
don't care about cheap low end machines, but they exist :). But as I
said before, if you want to be really strict about actually showing what
they're asked to show and not what they're not asked to show, very few
computers at all have OpenGL-compliant cards. But you seemed to find the
strange wedges in your perfect sphere to make it pretty, so I guess
you're happy about it. :)

> or you not knowing about:
>
>     http://www.mesa3d.org/

What does that have to do with movitz? And what does it have to do with
_my_ 3D accelerator on _any_ OS? But if you can convince all the 3D card
vendors out there to open up their specs (I don't think _any_ of them
have their complete specs for their latest cards open any more... maybe
Matrox still publishes partial specs... or maybe they maintain
backwards-compatibility... and I think SiS or whoever owns the Savage
line these days might have published some specs... no idea about Intel's
horrid 3D "accelerators") because otherwise their users will install
Windows and curse at their vendor because they want to be able to use
Cello on movitz or on the latest linux releases, I'll be quite
impressed.

FWIW, I did try to get my 3D drivers installed on linux today. I
couldn't even get the source and proprietary GL lib installed. Looks
like I'm going to have to suffer through trying to use ATI's packages
again... and having to jump through hoops again every time I want to
upgrade XFree86. Grr. And for all I know, it'll still just blank out my
screen every time I start X.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/18/2004 7:27:09 AM


Rahul Jain wrote:

> Kenny Tilton <ktilton@nyc.rr.com> writes:
> 
> 
>>Rahul Jain wrote:
>>
>>>Kenny Tilton <ktilton@nyc.rr.com> writes:
>>>
>>>
>>>>Cards? Kenny does not do hardware.
>>>
>>>Hmm, maybe that's why he requires special hardware to be able to use
>>>his
>>>library.
>>
>>I do not know which is funnier, hearing OpenGL-compatible cards
>>described as special hardware
> 
> 
> Well, it's not available on any random computer you can find (maybe you
> don't care about cheap low end machines, but they exist :).

This is weird, an old fart like me looking to the future and a young pup 
like you worrying about dusty old PC/XTs.  Your bet against Cello is a 
bet against the future of OpenGL. I have an open mind, but isn't that a 
bad bet?

Well, i guess if you have to find a reason not to like Cello (and you 
do) you haven't got much else other than posing as Defender of the VT100.


  But as I
> said before, if you want to be really strict about actually showing what
> they're asked to show and not what they're not asked to show, very few
> computers at all have OpenGL-compliant cards. But you seemed to find the
> strange wedges in your perfect sphere to make it pretty, so I guess
> you're happy about it. :)
> 
> 
>>or you not knowing about:
>>
>>    http://www.mesa3d.org/
> 
> 
> What does that have to do with movitz?

Sorry, did not realize you were still on topic. Why cannot Movitz use 
Mesa3D? I see Movitz intends to offer typical OS services along with a 
lisp implementation. Does that not include a graphics library?

  And what does it have to do with
> _my_ 3D accelerator on _any_ OS? But if you can convince all the 3D card
> vendors out there to open up their specs (I don't think _any_ of them
> have their complete specs for their latest cards open any more... maybe
> Matrox still publishes partial specs... or maybe they maintain
> backwards-compatibility... and I think SiS or whoever owns the Savage
> line these days might have published some specs... no idea about Intel's
> horrid 3D "accelerators") because otherwise their users will install
> Windows and curse at their vendor because they want to be able to use
> Cello on movitz or on the latest linux releases, I'll be quite
> impressed.

In an attempt to understand you, I imagined the long parenthetical aside 
was not there. The sentence got worse.

Why do we need vendor specs if we have the OpenGL spec? Are you talking 
about pain and suffering in re using non-commercial OSes? Isn't pain and 
suffering what non-commercial OSes do best?

> 
> FWIW, I did try to get my 3D drivers installed on linux today. I
> couldn't even get the source and proprietary GL lib installed. Looks
> like I'm going to have to suffer through trying to use ATI's packages
> again... and having to jump through hoops again every time I want to
> upgrade XFree86. Grr. And for all I know, it'll still just blank out my
> screen every time I start X.

Get a Mac.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/18/2004 8:00:41 AM

Kenny Tilton <ktilton@nyc.rr.com> writes:

> This is weird, an old fart like me looking to the future and a young pup
> like you worrying about dusty old PC/XTs.  Your bet against Cello is a
> bet against the future of OpenGL. I have an open mind, but isn't that a
> bad bet?

It's interesting that you call a modern pentium system an XT. I'm not
betting against the existence of OpenGL. As a 3D API, it's rather good. 
It's just not a very good bet for a _portable_ and _visually correct_
UI. It's great for creating cheap FPSes and for creating expensive 3D
modelling and rendering systems. Maybe Cello is secretly trying to be
that 3D FPS bootloader people were talking about at one time. :)

> Well, i guess if you have to find a reason not to like Cello (and you
> do) you haven't got much else other than posing as Defender of the VT100.

A VT100 may be the appropriate analogy with the timeframes appropriately
shifted. It wasn't the best terminal, but it was ubiquitous.

> Sorry, did not realize you were still on topic.

Cello on movitz was the topic. And movitz runs on hardware, some of
which doesn't have 3D acceleration.

> Why cannot Movitz use
> Mesa3D? I see Movitz intends to offer typical OS services along with a
> lisp implementation. Does that not include a graphics library?

Since when did Mesa3D work on any lisp graphics library? Or are you
volunteering to port ZETA-C to Movitz and add support for the linux
kernel API? Or do you assume that movitz is written in C from the start?

>   And what does it have to do with
>> _my_ 3D accelerator on _any_ OS? But if you can convince all the 3D card
>> vendors out there to open up their specs (I don't think _any_ of them
>> have their complete specs for their latest cards open any more... maybe
>> Matrox still publishes partial specs... or maybe they maintain
>> backwards-compatibility... and I think SiS or whoever owns the Savage
>> line these days might have published some specs... no idea about Intel's
>> horrid 3D "accelerators") because otherwise their users will install
>> Windows and curse at their vendor because they want to be able to use
>> Cello on movitz or on the latest linux releases, I'll be quite
>> impressed.
>
> In an attempt to understand you, I imagined the long parenthetical aside
> was not there. The sentence got worse.

Your refusal to believe the reality of how 3D card vendors do their
business explains your delusions as to how portable a library that
requires a fast OpenGL implementation can be.

> Why do we need vendor specs if we have the OpenGL spec? Are you talking
> about pain and suffering in re using non-commercial OSes? Isn't pain and
> suffering what non-commercial OSes do best?

I dunno. Does MS Windows never have any bugs or deficiencies? Isn't
portability what you wanted? Or if you're serious about providing a
cheap, functional LispOS that pays the appropriate taxes to the various
hardware vendors, sign me up. (As a customer, not an employee. ;)

>> FWIW, I did try to get my 3D drivers installed on linux today. I
>> couldn't even get the source and proprietary GL lib installed. Looks
>> like I'm going to have to suffer through trying to use ATI's packages
>> again... and having to jump through hoops again every time I want to
>> upgrade XFree86. Grr. And for all I know, it'll still just blank out my
>> screen every time I start X.
>
> Get a Mac.

I thought you were more interested in targetting the more common
hardware. Stuff that some random person might have in their living room. 
I also fail to see how getting a Mac would make linux drivers for the
video cards shipped with Macs suddenly appear. Or is portability not
your one of your main goals?

:)

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/18/2004 8:47:39 AM

Rahul Jain wrote:
 > Kenny Tilton <ktilton@nyc.rr.com> writes:
 >
 >
 >>This is weird, an old fart like me looking to the future and a young pup
 >>like you worrying about dusty old PC/XTs.  Your bet against Cello is a
 >>bet against the future of OpenGL. I have an open mind, but isn't that a
 >>bad bet?
 >
 >
 > It's interesting that you call a modern pentium system an XT.

Oh, cmon, this is a flamewar, you think I am going to be intellectually 
honest? Speaking of which, I hope by "modern" you mean "since XP came out".


> Cello on movitz was the topic. And movitz runs on hardware, some of
> which doesn't have 3D acceleration.

Oh. I get it. Cello sucks because it won't run on Movitz because Movitz 
won't support OpenGL. Only on systems without OpenGL cards? You still 
need gl and glu libs, even with the cards. No?

> 
> 
>>Why cannot Movitz use
>>Mesa3D? I see Movitz intends to offer typical OS services along with a
>>lisp implementation. Does that not include a graphics library?
> 
> 
> Since when did Mesa3D work on any lisp graphics library?

Hunh? "work on any Lisp gl"? Maybe you misunderstood /my/ stuff. I'll 
try again. What plans does Movitz have now for graphics.

  Or are you
> volunteering to port ZETA-C to Movitz and add support for the linux
> kernel API? Or do you assume that movitz is written in C from the start?

I just noticed Movitz today, so I have not had time to assume much. But 
I hear you saying "Movitz cannot (will not?) do OpenGL". Yes? No?


> Your refusal to believe the reality of how 3D card vendors do their
> business explains your delusions as to how portable a library that
> requires a fast OpenGL implementation can be.

Who says Cello /requires/ a fast OpenGL implementation? I said the GPU 
acceleration was a nice extra.

> ... Isn't
> portability what you wanted?

Portability to any serious Lisp or OS. A serious Lisp can call and be 
called from C, a serious OS can run OpenGL.

>>Get a Mac.
> 
> 
> I thought you were more interested in targetting the more common
> hardware. 

They're doing better. :) And it is a nice commercial market for the 
stuff I want to sell.

> ... Or is portability not
> your one of your main goals?

let's just say I have scaled back as defined above, simply to be 
practical. Cello has one developer, and that count can go down if I have 
to go get a job. so for now the Lisp and the OS have to meet Cello halfway.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/18/2004 10:56:53 AM

All windows versions from win 98 on up ship with openGL.
Af for graphics acceleration this is supported by all modern
graphics cards. Hell I have a motherbord with integrated graphics
and it supports openGL just fine.
(Compaq Presario 2.4 GHz P4 256 Mb RAM)


P� Sun, 18 Apr 2004 10:56:53 GMT, skrev Kenny Tilton <ktilton@nyc.rr.com>:

>
> Rahul Jain wrote:
>  > Kenny Tilton <ktilton@nyc.rr.com> writes:
>  >
>  >
>  >>This is weird, an old fart like me looking to the future and a young 
> pup
>  >>like you worrying about dusty old PC/XTs.  Your bet against Cello is a
>  >>bet against the future of OpenGL. I have an open mind, but isn't that 
> a
>  >>bad bet?
>  >
>  >
>  > It's interesting that you call a modern pentium system an XT.
>
> Oh, cmon, this is a flamewar, you think I am going to be intellectually 
> honest? Speaking of which, I hope by "modern" you mean "since XP came 
> out".
>
>
>> Cello on movitz was the topic. And movitz runs on hardware, some of
>> which doesn't have 3D acceleration.
>
> Oh. I get it. Cello sucks because it won't run on Movitz because Movitz 
> won't support OpenGL. Only on systems without OpenGL cards? You still 
> need gl and glu libs, even with the cards. No?
>
>>
>>
>>> Why cannot Movitz use
>>> Mesa3D? I see Movitz intends to offer typical OS services along with a
>>> lisp implementation. Does that not include a graphics library?
>>
>>
>> Since when did Mesa3D work on any lisp graphics library?
>
> Hunh? "work on any Lisp gl"? Maybe you misunderstood /my/ stuff. I'll 
> try again. What plans does Movitz have now for graphics.
>
>   Or are you
>> volunteering to port ZETA-C to Movitz and add support for the linux
>> kernel API? Or do you assume that movitz is written in C from the start?
>
> I just noticed Movitz today, so I have not had time to assume much. But 
> I hear you saying "Movitz cannot (will not?) do OpenGL". Yes? No?
>
>
>> Your refusal to believe the reality of how 3D card vendors do their
>> business explains your delusions as to how portable a library that
>> requires a fast OpenGL implementation can be.
>
> Who says Cello /requires/ a fast OpenGL implementation? I said the GPU 
> acceleration was a nice extra.
>
>> ... Isn't
>> portability what you wanted?
>
> Portability to any serious Lisp or OS. A serious Lisp can call and be 
> called from C, a serious OS can run OpenGL.
>
>>> Get a Mac.
>>
>>
>> I thought you were more interested in targetting the more common
>> hardware.
>
> They're doing better. :) And it is a nice commercial market for the 
> stuff I want to sell.
>
>> ... Or is portability not
>> your one of your main goals?
>
> let's just say I have scaled back as defined above, simply to be 
> practical. Cello has one developer, and that count can go down if I have 
> to go get a job. so for now the Lisp and the OS have to meet Cello 
> halfway.
>
> kt
>



-- 
Sender med M2, Operas revolusjonerende e-postprogram: http://www.opera.com/
0
Reply john.thingstad (1211) 4/18/2004 3:52:46 PM

Kenny Tilton <ktilton@nyc.rr.com> writes:

> Oh, cmon, this is a flamewar, you think I am going to be intellectually
> honest?

Yeah, but I figured I'd continue the flamewar, duh. If I just ignored
it, you wouldn't have much of a chance to flame back, would you? :P

> Speaking of which, I hope by "modern" you mean "since XP came out".

Yes.

>> Cello on movitz was the topic. And movitz runs on hardware, some of
>> which doesn't have 3D acceleration.
>
> Oh. I get it. Cello sucks because it won't run on Movitz because Movitz
> won't support OpenGL.

Nah, that's not why it sucks. :)

I was merely claiming that you won't be able to _usably_ use OpenGL on
movitz any better than you could use OpenGL with a Riva128. And that's
assuming you have the latest and greatest CPU. But at least you won't
get ugly rendering artifacts, even if you'll never stick around to look
at what's rendered. ;)

> Only on systems without OpenGL cards? You still need gl and glu libs,
> even with the cards. No?

Yes, and how on earth are you going to make those tolerably fast?

> Hunh? "work on any Lisp gl"? Maybe you misunderstood /my/ stuff. I'll
> try again. What plans does Movitz have now for graphics.

You can write whatever graphics drivers you want for it. Of course,
you'll need to wander around Silicon Valley with a ski mask and an Uzi
to do that, if you'd like to support most modern 3D accelerators.

> I just noticed Movitz today, so I have not had time to assume much.

But you assume that Mesa will do anything on it... In any case...

> But I hear you saying "Movitz cannot (will not?) do OpenGL". Yes? No?

No. Movitz will not be able to accelerate OpenGL to any reasonable speed
on any reasonably modern hardware without someone from the hardware
vendors' company actively recognizing the existence of Movitz and
budgeting a team to write drivers for it.

>> Your refusal to believe the reality of how 3D card vendors do their
>> business explains your delusions as to how portable a library that
>> requires a fast OpenGL implementation can be.
>
> Who says Cello /requires/ a fast OpenGL implementation? I said the GPU
> acceleration was a nice extra.

Personally, I don't like waiting a second or so in order for the screen
to register that I've clicked on a button. Your tastes may vary.

>> ... Isn't portability what you wanted?
>
> Portability to any serious Lisp or OS. A serious Lisp can call and be
> called from C, a serious OS can run OpenGL.

Of course. A serious OS is only those that have gotten special attention
from overprotective 3D hardware vendors.

>> ... Or is portability not your one of your main goals?
>
> let's just say I have scaled back as defined above, simply to be
> practical. Cello has one developer, and that count can go down if I have
> to go get a job. so for now the Lisp and the OS have to meet Cello
> halfway.

You forgot about the hardware and the OS's support for the hardware. :)

An OS can provide an OpenGL implementation, the hardware can provide
OpenGL acceleration, but that doesn't mean that the user will get a
usable OpenGL application if the window has any textures or more than a
hundred polygons.

But it's ok. We have CLIM, which works for all of these situations and
looks exactly how the user has configured the toolkit being used.

Good luck with your 3D Swing-in-Lisp, in any case.

Now where's that bill? ... 15 times ... carry the two ...

;)

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/18/2004 4:08:50 PM

Rahul Jain <rjain@nyct.net> wrote in message news:<87u0zhwu3c.fsf@nyct.net>...
> >> FWIW, I did try to get my 3D drivers installed on linux today. I
> >> couldn't even get the source and proprietary GL lib installed. Looks
> >> like I'm going to have to suffer through trying to use ATI's packages
> >> again... and having to jump through hoops again every time I want to
> >> upgrade XFree86. Grr. And for all I know, it'll still just blank out my
> >> screen every time I start X.
> >
> > Get a Mac.
> 
> I thought you were more interested in targetting the more common
> hardware. Stuff that some random person might have in their living room. 
> I also fail to see how getting a Mac would make linux drivers for the
> video cards shipped with Macs suddenly appear. Or is portability not
> your one of your main goals?
> 
> :)

Isn't the common, random computer owning person using windows on a
machine with a 3d card?
0
Reply knos (12) 4/18/2004 4:17:11 PM

knos@free.fr (n++k) writes:

> Isn't the common, random computer owning person using windows on a
> machine with a 3d card?

Depends if you're talking about accelerators or decelerators. :)

Most computers provide 3d acceleration. There are a few at the low end
that don't, or don't provide anything of value in that department. The
accuracy of the rendering is another question, and I'm sure those
decelerators are even worse than, say, a Radeon 9600.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/18/2004 4:27:14 PM

>>>>> "RJ" == Rahul Jain <rjain@nyct.net> writes:
[...]
    >> Only on systems without OpenGL cards? You still need gl and glu
    >> libs, even with the cards. No?

    RJ> Yes, and how on earth are you going to make those tolerably
    RJ> fast?

They are already tolerably fast, IMHO.  I use opengl mainly out of
convenience for mostly 2D stuff and even with P-IIIs and sw-only
implementations or win32 under vmware it is tolerably fast (in fact it
is fast enough that I dunno what it is I am tolerating).

[...]
    RJ> Personally, I don't like waiting a second or so in order for
    RJ> the screen to register that I've clicked on a button. Your
    RJ> tastes may vary.

This doesn't sound right even adjusting for flamewar exaggeration.
Either Kenny is doing something very fancy for aesthetics or he
miscoded something in a particularly inefficient way.  When I have 
cycles to spare, I'll take a look.  But he'll most likely fix it 
before that. 

[...]
    RJ> An OS can provide an OpenGL implementation, the hardware can
    RJ> provide OpenGL acceleration, but that doesn't mean that the
    RJ> user will get a usable OpenGL application if the window has
    RJ> any textures or more than a hundred polygons. [...]

I don't have any data on textures but glxgears gets ~250 fps on sw gl 
under linux on a P4 2.6 + a 4 year old matrox card.  That's more than 
a few hundred polygons, no?  

cheers,

BM


0
Reply bm80 (247) 4/18/2004 4:31:40 PM


Bulent Murtezaoglu wrote:
>>>>>>"RJ" == Rahul Jain <rjain@nyct.net> writes:
> 
> [...]
>     >> Only on systems without OpenGL cards? You still need gl and glu
>     >> libs, even with the cards. No?
> 
>     RJ> Yes, and how on earth are you going to make those tolerably
>     RJ> fast?
> 
> They are already tolerably fast, IMHO.  I use opengl mainly out of
> convenience for mostly 2D stuff and even with P-IIIs and sw-only
> implementations or win32 under vmware it is tolerably fast (in fact it
> is fast enough that I dunno what it is I am tolerating).
> 
> [...]
>     RJ> Personally, I don't like waiting a second or so in order for
>     RJ> the screen to register that I've clicked on a button. Your
>     RJ> tastes may vary.
> 
> This doesn't sound right even adjusting for flamewar exaggeration.
> Either Kenny is doing something very fancy for aesthetics or he
> miscoded something in a particularly inefficient way.  When I have 
> cycles to spare, I'll take a look.  But he'll most likely fix it 
> before that.

I do not think Rahul was making a bug report, I think it was just an 
unfair, intellectually dishonest twisting of my words to win a flamewar. 
So (a) I am glad to see I am having such a positive influence on the 
lad, and (b) maybe everyone should put us in their killfiles.

That said, I have a long history of working without worrying about 
performance until the app gets too slow to live with, and then I do a 
Speed Week. I do not write slow code deliberately, but where I know I am 
an ignoramus (OpenGL) I especially defer it as long as possible.

The slowest frame rate I observe is 10fps on the magnificent Light 
Panel. This I believe is almost completely without display lists, 
including all that antialiased text. display list utilization in Cello 
comes and gos, the latter when I realize something did not change shape 
because I have not made the display list Cells-aware and I end up using 
obsolete lists. So why don't I do that?

As it is I can grab a 2d-slider puck tracked by an OpenGL light and 
swing a spotlight smoothly around the screen, with lighting effects on 
all the buttons drawn from scratch as well as the spinning 3d shape. A 
simpler screen runs at 30fps, and even simpler screens have run at 100+ 
fps. So no Speed Week just yet.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/18/2004 5:55:57 PM


Rahul Jain wrote:

> Kenny Tilton <ktilton@nyc.rr.com> writes:
> 
> 
>>Hunh? "work on any Lisp gl"? Maybe you misunderstood /my/ stuff. I'll
>>try again. What plans does Movitz have now for graphics.
> 
> 
> You can write whatever graphics drivers you want for it.

How practical. Where /is/ Peter's book?!


> Personally, I don't like waiting a second or so in order for the screen
> to register that I've clicked on a button. Your tastes may vary.

Hey, if the screen then displays "Sleep of 980 milliseconds completed", 
why not?

> 
> 
>>>... Isn't portability what you wanted?
>>
>>Portability to any serious Lisp or OS. A serious Lisp can call and be
>>called from C, a serious OS can run OpenGL.
> 
> 
> Of course. A serious OS is only those that have gotten special attention
> from overprotective 3D hardware vendors.

Let me guess. You are the Movitz developer assigned to OpenGL 
compatibility, aren't you? I can help with the ski masks.


> But it's ok. We have CLIM,...

Surprise, surprise! Which backend? CLIM->CLX->???

  which works for all of these situations and
> looks exactly how the user has configured the toolkit being used.

As long as its 24x80 ascii text in Courier?

> 
> Good luck with your 3D Swing-in-Lisp, in any case.

Thanks. It is great fun. When I add OpenAL and text-to-speech (anyone 
know a good library?) I expect to lose what remaining contact with 
reality I have.

Speaking of which, time to go skating. Good luck with Movitz as well, 
looks like a cool project.

> 
> Now where's that bill? ... 15 times ... carry the two ...

Bad news. Since Westside Brewery adds the tip automatically, we have 
eliminated your job. Can you do Java?

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/18/2004 6:15:52 PM

Bulent Murtezaoglu <bm@acm.org> writes:

> >>>>> "RJ" == Rahul Jain <rjain@nyct.net> writes:
> [...]
> [...]
>     RJ> An OS can provide an OpenGL implementation, the hardware can
>     RJ> provide OpenGL acceleration, but that doesn't mean that the
>     RJ> user will get a usable OpenGL application if the window has
>     RJ> any textures or more than a hundred polygons. [...]
> 
> I don't have any data on textures but glxgears gets ~250 fps on sw gl 
> under linux on a P4 2.6 + a 4 year old matrox card.  That's more than 
> a few hundred polygons, no?  
> 
> cheers,
> 
> BM

IIRC I can get 30 to 40 fps with Mesa on a Ultrasparc III 450 using
entirely software rendering w/ animation, texture and fog.  Cut the
latter 2 and its considerably above 60- shrink the window and it goes
up from there.  Not that 60 fps is all that wonderful, but these are
complex 3d scenes- not just windows.

If some OpenGL app drags with just a few hundred polygons, the problem
is almost certainly the software and not OpenGL.

Gregm

0
Reply gregm-news (165) 4/18/2004 6:19:41 PM

Kenny Tilton escreveu:
> 
[snipped]

> 
> Thanks. It is great fun. When I add OpenAL and text-to-speech (anyone 
> know a good library?) I expect to lose what remaining contact with 
> reality I have.

If you really want to do this someday you'll need to go after a case by 
case (OS by OS) solution :-|

But I know you're kidding ;-D so this is just a futile observation, right!?

Anyway, kudos for the development of cello so far!

--
Cesar Rabak

0
Reply crabak (131) 4/18/2004 6:32:05 PM

Kenny Tilton wrote:

> As it is I can grab a 2d-slider puck tracked by an OpenGL light and
> swing a spotlight smoothly around the screen, with lighting effects on
> all the buttons drawn from scratch as well as the spinning 3d shape. A
> simpler screen runs at 30fps, and even simpler screens have run at 100+
> fps. So no Speed Week just yet.

Uhm, I'm not sure I got the point: Does cello really /calculate/ the buttons
appearance? I mean in 3d?

I thought cello is going to be a *2d*-gui toolkit that's based on OpenGL
mainly for portability and rendering speed. Your not really planning to
make it (all) 3d, do you?

From the screenshots I've seen it's going to have a little 3d-stuff like
lighting. But I think this is in no way essential to a good gui toolkit and
therefore no argument for performance criticsm. If one would really have to
use a slow OpenGL-implementation this eye-candy could simply be turned off.

feel free to correct me

ts
0
Reply tjs_ng (139) 4/18/2004 7:43:36 PM

Thomas Schilling <tjs_ng@yahoo.de> writes:

> I thought cello is going to be a *2d*-gui toolkit that's based on OpenGL
> mainly for portability and rendering speed. Your not really planning to
> make it (all) 3d, do you?

As I understand it, Quartz Extreme under Mac OSX uses 3D exclusively
(even for 2D stuff) in order to take advantage of hardware
acceleration that is apparantly disappearing from the 2D ops.

OS X 10.3 on the later Apple hardware is a very good demo of what can
be done using OpenGL for all screen drawing operations.

-- 
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
0
Reply david1426 (765) 4/18/2004 9:21:04 PM

One thing you might want to consider is that even brand new systems
don't do GL very well. Consumer-level hardware is designed mainly for
non-current OpenGL access (single intensive game or application), and
has performance issues balancing load from multiple apps. OpenGL can
be useful for a UI, but on existing hardware, the best way to utilize
it would be to define an abstract graphics API that spoke to an OpenGL
"server" over a protocol, so a single OpenGL context could be shared
by multiple apps.
0
Reply heliosc (124) 4/18/2004 9:42:20 PM


Thomas Schilling wrote:
> Kenny Tilton wrote:
> 
> 
>>As it is I can grab a 2d-slider puck tracked by an OpenGL light and
>>swing a spotlight smoothly around the screen, with lighting effects on
>>all the buttons drawn from scratch as well as the spinning 3d shape. A
>>simpler screen runs at 30fps, and even simpler screens have run at 100+
>>fps. So no Speed Week just yet.
> 
> 
> Uhm, I'm not sure I got the point: Does cello really /calculate/ the buttons
> appearance? I mean in 3d?

Vanilla buttons are just 5 polygonse. A scroll bar thumb has a couple 
hundred, I'd say.

> 
> I thought cello is going to be a *2d*-gui toolkit that's based on OpenGL
> mainly for portability and rendering speed. Your not really planning to
> make it (all) 3d, do you?

I got carried away. But you don't get shaded buttons with lighting 
unless the buttons are built of polygons. But I use an orthogonal 
projection.

> 
> From the screenshots I've seen it's going to have a little 3d-stuff like
> lighting. But I think this is in no way essential to a good gui toolkit and
> therefore no argument for performance criticsm. If one would really have to
> use a slow OpenGL-implementation this eye-candy could simply be turned off.
> 

Well, if you want shaded buttons you gotta do something with polygons. 
But, yes, I do not really have to use textures and emit light from 
slider thumbs to do a nice scroll bar, I am just trying to show that 
Cello will take Common Lisp "from worst to first" in GUI power.

My only quibble with what you wrote is that you give any credence at all 
to the idea that OpenGL even in software might be slow. But let's read 
the other messages and see what folks have to say.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/18/2004 11:59:49 PM


Rayiner Hashem wrote:

> One thing you might want to consider is that even brand new systems
> don't do GL very well. Consumer-level hardware is designed mainly for
> non-current OpenGL access (single intensive game or application), and
> has performance issues balancing load from multiple apps. OpenGL can
> be useful for a UI, but on existing hardware, the best way to utilize
> it would be to define an abstract graphics API that spoke to an OpenGL
> "server" over a protocol, so a single OpenGL context could be shared
> by multiple apps.

That works?! Damn. Your hired. When can you start? My dream is to suck 
in some unsuspecting OpenGL/Lisp whizkid and get on with Cells and the 
widgets.

btw, I have found with the Glut that I /am/ able to use my internal 
invalidation scheme (carried over from Mac/win32 environments which work 
by update events) to avoid simply sitting there hogging the cpu 
mindlessly spitting out frames while the user contemplates their next 
ation. the Cpu load drops to negligible, until of course I start 
dragging things around.

I am hoping this makes multiwindows apps viable. If not, I'll keep your 
note in mind. Thx.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/19/2004 12:06:49 AM

Bulent Murtezaoglu <bm@acm.org> writes:

> They are already tolerably fast, IMHO.  I use opengl mainly out of
> convenience for mostly 2D stuff and even with P-IIIs and sw-only
> implementations or win32 under vmware it is tolerably fast (in fact it
> is fast enough that I dunno what it is I am tolerating).

How many polys? What size textures? Antialiasing? Light sources?
Mip-mapping?

> [...]
>     RJ> Personally, I don't like waiting a second or so in order for
>     RJ> the screen to register that I've clicked on a button. Your
>     RJ> tastes may vary.
>
> This doesn't sound right even adjusting for flamewar exaggeration.
> Either Kenny is doing something very fancy for aesthetics or he
> miscoded something in a particularly inefficient way.  When I have 
> cycles to spare, I'll take a look.  But he'll most likely fix it 
> before that.

He's getting 20-25 fps _with_ acceleration on a rather simple screen. 
Less than a dozen sliders, a light source, and a rotating shape. 
Hopefully most of that is cello's overhead, but I don't know what kind
of accelerator/decelerator he has.

> [...]
>     RJ> An OS can provide an OpenGL implementation, the hardware can
>     RJ> provide OpenGL acceleration, but that doesn't mean that the
>     RJ> user will get a usable OpenGL application if the window has
>     RJ> any textures or more than a hundred polygons. [...]
>
> I don't have any data on textures but glxgears gets ~250 fps on sw gl 
> under linux on a P4 2.6 + a 4 year old matrox card.  That's more than 
> a few hundred polygons, no?  

No, that's the example I had in mind. Note that there are no textures. 
Also note that matrox cards 4 years ago were rather decently fast. Not
the fastest, but decent. 4-year-old matrox cards also aren't cheap even
now, but they're the best bet if you want halfway accurate rendering. 

Full 2D texturing is just now becoming tolerable in a UI with recent,
mid-range hardware. But maybe Kenny's decided to target the market that
spends $2000 on their computers. Still, I can hardly tolerate dealing
with the speed of a fully textured UI. On the other hand, I find them to
be rather ugly, so I'm ok with that. :)

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/19/2004 12:11:58 AM


Cesar Rabak wrote:

> Kenny Tilton escreveu:
> 
>>
> [snipped]
> 
>>
>> Thanks. It is great fun. When I add OpenAL and text-to-speech (anyone 
>> know a good library?) I expect to lose what remaining contact with 
>> reality I have.
> 
> 
> If you really want to do this someday you'll need to go after a case by 
> case (OS by OS) solution :-|

Yes, I would love to lose the Glut. Or port it to Lisp. But this Open 
Source Fairy is already maxxed out and thinking dark thoughts about 
focusing on a specific app instead of providing a GUI for a bunch of 
ungrateful yabos, so let's stay Practical. With Frode (sp?) doing great 
things with Movitz tunnelling from the other direction, maybe we can 
meet up sometime for a drop dead Lisp OS.

If only Rahul would stop whining and get on with the OpenGL drivers.

> 
> But I know you're kidding ;-D so this is just a futile observation, right!?

Kidding? About OpenAL or losing my mind or...? Anyway, no, it is not 
futile at all, I am pencilling you in for the native OS X implementation.

> 
> Anyway, kudos for the development of cello so far!

A grateful yabo! Well, thanks.

kenny

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/19/2004 12:17:30 AM

Thomas Schilling <tjs_ng@yahoo.de> writes:

> From the screenshots I've seen it's going to have a little 3d-stuff like
> lighting. But I think this is in no way essential to a good gui toolkit and
> therefore no argument for performance criticsm. If one would really have to
> use a slow OpenGL-implementation this eye-candy could simply be turned off.

No, it's truely 3D. He's using 3D shapes to get the beveled edges you
see in toolkits today (as in not in the 1980s). With that, you need
lighting, of course, to get an actual beveled effect. Unless you want to
have a 1980s-looking UI like classic CLIM.

;)

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/19/2004 12:19:02 AM


David Steuber wrote:

> Thomas Schilling <tjs_ng@yahoo.de> writes:
> 
> 
>>I thought cello is going to be a *2d*-gui toolkit that's based on OpenGL
>>mainly for portability and rendering speed. Your not really planning to
>>make it (all) 3d, do you?
> 
> 
> As I understand it, Quartz Extreme under Mac OSX uses 3D exclusively
> (even for 2D stuff) in order to take advantage of hardware
> acceleration that is apparantly disappearing from the 2D ops.
> 
> OS X 10.3 on the later Apple hardware is a very good demo of what can
> be done using OpenGL for all screen drawing operations.

I think we had this discussion before, but I think it is imperative to 
note that Cello goes further by using OpenGL primitives to build up the 
frames eventually output by, again, OpenGL. The advantage is that I can 
execute a kazillion instructions and have OpenGL compile them and 
remember them as display-list 42. Then the CPU just has to yell out 42 
to the GPU and away we go. the idea being less traffic to the card as 
well as less work for the CPU the second time I render the same stuff. 
What I do not know is how much is saved on the GPU by "compiling" a long 
sequence of GL api calls.

kenny

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/19/2004 12:23:55 AM

Greg Menke <gregm-news@toadmail.com> writes:

> If some OpenGL app drags with just a few hundred polygons, the problem
> is almost certainly the software and not OpenGL.

I'm not sure how Kenny's doing the anti-aliased text in OpenGL, but
ignoring the effects of that, a few hundred polygons (e.g., 300) will
only allow a few dozen (i.e., 75) buttons on the screen. Note that a
scroll bar counts as 4 "buttons" (trough, slider, 2 buttons). That's
quite a small upper limit. All the apps I've created require about that
much UI complexity, at a minimum (although I have to guesstimate for the
effect of text, which was often a large portion of the UI). But hey, if
Kenny is slow enough coding up cello, maybe CPUs will get fast enough to
make it usable.

;)

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/19/2004 12:25:25 AM

Bulent Murtezaoglu <bm@acm.org> writes:

> I don't have any data on textures but glxgears gets ~250 fps on sw gl 
> under linux on a P4 2.6 + a 4 year old matrox card.  That's more than 
> a few hundred polygons, no?  

I think glclock might be a better benchmark. But then again: Try
running Enemy Territory using software rendering...

Regards,
-- 
Julian Stecklina 

Signed and encrypted mail welcome.
Key-Server: pgp.mit.edu         Key-ID: 0xD65B2AB5
FA38 DCD3 00EC 97B8 6DD8  D7CC 35D8 8D0E D65B 2AB5

Any sufficiently complicated C or Fortran program
contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
 - Greenspun's Tenth Rule of Programming
0
Reply der_julian (167) 4/19/2004 12:25:59 AM

Kenny Tilton <ktilton@nyc.rr.com> writes:

>>>Portability to any serious Lisp or OS. A serious Lisp can call and be
>>>called from C, a serious OS can run OpenGL.
>> Of course. A serious OS is only those that have gotten special
>> attention
>> from overprotective 3D hardware vendors.
>
> Let me guess. You are the Movitz developer assigned to OpenGL
> compatibility, aren't you? I can help with the ski masks.

Nope.

>> But it's ok. We have CLIM,...
>
> Surprise, surprise! Which backend? CLIM->CLX->???

"Which backend?" is exactly the question that implies you already know
the answer.

>   which works for all of these situations and
>> looks exactly how the user has configured the toolkit being used.
>
> As long as its 24x80 ascii text in Courier?

Hah.

>> Good luck with your 3D Swing-in-Lisp, in any case.
>
> Thanks. It is great fun. When I add OpenAL and text-to-speech (anyone
> know a good library?) I expect to lose what remaining contact with
> reality I have.

Eh, sound is at least decently standardized and commonly available. Even
though many on-board sound chips do silly things like warble when you
scroll in IE. At least they can turn off the speakers if it sounds bad. 
:P

> Speaking of which, time to go skating. Good luck with Movitz as well,
> looks like a cool project.

Thanks, but wish Frode luck, not me. :)

>> Now where's that bill? ... 15 times ... carry the two ...
>
> Bad news. Since Westside Brewery adds the tip automatically, we have
> eliminated your job. Can you do Java?

Can I... Can I...

:-|

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/19/2004 12:30:17 AM

Cesar Rabak <crabak@acm.org> writes:

> Kenny Tilton escreveu:
> 
>> Thanks. It is great fun. When I add OpenAL and text-to-speech (anyone
>> know a good library?) I expect to lose what remaining contact with
>> reality I have.
>
> If you really want to do this someday you'll need to go after a case by
> case (OS by OS) solution :-|
>
> But I know you're kidding ;-D so this is just a futile observation, right!?

You misunderestimate Kenny. :)

He's already on an OS by OS solution with his attempt at using OpenGL. 
But OpenAL is more likely to be supported more uniformly (I hope). 
Text-to-speech shouldn't be a problem. It's just generating a waveform
which you throw at your sound drivers (OpenAL, in this case).

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/19/2004 12:34:17 AM

heliosc@mindspring.com (Rayiner Hashem) writes:

> One thing you might want to consider is that even brand new systems
> don't do GL very well. Consumer-level hardware is designed mainly for
> non-current OpenGL access (single intensive game or application),

You mean _con_current?

> and has performance issues balancing load from multiple apps.

"Issues"? Mine doesn't even allow it in the first place. And I spent
$220 on the card at a discount mail-order place (and got a free upgrade
to boot).

> OpenGL can be useful for a UI, but on existing hardware, the best way
> to utilize it would be to define an abstract graphics API that spoke
> to an OpenGL "server" over a protocol, so a single OpenGL context
> could be shared by multiple apps.

Not just multiple, but _all_ apps if you want more than one app using
it. And you'd have to write your own windowing system.

Not to mention the hokey rendering artifacts you'll get on any cards
that cost less than $1000.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/19/2004 12:38:40 AM

Kenny Tilton <ktilton@nyc.rr.com> writes:

> If only Rahul would stop whining and get on with the OpenGL drivers.

Where's the budget for my army? A small airforce would be a huge help,
too. Don't think marines would help much, since they're mostly solidly
in the valley. Maybe some paratroopers will be the key.

>> But I know you're kidding ;-D so this is just a futile observation,
>> right!?
>
> Kidding? About OpenAL or losing my mind or...?

Of course you couldn't be kidding about losing your mind. I should know,
I've already lost mine.

:)

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/19/2004 1:05:58 AM


Rahul Jain wrote:

> Bulent Murtezaoglu <bm@acm.org> writes:
> 
> 
>>They are already tolerably fast, IMHO.  I use opengl mainly out of
>>convenience for mostly 2D stuff and even with P-IIIs and sw-only
>>implementations or win32 under vmware it is tolerably fast (in fact it
>>is fast enough that I dunno what it is I am tolerating).
> He's getting 20-25 fps _with_ acceleration on a rather simple screen. 

Without any attention to tuning, including OpenGL tuning, so.... the 
numbers are meaningless, yes? Except that they /will/ get better.

I'd do a Speed Week, but I have enough experience to know performance is 
not going to be a problem, so... not yet.

> Less than a dozen sliders, a light source, and a rotating shape. 

Wow, we had you on Tip Duty? There are two lights, about 33 sliders, 
each with a thumb. Three scroller widgets, a dozen buttons, and maybe 
two-dozen anti-aliased text strings. If you consider that "a rather 
simple screen", I don't want to see one of yours. But!...

> Hopefully most of that is cello's overhead,

Yep. Changing the shape from a cube to "Cello" as an extruded polygon 
(which I can see is done with a kazillion polygons in wireframe mode and 
in texturing) decrease the frame rate from like 10.5 to 9.8. Any other 
shape made no difference, nor did tweaking the number of slices/stacks 
used in constructing the shapes. Turning off the texture has no effect.

  but I don't know what kind
> of accelerator/decelerator he has.

3ghz laptop. I'd go check my GPU, but I think we have ascertained 
already that OpenGL is not the problem. As for Cello, hell, in this case 
I would make the spinning shape a subwindow and watch the FPS go through 
the roof.

Too easy?


> Full 2D texturing is just now becoming tolerable in a UI with recent,
> mid-range hardware. But maybe Kenny's decided to target the market that
> spends $2000 on their computers.  Still, I can hardly tolerate dealing
> with the speed of a fully textured UI. On the other hand, I find them to
> be rather ugly, so I'm ok with that. :)

A $799 eMac comes with a radeon 9200 and 32mb DDR video memory. Good 
graphics cards off the shelf are a ticket to a Broadway play. As for eye 
candy, yeah, nobody likes the way Mac OS X looks. PWUAAUAAHHAHAHAHAH....



kenny


-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/19/2004 1:14:13 AM


Rahul Jain wrote:

> Greg Menke <gregm-news@toadmail.com> writes:
> 
> 
>>If some OpenGL app drags with just a few hundred polygons, the problem
>>is almost certainly the software and not OpenGL.
> 
> 
> I'm not sure how Kenny's doing the anti-aliased text in OpenGL, but
> ignoring the effects of that, a few hundred polygons (e.g., 300) will
> only allow a few dozen...

who said OpenGL can only do 300 polygons. Jeex, one of my scroll bar 
thumbs has that many.

  (i.e., 75) buttons on the screen. Note that a
> scroll bar counts as 4 "buttons" (trough, slider, 2 buttons). That's
> quite a small upper limit. All the apps I've created require about that
> much UI complexity, at a minimum (although I have to guesstimate for the
> effect of text, which was often a large portion of the UI). But hey, if
> Kenny is slow enough coding up cello, maybe CPUs will get fast enough to
> make it usable.

Exactly. When does Movitz ship? Where will hardware be then? Why are you 
clinging to the past? To justify a less capable GUI?

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/19/2004 1:18:59 AM


Rahul Jain wrote:

> Kenny Tilton <ktilton@nyc.rr.com> writes:
> "Which backend?" is exactly the question that implies you already know
> the answer.

Answer? ease up on the paranoia, I do not even understand the question, 
or how CLIM can run on Movitz. All I know about Movitz is that line 
about running on the metal. x86, to be specific. I guess any computer 
can draw to a screen via memory-mapped video, and come to think of it 
that is how I wrote a game in assembler on the 6502, but I wager Movitz 
wants to work a little higher than that. No C? yer gonna do FreeType in 
Lisp?

I'm lost. Wanna throw me a frickin bone and just tell me?

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/19/2004 1:28:17 AM

>>>>> "RJ" == Rahul Jain <rjain@nyct.net> writes:

    RJ> Bulent Murtezaoglu <bm@acm.org> writes:
    >> They are already tolerably fast, IMHO.  I use opengl mainly out
    >> of convenience for mostly 2D stuff and even with P-IIIs and
    >> sw-only implementations or win32 under vmware it is tolerably
    >> fast (in fact it is fast enough that I dunno what it is I am
    >> tolerating).

    RJ> How many polys? What size textures? Antialiasing? Light
    RJ> sources?  Mip-mapping?

Dunno, maybe 200 or so rectangles + 50 or so disks cones and such +
maybe 1kb of stroked text and some 200 or so lines.  A few 64x64
textures (tiled).  Only line anti-aliasing (hinted at best) 1 light
source.  No mipmaps (I haven't learned about them!).  This is with
debug 3 and no effort to increase performance under lispworks.  Strict
GL 1.1 too.  I do use display lists but I do it mostly out of
convenience (so there's a translate in a list called from the actual
draw-object list. That kind of indirection trick can't be efficient).

[...]
    >> I don't have any data on textures but glxgears gets ~250 fps on
    >> sw gl under linux on a P4 2.6 + a 4 year old matrox card.
    >> That's more than a few hundred polygons, no?

    RJ> No, that's the example I had in mind. Note that there are no
    RJ> textures. Also note that matrox cards 4 years ago were rather
    RJ> decently fast. Not the fastest, but decent. 

Yeah but this is unaccelerated mesa, the most it can be using is 
whatever 2D xfree acceleration is in the xfree matrox driver.

    RJ> 4-year-old matrox
    RJ> cards also aren't cheap even now, but they're the best bet if
    RJ> you want halfway accurate rendering. [...]

I agree, the output driver seems much better than my newish ATi's.  
The tiny text is much sharper at 1920x1440 with my G400 that it was 
with the Ati 9200 on my sony CRT.  It can't drive analog LCDs nearly 
as well, alas.  

cheers,

BM


0
Reply bm80 (247) 4/19/2004 1:37:51 AM

Kenny Tilton <ktilton@nyc.rr.com> writes:

> Rahul Jain wrote:
>
>> Kenny Tilton <ktilton@nyc.rr.com> writes:
>> "Which backend?" is exactly the question that implies you already know
>> the answer.
>
> Answer? ease up on the paranoia,

I'm not sure where you find paranoia here. Maybe that's the answer that
implies another answer. ;)

> I do not even understand the question, or how CLIM can run on Movitz.

The same way it runs on a whole boatload of platforms already, just like
CL. Note that your conflation of an implementation with a specification
is rather irritating.

> All I know about Movitz is that line about running on the metal. x86,
> to be specific. I guess any computer can draw to a screen via
> memory-mapped video, and come to think of it that is how I wrote a
> game in assembler on the 6502, but I wager Movitz wants to work a
> little higher than that.

Sure. What does that have to do with preventing a UI toolkit from
existing? McCLIM can just have a Movitz backend. (Actually backends for
whatever number of specific driver interfaces are implemented for
Movitz.)

Cello would use some sort of Lisp-intercepted OpenGL thing... or
something. I dunno how you'd structure it, since you don't have/need any
FFI. OpenGL seems only to make sense as a C interface, to me. Maybe
there's something more to it. The API would need to be different, of
course, since you're not calling C functions, but Lisp functions. Maybe
you have that stuff implemented separately for each platform anyway.

> No C? yer gonna do FreeType in Lisp?

Is plotting quadratic functions THAT hard?

> I'm lost. Wanna throw me a frickin bone and just tell me?

Heh. Tell you about what? The fact that we've said over and over again
that the current portedness of a portable interface has no bearing on
its portability? Or should I say that Cello will never run on Linux
because it didn't a month ago?

;)

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/19/2004 3:38:47 AM

Kenny Tilton <ktilton@nyc.rr.com> writes:

> David Steuber wrote:
> 
> > Thomas Schilling <tjs_ng@yahoo.de> writes:
> >
> >>I thought cello is going to be a *2d*-gui toolkit that's based on OpenGL
> >>mainly for portability and rendering speed. Your not really planning to
> >>make it (all) 3d, do you?
> > As I understand it, Quartz Extreme under Mac OSX uses 3D exclusively
> > (even for 2D stuff) in order to take advantage of hardware
> > acceleration that is apparantly disappearing from the 2D ops.
> > OS X 10.3 on the later Apple hardware is a very good demo of what can
> > be done using OpenGL for all screen drawing operations.
> 
> I think we had this discussion before, but I think it is imperative to
> note that Cello goes further by using OpenGL primitives to build up
> the frames eventually output by, again, OpenGL. The advantage is that
> I can execute a kazillion instructions and have OpenGL compile them
> and remember them as display-list 42. Then the CPU just has to yell
> out 42 to the GPU and away we go. the idea being less traffic to the
> card as well as less work for the CPU the second time I render the
> same stuff. What I do not know is how much is saved on the GPU by
> "compiling" a long sequence of GL api calls.

We've certainly had a similar discussion before.

I don't know the internals of OpenGL, so I can't say even where the
compiled display list data goes or what form it is in.

Mesa itself is an independent OpenGL implementation used on Linux.
Like X, it ultimately has to talk to the video hardware via its driver
at some point.  It would probably be a pretty damn big job, but I
think it is possible to do an OpenGL implementation in Lisp.  Then the
only FFI component is talking to the driver.  I don't know how uniform
that API is.  It would suck if the C code had a sperate backend for
each and every driver.  That would mean that Lisp code would need the
same thing.

The only reason I would even suggest going with a pure Lisp (as is
possible) OpenGL implementation is for GC purposes.  I'm sure that FFI
makes GC more interesting than it already is.

Regardless of ubiquity, I think that OpenGL *is* a good API to use.
While support may not be technically universal, I think it is
widespread enough to consider it accepted by the industry.  Video
cards that support it are common in PC land and 100% on new Apple
computers.  Software emulation is available at a rather considerable
performance penalty.

I think it would be safe to assume OpenGL on SGI boxes ;-)

-- 
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
0
Reply david1426 (765) 4/19/2004 3:58:14 AM

Rahul Jain <rjain@nyct.net> writes:

> > OpenGL can be useful for a UI, but on existing hardware, the best way
> > to utilize it would be to define an abstract graphics API that spoke
> > to an OpenGL "server" over a protocol, so a single OpenGL context
> > could be shared by multiple apps.
> 
> Not just multiple, but _all_ apps if you want more than one app using
> it. And you'd have to write your own windowing system.

I am pretty sure this is EXACTLY what Quartz is on Mac OS X.

> Not to mention the hokey rendering artifacts you'll get on any cards
> that cost less than $1000.

Depending on what you do I expect.  Meddle of Honor has shown off some
classic artifacts that I put down to its model.  The normal Mac
behavior is, well, well behaved.  Needless to say, I'm very impressed
by it.

-- 
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
0
Reply david1426 (765) 4/19/2004 4:04:39 AM

David Steuber <david@david-steuber.com> writes:

> Then the only FFI component is talking to the driver.

In linux, that "driver" is the DRM, whose interface is DRI.

> I don't know how uniform that API is.

....That is, assuming your driver is a DRM...

> It would suck if the C code had a sperate backend for
> each and every driver.  That would mean that Lisp code would need the
> same thing.

You'd need an nvidia backend and a DRM backend. Hopefully a matrox one,
too (but there is also an open source DRM for their cards).

> The only reason I would even suggest going with a pure Lisp (as is
> possible) OpenGL implementation is for GC purposes.  I'm sure that FFI
> makes GC more interesting than it already is.

Sure.

> Regardless of ubiquity, I think that OpenGL *is* a good API to use.
> While support may not be technically universal, I think it is
> widespread enough to consider it accepted by the industry.  Video
> cards that support it are common in PC land and 100% on new Apple
> computers.

Too bad those cards can't draw things in the right places to save their
lives. But we can always spend $1000 to get a decent 3D accelerator!@

> I think it would be safe to assume OpenGL on SGI boxes ;-)

They use Nvidia cards on the lower end boxes, last I checked.

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
0
Reply rjain (742) 4/19/2004 4:18:31 AM

Rahul Jain <rjain@nyct.net> wrote in message news:<874qrhw8tc.fsf@nyct.net>...
> knos@free.fr (n++k) writes:
> 
> > Isn't the common, random computer owning person using windows on a
> > machine with a 3d card?
> 
> Depends if you're talking about accelerators or decelerators. :)
> 
> Most computers provide 3d acceleration. There are a few at the low end
> that don't, or don't provide anything of value in that department. The
> accuracy of the rendering is another question, and I'm sure those
> decelerators are even worse than, say, a Radeon 9600.

http://www.blender.org/modules/gfxdatabase/index.php
--
Blender OpenGL/Gfx Database
This is the OpenGL database of blender.org. Here we gather reports
from Blender users on the display quality of Blender's GUI, which is
entirely written in OpenGL.

Purpose is:

    * To give us an overview of issues which need to be tackled,
sometimes a bypass can be coded.
    * Give insight to Blender users which graphics card / OS / driver
combos perform best.
    * Provide us statistics to contact 3D card driver developers with
errors they could fix.

Please note that the reports here are about quality; a proper display
of the user interface. It is not meant to compare Gfx card 3d
performance (speed)
0
Reply knos (12) 4/19/2004 6:06:01 AM

Rahul Jain <rjain@nyct.net> wrote in message news:<874qrhw8tc.fsf@nyct.net>...
> knos@free.fr (n++k) writes:
> 
> > Isn't the common, random computer owning person using windows on a
> > machine with a 3d card?
> 
> Depends if you're talking about accelerators or decelerators. :)
> 
> Most computers provide 3d acceleration. There are a few at the low end
> that don't, or don't provide anything of value in that department. The
> accuracy of the rendering is another question, and I'm sure those
> decelerators are even worse than, say, a Radeon 9600.

Let's be a bit reasonable. A GUI is what, a few textured triangles?
Even the crappy 3d cards present in old laptops like those ati rage
mobility chips can cope with an opengl gui with ease.

It's not likely you'd need something like render-to-texture in a gui.
(I just mention it because that's the only thing I know that wasn't
optimized well in old ~1997 range 3d cards)
0
Reply knos (12) 4/19/2004 6:11:13 AM

Kenny Tilton <ktilton@nyc.rr.com> writes:

> Rahul Jain wrote:
>
>> Kenny Tilton <ktilton@nyc.rr.com> writes:
>>
>>>Hunh? "work on any Lisp gl"? Maybe you misunderstood /my/ stuff. I'll
>>>try again. What plans does Movitz have now for graphics.
>> You can write whatever graphics drivers you want for it.
>
> How practical. Where /is/ Peter's book?!

It's coming; it's coming. Writing about pathnames sapped my will to
live but I'm bouncing back now.

-Peter

-- 
Peter Seibel                                      peter@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
0
Reply peter9330 (968) 4/19/2004 2:58:22 PM


Rahul Jain wrote:

> Kenny Tilton <ktilton@nyc.rr.com> writes:
> 
> 
>>Rahul Jain wrote:
>>
>>
>>>Kenny Tilton <ktilton@nyc.rr.com> writes:
>>>"Which backend?" is exactly the question that implies you already know
>>>the answer.
>>
>>Answer? ease up on the paranoia,
> 
> 
> I'm not sure where you find paranoia here. Maybe that's the answer that
> implies another answer. ;)
> 
> 
>>I do not even understand the question, or how CLIM can run on Movitz.
> 
> 
> The same way it runs on a whole boatload of platforms already, just like
> CL. Note that your conflation of an implementation with a specification
> is rather irritating.

Sorry, I just flat out do not understand you, and I am sincerely trying 
to do so. Anyway, I think we can drop it here. You may be right in your 
position that OpenGL is an imperfect solution. Lispworks seems to have 
the problem solved with native solutions. Please do not confuse me with 
anyone of that size or technical strength. I am just an application 
programmer who has moved from OS9 to WinNT and is looking forward to 
getting back to OS X. All I have is Cells, which makes GUIs as much fun 
to program as they usually are hell. Give me a bitmap and an event 
stream to steer her by and Cells and I can give you a framework as good 
as CLOS is relative to other OO models. For portability I looked at gtk 
and openrm and coding up native each of the big three and I settled on 
Glut and OpenGL as the best mix of power and practicality. the native 
solution would be ideal, but would take too long and add too little 
value to the Glut. It seems to be working, thank you very much. 
Christophe will be happy to show you the Cello/Linux screenshot. That 
was achieved by a Lisp newbie (albeit very strong Linux programmer) with 
about three email questions to me which all tracked back to hardcoded 
paths (eliminated in PortaCello3). And if UFFI "load-library" knew 
Allegro ran on Linux, Frank would not have had to do the work he did. 
He'll be submitting his stuff to UFFI.

Anyway, if the imperfections of Cello derive from imperfections in 
OpenGL or its ubiquity, then those are the best imperfections to have. 
Games and especially MMORPGs such as:

     http://www.anarchy-online.com/

....are turbodriving OpenGL forward in performance and aesthetics. Look 
also for 3D interfaces and screens to become de riguer for the 
presentation of complex information.

Cello is hitched to that wagon, stuck with their imperfections (hair 
coming through a wall?) but improving as they do, and this Open Source 
Fairy does not have to lift a finger to get those ongoing benefits. Perfect.

kenny


-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

0
Reply ktilton (2220) 4/19/2004 3:00:24 PM

Kenny Tilton <ktilton@nyc.rr.com> wrote:

> Rahul Jain wrote:
>> The same way it runs on a whole boatload of platforms already, just like
>> CL. Note that your conflation of an implementation with a specification
>> is rather irritating.

> Sorry, I just flat out do not understand you, and I am sincerely
> trying to do so.

I think he's trying to hint at

 a) CLIM being a backend-agnostic spec.

 b) McCLIM having multiple backends: AFAICT currently at least
    CLX, OpenGL and postscript, and even CLX running quite happily
    on Windows given an X-server, which are a plethora.

Cheers,

  -- Nikodemus
0
Reply nikodemus (193) 4/19/2004 4:48:49 PM

> > Not just multiple, but _all_ apps if you want more than one app using
> > it. And you'd have to write your own windowing system.
> 
> I am pretty sure this is EXACTLY what Quartz is on Mac OS X.
Yep, this is what Quartz does. Except instead of a rendering protocol,
it has applications draw (via software) into a texture, and the
windowing system uses OpenGL to composit those. Since only the WM is
actually using OpenGL, it doesn't suffer with concurrency problems.
0
Reply heliosc (124) 4/19/2004 11:40:53 PM
comp.lang.lisp 15505 articles. 5 followers. Post

51 Replies
1186 Views

Similar Articles

[PageSpeed] 44


  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

I feel a bit dumb, but getting a bit clueless
I am certainly not awake, that I have troubles with a simple thing like this, but there it is.... I have three tables: Names(NameID INT4 PRIM INDEX, Name VARCHAR(30)), Groups(GroupID INT4 PRIM INDEX, Group VARCHAR(30)) And a table Members(NameID,GroupID) PRIM INDEX ON (NameID, GroupID) Now I put some data in all three tables, first created some Names (a grand total of 4) and a few groups (a grand total of 6) And Members like this (NameID, GroupID) 1, 1 1, 2 1, 3 2, 1 2, 4 2, 5 3, 2 3, 6 4, 1 Now I want to show essentially the Members table, but the numbers should be...

Feeling a bit petulant...
Think I'll go mess with the wintards in a.o.w-xp... Don't worry, I'll wipe my feet before coming back in. :-) -- rapskat - 21:42:56 up 1 day, 20:07, 3 users, load average: 0.73, 0.32, 0.18 "I hear that if you win, you get a free probe by aliens." -- Bill Coldwell, regarding the SETI@home project rapskat wrote: > Think I'll go mess with the wintards in a.o.w-xp... > > Don't worry, I'll wipe my feet before coming back in. :-) > Man, you need to do more than wipe your feet. You'll need a bath with a good strong disinfectant soap. ...

Feeling a little bit Nastolgic?
Call Fantasia's Return BBS @ Telnet://65.80.188.195:6400 a TEC-South II DMBBS! This did not work for me.. Gary -- Visit our WebSite at http://www.mnst.net/~granchuk My Yahoo Group : http://ca.groups.yahoo.com/group/ClassicMercuryClub/ Amiga Computers YaHoo Group : http://ca.groups.yahoo.com/group/Amiga_Computers/ "warya" <waderyan@bellsouth.net> wrote in message news:FsQng.8940$7K2.4887@bignews2.bellsouth.net... > Call Fantasia's Return BBS @ Telnet://65.80.188.195:6400 a TEC-South II > DMBBS! > > ...

Feeling a bit disturbed by the direction scheme is going
Ok, I've only been using scheme for about 4 months now, so I'm a bit new at it. I have over 30 years experience programming, in languages like Basic, COBOL, C, X86 Assembler, C++, C#, FORTRAN, etc., but this is my first "functional" language. I'm having lots of fun, and was very drawn to the "simplicity" of the syntax. I like the "it just works" mentality. To quote the first paragraph of the various RnRS reports: "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions tha...

Ubuntu Nappy victim: 6 bugs bit his ass.... only 2 apps run right... "it feels like alpha 1"
"Ok, just installed 11.04 on my main pc among with fedora 14. Here are the list of problems I have right out of the box. 1.) I have dual-monitors. My second monitor isn't recognized and its blank in unity. How do I fix this? 2.) I am unable to add anymore apps in launcher, is there a limit? 3.) Eclipse PDT fails to install, Eclipse PDT all in 1 fails to load any php files. Help! 4.) Where are my wine apps? I cant find them trough unity launch and I don't wanna terminal access via .wine every time I want to run something. 5.) Kdenlive fails to start (missing MLT SDL module??) ...

bits of this, bits of that
Hi, I need to write some data types into an array of unsigned chars. These are basically "signals" within a message, so each signal will have a start bit and a length. The signals will also have a type, one of: unsigned long signed long float double The signals with float and double will be 32 or 64 bits long, as appropriate. I need to just shift the bits and throw them into the array, untouched. Whats the best way of doing this? Since I can't bit shift a float around, I was thinking of a union of the 4 types, and doing all the bit twiddling using the ...

A poem
bling blang give me toe. Blong krong, what's down dic. I have a problem, let me share. thats not right, bling kring qring. Hats for sale, block a crock smock. I need to ride my bike, klong a yong vong Methodists are here, hooray hooray, jink a link crink. The spastics are comming, bung a kung qung. The table is gay, jick a crick dick. The food is computer, up a lup tup. I want box, dong a klong iong. The papar is smashy, ing a uing ping. Meetings for the disabled, ip a crip dip dip snip. I enjoy noodle dancing, snot a lot crot. I go fish making, ish a lish crish. The mouse ...

Size 8 bit, 16 bit, 32 bit and 64 bit systems.
I need to find out what is the size of following data structures in 8 bit, 16 bit, 32 bit, and 64 bit systems. struct findsize{ unsigned char chA; unsigned long lg; unsigned short sh; unsigned char chB; }; sizeof() runs at compile time, that means one can know in advance what size of these. I don't have 8 bit or 16 bit systems. I do have 32 bit and 64 bit system. I believe, in 32 bit system, this would be 1+4+2+1 = 8 bytes. Can anyone throw some light here on how to find size? adar <adar_ji@yahoo.com> ...

Size 8 bit, 16 bit, 32 bit and 64 bit systems. #2
I need to find out what is the size of following data structures in 8 bit, 16 bit, 32 bit, and 64 bit systems. struct findsize{ unsigned char chA; unsigned long lg; unsigned short sh; unsigned char chB; }; sizeof() runs at compile time, that means one can know in advance what size of these. I don't have 8 bit or 16 bit systems. I do have 32 bit and 64 bit system. I believe, in 32 bit system, this would be 1+4+2+1 = 8 bytes. Can anyone throw some light here on how to find size? On Wed, 01 Aug 2007 15:34:56 -0...

compression bit by bit
This is for coding a binary sequence. Let n be the length of the sequence and r the number of 1's in it. The sequence is called X and the bits are numbered from 0-n-1, from right to left, so the individual bits from right to left are X[0], X[1],..... In regular binary encoding, the individual bit positions are assigned fixed weights. Since compression is desired therefore 1) The weights assigned must be variable , and 2) The weight of any position must only be dependent on the number of one's so far or r. Clearly if there are r 1's in a sequence of length n, the weight ...

how to determine Bits Stored, Bits Allocated and High Bit?
Hi, I'm trying to understand this 3 concepts.. I can't seem to find this info anywhere. For JPG, by examining the img2dcm code from DCMTK, I see that it is extracted from the file. How about if I am creating my own 2D array of pixel data? Can anyone care to explain how to determine the Bits Stored, Bits Allocated and High Bit? Thanks! See PS 3.5 8.1.1 "Pixel data encoding of related data elements", and PS 3.5 Annex D "Examples of various pixel data and overlay encoding schemes". Aimevous wrote: > Hi, I'm trying to understand this 3 concep...

Windows 7 64 bit
My server works under Windows 7 Professional 64 bits, my FileMaker Pro10 Advanced is 32 bits. FM has to connect to a MySQL-database, which driver should I use? The 64bits or the 32bits version? And if 64, can FM communicate via the 64bits driver with MySQL? Or should I better downgrade W7 to 32bits? Harry <a@b.c> wrote: > My server works under Windows 7 Professional 64 bits, my FileMaker > Pro10 Advanced is 32 bits. > FM has to connect to a MySQL-database, which driver should I use? > The 64bits or the 32bits version? I never used Filemaker. And I try to sta...

64-bit and 128 bit integer as a combination of 32-bits
Hi all, How to program 64-bit and 128-bit integers as a combination of 32bits. I need this string to integer conversion. Thank you On Aug 2, 10:51=A0am, xyz <lavanyaredd...@gmail.com> wrote: > > How to program 64-bit and 128-bit integers as a combination of 32bits. > I need this string to integer conversion. > It's easiest in assembler. Instruction sets for 32-bit microprocessors have the ability to access the carry when two numbers are added, or to take the high 32 bits from a multiplication. It's more difficult to achieve this in C. The easiest way ...

Which Is Better To Use 8 Bits, 16 Bits, or 32 Bits?
Flat model provides a full 32 Bits Mode that it allows me to choose 8 Bits or 32 Bits like MOV AL, 041H and MOV EAX, 041424344H. My question is: do 8 Bits and 32 Bits have the same speed of transfeering data from memory into register. If I want to use 16 Bits, I must add 066H prefix to select 16 Bits instead of 32 Bits like 066H MOV AX, 04142H. Do you think that 16 Bits is slower than both 8 Bits and 32 Bits because of extra one byte such as 066H prefix. Is it the best practice to use 32 Bits register to copy 8 Bits data or 16 Bits data like MOV EAX, Memory? If I always use AND EAX...

shifting bits, shift 32 bits on 32 bit int
Noticed something odd in the way bit shifting was working today. As far as I have ever heard, shifting will shift in zeros(signed ints aside) However I foudn something odd when I am shifting exactly the number of bits in a value... i.e. uint32_t x = 5; uint32_t y = x << 32; uint32_t z = x << 32; In the above example y and z are both still 5. Why is this? Now I understand doing a shift like this seems silly, but in this code sometimes the resulting shift validly turns out to be exactly the number of bits in that data type, and expects the result to be 0. I can change the c...

32 bit or 64 bit Oracle on 64 bit OS?
Hello, Currently our environment is on 10g Release 2, OS windows 2000/2003 standard edition 32 bit. We use shared server to take advantage of scalability and connecting maximum no of simultaneous connections to the database. Now we take advantage of memory beyond 4GB we are planning to check following. 64 bit Windows 2003 standard edition on AMD64/EM64T Servers. Do we need to install 64 bit Oracle as well? Do we need to reinstall Oracle clients with 64 bit installable if Oracle Server is upgraded to 64 bit? Is 32 bit Oracle is certified on 64 bit OS? Do we need to take care of any other ...

Advanced Compiler Request: 8 bit, 16 bit, 32 bit, 64 bit code path/instruction generation and selection !
Hello, It would be very handy if Delphi could somehow generate code paths for 8 bit, 16 bit, 32 bit and 64 bit integers and possible even structures etc. So maybe with some compiler magic multiple instruction code paths can be generated AND SELECTED based on a "code path selection" variable. Here some ideas: Idea 1: Delphi could introduce a new "code path selection type" TcodePathSelection = ( cps_8_bit, cps_16_bit, cps_32_bit, cps_64_bit ); // the Delphi programmers can then use: var vCodePathSelection : TcodePathSelection; // Then somehow the Delphi program...

An approach for n-bit int. / m-bit ext. scanners (was: Re: Sprintscan 35+, 10 bits vs 8 bits)
Don wrote: > On Thu, 20 Oct 2005 22:18:02 +0200, "Lorenzo J. Lucchini" > <ljl@tiscali.it> wrote: > >>I'm not saying that one should not use an external editor because the >>driver-integrated tools are equivalent. They are obviously not, with any >>dedicated editor having many more tools. > > There you go! So why do you argue against it? > > [snip] Look, we're going around in circles and we'll never get out of this discussion like this. I'll try to take another approach, by laying down my point of view i...

64 bit assembly m.s.bit and l.s.bit
For the 64 bit instruction set, what is the most efficient way to get and clear the most significant bit and the least significant bit in an unsigned 64 bit integer? If I were to use (for instance) yasm to compile the assembly, how do I interface with 64 bit C code? My interest is in connection with chess programs, which represent a board as a 64 bit integer typically. On Jun 25, 2:21=A0pm, user923005 <dcor...@connx.com> wrote: > For the 64 bit instruction set, what is the most efficient way to get > and clear the most significant bit and the least significant bit in an > u...

32-bit Number * 32-bit Number = 64-bit result
I need to do multiplication that mirrors how C handles integer multiplication. That is, one 32-bit number times another 32-bit number equals the least significant 32-bits of the 64-bit result. In theory, I could mimic that behavior like so: (x * x) & 0xFFFFFFFF But this doesn't work quite right because the initial multiplication can produce such a large result that JavaScript looses some precision. Any thoughts? Ideas? "Jeff.M" <Mott.Jeff@gmail.com> writes: > I need to do multiplication that mirrors how C handles integer > multiplication. That is, one 32-bit...

Re: Which Is Better To Use 8 Bits, 16 Bits, or 32 Bits?
"Bryan Parkoff" <bryan.nospam.parkoff@nospam.com> wrote in message news:2Kazc.12352$ar2.4884@fe2.texas.rr.com... > Flat model provides a full 32 Bits Mode that it allows me to choose 8 > Bits or 32 Bits like MOV AL, 041H and MOV EAX, 041424344H. My question is: > do 8 Bits and 32 Bits have the same speed of transfeering data from memory > into register. Yes; all load instructions have the same latency, assuming they're aligned. > If I want to use 16 Bits, I must add 066H prefix to select 16 Bits instead > of 32 Bits like 066H MOV AX, 04142H. Do you...

12 Bit data inside 16 bit words: how to truncate blanking bits
Dear comp.lang.c members, I have the following problem: I am writing an application which reads data from a device. This data is 12 bit wide and comes as a stream of words to be stored to a file. At the moment I write it to 16 bit words, which creates an unessecary overhead. I currently use uint16_t. How may I do this? Any comments welcome ;-) Thank you and best regards, Johann johnny wrote: > Dear comp.lang.c members, > > I have the following problem: > I am writing an application which reads data from a device. This data > is 12 bit wide and comes as a stream of words t...

64-bit instance on Aix 32 bit kernel / 64 bit hardware
Hi, Is it worth to use 64-bit DB2 instances on a 32-bit kernel, in terms of: - performance - configuration (go beyond the 256 Mb segment for private mem, 1.75 Gb for Bufferpools) - other ? I've seen NIS is not supported, downlevel (64 to 32 bit ?) is not supported .... The "Should I be using DB2 64-bit?" tech note seems confusing: http://www-1.ibm.com/support/docview.wss?rs=71&context=SSEPGG&q1=64-bit&uid=swg21188114&loc=en_US&cs=utf-8&lang=en It states some restrictions - You can install 64-bit DB2 UDB Version 8 on 32-bit operating syst...

AIX 64-bit kernel vs. 32-bit with 64-bit extensions
We are in the process of migrating our IDS 7.31 UD4 instance to IDS 9.4FC6. At the same time, we are moving to IBM p630 servers with 2 1.2Ghz Power4 processors with 4G of RAM running on AIX 5.2. We are beginning to test a reorg/migration script which uses distributed SQL queries to move data from our very-interleaved, messy IDS 7 instance to a well-organized IDS 9 instance with big chunks (where needed). In our test, both instances are on separate p630 AIX 5.2 servers connected on the same subnet. We were just told by our AIX admins that our standard mode for the AIX 5.2 servers ...