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: SLAYER announcement and help request for preparing a GNU package Date: Sun, 5 May 2013 23:37:25 +0200 Message-ID: References: <20130505051554.GA2558@intra> <87zjw9p8jy.fsf@zigzag.favinet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf307ca52ae5b7d004dbff6395 X-Trace: ger.gmane.org 1367789866 13482 80.91.229.3 (5 May 2013 21:37:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 May 2013 21:37:46 +0000 (UTC) Cc: "guile-user@gnu.org" To: Thien-Thi Nguyen Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun May 05 23:37:45 2013 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 1UZ6cq-0004b3-FE for guile-user@m.gmane.org; Sun, 05 May 2013 23:37:44 +0200 Original-Received: from localhost ([::1]:47898 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZ6cp-0006JF-Pf for guile-user@m.gmane.org; Sun, 05 May 2013 17:37:43 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44411) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZ6ce-0006JA-Gf for guile-user@gnu.org; Sun, 05 May 2013 17:37:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZ6cc-0004Wy-AC for guile-user@gnu.org; Sun, 05 May 2013 17:37:32 -0400 Original-Received: from mail-vb0-x22c.google.com ([2607:f8b0:400c:c02::22c]:53775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZ6cY-0004WY-KT; Sun, 05 May 2013 17:37:26 -0400 Original-Received: by mail-vb0-f44.google.com with SMTP id e13so2570616vbg.3 for ; Sun, 05 May 2013 14:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LEuB5kN4EWCBWtvSfIeH9J8K9PElgUg/mhlW3mey3lQ=; b=PNhkfWuJn7uxMLSyKcfuap1z8lOnMOQ1HaqQQgpK22t0V05IQABSZOQsmVrdNhuc7F uC8EDRXVLVFzM8dRDld644HCDnNmwp1+f14NqVME49AXqBaRafTm77bbTbMllQGSLrfc Xy7ucmigaOebXVqhq7uXlmt6PtPQUtlFtTmNM3qemk5aqJJlGGM9IW3rDnpu57w3hzn9 +5r3tlBwnWxVA5VuXWkJzk/JHcnpBiXFeJdHREH2yaqjgaMIDuSwYj5qlvZMX0penWhH VntcdEycq2GYbOVLfw2YtR0646/Nn1f5oK7d1sc9va+l44j/mhAR4iBlcIMjlhgV8i2l bhRA== X-Received: by 10.52.27.163 with SMTP id u3mr4991828vdg.60.1367789845983; Sun, 05 May 2013 14:37:25 -0700 (PDT) Original-Received: by 10.220.141.10 with HTTP; Sun, 5 May 2013 14:37:25 -0700 (PDT) In-Reply-To: <87zjw9p8jy.fsf@zigzag.favinet> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400c:c02::22c 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:10319 Archived-At: --20cf307ca52ae5b7d004dbff6395 Content-Type: text/plain; charset=ISO-8859-1 2013/5/5 Thien-Thi Nguyen > I think that the simplicity could convince some people to employ > slayer to their multimedia projects -- because it requires no > additional setup and works out of the box, so for instance it could > be quite easily employed to implement the picture language from SICP > > Probably the valuation of simplicity depends largely on point of view. > > As the author, for you it is simple and transparent. > > For the newcomer, it is opaque, and its simplicity is to be determined. > > I can't say that my judgements are unbiased, but I claim that the interface of slayer is objectively simpler than the one of SDL (and consequently -- Guile-SDL) -- obiously to the extent to which the comparison makes sense. Slayer is an event-driven abstraction layer over SDL (and OpenGL). Thus, the whole application that, for instance, plays a certain sound when a key is pressed, would look like that in slayer: (use-modules (slayer)) (define sound (load-sound "sound.wav")) (keydn 'esc quit) (keydn 'm (lambda()(play-sound! sound))) I dare to say that this is much simpler than in raw SDL, where one needs to write his own loop to handle the input, not to mention the fairly complicated initialization routines. Working with images would require employing the widget framework (I admit that the interface is a little unintuitive at the moment, but it can be improved easily) (use-modules (slayer) (slayer image) (widgets base) (widgets bitmap)) (keydn 'esc quit) (define image (load-image "image.png")) (add-child! *stage* (make-image image 70 20)) The above code creates an image that can be dragged around the screen. I agree that it's counterintuitive (because nothing in the code suggests that the image is draggable) and could be done better -- and that without this example it would be difficult to figure out how to do that. But still I dare to claim that it's simpler than if one had to do it in pure SDL (and he would probably end up reimplementing slayer) Things get more complicated when one wants to manually draw the stage, because then he needs to set-display-procedure! (the way it's done in the pong.scm demo). But as I reckon from my experience with SDL and OpenGL, it's still simpler than figuring out the setup for double buffered mode and making things in the right order (and remembering to glFinish()). Also, doing some more sophisticated timing requires creating a new thread, which -- fortunately -- is quite simple in guile. (I admit, however, that because of that reason, the included demos may be non-thread-safe) As Guile-SDL maintainer, i wonder what i can do to attract the same > audience, whether or not it is worth expending the energy to do so, in > what ways have i failed to encourage organic additive (as opposed to > parallel) hacking, and how wonderful/terrible it is for GNU to be so > loosely coupled. > My project transformed and evolved from a C++ OpenGL engine that I've been working on a couple of years ago, and then abandoned it. Years later, the input system that I implemented (array of approx. SDLK_LAST SCM thunks, supported by a few arrays of C function pointers and a loop) turned out to be still useful. Anyway, should you wish to rebase SLAYER onto Guile-SDL (which has > surmounted the documentation, autotools, and certain libguile churn > issues), i, too, am happy to help out. (Maybe we can work together.) > I'd really love to work together! However, there would be very little point in rebasing slayer onto Guile-SDL because of the project's goal, which is to supply a standalone executable that embeds (rather than extends) guile, and can therefore be thought of as a separate environment. I remember Ludovic reprimending me for embedding guile instead of extending it, but I believe that slayer is a humble exception from that otherwise notable rule. Perhaps the difference is psychological rather than technical, and perhaps one day someone decides to transform slayer into a loadable guile module, as it should be a truly trivial task, but for now I think that it will be easier for people to understand that they get "something similar to flash player" (it is for me :D) Besides, I really don't think that we would gain anything by taking the code that works and rewriting it to something else. If you are willing to help, I will appreciate it, and I believe that the experience that you got working on Guile-SDL would then be utilized properly (especially that you plainly put a lot of labour into that project, and your programming style seems more mature than mine). It would be a brand new experience for me to cooperate on an open source project with some other person. When it comes to the line of development, my main motivation for adding new features is the game that I'm trying to create, and -- as I wrote -- slayer is a byproduct, and it's meant to be useful for the set of its users (which is currently a singleton consisting of its author) rather than complete. However, I do have certain ideas of how the slayer environment could be enriched with some useful features (making a scheme editor widget, to begin with) I hope we can make our way somehow Best regards! --20cf307ca52ae5b7d004dbff6395 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2013/5/5 Thien-Thi Nguyen <ttn@gnu.org>
=A0 =A0I think that the simplicity could convince some pe= ople to employ
=A0 =A0slayer to their multimedia projects -- because it requires no
=A0 =A0additional setup and works out of the box, so for instance it could<= br> =A0 =A0be quite easily employed to implement the picture language from SICP=

Probably the valuation of simplicity depends largely on point of view= .

As the author, for you it is simple and transparent.

For the newcomer, it is opaque, and its simplicity is to be determined.


I can't say that my judgemen= ts are unbiased, but I claim that the interface of slayer is objectively si= mpler than the one of SDL (and consequently -- Guile-SDL) -- obiously to th= e extent to which the comparison makes sense. Slayer is an event-driven abs= traction layer over SDL (and OpenGL). Thus, the whole application that, for= instance, plays a certain sound when a key is pressed, would look like tha= t in slayer:

(use-modules (slayer))
(def= ine sound (load-sound "sound.wav"))
(keydn &#= 39;esc quit)
(keydn 'm (lambda()(play-sound! sound)))

I dare to say that this is much simpler tha= n in raw SDL, where one needs to write his own loop to handle the input, no= t to mention the fairly complicated initialization routines. Working with i= mages would require employing the widget framework (I admit that the interf= ace is a little unintuitive at the moment, but it can be improved easily)

(use-modules (slayer) (slayer image) (widge= ts base) (widgets bitmap))
(keydn 'esc quit)
(define image (load-image "image.png"))
(add-child! *stage* (make-image image 70 20))

The above code creates an image that can be dragged around the scre= en. I agree that it's counterintuitive (because nothing in the code sug= gests that the image is draggable) and could be done better -- and that wit= hout this example it would be difficult to figure out how to do that. But s= till I dare to claim that it's simpler than if one had to do it in pure= SDL (and he would probably end up reimplementing slayer)

Things get more complicated when one wants to man= ually draw the stage, because then he needs to set-display-procedure! (the = way it's done in the pong.scm demo). But as I reckon from my experience= with SDL and OpenGL, it's still simpler than figuring out the setup fo= r double buffered mode and making things in the right order (and rememberin= g to glFinish()).

Also, doing some more sophisticated timing = requires creating a new thread, which -- fortunately -- is quite simple in = guile. (I admit, however, that because of that reason, the included demos m= ay be non-thread-safe)

As Guile-SDL maintainer, i wonder what i can do to attract the same
audience, whether or not it is worth expending the energy to do so, in
what ways have i failed to encourage organic additive (as opposed to
parallel) hacking, and how wonderful/terrible it is for GNU to be so
loosely coupled.
=A0
My project transf= ormed and evolved from a C++ OpenGL engine that I've been working on a = couple of years ago, and then abandoned it. Years later, the input system t= hat I implemented (array of approx. SDLK_LAST SCM thunks, supported by a fe= w arrays of C function pointers and a loop) turned out to be still useful.<= /div>

Anyway, should you wish to rebase SLAYER onto Guile-SDL (which has
surmounted the documentation, autotools, and certain libguile churn
issues), i, too, am happy to help out. =A0(Maybe we can work together.)
=

I'd really love to work together= ! However, there would be very little point in rebasing slayer onto Guile-S= DL because of the project's goal, which is to supply a standalone execu= table that embeds (rather than extends) guile, and can therefore be thought= of as a separate environment.
I remember Ludovic reprimending me for embedding guile instead o= f extending it, but I believe that slayer is a humble exception from that o= therwise notable rule. Perhaps the difference is psychological rather than = technical, and perhaps one day someone decides to transform slayer into a l= oadable guile module, as it should be a truly trivial task, but for now I t= hink that it will be easier for people to understand that they get "so= mething similar to flash player" (it is for me :D)

Besides, I really don't think that we w= ould gain anything by taking the code that works and rewriting it to someth= ing else. If you are willing to help, I will appreciate it, and I believe t= hat the experience that you got working on Guile-SDL would then be utilized= properly (especially that you plainly put a lot of labour into that projec= t, and your programming style seems more mature than mine).
It would be a brand new experience for me to cooperate on an ope= n source project with some other person.

When it comes to the line of development, my main motivation for adding = new features is the game that I'm trying to create, and -- as I wrote -= - slayer is a byproduct, and it's meant to be useful for the set of its= users (which is currently a singleton consisting of its author) rather tha= n complete.
However, I do have certain ideas of how the slayer environment c= ould be enriched with some useful features (making a scheme editor widget, = to begin with)

I hope we can make our = way somehow
Best regards!

--20cf307ca52ae5b7d004dbff6395--