While trying to make a binding to a heavily-OOP (in C++ notion)
library I stuck in question: is it possible to reflect all the C++
classes and methods in CLOS? I mean I really want to have the ability
to extend the library from Common Lisp`s side and utilize CLOS.
Can you please point me to some source that will provide me the
answer?
Best regards
·················@gmail.com wrote:
> While trying to make a binding to a heavily-OOP (in C++ notion)
> library...
Which one?
>... I stuck in question: is it possible to reflect all the C++
> classes and methods in CLOS?
"reflect"? Do you want to call the C++ methods via FFI? I know the
developer of Verrazano had that on his do list.
> I mean I really want to have the ability
> to extend the library from Common Lisp`s side and utilize CLOS.
You will not be able, say, to subclass a C++ class with a CLOS class if
that is what you mean by extend.
> Can you please point me to some source that will provide me the
> answer?
What we normally do, and perhaps this is what you mean, "wrap" the C++
library. In my cl-ftgl project I have classes that correspond with any
FTGL (the C++ library) class whose behavior I need to use or extend. I
also wrote a small C library for the C++ methods I wanted to call
because I did not have anything at hand that would let me at C++ directly.
So I make a CLOS instance which during initialization has the C++
library make a C++ instance of the corresponding class, and now I can
knowck myself out with further subclassing, GFs and all that good stuff.
hth, kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 17, 3:55 pm, Ken Tilton <···········@optonline.net> wrote:
> Which one?
OpenSceneGraph.
The library has outstanding reflection capabilities among C++
libraries so I thought it would be easy. Also it would be very useful
for Common Lisp community to have such a good 3D rendering engine
available.
> "reflect"? Do you want to call the C++ methods via FFI? I know the
> developer of Verrazano had that on his do list.
Yes. I want to call the C++ methods via FFI (CFFI) and also use
subclassing.
> You will not be able, say, to subclass a C++ class with a CLOS class if
> that is what you mean by extend.
Sounds upsetting.
> So I make a CLOS instance which during initialization has the C++
> library make a C++ instance of the corresponding class, and now I can
> knowck myself out with further subclassing, GFs and all that good stuff.
By now I can define CLOS classes corresponding to C++ classes with
predecessors. Also now I can create instances of C++ classes by
calling make-instance. I can use only default C++ constructors by now.
The main problem is calling C++ methods on the instances, constructing
of objects with non-default constructors and observance of C++
inheritance rules using CLOS.
What is your opinion on the subject?
On Dec 17, 8:27 am, ·················@gmail.com wrote:
> On Dec 17, 3:55 pm, Ken Tilton <···········@optonline.net> wrote:> Which one?
>
> OpenSceneGraph.
> The library has outstanding reflection capabilities among C++
> libraries so I thought it would be easy. Also it would be very useful
> for Common Lisp community to have such a good 3D rendering engine
> available.
>
> > "reflect"? Do you want to call the C++ methods via FFI? I know the
> > developer of Verrazano had that on his do list.
>
> Yes. I want to call the C++ methods via FFI (CFFI) and also use
> subclassing.
>
> > You will not be able, say, to subclass a C++ class with a CLOS class if
> > that is what you mean by extend.
>
> Sounds upsetting.
>
> > So I make a CLOS instance which during initialization has the C++
> > library make a C++ instance of the corresponding class, and now I can
> > knowck myself out with further subclassing, GFs and all that good stuff.
>
> By now I can define CLOS classes corresponding to C++ classes with
> predecessors. Also now I can create instances of C++ classes by
> calling make-instance. I can use only default C++ constructors by now.
> The main problem is calling C++ methods on the instances, constructing
> of objects with non-default constructors and observance of C++
> inheritance rules using CLOS.
>
> What is your opinion on the subject?
As someone who worked on integration of c++ and lisp, first with the
Truevision3D http://www.truevision3d.com/ than with lighfeather
http://lightfeather.de/news.php my humble opinion is to forget about
it. Stay away from LARGE c++ libraries as far as you can, especially
game engines.
1st You wont learn nothing in your journey except fixing
incompabilities issues in each side of the fence.
2nd your work will be useless in the community. It'll be incomplete,
it'll outdate as soo as you stop being interested developing it and
newer versions of opengraph comes around.
3rd it'll make you hate lisp, hate c++ & hate programming i general.
4th it'll be a long painfull process with no rewards.
So if you really want to help, start rewriting the engine you like in
lisp from scratch, you can use opengl bindings through cffi. You will
learn a lot of things and you make something usefull.
This si my honest opinion that I wish someone gave me before I
wandered into muddy world of c++/cl interaction. If I started
rewriting directly in lisp from the start for those fricking months I
would have something intresthing that other lispers could use as a
base for improving, not some some buggy slow bindings to outdated
version of someones else buggy c++ code.
stay away you don't need that crup
Slobodan
Slobodan Blazeski schrieb:
> As someone who worked on integration of c++ and lisp, first with the
> Truevision3D http://www.truevision3d.com/ than with lighfeather
> http://lightfeather.de/news.php my humble opinion is to forget about
> it. Stay away from LARGE c++ libraries as far as you can, especially
> game engines.
> 1st You wont learn nothing in your journey except fixing
> incompabilities issues in each side of the fence.
> 2nd your work will be useless in the community. It'll be incomplete,
> it'll outdate as soo as you stop being interested developing it and
> newer versions of opengraph comes around.
> 3rd it'll make you hate lisp, hate c++ & hate programming i general.
> 4th it'll be a long painfull process with no rewards.
>
> So if you really want to help, start rewriting the engine you like in
> lisp from scratch, you can use opengl bindings through cffi.
I think that's a major problem with lispers. Rewriting everything in
Lisp and making it incompatible with the rest of the world is a major
pain in the... you know where. What I would like to see is the following:
An automated tool that wraps C++ classes into C functions and
automatically creates Lisp FFI-glue-code for it.
You should be able to do this with relatively low effort. You can
(theoretically) use GCC-XML, but I think you need to expand it's
functionality a bit, since it's currently quite limited.
So here's a very basic example:
The C++ library 'libtest' consists of the following header:
#ifndef TEST_H_8923
#define TEST_H_8923
class Test {
public:
Test(const char *name);
const char *get_name() const;
};
#endif
The automated tool will create a C(++)-library which exposes only
functions with C-bindings, but uses the C++-compiler to compile the
function implementations, hence you get rid of all the C++-ABI troubles.
#ifndef TEST_C_H_3894
#define TEST_C_H_3894
extern "C" {
struct Test *Test_Test(const char *name);
const char *Test_get_name(struct Test *obj);
}
#endif
And here's the implementation:
#include "Test_c.h"
#include "Test.h"
extern "C" {
struct Test *Test_Test(const char *name) {
return new Test(name);
}
const char *Test_get_name(struct Test *obj) {
return obj->get_name();
}
}
And then there's the CFFI-binding for the C-wrappers. You should all
know how it looks like, I'm too lazy to write it down now, too. :-)
Of course this example is *extremely* over-simplified and there are much
more complicated things to be aware here. But I've already put some
thought into it and I think there's no problem that can not be overcome
with this approach.
Unfortunately, not having much spare-time (that I spend coding, anyways)
and not working with Lisp at work, I haven't found the time to code
this myself. But I think it won't be too much of a hassle. Especially
since you keep out of ABI-compatibility-problems.
Also, there's the PyQt project which has written something similar to
automatically create bindings to Qt for Python. The tool is called SIP:
<http://www.riverbankcomputing.co.uk/sip/index.php>
Kind regards,
Daniel Albuschat
Daniel Albuschat wrote:
> Slobodan Blazeski schrieb:
>
>> As someone who worked on integration of c++ and lisp, first with the
>> Truevision3D http://www.truevision3d.com/ than with lighfeather
>> http://lightfeather.de/news.php my humble opinion is to forget about
>> it. Stay away from LARGE c++ libraries as far as you can, especially
>> game engines.
>> 1st You wont learn nothing in your journey except fixing
>> incompabilities issues in each side of the fence.
>> 2nd your work will be useless in the community. It'll be incomplete,
>> it'll outdate as soo as you stop being interested developing it and
>> newer versions of opengraph comes around.
>> 3rd it'll make you hate lisp, hate c++ & hate programming i general.
>> 4th it'll be a long painfull process with no rewards.
>>
>> So if you really want to help, start rewriting the engine you like in
>> lisp from scratch, you can use opengl bindings through cffi.
>
>
> I think that's a major problem with lispers. Rewriting everything in
> Lisp and making it incompatible with the rest of the world is a major
> pain in the... you know where. What I would like to see is the following:
>
> An automated tool that wraps C++ classes into C functions and
> automatically creates Lisp FFI-glue-code for it.
> You should be able to do this with relatively low effort.
http://common-lisp.net/project/fetter/ anyone?
:)
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
·················@gmail.com wrote:
> On Dec 17, 3:55 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>Which one?
>
> OpenSceneGraph.
> The library has outstanding reflection capabilities among C++
> libraries so I thought it would be easy. Also it would be very useful
> for Common Lisp community to have such a good 3D rendering engine
> available.
I keep wondering if I should add something like that to Cello. I
hesitate because I think my Cello project should be a Lisp SG manager,
not wrap one.
>
>
>>"reflect"? Do you want to call the C++ methods via FFI? I know the
>>developer of Verrazano had that on his do list.
>
> Yes. I want to call the C++ methods via FFI (CFFI) and also use
> subclassing.
>
>
>>You will not be able, say, to subclass a C++ class with a CLOS class if
>>that is what you mean by extend.
>
> Sounds upsetting.
Well, we are not sure we are talking about the same thing, so don't give
up yet. I just mean that anything you want your program to know about
will have to be mirrored with a Lisp class, slot, method, etc. That's
just obvious, so probably not as bad as I made it sound.
>
>
>>So I make a CLOS instance which during initialization has the C++
>>library make a C++ instance of the corresponding class, and now I can
>>knowck myself out with further subclassing, GFs and all that good stuff.
>
> By now I can define CLOS classes corresponding to C++ classes with
> predecessors. Also now I can create instances of C++ classes by
> calling make-instance. I can use only default C++ constructors by now.
> The main problem is calling C++ methods on the instances, constructing
> of objects with non-default constructors and observance of C++
> inheritance rules using CLOS.
>
> What is your opinion on the subject?
Someone threatened to resurrect Verrazano, which was going to use
gcc_xml output to get mangled names and give easy FFI to C++, maybe if
you get involved work will resume. Also, poke around on common-lisp.net,
ISTR someone else building FFI to OSG or maybe some other SG.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
·················@gmail.com wrote:
>> So I make a CLOS instance which during initialization has the C++
>> library make a C++ instance of the corresponding class, and now I can
>> knowck myself out with further subclassing, GFs and all that good stuff.
> By now I can define CLOS classes corresponding to C++ classes with
> predecessors. Also now I can create instances of C++ classes by
> calling make-instance. I can use only default C++ constructors by now.
So you have some things working?
> The main problem is calling C++ methods on the instances,
The C++ functions
cat <<_EOF > C.hpp
class C
{
int f(int x);
int g(int x) const;
};
_EOF
translate to the C functions (modulo name mangling)
int _Z1C1f(C *this, int x);
int _Z1C1g(C const *this, int x);
Thus, "class member functions" are just ordinary functions with a
hidden first parameter[1]. While you could compare 'nm -v libXYZ.so'
with 'nm -v -C libXYZ.so' to determine the mangled names and call them
directly from Lisp, its generally easier to make a C++ wrapper:
cat <<_EOF > wrapper.cpp
extern "C" // disable name mangling for these functions
{
int C_f(C *self, int x)
{
return self->f(x);
}
}
_EOF
[1] Not always true: I seem to remember that MS compilers used a
different "calling convention" to pass the class pointer. But the
"extern C" wrapper will always work correctly.
> constructing of objects with non-default constructors
Same basic idiom as before; a constructor is merely a function:
cat <<_EOF > wrapper2.cpp
extern "C"
{
// pretend C had this non-default constructor
// could be extended with "placement new" to initialize memory
// that was allocated by Lisp
C * C_C(int count, char *string)
{
return new C(count, string);
}
}
_EOF
> and observance of C++ inheritance rules using CLOS.
CLOS classes follow basically the same inheritance rules (at least
under single-dispatch)...
- Daniel
P.S. You might give Verrazano a whirl. A while ago, I got a
primitive Qt binding to "work". Attila made some improvements to vzn
since then, but recently he lost some steam:
http://common-lisp.net/pipermail/fetter-devel/2007-December/000292.html
Thanks guys for your opinions. I really don`t think that SWIG or
something would help me. Also I don`t think that messing with
incompatibilities of C++ and Common Lisp will make me hate programming
more than I already do. (I experienced a lot of headache with C++ in
the past. Nevertheless programming for me is still the best thing to
do while being dressed).
I don`t think I have so much experience with 3D engines that I can
write one myself. Especially such powerful as OSG.
My short-time plan now is to make something that works and release it
to the community approximately within a month or something. Let it be
not as elegant and fast as I wanted but it will work.
Cheers!
On Dec 19, 2:01 am, ·················@gmail.com wrote:
> Thanks guys for your opinions. I really don`t think that SWIG or
> something would help me. Also I don`t think that messing with
> incompatibilities of C++ and Common Lisp will make me hate programming
> more than I already do. (I experienced a lot of headache with C++ in
> the past. Nevertheless programming for me is still the best thing to
> do while being dressed).
> I don`t think I have so much experience with 3D engines that I can
> write one myself. Especially such powerful as OSG.
> My short-time plan now is to make something that works and release it
> to the community approximately within a month or something. Let it be
> not as elegant and fast as I wanted but it will work.
I understand that you want to help the lisp community but you won't be
doing any good.
Keep in mind this:
1. As per my own experiences calling engine through wrappers will cost
you about 30% of your framerate, and that's using LW foreign language
interface, if you plan to use cffi, and you should do that to keep
wrappers portable, framerate will probably drop even more.
2. Lispers doing game development WITH lisp are nonexistent. Are you
ready to be alone in your journey? Making something that noone will
use.
3. Even if you made your wrappers perfect, whatever that means, they
will always be that, wrappers, whenever I see wrappers for some
library that we don't have it reminds me how much sucks to be a
lisper. And as I said they will get old and used by nobody. Only one
guy used my wrappers for tv3d engine, and I doubt that he
delivered anything with them.
Take web development for example, if great lispers didn't produce
tools in lisp like web servers & web frameworks like AllegroServe ,
UCW, KPAX, .. but instead were writing wrappers around java, ruby on
rails, or whatever how many lispers would think twice about wiring web
applications with lisp? I certainly wouldn't. Nobody expects
hunchentoot to have a battle proven record like apache or IIS, or
feature to feature comparasion with full their toolbox but it hunch'
has it's on strengths in the lisp world and makes a great choice. Your
engine will have it's strengths too.
The stinky wrappers won't.
So think again and start building you graphic engine with lisp. Nobody
expect you to be it as good as scene graph, ogre, irrlicht or any
other that army of programmers work on it a very long time , even if
you make a simple one it'll provide functionality that could be used
in many places, whole or in pieces. And later it would have it's
strength coming from lisp.
And lispers will be happy to help you improve it, file bug reports,
send you patches, demonstrate it in their toy projects, make
suggestions about your lisp code. You'll get nothing of those writing
stinky wrappers for c++ code. If you plan to make a game of your own
choose some engine written in c or c# to make easy on your job, but if
you plan to help the community write your own engine. Simple engine
could be made in 2 months and later improved by anybody with interest
and some time to spare. Also there's a lot of small engines made by
students or hobbysts that you could rewrite in lisp fairly and learn a
lot about 3d graphic and lisp while lisping full time.
As someone who already walked that path and the only one who did what
you already plan to do, I'm telling to you that you're making a huge
mistake. The rest is up to you.
cheers
Slobodan
On 19 Dec, 11:17, Slobodan Blazeski <·················@gmail.com>
wrote:
> As someone who already walked that path and the only one who did what
> you already plan to do, I'm telling to you that you're making a huge
> mistake. The rest is up to you.
I guess the question is, how much of OpenSceneGraph does the OP need?
OSG is a huge library and to wrap it all will probably take a lot of
effort and continual updates as new features are added. Of course, if
they intend to be the only user then they can wrap just the bits they
need but we all know how annoying a partial wrapper is in the wild.
And a non-up-to-date wrapper is almost as bad.
If the intention is to make the wrapper available to others then they
need to weigh up the time costs of wrapping 100% of OSG vs growing
their own CL scene graph over time. Sure, it won't be as powerful for
a decade or so but they can start off by implementing the bits they
need first and have something useful in a few months.
--
Phil
http://phil.nullable.eu/
> 2. Lispers doing game development WITH lisp are nonexistent. Are you
> ready to be alone in your journey? Making something that noone will
> use.
Oh yeah. Well this people didn't read your post.
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
--------------
John Thingstad
On Dec 19, 6:38 am, "John Thingstad" <·······@online.no> wrote:
> > 2. Lispers doing game development WITH lisp are nonexistent. Are you
> > ready to be alone in your journey? Making something that noone will
> > use.
>
> Oh yeah. Well this people didn't read your post.
>
> http://www.franz.com/success/customer_apps/animation_graphics/naughty...
>
> --------------
> John Thingstad
Look at the dates John , Naughty Dog is a c++ shop now :
On the PlayStation 2 we were programming in our own unique language
that we had developed at Naughty Dog, it's called GOAL, Game Object
Assembly Lisp. It was all lisp based and the entire rest of the
industry is working in C++, nobody I knew was completely, off the wall
doing this thing in Lisp. It was started with Andy Gavin who was an
MIT graduate, I'm probably showing too much of my geek cred, MIT and
Lisp are closely linked and that's where it all started from. So we've
been working in that language all through the PlayStation One and the
PlayStation Two, now coming to the PlayStation Three we realised these
projects are getting so much more complex and they just require so
much more effort that we realised across Sony that we'd have to start
sharing code. If we develop something we're going to have to make sure
that Santa Monica can borrow it if they want too or Insomniac or vice
versa, things should be interchangable. So we realised we'd have to
put this behind us and adopt C++ like everyone.
http://palgn.com.au/article.php?id=9226
cheers
Slobodan
Slobodan Blazeski <·················@gmail.com> writes:
> On Dec 19, 6:38 am, "John Thingstad" <·······@online.no> wrote:
>> > 2. Lispers doing game development WITH lisp are nonexistent. Are you
>> > ready to be alone in your journey? Making something that noone will
>> > use.
>>
>> Oh yeah. Well this people didn't read your post.
>>
>> http://www.franz.com/success/customer_apps/animation_graphics/naughty...
>>
>> --------------
>> John Thingstad
>
> Look at the dates John , Naughty Dog is a c++ shop now :
So, but lisp is just an obsolete language nobody uses, right? Let's go
tell that to everyone so nobody get the stupid idea to actually use it.
If you want to tell people that they are stupid to suggest lisp can be
used for game development, what are you doing here?
/Andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Dec 19, 10:32 am, Andreas Davour <·······@updateLIKE.uu.HELLse>
wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > On Dec 19, 6:38 am, "John Thingstad" <·······@online.no> wrote:
> >> > 2. Lispers doing game development WITH lisp are nonexistent. Are you
> >> > ready to be alone in your journey? Making something that noone will
> >> > use.
>
> >> Oh yeah. Well this people didn't read your post.
>
> >>http://www.franz.com/success/customer_apps/animation_graphics/naughty...
>
> >> --------------
> >> John Thingstad
>
> > Look at the dates John , Naughty Dog is a c++ shop now :
>
> So, but lisp is just an obsolete language nobody uses, right? Let's go
> tell that to everyone so nobody get the stupid idea to actually use it.
>
> If you want to tell people that they are stupid to suggest lisp can be
> used for game development, what are you doing here?
>
> /Andreas
I said that Lispers doing ->game development WITH lisp<- are
nonexistent. And that's a fact, unless somebody could prove me wrong.
That's the way things are in the world. It doesn't matter do we like
it or not. And I don't think that writing wrappers to some c++ engine
will do lisp any good.
Been there, done that and it sucks. We need lisp solutions, because
they and only they could offer power of lisp from the bottom. Wrappers
are good only for things that are impossible (opengl) or not viable to
control (ssl, gtk, Qt).
I have a dream that someone will write a lisp proxy server to feel
safer on the internet.
I have a dream that someday Franz will offer AllegroCache and
AllegroGraph, for a fee, as separate products so the users of other
lisp implementation could feel the benefits, and lispers won't spend
time writing wrappers around relational databases.
And I have a dream that someone will write a game or graphic engine in
lisp.
And whoever writes any of those will be my hero, same as battyani,
king, weitz, constanza, foderaro, tilton, baringer, beane and many
other who wrote libraries are today.
The rest is your over-emotional response drawing conclusions for
things I never said.
cheers
Slobodan
P.S.
Under we I mean lisp community , lisp is a shorthand for common lisp.
On Dec 19, 8:29 pm, Slobodan Blazeski <·················@gmail.com>
wrote:
[snip]
> I have a dream that someone will write a lisp proxy server to feel
> safer on the internet.
[snip]
It's funny how ideas percolate to the surface at the time when they
are ripe (sorry for the mixed metaphor). I've been thinking about the
same thing the last month or so. Haven't seen anybody write about it
until now.
I think the reason why the time for this has come is not just due to
security, but to a host of other benefits:
o proxy servers are a good place to put IA[1] logic that can watch
our internet surfing, and act as our agent based on our click history:
- the proxy can do "preemptive polling" and cache the sites that we
most commonly frequent. They can also poll the sites that we've been
adding comments to to see if anybody has responded to the comments.
- proxies can tailor the sites to our preferences (e.g. removing
ads, flash, etc.)
o proxies can automatically index all the sites we've visited and
allow us to do personalized searches that even Google can't match.
o proxies can filter not only the obvious internet evils, but also be
set up to filter out, for example, porn (parents would like this--
think of the children!)
o proxies can be set up to allow parents to monitor their children's
internet usage
o proxies allow you to modify your browser environment much more
readily than waiting for MSoft to fix their software. It took MS
*years* to figure out that tabs were a Good Thing, and to correct the
problem. There is going to be much more evolution in how people are
going to surf the web, and it's not going to be done by the browser
manufacturers (because they iterate too infrequently). It's going to
be done by the people who either build the add-ons, or filter the
content (via proxies). The revolution isn't going to be televised,
it's going to be streamed through my (customized) proxy server.
As you can tell, I've spent way too much time thinking about this.
[1] IA Intelligent Application
--
(+ware) I rear-ended a car this morning. So there we are alongside the
road and
(+ware) slowly the driver gets out of the car . . . and you know how
you just get sooo
(+ware) stressed and life seems to get funny?
(+ware) Well, I could NOT believe it . . he was a DWARF! He storms
over to my car,
(+ware) looks up at me and says, "I AM NOT HAPPY!"
(+ware) So, I look down at him and say, "Well, which one are you
then?"... and
(+ware) THAT'S when the fight started . .
On Wed, 19 Dec 2007 19:32:45 +0100, Andreas Davour wrote:
> If you want to tell people that they are stupid to suggest lisp can be
> used for game development, what are you doing here?
If you read his earlier post, he was advising against using wrappers and
writing the engine in pure Lisp.
--
Sohail Somani
http://uint32t.blogspot.com
Slobodan Blazeski <·················@gmail.com> writes:
> I said that Lispers doing ->game development WITH lisp<- are
> nonexistent. And that's a fact, unless somebody could prove me wrong.
> That's the way things are in the world. It doesn't matter do we like
> it or not. And I don't think that writing wrappers to some c++ engine
> will do lisp any good.
> Been there, done that and it sucks. We need lisp solutions, because
> they and only they could offer power of lisp from the bottom. Wrappers
> are good only for things that are impossible (opengl) or not viable to
> control (ssl, gtk, Qt).
> I have a dream that someone will write a lisp proxy server to feel
> safer on the internet.
> I have a dream that someday Franz will offer AllegroCache and
> AllegroGraph, for a fee, as separate products so the users of other
> lisp implementation could feel the benefits, and lispers won't spend
> time writing wrappers around relational databases.
> And I have a dream that someone will write a game or graphic engine in
> lisp.
> And whoever writes any of those will be my hero, same as battyani,
> king, weitz, constanza, foderaro, tilton, baringer, beane and many
> other who wrote libraries are today.
>
> The rest is your over-emotional response drawing conclusions for
> things I never said.
The thing is telling someone that nobody does game development in Lisp,
and when someone post a sucess story you try to shoot it down is just
counter productive, thus my rant.
Just writing wrappers is not the same as actually doing real lisp
development, sure not. It is, though, way better than discourage people
so they go and write junk in something like C++ instead. Then you'll
never see anything on your wishlist above come true.
I understand what you meant, but think you're being negative and sulking
instead of encouraging. Probably not what you meant to do, but that's
how it came across. I tried to show it with my post. Maybe I was to
fancy. Text is a blunt medium for irony.
Now, let's go write that damn database or game engine in lisp, or
whatever.
/Andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Dec 20, 9:11 am, Andreas Davour <·······@updateLIKE.uu.HELLse>
wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > I said that Lispers doing ->game development WITH lisp<- are
> > nonexistent. And that's a fact, unless somebody could prove me wrong.
> > That's the way things are in the world. It doesn't matter do we like
> > it or not. And I don't think that writing wrappers to some c++ engine
> > will do lisp any good.
> > Been there, done that and it sucks. We need lisp solutions, because
> > they and only they could offer power of lisp from the bottom. Wrappers
> > are good only for things that are impossible (opengl) or not viable to
> > control (ssl, gtk, Qt).
> > I have a dream that someone will write a lisp proxy server to feel
> > safer on the internet.
> > I have a dream that someday Franz will offer AllegroCache and
> > AllegroGraph, for a fee, as separate products so the users of other
> > lisp implementation could feel the benefits, and lispers won't spend
> > time writing wrappers around relational databases.
> > And I have a dream that someone will write a game or graphic engine in
> > lisp.
> > And whoever writes any of those will be my hero, same as battyani,
> > king, weitz, constanza, foderaro, tilton, baringer, beane and many
> > other who wrote libraries are today.
>
> > The rest is your over-emotional response drawing conclusions for
> > things I never said.
>
> The thing is telling someone that nobody does game development in Lisp,
> and when someone post a sucess story you try to shoot it down is just
> counter productive, thus my rant.
I'm telling the true, no matter how much it hurts. Lispers doing -
>game development WITH lisp<- are nonexistent. Naghty Dod switched.
Lying ourselves will get us nowhere.
Having wrappers to powerfull engine is good if you plan to develop
games immediately and you don't have time nor expertise to do it
elsewhere. If you don't plan to do that, building lisp engine from
scratch, or rewriting one, has all the benefits I already mentioned.
On the bright side there are lispers who do game development. Dimiter
Stanev is our local cll celebrity (True Crime, Call of Duty,
Spiderman, NHL) see his profile at http://www.mobygames.com/developer/sheet/view/developerId,74492/
I learned myself a few things in my pixel mines period and certainly
there are many more doing graphics and working with opengl.
So if our pal want's to write his engine in lisp he'll be in far
better position to ask for help in this newsgroup. If he's doing
wrappers he's on his own.
> I understand what you meant, but think you're being negative and sulking
> instead of encouraging. Probably not what you meant to do, but that's
> how it came across. I tried to show it with my post. Maybe I was to
> fancy. Text is a blunt medium for irony.
If you expect from me say that situation is better than it actually is
better ask somebody else.
I don't like to lie to people, nor stressing the good and let them
find themselves about the bad.
When they came to me and say is lisp good for such and such
development, I told the truth, only the truth and nothing but the
truth. It's better to let them go learn whatever langauge that is best
suited for their problem than to have somebody burned and than cursing
lisp all his life. Lisp is not a golden hammer, it has the potential
to be one, but reality says something else.
>
> Now, let's go write that damn database or game engine in lisp, or
> whatever.
I'm currently busy working with and on weblocks http://common-lisp.net/project/cl-weblocks/
but if you start a project making a game engine and need some help I
will try to help you providing it doesn't take a lot from my time.
I don't know anything about database building.
cheers
Slobodan
>
> /Andreas
Slobodan Blazeski wrote:
> On Dec 20, 9:11 am, Andreas Davour <·······@updateLIKE.uu.HELLse>
> wrote:
>
>>Slobodan Blazeski <·················@gmail.com> writes:
>>
>>>I said that Lispers doing ->game development WITH lisp<- are
>>>nonexistent. And that's a fact, unless somebody could prove me wrong.
>>>That's the way things are in the world. It doesn't matter do we like
>>>it or not. And I don't think that writing wrappers to some c++ engine
>>>will do lisp any good.
>>>Been there, done that and it sucks. We need lisp solutions, because
>>>they and only they could offer power of lisp from the bottom. Wrappers
>>>are good only for things that are impossible (opengl) or not viable to
>>>control (ssl, gtk, Qt).
>>>I have a dream that someone will write a lisp proxy server to feel
>>>safer on the internet.
>>>I have a dream that someday Franz will offer AllegroCache and
>>>AllegroGraph, for a fee, as separate products so the users of other
>>>lisp implementation could feel the benefits, and lispers won't spend
>>>time writing wrappers around relational databases.
>>>And I have a dream that someone will write a game or graphic engine in
>>>lisp.
>>>And whoever writes any of those will be my hero, same as battyani,
>>>king, weitz, constanza, foderaro, tilton, baringer, beane and many
>>>other who wrote libraries are today.
>>
>>>The rest is your over-emotional response drawing conclusions for
>>>things I never said.
>>
>>The thing is telling someone that nobody does game development in Lisp,
>>and when someone post a sucess story you try to shoot it down is just
>>counter productive, thus my rant.
>
>
>
>
> I'm telling the true, no matter how much it hurts. Lispers doing -
>
>>game development WITH lisp<- are nonexistent. Naghty Dod switched.
>
> Lying ourselves will get us nowhere.
> Having wrappers to powerfull engine is good if you plan to develop
> games immediately and you don't have time nor expertise to do it
> elsewhere. If you don't plan to do that, building lisp engine from
> scratch, or rewriting one, has all the benefits I already mentioned.
> On the bright side there are lispers who do game development. Dimiter
> Stanev is our local cll celebrity (True Crime, Call of Duty,
> Spiderman, NHL) see his profile at http://www.mobygames.com/developer/sheet/view/developerId,74492/
> I learned myself a few things in my pixel mines period and certainly
> there are many more doing graphics and working with opengl.
> So if our pal want's to write his engine in lisp he'll be in far
> better position to ask for help in this newsgroup. If he's doing
> wrappers he's on his own.
Not so.
I do lotsa wrappers and am a big believer in doing new things with Lisp,
not reinventing existing accomplishments just to say, Look! It's Lisp!
Now you say there is a performance (frame-rate to be specific) hit of
30% calling OSG. You think rewriting it all in Lisp will reclaim that? I
would be surprised, 20% is as close as Lisp could get to C in this big a
library, I should think. Either way, it is more important to move a
project forward, and stopping to reinvent OSG will not do that. Now if
OSG sucks, hey, that is a whole nother story, but that is not what I am
hearing.
hth,kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 20, 1:51 pm, Ken Tilton <···········@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > On Dec 20, 9:11 am, Andreas Davour <·······@updateLIKE.uu.HELLse>
> > wrote:
>
> >>Slobodan Blazeski <·················@gmail.com> writes:
>
> >>>I said that Lispers doing ->game development WITH lisp<- are
> >>>nonexistent. And that's a fact, unless somebody could prove me wrong.
> >>>That's the way things are in the world. It doesn't matter do we like
> >>>it or not. And I don't think that writing wrappers to some c++ engine
> >>>will do lisp any good.
> >>>Been there, done that and it sucks. We need lisp solutions, because
> >>>they and only they could offer power of lisp from the bottom. Wrappers
> >>>are good only for things that are impossible (opengl) or not viable to
> >>>control (ssl, gtk, Qt).
> >>>I have a dream that someone will write a lisp proxy server to feel
> >>>safer on the internet.
> >>>I have a dream that someday Franz will offer AllegroCache and
> >>>AllegroGraph, for a fee, as separate products so the users of other
> >>>lisp implementation could feel the benefits, and lispers won't spend
> >>>time writing wrappers around relational databases.
> >>>And I have a dream that someone will write a game or graphic engine in
> >>>lisp.
> >>>And whoever writes any of those will be my hero, same as battyani,
> >>>king, weitz, constanza, foderaro, tilton, baringer, beane and many
> >>>other who wrote libraries are today.
>
> >>>The rest is your over-emotional response drawing conclusions for
> >>>things I never said.
>
> >>The thing is telling someone that nobody does game development in Lisp,
> >>and when someone post a sucess story you try to shoot it down is just
> >>counter productive, thus my rant.
>
> > I'm telling the true, no matter how much it hurts. Lispers doing -
>
> >>game development WITH lisp<- are nonexistent. Naghty Dod switched.
>
> > Lying ourselves will get us nowhere.
> > Having wrappers to powerfull engine is good if you plan to develop
> > games immediately and you don't have time nor expertise to do it
> > elsewhere. If you don't plan to do that, building lisp engine from
> > scratch, or rewriting one, has all the benefits I already mentioned.
> > On the bright side there are lispers who do game development. Dimiter
> > Stanev is our local cll celebrity (True Crime, Call of Duty,
> > Spiderman, NHL) see his profile athttp://www.mobygames.com/developer/sheet/view/developerId,74492/
> > I learned myself a few things in my pixel mines period and certainly
> > there are many more doing graphics and working with opengl.
> > So if our pal want's to write his engine in lisp he'll be in far
> > better position to ask for help in this newsgroup. If he's doing
> > wrappers he's on his own.
>
> Not so.
>
> I do lotsa wrappers and am a big believer in doing new things with Lisp,
> not reinventing existing accomplishments just to say, Look! It's Lisp!
> Now you say there is a performance (frame-rate to be specific) hit of
> 30% calling OSG. You think rewriting it all in Lisp will reclaim that? I
> would be surprised, 20% is as close as Lisp could get to C in this big a
> library, I should think. Either way, it is more important to move a
> project forward, and stopping to reinvent OSG will not do that. Now if
> OSG sucks, hey, that is a whole nother story, but that is not what I am
> hearing.
>
> hth,kt
>
> --http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
Does apache suck? I don't think so.
Then why the hell do we need AllegroServe, cl-http, hunchentoot ... we
should throw them all and use apache or lighttpd or whatever?
Is ruby on rails fine framework ? Then why do ucw, weblocks, kpax ..
exist>
Does postgre, mysql & oracle suck? Then why the hell Franz wrote
AllegroCache when I'm sure they could make some ORM mapping and be
done in a week.
And what about cl-ppcre ? Weren't there any c libraries implementing
regexes, that Edi could write wrappers around instead of *wasting* his
time?
What about Frederic Jolliton cl-vector? Why don't he wrote a wrappers
around some c library?
Or remember our friends from Hungary who want to change their current
load balancer with lisp based one?
IMHO Because wrappers are only temporary fix. They let you get things
done quickly but that's it. If I need to develop application in 3
months that Huge-library-that-I-don't-know -domain exists in c/c++/
whatever I would wrote wrappers and use it. But it's always going to
be a foreign code.
Something that whenever I'll need to improve I will have to write in c/
c++/whatever something that we all agree it's not fun. I don't even
want to mention dragging various dll/so files that could break your
code. When I wrote wrappers around foreign code I experienced more
image dumps in a day then using lisp only code in 4 years.
I applaud that we should do new things with lisp , but those are few
and far between while 95% of all inovations are incremental in nature.
If we go only for the new staff we'll be left behind, for good.
cheers
Slobodan
* According to Permanent inovation
The Definitive Guide to the Principles, Strategies, and Methods of
Successful Innovators
On Dec 20, 1:51 pm, Ken Tilton <···········@optonline.net> wrote:
> Now you say there is a performance (frame-rate to be specific) hit of
> 30% calling OSG. You think rewriting it all in Lisp will reclaim that? I
> would be surprised, 20% is as close as Lisp could get to C in this big a
> library, I should think.
I first wrote a raycar as c++ class, and just call it from lisp,
afterward I switched all the raycar code in lisp, and there was no
difference in performance. Not to mention that lisp version could be
tuned on the run, fixing those small parameters that make difference
in physics behaviour.
So who knows? cl-ppcre is (mostly) faster than c optimized perl
engine, if there is a need lisp engine could be tuned. The modern
graphic engines are mostly optimized for choosing what shouldn't be
rendered, implementing various techniques for culling unneeded
triangles (1). Less junk you send to your GPU the higher framerate you
get. And GPU is becoming more and more important than the cpu. If I
have a DX10 capable card I would be able 99,99% of all 2007 games on
my 2002 2.4 GHz cpu, if I have a 2007 quad core cpu that won't mean a
damn with a shity 2002 GPU. Also the physics is moving to GPU so the
difference would be even larger.
C & C++ compile to faster code with all the SIMD/SSE2/MMX things and
making fast code for the CPU but they have to call OpenGL/DirectX to
render their triangles in the Graphic card just like we do.
Whatever we choose in the cpu we gain multiple times in the gpu and
that's where the speed gains are highest.
cheers
Slobodan
(1)
http://lightfeather.de/e107_plugins/wet_wiki/index.php?page=EngineDesignIntroduction
The scenenode is then added to a scenegraph which is implemented as a
boundingvolume-tree which means that each node contains a
combinedboundingbox/sphere which contains all boundingboxes/spheres of
its children. This is used to speed up the frustumculling-process
because if a parent is not visible, its children are also invisible
(due to the boundingvolume containing all childrens boundingvolumes).
As sphere calculations are much faster than box-calculations, the
frustum culling works in multiple steps: first the boundingsphere of
the scenenode is culled against the sphere around the frustum of the
currently active camera. After that, the boundingsphere of the node is
culled against the cone of the frustum of the currently active camera.
The nodes that are still not culled are then culled against the
individual planes of the frustum of the currently active camera.
Slobodan Blazeski wrote:
> On Dec 20, 1:51 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>Slobodan Blazeski wrote:
>>
>>>On Dec 20, 9:11 am, Andreas Davour <·······@updateLIKE.uu.HELLse>
>>>wrote:
>>
>>>>Slobodan Blazeski <·················@gmail.com> writes:
>>
>>>>>I said that Lispers doing ->game development WITH lisp<- are
>>>>>nonexistent. And that's a fact, unless somebody could prove me wrong.
>>>>>That's the way things are in the world. It doesn't matter do we like
>>>>>it or not. And I don't think that writing wrappers to some c++ engine
>>>>>will do lisp any good.
>>>>>Been there, done that and it sucks. We need lisp solutions, because
>>>>>they and only they could offer power of lisp from the bottom. Wrappers
>>>>>are good only for things that are impossible (opengl) or not viable to
>>>>>control (ssl, gtk, Qt).
>>>>>I have a dream that someone will write a lisp proxy server to feel
>>>>>safer on the internet.
>>>>>I have a dream that someday Franz will offer AllegroCache and
>>>>>AllegroGraph, for a fee, as separate products so the users of other
>>>>>lisp implementation could feel the benefits, and lispers won't spend
>>>>>time writing wrappers around relational databases.
>>>>>And I have a dream that someone will write a game or graphic engine in
>>>>>lisp.
>>>>>And whoever writes any of those will be my hero, same as battyani,
>>>>>king, weitz, constanza, foderaro, tilton, baringer, beane and many
>>>>>other who wrote libraries are today.
>>
>>>>>The rest is your over-emotional response drawing conclusions for
>>>>>things I never said.
>>
>>>>The thing is telling someone that nobody does game development in Lisp,
>>>>and when someone post a sucess story you try to shoot it down is just
>>>>counter productive, thus my rant.
>>
>>>I'm telling the true, no matter how much it hurts. Lispers doing -
>>
>>>>game development WITH lisp<- are nonexistent. Naghty Dod switched.
>>
>>>Lying ourselves will get us nowhere.
>>>Having wrappers to powerfull engine is good if you plan to develop
>>>games immediately and you don't have time nor expertise to do it
>>>elsewhere. If you don't plan to do that, building lisp engine from
>>>scratch, or rewriting one, has all the benefits I already mentioned.
>>>On the bright side there are lispers who do game development. Dimiter
>>>Stanev is our local cll celebrity (True Crime, Call of Duty,
>>>Spiderman, NHL) see his profile athttp://www.mobygames.com/developer/sheet/view/developerId,74492/
>>>I learned myself a few things in my pixel mines period and certainly
>>>there are many more doing graphics and working with opengl.
>>>So if our pal want's to write his engine in lisp he'll be in far
>>>better position to ask for help in this newsgroup. If he's doing
>>>wrappers he's on his own.
>>
>>Not so.
>>
>>I do lotsa wrappers and am a big believer in doing new things with Lisp,
>>not reinventing existing accomplishments just to say, Look! It's Lisp!
>>Now you say there is a performance (frame-rate to be specific) hit of
>>30% calling OSG. You think rewriting it all in Lisp will reclaim that? I
>>would be surprised, 20% is as close as Lisp could get to C in this big a
>>library, I should think. Either way, it is more important to move a
>>project forward, and stopping to reinvent OSG will not do that. Now if
>>OSG sucks, hey, that is a whole nother story, but that is not what I am
>>hearing.
>>
>>hth,kt
>>
>>--http://www.theoryyalgebra.com/
>>
>>"In the morning, hear the Way;
>> in the evening, die content!"
>> -- Confucius
>
>
> Does apache suck? I don't think so.
> Then why the hell do we need AllegroServe, cl-http, hunchentoot ..
Save it. My main point was that you are wrong: someone working on
wrappers to OSG will /not/ be "on his own" in this newsgroup. It was
extremely weird seeing you trying to speak for the newsgroup in such a
hostile no-one-will-help-you fashion, so incorrectly.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 21, 6:29 am, Ken Tilton <···········@optonline.net> wrote:
> Save it. My main point was that you are wrong: someone working on
> wrappers to OSG will /not/ be "on his own" in this newsgroup. It was
> extremely weird seeing you trying to speak for the newsgroup in such a
> hostile no-one-will-help-you fashion, so incorrectly.
>
> kt
Probably it was my genral frustration with wrappers talking instead of
reason. I apologize.
cheers
Slobodan
Slobodan Blazeski wrote:
> On Dec 21, 6:29 am, Ken Tilton <···········@optonline.net> wrote:
>
>>Save it. My main point was that you are wrong: someone working on
>>wrappers to OSG will /not/ be "on his own" in this newsgroup. It was
>>extremely weird seeing you trying to speak for the newsgroup in such a
>>hostile no-one-will-help-you fashion, so incorrectly.
>>
>>kt
>
>
> Probably it was my genral frustration with wrappers talking instead of
> reason. I apologize.
Very gracious of you. My next concern is the application of a general
frustration to what must be a specific requirement, the OP's. What is
their deadline? How good a fit is OSG for them, meaning how much
wrastling will be required even if they had the perfect bindings? Do
they have the chops to ground up an SG? Even with all that information
it is still a tough call -- we don't just autogen bindings, tho that's a
good start. There is always lispification to be done to truly benefit
from using Lisp. So the wrapping approach should never be looked at as
free, it is substantial and perpetual. The cost of ground upping
something like OSG is vast and potentially ultimate in that one might
well go in and never come out, end of enterprise.
In brief, I'd at least find out the deadline and whether the OP even has
the skills to reinvent OSG before excoriating them for wanting to build
a wrapper.
Finally, the Lisp community enjoys pretty sweet wrappers for Gtk and
Tcl/Tk, and on the pure Lisp side we have <cough> McCLIM, which is
impossible to learn and runs on about 4% of the world's computers. 'nuff
said?
kt
ps. Why all those Web frameworks? Because they are easy? Why cl-ppcre?
Because Edi got bored one day? etc etc kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Fri, 21 Dec 2007 19:51:32 -0500, Ken Tilton <···········@optonline.net> wrote:
> Why all those Web frameworks? Because they are easy? Why cl-ppcre?
> Because Edi got bored one day?
Right, it was actually the result of a bet and I happened to have some
spare time when I wrote it.
But allow me to get serious for a second. My personal experience is
that adding a C/C++ library to a Lisp project increases the amount of
headache you'll eventually have in the deployment phase by an order of
magnitude. I've worked on a project which involved access to SQL
databases via CLSQL and every time we had to install the application
on a new machine we encountered new problems (costing valuable time)
which were all related to the C libraries, their versions, their
locations, environment variables, all that stuff. I've had similar
problems with GD and other C libs.
Whenever there's a chance to have a solution that's "Lisp all the way
down", I'll go for it, even if it looks like a bit more work in the
beginning. Debugging broken C code is a fucking waste of time and
it's no fun at all. And even if the C code itself is not broken,
something else will fail. You might need a supporting C library that
doesn't work with your current kernel. Your customer wants the code
to be ported from Linux to Windows and the C code doesn't compile
there. Some admin guy does a "system upgrade" and suddenly your app
stops working. I could go on. BTDTGTTS.
YMMV, of course.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
I couldn't agree more with Edi I just want to add my remarks.
We should make it clear that's c++ we're interfacing to, not a c.
1st there is no direct way to interface with c++ code , only with c
http://www.lispworks.com/documentation/lw50/FLI/html/fli-57.htm#pgfId-891065
so you should either change c++ engine code or write a dll with c
wrappers
2nd c is a simple language c++ is very complex, you can't initialize
SceneNodeActorC++Class in lisp and use it back and forth in your c+
+/lisp interaction. You have to add another layer of abstraction to do
it for you
3rd Lispification is very hard, for most of c++ idioms there is no
direct mapping to lisp , so you will spend a lot of time writing a
glue code,
4th Game engines are fast moving target ,after 2 or 3 months they will
change so much that lot of your code from steps 1,2,3 will have to be
rewritten and reengineered.
Add to above the bugs in the c++ code, the implementations FFI code,
FFI abstraction code (CFFI /UFFI) , lispification code and you will
get exponential increase in complexity .
And if you plan to solve those you better understand what the hell is
going on in the c++ engine.
I'm telling OP, no I'm begging him, to stay away from wrappers to c++
game engines .
You're going to be torchured in purgatory and afterwards going
directly in hell. 9th circle
Don't be afraid that you will have to learn how engines behave ,
because if you plan to make your wrappers work you will have to learn
that anyway, but the wrong way.
If you really need wrappers find some c or c# engine to interact c+
+ will destroy you.
Slobodan
Slobodan Blazeski wrote:
> I couldn't agree more with Edi I just want to add my remarks.
Then you are wrong, too:
http://common-lisp.net/project/cello/
> We should make it clear that's c++ we're interfacing to, not a c.
>
> 1st there is no direct way to interface with c++ code ...
That's funny, Rayiner did not think it would be a problem:
http://common-lisp.net/project/fetter/
The difference between me and the rest of you c.l.l talk all day when
you could be producing something useful piss-arounds* is that I actually
write applications and I actually understand that Lisp makes me more
productive when it is not distracting me by being so much fun in its own
right (http://common-lisp.net/project/cells/). So if I have something
that stands between me and (see sig) I Just Solve It, I do not climb up
on my c.l.l sandbox and say things are not possible. These things are
hard when you do not need to them, just as Lisp syntax is funny if you
are not doing it. They say the difference between a struggle and an
adventure is the attitude one brings to it. Something like that.
kt
* No one has finished Vzn in two years of waiting. Lisp may not be dead,
but its users are useless. We won't go into how they smell. k
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Sun, 23 Dec 2007 11:19:49 -0500, Ken Tilton
<···········@optonline.net> wrote:
>
>
>Slobodan Blazeski wrote:
>> I couldn't agree more with Edi I just want to add my remarks.
>
> Then you are wrong, too:
>
> http://common-lisp.net/project/cello/
>
>> We should make it clear that's c++ we're interfacing to, not a c.
>>
>> 1st there is no direct way to interface with c++ code ...
>
>
>That's funny, Rayiner did not think it would be a problem:
>
> http://common-lisp.net/project/fetter/
Interfacing to C++ isn't much more difficult than interfacing to C,
the problem is the lack of a standard name mangling scheme. It's not
complicated to handle, it's just a pain to have to do it over and over
again for different C++ compilers.
George
--
for email reply remove "/" from address
George Neuner wrote:
> On Sun, 23 Dec 2007 11:19:49 -0500, Ken Tilton
> <···········@optonline.net> wrote:
>
>
>>
>>Slobodan Blazeski wrote:
>>
>>>I couldn't agree more with Edi I just want to add my remarks.
>>
>> Then you are wrong, too:
>>
>> http://common-lisp.net/project/cello/
>>
>>
>>>We should make it clear that's c++ we're interfacing to, not a c.
>>>
>>>1st there is no direct way to interface with c++ code ...
>>
>>
>>That's funny, Rayiner did not think it would be a problem:
>>
>> http://common-lisp.net/project/fetter/
>
>
>
> Interfacing to C++ isn't much more difficult than interfacing to C,
> the problem is the lack of a standard name mangling scheme. It's not
> complicated to handle, it's just a pain to have to do it over and over
> again for different C++ compilers.
Over and over? I thought we were down to VC++ and the Gnu compiler?
Anyway, yeah, I think Rayiner did the Gnu compiler, VC++ left as an
exercise.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Sun, 23 Dec 2007 18:47:02 -0500, Ken Tilton
<···········@optonline.net> wrote:
>> Interfacing to C++ isn't much more difficult than interfacing to C,
>> the problem is the lack of a standard name mangling scheme. It's not
>> complicated to handle, it's just a pain to have to do it over and over
>> again for different C++ compilers.
>
>Over and over? I thought we were down to VC++ and the Gnu compiler?
>Anyway, yeah, I think Rayiner did the Gnu compiler, VC++ left as an
>exercise.
Not quite yet and probably not ever. All the world is not an x86
compatible desktop or a Java VM.
Just off the top of my head: IBM, Intel, Sun, Motorola and Analog
Devices all have compilers for various of their chips that are not
based on GCC.
Although you can find a GCC for most chips, many are based on old
versions of the compiler. As you are probably aware, GCC has had an
backward compatibility problem since day 2 ... even working with
compatible chips within a family you may have to use more than one
compiler.
George
--
for email reply remove "/" from address
George Neuner wrote:
> On Sun, 23 Dec 2007 18:47:02 -0500, Ken Tilton
> <···········@optonline.net> wrote:
>
>
>>>Interfacing to C++ isn't much more difficult than interfacing to C,
>>>the problem is the lack of a standard name mangling scheme. It's not
>>>complicated to handle, it's just a pain to have to do it over and over
>>>again for different C++ compilers.
>>
>>Over and over? I thought we were down to VC++ and the Gnu compiler?
>>Anyway, yeah, I think Rayiner did the Gnu compiler, VC++ left as an
>>exercise.
>
>
> Not quite yet and probably not ever. All the world is not an x86
> compatible desktop or a Java VM.
>
> Just off the top of my head: IBM, Intel, Sun, Motorola and Analog
> Devices all have compilers for various of their chips that are not
> based on GCC.
>
> Although you can find a GCC for most chips, many are based on old
> versions of the compiler. As you are probably aware, GCC has had an
> backward compatibility problem since day 2 ... even working with
> compatible chips within a family you may have to use more than one
> compiler.
Yeah, but we are just talking about one simple issue in order to open up
all C++ libraries to Lisp, and Lispniks make it sound like a dead
frickin end, insurmountable, game over, let's go shopping when all that
is needed is a little elbow grease. It is a sad sign that no one has
stepped up to finish Vzn.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mon, 24 Dec 2007 20:18:26 -0500, Ken Tilton
<···········@optonline.net> wrote:
>George Neuner wrote:
>> On Sun, 23 Dec 2007 18:47:02 -0500, Ken Tilton
>> <···········@optonline.net> wrote:
>>
>>
>>>>Interfacing to C++ isn't much more difficult than interfacing to C,
>>>>the problem is the lack of a standard name mangling scheme. It's not
>>>>complicated to handle, it's just a pain to have to do it over and over
>>>>again for different C++ compilers.
>>>
>>>Over and over? I thought we were down to VC++ and the Gnu compiler?
>>>Anyway, yeah, I think Rayiner did the Gnu compiler, VC++ left as an
>>>exercise.
>>
>>
>> Not quite yet and probably not ever. All the world is not an x86
>> compatible desktop or a Java VM.
>>
>> Just off the top of my head: IBM, Intel, Sun, Motorola and Analog
>> Devices all have compilers for various of their chips that are not
>> based on GCC.
>>
>> Although you can find a GCC for most chips, many are based on old
>> versions of the compiler. As you are probably aware, GCC has had an
>> backward compatibility problem since day 2 ... even working with
>> compatible chips within a family you may have to use more than one
>> compiler.
Forgot to mention that GCC has also screwed with the function calling
conventions along the way.
>Yeah, but we are just talking about one simple issue in order to open up
>all C++ libraries to Lisp, and Lispniks make it sound like a dead
>frickin end, insurmountable, game over, let's go shopping when all that
>is needed is a little elbow grease. It is a sad sign that no one has
>stepped up to finish Vzn.
Absolutely. It's hardly insurmountable, particularly for Lisp because
virtually all linking will be done dynamically at run time (it's a
much harder problem to solve for static linking). I would think a
general solution wouldn't be too hard to implement - just tedious to
configure properly.
>
>kt
George
--
for email reply remove "/" from address
George Neuner wrote:
> On Sun, 23 Dec 2007 18:47:02 -0500, Ken Tilton
> <···········@optonline.net> wrote:
>
>
>>>Interfacing to C++ isn't much more difficult than interfacing to C,
>>>the problem is the lack of a standard name mangling scheme. It's not
>>>complicated to handle, it's just a pain to have to do it over and over
>>>again for different C++ compilers.
>>
>>Over and over? I thought we were down to VC++ and the Gnu compiler?
>>Anyway, yeah, I think Rayiner did the Gnu compiler, VC++ left as an
>>exercise.
>
>
> Not quite yet and probably not ever.
Well bring in the frickin violins and run up the white flag, the Lisp
community in all its smugweeniness apparently lacks the chops to tackle
a merely tedious engineering problem. So much for macros! I thought
macros could do everything! Well, let's go shopping, god forbid somebody
hunker down and do a lick of work.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Sun, 23 Dec 2007 11:19:49 -0500, Ken Tilton wrote:
> http://common-lisp.net/project/cello/
Hi, how do you get at the source for this project? The ftp service seems
to be down.
Thanks.
--
Sohail Somani
http://uint32t.blogspot.com
Sohail Somani wrote:
> On Sun, 23 Dec 2007 11:19:49 -0500, Ken Tilton wrote:
>
>
>> http://common-lisp.net/project/cello/
>
>
> Hi, how do you get at the source for this project? The ftp service seems
> to be down.
>
(a) http://common-lisp.net/cgi-bin/viewcvs.cgi/?root=cello
This by the way is a meta-tip for anyone lusting after any c-l.net code
-- go to the c-l.net homepage and follow the repositories link at the
top. That's what The Kenny does.
(b) There is in the cells (I think) mailing list archive (in the past
few weeks) a terrifying post from Frank G. on how to build Cello. He
estimates three weeks from scratch. PWUAHAHAHAHA. Unfortunately this
Open Source Fairy has left the building so it is every hacker for
themself until someone steps up to play Cello OSF.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 23, 8:19 am, Ken Tilton <···········@optonline.net> wrote:
> Slobodan Blazeski wrote:
> > I couldn't agree more with Edi I just want to add my remarks.
>
> Then you are wrong, too:
>
> http://common-lisp.net/project/cello/
I don't think so. Cello components are :cl-opengl, cl-ftgl, cl-
magick , cellocore.
Cellocore is pure lisp, cl-opengl are wrappers around stable c library
defined in early 90s, with some revisions about shaders that I doubt
you're using. cl-magick is probably wrappers around c MagickCore not
Magick++ (are they?) so that leaves Cello only with ftgl. How much
effort does it take to make ftgl c compatible ?
http://common-lisp.net/pipermail/cells-devel/2004-February/000075.html
The functionality of ftgl exist in all the engines I worked for, and
it's a negligeble part of the engine. The real problems are
elsewhere.
But you are right about one thing, this thread is waste of time, that
should be spent lisping
Slobodan
Slobodan Blazeski <·················@gmail.com> writes:
> I couldn't agree more with Edi I just want to add my remarks.
> We should make it clear that's c++ we're interfacing to, not a c.
> [...]
> 2nd c is a simple language c++ is very complex, you can't initialize
> SceneNodeActorC++Class in lisp and use it back and forth in your c+
> +/lisp interaction. You have to add another layer of abstraction to do
> it for you
Some C++ code bodies use a lot of templates (just consider the stl).
Using them from lisp would mean that any form typed at the REPL would
involve generating some C++ source, compile it (to expand the
templates) and dynamically load it before calling the expression.
> [...]
> I'm telling OP, no I'm begging him, to stay away from wrappers to c++
> game engines .
> You're going to be torchured in purgatory and afterwards going
> directly in hell. 9th circle
> Don't be afraid that you will have to learn how engines behave ,
> because if you plan to make your wrappers work you will have to learn
> that anyway, but the wrong way.
> If you really need wrappers find some c or c# engine to interact c+
> + will destroy you.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
>
>> I couldn't agree more with Edi I just want to add my remarks.
>> We should make it clear that's c++ we're interfacing to, not a c.
>> [...]
>> 2nd c is a simple language c++ is very complex, you can't initialize
>> SceneNodeActorC++Class in lisp and use it back and forth in your c+
>> +/lisp interaction. You have to add another layer of abstraction to do
>> it for you
>
> Some C++ code bodies use a lot of templates (just consider the stl).
> Using them from lisp would mean that any form typed at the REPL would
> involve generating some C++ source, compile it (to expand the
> templates) and dynamically load it before calling the expression.
At first, this does seem like an issue. On further inspection, I
found that its rarely an issue.
With any of these lisp/C bindings, the purpose of the exercise is
generally to use an existing library within lisp. Generally, if the
library function accepts/returns arguments, then the argument
constructor and destructor functions are nearby.
Its only when you want to do more programming in C++ (i.e. extend the
library) that compilation is needed.
A simple "template class<params>;" (note the missing <> between
template and class) will generally instantiate all the member
functions for a given class... Recompiling libraries is business as
usual when using C++.
- Daniel
P.S. This looks interesting:
http://root.cern.ch/twiki/bin/view/ROOT/CINT
Edi Weitz wrote:
> On Fri, 21 Dec 2007 19:51:32 -0500, Ken Tilton <···········@optonline.net> wrote:
>
>
>>Why all those Web frameworks? Because they are easy? Why cl-ppcre?
>>Because Edi got bored one day?
>
>
> Right, it was actually the result of a bet and I happened to have some
> spare time when I wrote it.
>
> But allow me to get serious for a second. My personal experience is
> that adding a C/C++ library to a Lisp project increases the amount of
> headache you'll eventually have in the deployment phase by an order of
> magnitude. I've worked on a project which involved access to SQL
> databases via CLSQL and every time we had to install the application
> on a new machine we encountered new problems (costing valuable time)
> which were all related to the C libraries, their versions, their
> locations, environment variables, all that stuff. I've had similar
> problems with GD and other C libs.
>
> Whenever there's a chance to have a solution that's "Lisp all the way
> down", I'll go for it, even if it looks like a bit more work in the
> beginning. Debugging broken C code is a fucking waste of time and
> it's no fun at all. And even if the C code itself is not broken,
> something else will fail. You might need a supporting C library that
> doesn't work with your current kernel. Your customer wants the code
> to be ported from Linux to Windows and the C code doesn't compile
> there. Some admin guy does a "system upgrade" and suddenly your app
> stops working. I could go on. BTDTGTTS.
>
> YMMV, of course.
>
Well it certainly did vary with Cello, where I use OpenGL, OpenAL for 3d
audio, FTGL/FreeType for seven flavors of type rendering, several
antialiased, GraphicsMagick for a huge library of image manipulation
functions on a vast number of image types, the entire Tcl/Tk platform
for the window/event layer and everything else that provides including
plug-n-play opengl, audio, and QuickTime packages. These all have run on
win32, the Mac, and Linux.
The only problem, and this is a problem with Lisp in general, is that I
started having so much damn fun I forgot to do my application.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Edi Weitz wrote:
> On Fri, 21 Dec 2007 19:51:32 -0500, Ken Tilton <···········@optonline.net> wrote:
>
>
>>Why all those Web frameworks? Because they are easy? Why cl-ppcre?
>>Because Edi got bored one day?
>
>
> Right, it was actually the result of a bet and I happened to have some
> spare time when I wrote it.
>
> But allow me to get serious for a second. My personal experience is
> that adding a C/C++ library to a Lisp project increases the amount of
> headache you'll eventually have in the deployment phase by an order of
> magnitude. I've worked on a project which involved access to SQL
> databases via CLSQL and every time we had to install the application
> on a new machine we encountered new problems (costing valuable time)
> which were all related to the C libraries, their versions, their
> locations, environment variables, all that stuff. I've had similar
> problems with GD and other C libs.
>
> Whenever there's a chance to have a solution that's "Lisp all the way
> down", I'll go for it, even if it looks like a bit more work in the
> beginning. Debugging broken C code is a fucking waste of time and
> it's no fun at all. And even if the C code itself is not broken,
> something else will fail. You might need a supporting C library that
> doesn't work with your current kernel. Your customer wants the code
> to be ported from Linux to Windows and the C code doesn't compile
> there. Some admin guy does a "system upgrade" and suddenly your app
> stops working. I could go on. BTDTGTTS.
>
> YMMV, of course.
>
Well it certainly did vary with Cello, where I use OpenGL, OpenAL for 3d
audio, FTGL/FreeType for seven flavors of type rendering, several
antialiased, GraphicsMagick for a huge library of image manipulation
functions on a vast number of image types, the entire Tcl/Tk platform
for the window/event layer and everything else that provides including
plug-n-play opengl, audio, and QuickTime packages. These all have run on
win32, the Mac, and Linux.
The only problem, and this is a problem with Lisp in general, is that I
started having so much damn fun I forgot to do my application.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Edi Weitz <········@agharta.de> wrote:
+---------------
| But allow me to get serious for a second. My personal experience is
| that adding a C/C++ library to a Lisp project increases the amount of
| headache you'll eventually have in the deployment phase by an order of
| magnitude. I've worked on a project which involved access to SQL
| databases via CLSQL and every time we had to install the application
| on a new machine we encountered new problems (costing valuable time)
| which were all related to the C libraries, their versions, their
| locations, environment variables, all that stuff. I've had similar
| problems with GD and other C libs.
|
| Whenever there's a chance to have a solution that's "Lisp all the way
| down", I'll go for it, even if it looks like a bit more work in the
| beginning. ...
+---------------
Yup. Every time I hear somebody say that it makes me really, *really*
glad that I went with <http://www.cliki.net/Pg> back in 2002 when I
started writing SQL-backed web apps in CL. I've had the version of
PostgreSQL running in dedicated production servers in co-lo sites
"accidentally" upgraded several times by careless "Customer Care"
admins, even though they had been specifically instructed not to!!
Never mind, the CL apps kept working just fine, since PG speaks the
PostgreSQL socket protocol directly, *not* some C library binding.
Thanks again to Eric Marsden for this fine tool.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Edi Weitz schrieb:
> Whenever there's a chance to have a solution that's "Lisp all the way
> down", I'll go for it, even if it looks like a bit more work in the
> beginning. Debugging broken C code is a fucking waste of time and
> it's no fun at all. And even if the C code itself is not broken,
> something else will fail. You might need a supporting C library that
> doesn't work with your current kernel. Your customer wants the code
> to be ported from Linux to Windows and the C code doesn't compile
> there. Some admin guy does a "system upgrade" and suddenly your app
> stops working. I could go on. BTDTGTTS.
And you say that this only (or probably especially) applies to C/C++
code? What's with all the incompatible, unportable implementations of
(Common) Lisp and specific libraries? Just evaluating which
CL-implementation to use after finding out whether libraries you need
(or may need, later) are compatible with which implementations are a
major headache. I don't have (any/much) experience in deploying Lisp
applications, but what I've seen so far is much more dependency-ridden
than any C-stuff I know.
Daniel
On Wed, 26 Dec 2007 04:53:25 +0100, Daniel Albuschat <······@happy.viming.de> wrote:
> And you say that this only (or probably especially) applies to C/C++
> code?
No. Where did you read that?
What I said is that debugging C code isn't fun (for me). I enjoyed
writing assembler code when I was 17 years old, but I'm too old for
that now.
I also said: YMMV.
> What's with all the incompatible, unportable implementations of
> (Common) Lisp and specific libraries? Just evaluating which
> CL-implementation to use after finding out whether libraries you
> need (or may need, later) are compatible with which implementations
> are a major headache.
In practice, this has never been a problem for me. All denizens of
c.l.l of course know that Kenny is The Only Application Programmer[TM]
here, but let's assume for the sake of argument that I've also written
and delivered one or two applications written in Common Lisp. What
happens if you work with CL professionally is the following:
1. You'll sooner or later decide to use one specific implementation
and you'll usually stick with it.
2. Once you've done that, you'll most likely figure out that there are
maybe one or two dozens of libraries you're really going to use.
(Yes, common-lisp.net alone lists more than 300 libraries nowadays
and lots of them don't even have an introductory webpage, let alone
code you can download and use. But how many of them do you really
/need/?)
3. If these libraries don't work with your favorite Lisp
implementation, it is usually very easy to fix that.
At least that's /my/ experience. Now tell us what /you/ wanted to do
and what exactly prevented you from doing that. List the libraries
and the implementations you couldn't use. Maybe we can help you.
> I don't have (any/much) experience in deploying Lisp applications
Yeah, I guessed that.
> but what I've seen so far is much more dependency-ridden than any
> C-stuff I know.
Did you work on a really large and complex C project? Did you decide
to switch to a different C compiler in the middle of it?
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Wed, 26 Dec 2007 04:53:25 +0100, Daniel Albuschat <······@happy.viming.de> wrote:
>
>
>>And you say that this only (or probably especially) applies to C/C++
>>code?
>
>
> No. Where did you read that?
>
> What I said is that debugging C code isn't fun (for me). I enjoyed
> writing assembler code when I was 17 years old, but I'm too old for
> that now.
>
> I also said: YMMV.
>
>
>>What's with all the incompatible, unportable implementations of
>>(Common) Lisp and specific libraries? Just evaluating which
>>CL-implementation to use after finding out whether libraries you
>>need (or may need, later) are compatible with which implementations
>>are a major headache.
>
>
> In practice, this has never been a problem for me.
Rubbish! I mean responding to this bozo, we need a no-feed-trolls logo here.
> All denizens of
> c.l.l of course know that Kenny is The Only Application Programmer[TM]
> here,...
Finally I am making some headway with you people!
But let's not forget the dark matter, the vast majority of Lispniks who
do not know c.l.l even exists. Can't wait to see the expression on their
faces at ECLM.
> Did you work on a really large and complex C project? Did you decide
> to switch to a different C compiler in the middle of it?
Yes. Symantec C to CodeWarrior. O. Mi. God. Such a joy when every
incompatibility brings down the system.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
> ps. Why all those Web frameworks? Because they are easy? Why cl-ppcre?
> Because Edi got bored one day? etc etc kt
Web frameworks /seem/ easy because web programming is relatively new
and no-one has figured out how to do it right. The good webapp
frameworks that I know are only really useful in specific
instances. It's obvious there's a lot of open field to play on.
Perl-style regular expressions are great because they're a very concise
and portable way of doing fairly arbitrary matching on strings while
still being constrained enough to be optimized. I'm not claiming string
can't be improved upon, but for a lot of problems regular perl's regular
expressions have just the right combination of flexibility and
computability.
By the way, take note of the new constructs in the just released perl
5.10:
http://search.cpan.org/~rgarcia/perl-5.10.0/pod/perl5100delta.pod#Regular_expressions
And IIRC perl 6's design has optimized support for "nested" regular
expressions which is great when you're dealing with very complex file formats.
Joost.
On Sat, 22 Dec 2007 02:55:41 +0100, Joost Diepenmaat <·····@zeekat.nl> wrote:
> Perl-style regular expressions are great because [...]
I think Kenny didn't want to know what's so great about regular
expressions. He wanted to know why I didn't write Lisp bindings for
PCRE. The answer of course is that they existed already. How many of
you guys use them, BTW?
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Sat, 22 Dec 2007 02:55:41 +0100, Joost Diepenmaat <·····@zeekat.nl> wrote:
>
>> Perl-style regular expressions are great because [...]
>
> I think Kenny didn't want to know what's so great about regular
> expressions. He wanted to know why I didn't write Lisp bindings for
> PCRE. The answer of course is that they existed already. How many of
> you guys use them, BTW?
Them what?
've never knowingly used PCRE. Some programs that I do use may use it.
I have used cl-ppcre, simply because it works and I know perl-style
regexes and I hate having to type more than necessary. :-)
Thanks and happy holidays!
Joost.
On Sat, 22 Dec 2007 03:33:43 +0100, Joost Diepenmaat <·····@zeekat.nl> wrote:
>> He wanted to know why I didn't write Lisp bindings for PCRE. The
>> answer of course is that they existed already. How many of you
>> guys use them, BTW?
>
> Them what?
The PCRE bindings for Lisp. CLiki shows this
http://www.cliki.net/PCRE
but I seem to rememeber Dan Barlow also once offered PCRE bindings.
Hmm, can't find them right now...
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> The PCRE bindings for Lisp. CLiki shows this
>
> http://www.cliki.net/PCRE
>
> but I seem to rememeber Dan Barlow also once offered PCRE bindings.
> Hmm, can't find them right now...
No, well, nor can I. But I use CL-PPCRE now anyway ;-)
-dan
Slobodan Blazeski <·················@gmail.com> writes:
>> I understand what you meant, but think you're being negative and
>> sulking instead of encouraging. Probably not what you meant to do,
>> but that's how it came across. I tried to show it with my post. Maybe
>> I was to fancy. Text is a blunt medium for irony.
>
> If you expect from me say that situation is better than it actually is
> better ask somebody else. I don't like to lie to people, nor
> stressing the good and let them find themselves about the bad. When
> they came to me and say is lisp good for such and such development, I
> told the truth, only the truth and nothing but the truth. It's better
> to let them go learn whatever langauge that is best suited for their
> problem than to have somebody burned and than cursing lisp all his
> life. Lisp is not a golden hammer, it has the potential to be one, but
> reality says something else.
>
>>
>> Now, let's go write that damn database or game engine in lisp, or
>> whatever.
>
> I'm currently busy working with and on weblocks
> http://common-lisp.net/project/cl-weblocks/ but if you start a project
> making a game engine and need some help I will try to help you
> providing it doesn't take a lot from my time. I don't know anything
> about database building.
Since you apparantly didn't get my point I guess there's no point in me
continuing. It's good that you're doing weblocks and good luck with that
project!
/Andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
You (intentionally?) left out this part:
>We were so used to working with this language GOAL which was very flexible and the whole purpose of it was so you
>could have your game running, you could compile your code and you could update your game right away without restarting the system,
>it's a really good environment and I miss it, you can tell.
Notice the "and I miss it, you can tell" part?
Baalbek
On Mon, 17 Dec 2007 01:06:58 -0800, quasistellarlight wrote:
> While trying to make a binding to a heavily-OOP (in C++ notion) library
> I stuck in question: is it possible to reflect all the C++ classes and
> methods in CLOS? I mean I really want to have the ability to extend the
> library from Common Lisp`s side and utilize CLOS. Can you please point
> me to some source that will provide me the answer?
It's difficult enough to do the same in C++. Your best bet when it comes
to cross-language C++ is using something like Boost.Python or SWIG. I
think SWIG can generate ?ffi bindings.
--
Sohail Somani
http://uint32t.blogspot.com