Re: [ANN] gzochi project development release 0.5

[Panicz Maciej Godek]

Hi!

<2014/1/15 Thompson, David <address@hidden>

> > For that reason, SLAYER is equipped with bindings to Open
> > Dynamics Engine, and also has a stub of a text editor widget
> > (which obiously allows to evaluate lisp expressions in a similar
> > way emacs+geiser does ;])
> >
> > Some time ago, I have also been experimenting with a design
> > of a general network architecture, but I eventually dropped it,
> > believing that there were some more urgent things to be done.
>
> You could perhaps use gzochi for this now.

I'd have to read a bit more about it, because although it sounds
really cool (and may turn out to suit my needs exactly), the
documentation is rather voluminous.
So if I manage to keep up with my ideas, I'll definitely dive into it :]

> > Anyway, the goal is ambitious, and I think that for that reason
> > we have a lot in common. There are also some ideas that I
> > see in guile-2d and that I truly love and would love to steal,
> > but that's impossible, because it's LGPL :)
>
> I guess there is a gap in my understanding of the compatibility
> between the GPL and LGPL. I chose the LGPL for 2 reasons: It is the
> same license as Guile and there are already a million game libraries
> out there that are either proprietary or more liberally licensed so I
> also opted for a more liberal license. I could surely grant exceptions
> to let you use my code for SLAYER, if necessary.

Well, I meant that it's impossible, because it's free software :)
I decided to equip SLAYER with GPL mainly because I wouldn't any
non-free modifications to appear, because however strange it may
sound, there seem to be many people who don't have a clue about the
idea of free software.

But anyway, I think that FSF favours GPL over LGPL, and that it is
possible to convert LGPL to GPL (which is more restrictive) and not
the other way around.

> > I also see that our approach differs in that I have been
> > using the GOOPS system extensively for the GUI design
> > (which has some advantages, despite its drawbacks, such
> > as decreased portability between other Scheme
> > implementations)
>
> Ah, I have chosen to not depend on GOOPS in favor of plain old record types.

I am curious what caused that decision. It seems reasonable, because
it allows to keep the source relatively portable. On the other hand,
GUI goes rather naturally with OOP, and although it's still an
experiment, and I'm lacking certain features that are present in some
more widespread OOP systems, it's certainly
comfortable to have that multi-method dispatch, as it allows to write
programs in a more flexible (and a little carefree) manner.

The nice thing about it is that it works a little bit like the natural
language, where the meaning of certain words depend on their context.

But I actually dislike a few aspects. First that I know of no good
method for creating hidden slots, i.e. such that their storage would
be accessible only via virtually allocated slots.

The second is that there is there is no way to specify a type for a
slot. I can only provide a comment, but it's not particularly
reliable.

It is also slightly annoying that I have to define a class before I
can refer to it, e.g. in a method definition. It causes the code to be
scattered around in the file.

> > One thing that might seem dubious is my decision to keep
> > slayer a stand-alone application (rather than guile module).
> > It is not a deep decision and could be changed rather easily,
> > but as for now it has proven good at some points (namely,
> > it gave me a better control over the program behaviour while
> > I was creating a Windows port), and a pain-in-the-ass at
> > anothers (it's difficult to create slayer applications using the
> > emacs+geiser methodology).
>
> Our differing choices is a good example of "embedding vs. extending".
> You've probably already read this article
> (https://twistedmatrix.com/users/glyph/rant/extendit.html) but it
> explains exactly why I prefer to extend.
>
> One of Guile-2d's main goals is to work really nicely with Emacs +
> Geiser. I am working on a patch for the Guile 2.0.10 release that will
> allow any Guile program that runs an event loop to integrate a REPL
> server that doesn't have the multi-threading issues present with the
> normal REPL server. So, if you are open to turning SLAYER into a
> shared library, I hope that a free REPL server will sweeten the deal.
> :)

Well, for now I plan to stick to the "embedding" strategy, although I
realize its shortcomings. The big idea is to make sure that every
module that uses SLAYER is able to use all features of multimedia
environment, which should also be simple to use (so SLAYER does not
provide all the modes that SDL or OpenGL do, and binds only a few
procedures from SDL_ttf, for instance).

In the future, if I ever decide to create SLAYER2 that would be based
on SDL2 library, I will certainly make it a loadable module for Guile
-- that's because the specifics of the SDL2 library are such, that you
can create multiple windows.

Since SDL1.2 is tied to one window, I think that it's reasonable to
assume that all the modules can access it in some way.

On the other hand, I think that the architecture of SLAYER makes it
relatively easy to cooperate with REPL (which has actually been proven
with the aforementioned text-area widget). Since SLAYER runs its own
event loop, it's rather straightforward to evaluate Scheme expressions
there, provided that they are available.

However, it is not unlikely that I'm missing something with those
multi-threading issuses. But the solution that I have been using so
far was that I only used supplementary threads only to handle the
network connections, and all the packages that were received from a
socket were being propagated to the main thread using the SDL User
Events.

> > Anyway, if any of you thinks that we could cooperate,
> > I'm really looking forward to it. I'd also like to hear about
> > your goals and ideas, if you're willing to share :)
>
> I would definitely like to cooperate. Perhaps there is a library or
> two that we could extract from our projects for everyone to use.

I think that it might be an excellent idea. There's also this
CPAN-inspired guile-lib project that contains a set of libraries, so
perhaps it would be a good idea to have a module that would be shipped
with Guile and that would allow to easily access some set of modules
from an external repository.

The difficult part is on deciding which things go beyond a
programmer's private language and are actually worth becoming public.
But I think that it's a matter of a good discussion :)

I took an approach such that I have one module that defines a set of
language extensions that I use commonly in my programs, which e.g.
re-exports some popular modules like srfi-1, srfi-2 or (ice-9 match),
and also adds a few of my own extensions. This often saves me a lot of
writing.

Besides I admit that whenever I find it reasonable, I create modules
that do not require SLAYER and go well with pure Guile. The Open
Dynamics Engine wrapper library is such case, that could easily be
taken to another project (however, it consists of a low level code
that requires C++11 compiler to get built)

> My main goal is to apply the Emacs philosophy to game development. I
> want guile-2d to be an easy way to create 2D games interactively using
> the REPL with the ideal environment being Emacs + Geiser. Ideally,
> guile-2d will remain pure Guile and use the CFFI to call out to other
> libraries.

I see. It is a nice philosophy :)
I didn't focus so much on Emacs integration, because I'd like SLAYER
to provide its own editor, that would be more accessible to a broader
class of users (the default keystrokes are always a source of
amusement for the newcomers, and setting up Geiser, although not
particularly difficult, is still non-trivial, unlike setting up the
environment to evaluate Emacs Lisp expressions). Plus I'd like to
integrate it with multimedia content better (Emacs is great for
editing text, but -- despite the existence of such projects as GNEVE
-- it isn't equally good for editing videos or sounds).