From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.user Subject: Re: [ANN] gzochi project development release 0.5 Date: Fri, 17 Jan 2014 10:43:13 +0100 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1389951803 25664 80.91.229.3 (17 Jan 2014 09:43:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jan 2014 09:43:23 +0000 (UTC) Cc: Guile Users To: "Thompson, David" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Jan 17 10:43:31 2014 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W45xX-0004dG-FF for guile-user@m.gmane.org; Fri, 17 Jan 2014 10:43:27 +0100 Original-Received: from localhost ([::1]:37092 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W45xX-0007p0-3c for guile-user@m.gmane.org; Fri, 17 Jan 2014 04:43:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W45xN-0007om-1b for guile-user@gnu.org; Fri, 17 Jan 2014 04:43:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W45xL-0003XB-47 for guile-user@gnu.org; Fri, 17 Jan 2014 04:43:16 -0500 Original-Received: from mail-wg0-x22b.google.com ([2a00:1450:400c:c00::22b]:36847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W45xK-0003WP-Pf for guile-user@gnu.org; Fri, 17 Jan 2014 04:43:15 -0500 Original-Received: by mail-wg0-f43.google.com with SMTP id y10so4305262wgg.10 for ; Fri, 17 Jan 2014 01:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YXaAaXOBSnEgptAHxmq61Y9vli41P4JV3y7JKnlVkJQ=; b=w27kDiBwh+R+Ny1oE8nUI2Wckqb8qQQN+0c1iXDI/NQLL8ViJld1Pgv6ZuSd3yRz6O aqVBxOI27ATkI1Xto1sDUfMRXqyPTMlqbHXX5x09R7hFy4U6BV7SOniX5otr7uGOHAZX XyEU7yhiuC/CXovwAKSeLDZgcCwOPQJkTMOsSNSefvXlnxACjc/n8qUqAldJ0xkxLIp3 0dcHRKDOmb3QLFsIZ9uUEFwujOjA/eqzUokLI3YKhtNqQyAkZnYGt6Jq1hBMcrC6s6Mc 7xYCIeFz2I4SF71iElNGeSYHj1ckK5/eWrQi6/BKL4Tv9uwGMloRGvRwcLWysIMWuDJd svTw== X-Received: by 10.194.92.109 with SMTP id cl13mr908648wjb.13.1389951793479; Fri, 17 Jan 2014 01:43:13 -0800 (PST) Original-Received: by 10.194.178.134 with HTTP; Fri, 17 Jan 2014 01:43:13 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::22b X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:11033 Archived-At: Hi! <2014/1/15 Thompson, David > > 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).