Hey everyone,
Thanks to Kenny Tilton, I've become interested in RoboCup. I've
started a client in Common Lisp, with a friend who happens to play
soccer.
Anyway, I'm looking for a Lisp implementation to use. I've looked
through all the ones I know of and none of them fit all the
requirements. So, I was hoping you guys could help me out with some
suggestions.
The absolute minimum requirements are:
Free (or at the very least, free for non-commercial use), as I'm a
poor college student.
UDP/IP support is required for the RoboCup protocol.
Mac OS X support is needed as that's my development environment.
Windows support is needed as that's my friend's development
environment.
mk-defsystem support is a win, but not required.
So, I'm looking for (ideally) a single implementation that meets all
of those needs. Or, two implementations (one for OS X and one for
windows) that each meet the rest of the needs and will be compatible
in areas lacking from the standard (ie. UDP/IP and mk-defsystem).
Here's what I've come up with. Please correct what I have wrong.
clisp:
Supports both OS's, CLOCC (and therefore mk-defsystem), but not
UDP/IP. It's FFI is also non-functional on OS X so using that for the
UDP/IP is not an option. So, this seems like it's out of the running.
openmcl:
Supports OS X and UDP/IP, but not CLOCC or any other mk-defsystem
package that I've found. So, this is a valid option for the OS X
half, assuming I can find a compatible system on Windows.
cmucl:
No support for OS X or Windows. So, it's out.
sbcl:
Supports OS X in CVS, but not Windows. Supports CLOCC. Supports
UDP/IP via db-sockets.
So, both sbcl and openmcl seem to be options on OS X. However, I
can't find a satisfactory option for Windows. I could use clisp and
use it's FFI for UDP on Windows, I believe.
So, what have I missed? Is there an easier way? A different
implementation? What do you use Kenny?
Thanks everyone.
Justin Dubs
······@eos.ncsu.edu (Justin Dubs) writes:
> The absolute minimum requirements are:
>
> Free (or at the very least, free for non-commercial use), as I'm a
> poor college student.
> UDP/IP support is required for the RoboCup protocol.
> Mac OS X support is needed as that's my development environment.
> Windows support is needed as that's my friend's development
> environment.
> mk-defsystem support is a win, but not required.
> [...]
> So, what have I missed? Is there an easier way? A different
> implementation? What do you use Kenny?
You can use two different lisp implementations, one on MacOS and one
on Windows; a communications compatibility layer is usually the matter
of 20 or so lines of code (more if you have to write the ffi yourself,
of course).
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> ······@eos.ncsu.edu (Justin Dubs) writes:
>
>
>>The absolute minimum requirements are:
>>
>>Free (or at the very least, free for non-commercial use), as I'm a
>>poor college student.
>>UDP/IP support is required for the RoboCup protocol.
>>Mac OS X support is needed as that's my development environment.
>>Windows support is needed as that's my friend's development
>>environment.
>>mk-defsystem support is a win, but not required.
>
>
>>[...]
>
>
>>So, what have I missed? Is there an easier way? A different
>>implementation? What do you use Kenny?
>
>
> You can use two different lisp implementations, one on MacOS and one
> on Windows;
You are absolutely right, but you read too fast. :) Justin already
indicated he was open to that possibility. His big problem is which
platform to use on Windows.
There are three-four lines we had to conditionalize last night in
beginning the port from win32 (where I used ACL and their sockets
package) to Linux (CMUCL and db-sockets).
Justin, there's the bad news: I use ACL (and having seen the legendary
Emacs/ILisp/CMUCL/Hemlock stuff I thank my lucky stars). You might want
to look into using Corman, you might need the speed to keep up with play
in this real time game.
Also, watch this space for an announcement of an upload to my new
RoboCells project on sourceforge. Even if you do not want to use the
starter client I will be offering, you might pick up some pointers on
dealing with the soccer server. One example is turning on and managing
synch_mode during development so debugging activities don't put you out
of synch with play.
Planning on competing at ILC2003? When we get our teams working we
should have some friendly matches.
Game on!
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
> There are three-four lines we had to conditionalize last night in
> beginning the port from win32 (where I used ACL and their sockets
> package) to Linux (CMUCL and db-sockets).
Okay. AFAIK, ACL offers a free, although limited, version for
Windows. I'll get my friend to check that out for usage on his side.
I have no experience with db-sockets, but as they are supported in
SBCL, and I got SBCL up and running on my Mac last night, I'll start
looking into it more deeply.
>
> Justin, there's the bad news: I use ACL (and having seen the legendary
> Emacs/ILisp/CMUCL/Hemlock stuff I thank my lucky stars). You might want
> to look into using Corman, you might need the speed to keep up with play
> in this real time game.
Corman, of course, is Windows only. I will again recommend that my
friend check that out. I don't even own a Windows box on which to
test such software.
About your speed comment:
I realize that this is a real-time game. So, I'm wondering just how
much speed I'll be needing. I know ACL is supposed to be very fast.
I assume Corman is as well. So, they should both be more than
satisfactory on the Windows side if he's up to buying them.
Do you think that openmcl or sbcl would have the needed speed? CMUCL
is very fast, I believe, and SBCL is a fork off of that. I know they
removed some of the compiler optimization stuff for the sake of
portability, but SBCL may still be fast enough. It is a native-code
compiler. What do you think? If not, ACL makes an OS X version that
I can look into. That'd make things easy, actually... using ACL on
both sides. I'd just have to find some money. I just wrangled myself
an internship with IBM so I suppose that that's a possibility. :-)
>
> Also, watch this space for an announcement of an upload to my new
> RoboCells project on sourceforge. Even if you do not want to use the
> starter client I will be offering, you might pick up some pointers on
> dealing with the soccer server. One example is turning on and managing
> synch_mode during development so debugging activities don't put you out
> of synch with play.
Yeah, I've been looking forward to seeing RoboCells' release. I've
got the source for the trilearn_2002 client sitting here as well.
I've subscribed to the robocup mailing list and have seen your recent
conversation about synch_mode.
I just started my client less than a week ago, so I'm still in the
exploratory phase. I've got some basic stuff working, minus the
networking code. I've got basic primitives such as point, line and
region and math routines to deal with them. I've got defconstants for
every part of the field/pitch, such as the flags, side-lines, goals
and such. I've also just finished the trigonometry code to infer the
client's position from the positions of two visible objects. I was
about to start on some wrappers for the networking when I realized
that clisp didn't support UDP... :-(
>
> Planning on competing at ILC2003? When we get our teams working we
> should have some friendly matches.
If I can get a client up and running, and if I can get it to beat
trilearn_2002, then I'll enter at ILC2003. trilearn_2002 is the team
you have to beat to qualify for ILC, in case you didn't know.
I'd love to take part in some matches once I get something up and
running.
>
> Game on!
Indeed. Thanks for all the help. The best of luck to you, except for
during any matches we might play together, in which case I wish the
best of luck to me!
Justin Dubs
······@eos.ncsu.edu (Justin Dubs) writes:
> Do you think that openmcl or sbcl would have the needed speed? CMUCL
> is very fast, I believe, and SBCL is a fork off of that. I know they
> removed some of the compiler optimization stuff for the sake of
> portability, but SBCL may still be fast enough. It is a native-code
Maintainability, really, not portability. Note that for the most part
this only affects compilation speed, and not speed of the compiled
code, which is ballpark-comparable with CMUCL. Some bits faster, some
bits slower, perpetual mostly-friendly arms race with the CMUCL
developers, you get the idea.
Yes, it's native code (in fact, in said pursuit of maintainability we
removed the interpreter and byte compiler, so now it has to compile
/everything/ to native code. That's probably one of the reasons
compilation is slower)
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Justin Dubs wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
>
>>There are three-four lines we had to conditionalize last night in
>>beginning the port from win32 (where I used ACL and their sockets
>>package) to Linux (CMUCL and db-sockets).
>
>
> Okay. AFAIK, ACL offers a free, although limited, version for
> Windows. I'll get my friend to check that out for usage on his side.
> I have no experience with db-sockets, but as they are supported in
> SBCL, and I got SBCL up and running on my Mac last night, I'll start
> looking into it more deeply.
we use db-sockets, it turns out (now that I am looking at the work the
team has done on the linux side).
> I realize that this is a real-time game. So, I'm wondering just how
> much speed I'll be needing.
The soccer server recomputes reality every 100ms. It sends you news
about your body state just after recomputing reality. It sends you a
"see" message about things in sight every 150ms, so sometimes you get it
just afetr the body info, sometimes 50ms afetr the body info, and in
every third cycle you do not get a "see".
Teams like to go on the latest info possible, so they wait for the
latest see message in a cycle (if one is coming) before computing and
sending their actions.
> Do you think that openmcl or sbcl would have the needed speed? CMUCL
> is very fast, I believe, and SBCL is a fork off of that.
I hear MCL is a screamer.
> Yeah, I've been looking forward to seeing RoboCells' release.
Just working in the db-sockets to replace ACL sockets now, should be up
by tomorrow. But I think I will do a world model before sharing, because
I plan to turn the world upside down (inside out, actually) compared to
the soccer server view.
> I've also just finished the trigonometry code to infer the
> client's position from the positions of two visible objects.
Pretty tricky, right?
> If I can get a client up and running, and if I can get it to beat
> trilearn_2002, then I'll enter at ILC2003. trilearn_2002 is the team
> you have to beat to qualify for ILC, in case you didn't know.
No, on two points:
1) ILC2003 is looking for a few teams, ful stop.
2) Here http://www.uni-koblenz.de/%7Efruit/orga/rc03/ we see that to
qualify for the mainstream competition you must submit a log file of
play against TriLearn or a Top 8 finisher. You do not have to beat them,
they just want to assess your team by comparing it against a solid team.
> Indeed. Thanks for all the help. The best of luck to you, except for
> during any matches we might play together, in which case I wish the
> best of luck to me!
Let the trash-talking begin! Welcome to the fray. Let me know if you
have any questions (tho I guess the RoboCup list is the place to most
them, and I'll see those there).
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
> The soccer server recomputes reality every 100ms. It sends you news
> about your body state just after recomputing reality. It sends you a
> "see" message about things in sight every 150ms, so sometimes you get it
> just afetr the body info, sometimes 50ms afetr the body info, and in
> every third cycle you do not get a "see".
>
> Teams like to go on the latest info possible, so they wait for the
> latest see message in a cycle (if one is coming) before computing and
> sending their actions.
Right. I've got ACL now, so I'm not going to worry about speed.
I don't like the waiting-for-the-sense-info thing.
So, on (step % 3 == 0) you get the sense info right at the beginning.
No problem there. Go ahead and wait for it.
On (step % 3 == 1) you'll get it 50ms late. I figure you should spend
the first 50 working out your best guess action based on a quick
prediction of the next events. Then, when the sense info hits you
check if you were right. If so, you have an extra 50ms to refine your
choice. If you were wrong, you have 50ms to start over.
On (step % 3 == 2) you don't get it at all, like you said. So I'm
looking at this step as the same as the previous one, just without the
sense info ever coming in. So we spend all 100ms off the prediction.
>
> > Do you think that openmcl or sbcl would have the needed speed? CMUCL
> > is very fast, I believe, and SBCL is a fork off of that.
>
> I hear MCL is a screamer.
Yeah. I've heard that as well.
>
> > Yeah, I've been looking forward to seeing RoboCells' release.
>
> Just working in the db-sockets to replace ACL sockets now, should be up
> by tomorrow. But I think I will do a world model before sharing, because
> I plan to turn the world upside down (inside out, actually) compared to
> the soccer server view.
Good deal. I'm curious as to what you mean by "inside out." I guess
I'll find out when you release the code.
>
> > I've also just finished the trigonometry code to infer the
> > client's position from the positions of two visible objects.
>
> Pretty tricky, right?
I've only got it written right now for two points (ie. flags or
goals). I'm going to sit down later today and do it with a flag and a
line or that kind of thing. Offhand, I think a flag and a line should
give it to me no problem. The line will narrow down my possible
positions to a line parallel to itself as I know my distance from it.
A single point/flag narrows me down to a circle around itself as I
know that distance as well. Circle and line intersect at two points,
but only at one of them am I facing the right way givin the angle of
the line. So, boom. No problem.
Two lines should be just as easy. Each narrows me to a line, they
intersect at one point. Done.
It was fun to sit down with a sheet of paper or two, draw some
triangles, and work out the point-point formula. I used to do (still
do on occasion), a lot of 3d graphics programming, so I'm pretty well
versed in trig and vector math. Dot products and all that. Fun
stuff.
>
> > If I can get a client up and running, and if I can get it to beat
> > trilearn_2002, then I'll enter at ILC2003. trilearn_2002 is the team
> > you have to beat to qualify for ILC, in case you didn't know.
>
> No, on two points:
>
> 1) ILC2003 is looking for a few teams, ful stop.
>
> 2) Here http://www.uni-koblenz.de/%7Efruit/orga/rc03/ we see that to
> qualify for the mainstream competition you must submit a log file of
> play against TriLearn or a Top 8 finisher. You do not have to beat them,
> they just want to assess your team by comparing it against a solid team.
Oh, great. Thanks. That takes some of the pressure off. :-)
>
> > Indeed. Thanks for all the help. The best of luck to you, except for
> > during any matches we might play together, in which case I wish the
> > best of luck to me!
>
> Let the trash-talking begin! Welcome to the fray. Let me know if you
> have any questions (tho I guess the RoboCup list is the place to most
> them, and I'll see those there).
Thanks. I'm sure I'll be full of questions once I get this thing
further along. Good luck with your client.
Justin Dubs
Justin Dubs wrote:
> Right. I've got ACL now, so I'm not going to worry about speed.
> I don't like the waiting-for-the-sense-info thing.
>
> So, on (step % 3 == 0) you get the sense info right at the beginning.
> No problem there. Go ahead and wait for it.
Watch your language. :) The "sense_body" info always comes at the start
of a cycle (one team figured out). The "see" message is the one that
comes just after, 50ms after or not at all after the sense_body message.
> Good deal. I'm curious as to what you mean by "inside out."
Their coordinate system is a mirror reflection of the usual Cartesian
system. You sound strong on math so that might roll right off you, but I
cannot cope with it.
They reasonably enough have the right side of the field positive and
left side negative, relative to the side you are playing. Likewise the
opponent's goal is plus, your goal is minus. But that means increasing
angles sweep clockwise instead of CCW, because up and down the field
runs across your screen so they made that the x-axis! going across the
field (sideline to sideline) is vertical on the screen, so they made
that the y-axis.
well, up and down the field sounds like Y to me, and across sounds X,
and doing that makes increasing angles go CCW again, so that's where I'm
headed.
> Offhand, I think a flag and a line should
> give it to me no problem.
That's what the doc for one team said, a flag and a line. Other doc for
other teams go crazy over the calculations. I am very puzzled. I used
two flags and eventually relearned enough trig to find myself OK.
Don't forget, it is a rare case to see only one flag, and you get see
info six times a second. If you are maintaing a world model which is
updated from see info, how often do you need to ascertain your exact
position? In many cases the relative info is all you need.
> Two lines should be just as easy. Each narrows me to a line, they
> intersect at one point. Done.
You sound better at this stuff than me. All I (the player) know is my
distance D to a line in the direction I am looking, and the equation of
the line. I do not know the direction in which I am looking because I do
not know my body direction, only the direction of my head relative to my
body. So amn't I somewhere on a (* 2 D)-wide 2-lane blacktop with the
side/end line as the centerline?
Or are you thinking speed direction is body direction? I know it is
flipped if you are backing up, but did not think to check if it
otherwise aligns with body direction. But other teams never seem to use
that in their calculations, so I suspect not.
>
> It was fun to sit down with a sheet of paper or two, draw some
> triangles, and work out the point-point formula.
I'm saving the two dozen pages of graph paper I went thru. :) Keep us
posted. I am damn close to having the code working under CMUCL. Already
have seen some play. Which means (back on topic)..........
...Cells do CMUCL!
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
······@eos.ncsu.edu (Justin Dubs) wrote in message news:<····························@posting.google.com>...
> Do you think that openmcl or sbcl would have the needed speed? CMUCL
> is very fast, I believe, and SBCL is a fork off of that. I know they
> removed some of the compiler optimization stuff for the sake of
> portability, but SBCL may still be fast enough. It is a native-code
> compiler. What do you think?
1. In my experience, OpenMCL and SBCL produce compiled code of roughly
comparable speed (i.e., fast) with one exception - SBCL produces
significantly faster (up to 3x faster) floating point code.
2. OpenMCL's compiler is *much* faster than SBCLs. That is, compiling
the same code in OpenMCL (just as in MCL) is very fast, but takes a
noticeable amount of time in SBCL (presumably due to all the advanced
type inferencing, etc.).
So, if you need compilation speed, go with OpenMCL. If you need
floating point speed in compiled code, go with SBCL.
OpenMCL is also a more mature offering, having been honed over several
years, while SBCL has only recently been ported to Mac OS X, and has
some rough edges.
Just my $.02 - I'm sure others will offer differing perspective.
Raf
······@eos.ncsu.edu (Justin Dubs) writes:
> Here's what I've come up with. Please correct what I have wrong.
Mostly pretty accurate as far as I know, but for
> openmcl:
> Supports OS X and UDP/IP, but not CLOCC or any other mk-defsystem
> package that I've found. So, this is a valid option for the OS X
> half, assuming I can find a compatible system on Windows.
mk-defsystem can be used on OpenMCL, but may need patching. The patch
below is taken from McCLIM's INSTALL.OPENMCL file - I don't know if
it;s been merged back into CLOCC or not. Note that you don't need the
rest of clocc if you just want mk-d, as it's basically standalone.
diff -d -u -r1.48 defsystem.lisp
--- defsystem.lisp 17 Jun 2002 20:47:06 -0000 1.48
+++ defsystem.lisp 6 Sep 2002 01:54:36 -0000
@@ -1362,12 +1362,13 @@
#+TI ("lisp" . #.(string (si::local-binary-file-type)))
#+:gclisp ("LSP" . "F2S")
#+pyramid ("clisp" . "o")
- #+:coral ("lisp" . "pfsl")
;; Harlequin LispWorks
#+:lispworks ("lisp" . ,COMPILER:*FASL-EXTENSION-STRING*)
; #+(and :sun4 :lispworks) ("lisp" . "wfasl")
; #+(and :mips :lispworks) ("lisp" . "mfasl")
- #+:mcl ("lisp" . "pfsl")
+ #+(and (or :coral :mcl) (not :darwinppc-target))
+ ("lisp" . "pfsl")
+ #+(and :openmcl :darwinppc-target) ("lisp" . "dfsl")
;; Otherwise,
("lisp" . ,(pathname-type (compile-file-pathname "foo.lisp")))))
> sbcl:
> Supports OS X in CVS, but not Windows. Supports CLOCC. Supports
> UDP/IP via db-sockets.
Minor note: SBCL is bundled with SB-BSD-SOCKETS, which is essentially
a renamed (so as not to tread on user namespace) db-sockets anyway.
So, getting UDP from SBCL is a simple matter of (require 'sb-bsd-sockets)
and away you go
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Thanks for the info Kenny and Daniel.
I've managed to get my hands on copies of ACL for OS X and Windows.
So, problem solved.
I'll post something when I get a working client, and I look forward to
seeing your Cells version, Kenny.
Thanks again for your input,
Justin Dubs