Hi,
AFAIK, there doesn't exist an XPCOM bridge for Common Lisp. I think
such a project would bring seriously good potentials for Common Lisp.
For instance, as a very simple example, you'll be able to write cross-
platform GUI enable applications in Common Lisp by interfacing XUL
components through XPCOM bindings. (No need to say that you'll also be
free to use your favorite sexp-to-xml tool.) I don't want to push this
work to someone else's shoulders, and am volunteered to help to the
implementation of cl-xpcom. The problem is, I don't have any
experience with any COM derivate and looking for some sort of mentor.
Would anybody mind assisting me in the right direction to implement an
XPCOM bridge for Common Lisp?
Regards.
P.S. There was a project -- that I couldn't recall its name right now
-- that enables Mozilla to interpret Common Lisp code between <script>
tags by embedding ECL into Mozilla core. But that's not the same thing
I have in mind. In such an implementation, your common lisp code gets
executed by Mozilla using ECL, which makes it, IMHO, impossible to
have any REPL interaction, which I think totally terminates the crux
of the idea.
On Aug 13, 9:24 am, Volkan YAZICI <·············@gmail.com> wrote:
> Hi,
>
> AFAIK, there doesn't exist an XPCOM bridge for Common Lisp. I think
> such a project would bring seriously good potentials for Common Lisp.
> For instance, as a very simple example, you'll be able to write cross-
> platform GUI enable applications in Common Lisp by interfacing XUL
> components through XPCOM bindings. (No need to say that you'll also be
> free to use your favorite sexp-to-xml tool.) I don't want to push this
> work to someone else's shoulders, and am volunteered to help to the
> implementation of cl-xpcom. The problem is, I don't have any
> experience with any COM derivate and looking for some sort of mentor.
> Would anybody mind assisting me in the right direction to implement an
> XPCOM bridge for Common Lisp?
>
> Regards.
I have no experience in XPCOM, either, but I too think it would be a
great project. Unfortunately I have very little spare time, but
nevertheless if I can be of any help, I'd be willing to partecipate to
such a project. I briefly worked with COM in C++ some time ago and it
was a real pain (to be fair, in part that's because I was completely
new to that technology and in very little time I had to hack something
functional).
> P.S. There was a project -- that I couldn't recall its name right now
> -- that enables Mozilla to interpret Common Lisp code between <script>
> tags by embedding ECL into Mozilla core. But that's not the same thing
> I have in mind. In such an implementation, your common lisp code gets
> executed by Mozilla using ECL, which makes it, IMHO, impossible to
> have any REPL interaction, which I think totally terminates the crux
> of the idea.
You're speaking of Kamen Lisp, I guess. I recall it had some way of
accessing the HTML DOM... never got it to run though. I agree that's a
different project, albeit interesting as well. It's more like the Java
plugin for Lisp.
Regards,
Alessio
On Aug 13, 3:01 pm, Alessio Stalla <·············@gmail.com> wrote:
> I have no experience in XPCOM, either, but I too think it would be a
> great project. Unfortunately I have very little spare time, but
> nevertheless if I can be of any help, I'd be willing to partecipate to
> such a project. I briefly worked with COM in C++ some time ago and it
> was a real pain (to be fair, in part that's because I was completely
> new to that technology and in very little time I had to hack something
> functional).
I have never coded C++, but know C -- not filled my 10th year in C
thou. And I think I can imitate C++ sources of existing F/OSS
projects. Should I interpret your comment as that a solid C++
background is a must for such a project? If you have experience both
in C++ and COM, would you mind checking sources of existing XPCOM
bindings (e.g. PyXPCOM, RbXPCOM, JavaXPCOM, etc.) and giving a rough
explanation about the complicity level of C++ related parts?
> You're speaking of Kamen Lisp, I guess. I recall it had some way of
> accessing the HTML DOM... never got it to run though. I agree that's a
> different project, albeit interesting as well. It's more like the Java
> plugin for Lisp.
Yep, it is Kamen Lisp.
Regards.
On 13 Ago, 14:44, Volkan YAZICI <·············@gmail.com> wrote:
> On Aug 13, 3:01 pm, Alessio Stalla <·············@gmail.com> wrote:
>
> > I have no experience inXPCOM, either, but I too think it would be a
> > great project. Unfortunately I have very little spare time, but
> > nevertheless if I can be of any help, I'd be willing to partecipate to
> > such a project. I briefly worked with COM in C++ some time ago and it
> > was a real pain (to be fair, in part that's because I was completely
> > new to that technology and in very little time I had to hack something
> > functional).
>
> I have never coded C++, but know C -- not filled my 10th year in C
> thou. And I think I can imitate C++ sources of existing F/OSS
> projects. Should I interpret your comment as that a solid C++
> background is a must for such a project? If you have experience both
> in C++ and COM, would you mind checking sources of existingXPCOM
> bindings (e.g. PyXPCOM, RbXPCOM, JavaXPCOM, etc.) and giving a rough
> explanation about the complicity level of C++ related parts?
No, my comment did not mean that - only that COM (from a newbie
standpoint) is complex, and C++ didn't help much :). That is, I know C+
+ only superficially, but I think the main difficulty lies in
understanding XPCOM itself rather than C++. I have looked very briefly
at the JavaXPCOM and PyXPCOM sources, not enough to understand them,
but enough to form the opinion that what they do is not very
complicated, nor they use exotic C++ features; instead it seems to be
mostly bookkeeping, converting, and what you'd normally expect from a
bridge between different languages... The PyXPCOM sources seem to be a
bit more complex than the Java counterpart, but I know Java way better
than Python (plus, I have a feeling that the Python XPCOM bridge is
older, and thus more stable and feature-complete than the Java one).
But, I definitely think that the starting point should be the XPCOM
documentation (duh), and maybe a toy XPCOM example in C++, and only
then the sources of existing bridges, which are more complex.
Cheers
Alessio
PS: I'm still a newbie in both C++ and COM, especially the latter. The
work I did with them was for a tiny project, where the COM part was
very repetitive once you understood it - and I did understand it only
partially, just enough to get the job done ;)
> > You're speaking of Kamen Lisp, I guess. I recall it had some way of
> > accessing the HTML DOM... never got it to run though. I agree that's a
> > different project, albeit interesting as well. It's more like the Java
> > plugin for Lisp.
>
> Yep, it is Kamen Lisp.
>
> Regards.