We're just (re-)starting to design an open source Go-Server
(http://senseis.xmp.net/?UGS, pages out of date - e.g. they still talk
about using an ugly language starting with J..).
To my surprise, it looks like the others could agree on CL as language
for it.
Now we are looking for an/a few implementation(s) and a set of libraries
to start with - for my work, I use Allegro, but we would need a free
Lisp, where I don't have any experiences.
Other constraints are:
-web communication over sockets
-a graphical client will be needed (shouldn't look too ugly)
-clients should work for Win, Mac and Linux (not necessarily the same
one, but we want to reuse as much code as possible)
For the GUI, my ideas would be around GTK, native stuff like
Windows-Form (better look, but three times work) or even some
Java-Swing-Complilation.
For using almost the same web-stuff-code in Lisps under three OSs, I
don't have a single clue..
Regards,
Ben
Benjamin Teuber wrote:
> We're just (re-)starting to design an open source Go-Server
> (http://senseis.xmp.net/?UGS, pages out of date - e.g. they still talk
> about using an ugly language starting with J..).
> To my surprise, it looks like the others could agree on CL as language
> for it.
>
> Now we are looking for an/a few implementation(s) and a set of libraries
> to start with - for my work, I use Allegro, but we would need a free
> Lisp, where I don't have any experiences.
>
> Other constraints are:
> -web communication over sockets
> -a graphical client will be needed (shouldn't look too ugly)
> -clients should work for Win, Mac and Linux (not necessarily the same
> one, but we want to reuse as much code as possible)
>
>
> For the GUI, my ideas would be around GTK, native stuff like
> Windows-Form (better look, but three times work) or even some
> Java-Swing-Complilation.
http://www.newlisp.org
William James <·········@yahoo.com> wrote:
> Benjamin Teuber wrote:
>> To my surprise, it looks like the others could agree on CL as language
>> for it.
>
> http://www.newlisp.org
That's not a Common Lisp.
And I hope this is no astroturfing thread. :-/
You can find some useful discussions on
http://lambda-the-ultimate.org/node/257 and
http://groups.google.com/group/comp.lang.lisp/msg/1f70fe70a7b35aca?dmode=source&hl=en
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
Stefan Scholl wrote:
> William James <·········@yahoo.com> wrote:
> > Benjamin Teuber wrote:
> >> To my surprise, it looks like the others could agree on CL as language
> >> for it.
> >
> > http://www.newlisp.org
>
>
> That's not a Common Lisp.
>
> And I hope this is no astroturfing thread. :-/
Naw, I've seen Benjamin over at SL working on his server for a long
time. he is for real. Probably just an honest naming mistake. He is
looking for a Lisp that is supported on multiple platforms and newlisp
turned up.
'NewLisp' blech. I'm all for creating a lisp for scripting but what is
with all the weird changes like no static variable scoping? This and
other things seem like gratuitious changes to me.
Now if they started from common lisp (or even scheme) and then omitted
some stuff (e.g. to reduce the size of their lisp) then I would be
interested. Give me a CL that is supported across many platforms and
does scripting stuff well and has an expect like module!
Stefan Scholl wrote:
> William James <·········@yahoo.com> wrote:
> > Benjamin Teuber wrote:
> >> To my surprise, it looks like the others could agree on CL as language
> >> for it.
> >
> > http://www.newlisp.org
>
>
> That's not a Common Lisp.
It's not a Commune Lisp, so you are absolutely forbidden to use it.
>
> And I hope this is no astroturfing thread. :-/
>
>
> You can find some useful discussions on
> http://lambda-the-ultimate.org/node/257 and
> http://groups.google.com/group/comp.lang.lisp/msg/1f70fe70a7b35aca?dmode=source&hl=en
Yes, don't decide for yourself; hear and heed the imprecations of the
commissars. Always remember, if you anger them, they will erase your
hard-drive:
http://groups.google.com/group/comp.lang.lisp/msg/4c95766a8bdda347
"Think as I think," said a man,
"Or you are abominably wicked;
You are a toad."
And after I had thought of it,
I said: "I will, then, be a toad."
William James <·········@yahoo.com> wrote:
> Stefan Scholl wrote:
>> William James <·········@yahoo.com> wrote:
>> > Benjamin Teuber wrote:
>> >> To my surprise, it looks like the others could agree on CL as language
>> >> for it.
>> >
>> > http://www.newlisp.org
>>
>> That's not a Common Lisp.
>
> It's not a Commune Lisp, so you are absolutely forbidden to use it.
CL means Common Lisp in comp.lang.lisp. He asked for a Common
Lisp. So don't get funny with me.
Stefan Scholl wrote:
...
> CL means Common Lisp in comp.lang.lisp. He asked for a Common
> Lisp. So don't get funny with me.
Actually, he didn't ask for a Common Lisp, he just said they might go
with CL and that while he uses Allegro, they "would need a free Lisp".
I think newLisp is both free and a Lisp dialect...
Remember, comp.lang.lisp means any and all Lisp dialects and commenting
that newLisp is not CL is a waste of time. And the use of the term
astroturfing...so what? He just gave a link to newlisp. If he were to
step on a soapbox and start ranting about why CL sucks and why newlisp
is much better and cooler (which I don't believe it is), then you could
call it astroturfing. But pasting a link hardly counts.
Rudolf
> For the GUI, my ideas would be around GTK, native stuff like
> Windows-Form (better look, but three times work) or even some
> Java-Swing-Complilation.
Maybe some people will run a tar-and-feathers attack on me, but for the
client, I'd use some J.. Sw.. stuff, simply because GUI-application
deployment on all three platforms using only free CL implementations
seems to be rather painful.
regards,
Stefan
PS: I'd be too happy if someone could prove me wrong by pointing me to
an easy to install GUI library that works - out of the box - and is easy
to install for users.
Don't worry about the tar-and-feathers! And you might want to check out
C#...unless it *has* to be done in LISP, then I suggest you start
checking out the bindings that are listed here:
http://www.cliki.net/Gtk
There are 4 of them, have fun!
Rudolf
Stefan Mandl wrote:
> > For the GUI, my ideas would be around GTK, native stuff like
> > Windows-Form (better look, but three times work) or even some
> > Java-Swing-Complilation.
>
> Maybe some people will run a tar-and-feathers attack on me, but for the
> client, I'd use some J.. Sw.. stuff, simply because GUI-application
> deployment on all three platforms using only free CL implementations
> seems to be rather painful.
>
> regards,
> Stefan
>
> PS: I'd be too happy if someone could prove me wrong by pointing me to
> an easy to install GUI library that works - out of the box - and is easy
> to install for users.
Stefan Mandl wrote:
> > For the GUI, my ideas would be around GTK, native stuff like
> > Windows-Form (better look, but three times work) or even some
> > Java-Swing-Complilation.
>
> Maybe some people will run a tar-and-feathers attack on me, but for the
> client, I'd use some J.. Sw.. stuff, simply because GUI-application
> deployment on all three platforms using only free CL implementations
> seems to be rather painful.
AMEN to that brother! If you want platform independence that java is
the way to go for the client. Forget C# as that will give Mac and
Linux users heartburn.
CGoban has already proven that Java can deliver a beautiful UI across
multiple platforms and it has excellent infrastructure for automatic
upgrades.
CL on the server side makes more sense as you control what OS the
server is running et cetera. For the server you will want a CL that is
fast and supports threads. Does SBCL or CMUCL provide threads support?
Perhaps I'm mistaken and you don't mind limiting your users to the one
OS/CL platform you choose to develop on. If that is the case by all
means do your client in CL.
funkyj <······@gmail.com> wrote:
> CL on the server side makes more sense as you control what OS the
> server is running et cetera. For the server you will want a CL that is
> fast and supports threads. Does SBCL or CMUCL provide threads support?
SBCL. Not on all platforms. And it could be problematic if you
don't limit the number of threads, depending on your system
(RAM).
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
I'm using google now as my normal usenet access doesn't seem to work
right now..
> Maybe some people will run a tar-and-feathers attack on me, but for the
> client, I'd use some J.. Sw.. stuff, simply because GUI-application
> deployment on all three platforms using only free CL implementations
> seems to be rather painful.
Do you mean a pure Java Client, or some Java-in-Lisp or vice versa
stuff?
> some Java-in-Lisp or vice versa
Benjamin, that could be a nice option, as you wouldn't have to cross
language boundaries when implementing the communication protocol.
Maybe something like this: http://armedbear.org/abcl.html ?
regards, Stefan
Benjamin Teuber wrote:
> I'm using google now as my normal usenet access doesn't seem to work
> right now..
>
> > Maybe some people will run a tar-and-feathers attack on me, but for the
> > client, I'd use some J.. Sw.. stuff, simply because GUI-application
> > deployment on all three platforms using only free CL implementations
> > seems to be rather painful.
>
> Do you mean a pure Java Client, or some Java-in-Lisp or vice versa
> stuff?
I don't know what he means but I mean a pure Java client. If you want
a nice UI (it is a client, after all) and portability across as many
major platforms as possible then Java is the only rational choice.
Lisp is powerful! Lisp is great! I wish I could use lisp for more
things but darn it, until a bunch really smart AND PRODUCTIVE people
(and, no Pascal B, that ain't me) puts in a couple of man-decades into
making one of the Lisp implementations run everwhere (not so hard,
choose CLisp -- it already runs most everywhere), give it a high
quality native GUI library (this is the meat of the matter) and develop
application delivery and upgrade infrastructure (Java Web Start is a
god send) then you are handicapping yourself by chosing any other
language for a cross platform GUI. Many people already have java
installed on their PC/Mac/Linux box. This greatly simplifies the task
of getting the end user up and running.
Sure, you want to make a Go server that is even better than KGS and I
applaud the goal but don't make the mistake of thinking that to be
better than KGS you need to be different from KGS in every way. KGS's
choice to use Java for the client is the right one! If you have ever
deployed real commercial software then you would know how much pain
comes from supporting the customer environement. Java is not perfect
but it eases this pain better than any other cross platform system out
there.
The server is where you should use your esoteric language (be it Lisp,
Ocaml, haskell or peridot). There will only be a few servers and these
will be run by wizards. There will (if you are successful) be
thousands or millions or clients run by luddites who just want to play
go. Minimizing install and support issues for this second group is a
huge win.
Good luck. I look forward to hearing about the alpha release of your
project.
--fj
Stefan Mandl wrote:
> > For the GUI, my ideas would be around GTK, native stuff like
> > Windows-Form (better look, but three times work) or even some
> > Java-Swing-Complilation.
>
> Maybe some people will run a tar-and-feathers attack on me, but for the
> client, I'd use some J.. Sw.. stuff, simply because GUI-application
> deployment on all three platforms using only free CL implementations
> seems to be rather painful.
I'd agree with that portable GUI programs are a sticking point for
current free CLs.
If you want to stick with a Lisp you could try PLT Scheme.
Stefan Mandl <············@informatik.uni-erlangen.de> wrote:
>> For the GUI, my ideas would be around GTK, native stuff like
>> Windows-Form (better look, but three times work) or even some
>> Java-Swing-Complilation.
>
> Maybe some people will run a tar-and-feathers attack on me, but for the
> client, I'd use some J.. Sw.. stuff, simply because GUI-application
> deployment on all three platforms using only free CL implementations
> seems to be rather painful.
Well, if you like lists, then thinking about Haskell could be a
good idea. The common implementation Glasgow Haskell Compiler
(GHC) is available for the main three (Linux, MacOS X, Windows).
And there's wxHaskell <http://wxhaskell.sourceforge.net/> for
portable GUIs.
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
> Well, if you like lists, then thinking about Haskell could be a
> good idea. The common implementation Glasgow Haskell Compiler
> (GHC) is available for the main three (Linux, MacOS X, Windows).
> And there's wxHaskell <http://wxhaskell.sourceforge.net/> for
> portable GUIs.
*sigh* Why do the Haskell guys have that and we don't?
Actually, Haskell does seem to be another option, although I don't know
it well yet.
I just like language-oriented programming too much :)
"Benjamin Teuber" <······@web.de> writes:
>> Well, if you like lists, then thinking about Haskell could be a
>> good idea. The common implementation Glasgow Haskell Compiler
>> (GHC) is available for the main three (Linux, MacOS X, Windows).
>> And there's wxHaskell <http://wxhaskell.sourceforge.net/> for
>> portable GUIs.
>
> *sigh* Why do the Haskell guys have that and we don't?
Because you didn't work enough on this project?
http://www.wxcl-project.org/en/
--
__Pascal Bourguignon__ http://www.informatimago.com/
"By filing this bug report you have challenged the honor of my
family. Prepare to die!"
On 2006-06-28 09:39:50 -0400, Pascal Bourguignon <···@informatimago.com> said:
> "Benjamin Teuber" <······@web.de> writes:
>
>>> Well, if you like lists, then thinking about Haskell could be a
>>> good idea. The common implementation Glasgow Haskell Compiler
>>> (GHC) is available for the main three (Linux, MacOS X, Windows).
>>> And there's wxHaskell <http://wxhaskell.sourceforge.net/> for
>>> portable GUIs.
>>
>> *sigh* Why do the Haskell guys have that and we don't?
>
> Because you didn't work enough on this project?
>
> http://www.wxcl-project.org/en/
Which I stopped looking at after 5 minutes as it didn't work using the
included directions on a stock Redhat installation.
Novus
Stefan Scholl wrote:
> Peter Herth <·······@t-online.de> wrote:
>
>>If you want a portable and headache-free gui, look at Ltk!
>
>
> Still only for non-AOL users? :-)
>
I had one AOL user several years ago who reported problems.
If this is the amount of problems reported with Ltk, I can
live with it :).
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
Peter Herth <·······@t-online.de> writes:
> Stefan Scholl wrote:
> > Peter Herth <·······@t-online.de> wrote:
> >
> >>If you want a portable and headache-free gui, look at Ltk!
> > Still only for non-AOL users? :-)
> >
> I had one AOL user several years ago who reported problems.
> If this is the amount of problems reported with Ltk, I can
> live with it :).
I think the latest hypothesis is that you need to (brace yourself)
reboot windows after installing Tcl/Tk. Anyhow, it's been a looong
time since I've heard of any Ltk-on-Windows problems that weren't
solved by rebooting.
Thomas F. Burdick wrote:
> Peter Herth <·······@t-online.de> writes:
> > I had one AOL user several years ago who reported problems.
> > If this is the amount of problems reported with Ltk, I can
> > live with it :).
>
> I think the latest hypothesis is that you need to (brace yourself)
> reboot windows after installing Tcl/Tk. Anyhow, it's been a looong
> time since I've heard of any Ltk-on-Windows problems that weren't
> solved by rebooting.
I heard that hypothesis a couple years back when we tested it, but it
unfortunately wasn't true. Yes, Ltk might need a reboot, but that's a
separate issue. (Fortunately, downloading Babylon/TheWonderfulIcon/AOL
into a VMWare instance hopefully gives you all you need to find out for
sure...)
I hope the problem was solved, but a possible explanation is that no
one thought there was a point to re-reporting a well known issue. ;)
Tayssir