robocoderepository.com
Pavel Šavara
it is down again!
But Dan Lynn is not responding to me. I do not wish to offend him. He
served well, long time.
Could we do something with it in the mid or long term?
- - - -
I would like to have the backup of database of bots, so I could built
more reliable service.
My idea is that I will create service with compatible API, even maybe
with synchronization to robocoderepository.com.
Something like mirror, but more reliable. So it will be up to user to
choose which service he will use.
I will use Google App Engine to implement that.
This will save me from issues with hosting, traffic, database, etc.
http://googleappengine.blogspot.com/2008/05/announcing-open-signups-expected.html
Already have account and went thru tutorial ;-)
Ok, I know, too many balls in the air to juggle for me.
I just wanted you to know my plan for year 2021 ;-)
- - - -
Seriously, I see it as major issue for our users. What priority you
will give it?
Do you have some better idea how to solve it ?
What key features should new design have ?
Pavel
Alex Schultz
"Pavel Šavara" <pavel....@gmail.com> wrote:
> I would like to have the backup of database of bots, so I could built
> more reliable service.
<snip>
> - - - -
> Seriously, I see it as major issue for our users. What priority you
> will give it?
> Do you have some better idea how to solve it ?
> What key features should new design have ?
Well, one note, is that David Alves (wiki member and author of the
high ranking bot Phoenix) once started working what was meant to be a
combined bot repository and roborumble server, but from what I can see
that project is currently stale.
(See http://robowiki.net/cgi-bin/robowiki?Roborumble.org and
http://roborumble.org for more information about that project)
Ideally, I'd personally like to see something similar (or work on it
resumed), that combines the bot repository, roborumble server, and then
perhaps eventually even becomes a RoboResearch server. If you haven't
seen it already, RoboResearch is a a tool made by Simonton (wiki member
and bot author) made for testing a robot against a series of
reference robots in an automated way. It has been discussed that a
future generation of RoboResearch be possible to run distributed over
the internet similar to the roborumble.
(See http://robowiki.net/cgi-bin/robowiki?RoboResearch and
http://sourceforge.net/projects/roboresearch for more
information about RoboResearch)
Perhaps this is a bit lofty, but personally I think it would be really
nice if we had repository, rumble, and research (3 Rs!) manageable from
a single server. I might be able to try investing some time myself
helping with this if we get a clear plan.
Alex Schultz
David Alves
As Alex mentioned, I started the roborumble.org project a while ago
with the idea of providing people with a reliable place to upload
their bots as well as a RRAH server that could host stable rankings
with a nicer interface than the current ones. To that end, I began
work on roborumble.org, but as usual, life got in the way (I was
taking a full load of classes and working 20 hours a week). I just got
out of school for the summer, however, and my only summer commitment
is a part-time job, so I'd definitely like to complete this project.
I'd also welcome anyone that wants to contribute; roborumble.org is
intended to an open project. It's written in Ruby on Rails, and uses
MySQL for the database. As for hosting, it's on a virtual private
server with 20 GB of disk space and 512MB of dedicated RAM. I think it
has more than enough capacity for our needs.
If anyone would like to work on roborumble.org with me, I'd be happy
to set up SVN and create accounts for you. I hope you'll consider
working on roborumble.org with me instead of starting your own project
from scratch, but I understand if you'd prefer to do it on your own.
Regards,
David Alves
On Jun 1, 11:46 am, Alex Schultz <agsch...@ucalgary.ca> wrote:
> On Sun, 1 Jun 2008 20:09:21 +0200
>
> > I would like to have the backup of database of bots, so I could built
> > more reliable service.
>
> <snip>
>
> > - - - -
> > Seriously, I see it as major issue for our users. What priority you
> > will give it?
> > Do you have some better idea how to solve it ?
> > What key features should new design have ?
>
> Well, one note, is that David Alves (wiki member and author of the
> high ranking bot Phoenix) once started working what was meant to be a
> combined bot repository and roborumble server, but from what I can see
> that project is currently stale.
> Ideally, I'd personally like to see something similar (or work on it
> resumed), that combines the bot repository, roborumble server, and then
> perhaps eventually even becomes a RoboResearch server. If you haven't
> seen it already, RoboResearch is a a tool made by Simonton (wiki member
> and bot author) made for testing a robot against a series of
> reference robots in an automated way. It has been discussed that a
> future generation of RoboResearch be possible to run distributed over
> the internet similar to the roborumble.
>
> Perhaps this is a bit lofty, but personally I think it would be really
> nice if we had repository, rumble, and research (3 Rs!) manageable from
> a single server. I might be able to try investing some time myself
> helping with this if we get a clear plan.
>
> Alex Schultz
>
> 1KDownload
Pavel Šavara
I opened the discussion not because I would like to create my own
solution, but because I'm unhappy with currerent robot repository. So
I welcome your effort.
Could you please share with us your current plan, status of the work
and time estimates?
Few my ideas to share. (You may assume that I don't know anything
about subject ;-)
I would like to assure that future repository of robocode robots will
be really open and reliable. So I propose:
- could you create some project at sourceforge to host sources of the
web server? I will join you there to watch, consult and maybe help ;-)
Alex also signaled that he may help.
- the site should allow for download of whole database, so that people
could have backup and/or all robots at once
- the site should allow replication or mirroring. We should discuss
it, to have good plan.
- could we have some REST or SOAP API for the database on roborumble.org ?
We may want to redirect RR@Home traffic to new site.
Could someone invite PEZ or Pulzar or whoever is owner of RR server to
this discussion ?
What are the features that the server should have for contoling RR@Home ?
Could we reuse current solution ?
Is your plan to also takeover the control of battles of RR@Home ?
Database: does anyone have backup of database of robots to upload it
to roborumble.org ?
Does anyone know Dan Lynn well enough to convince him to cooperate ?
Reliability questions:
- do you pay for traffic on the server or for the hosting ?
- how big trafic we may expect ?
- why robocoderepository.com is so unreliable ? Is there some risk ?
- are you willing to share access rights to the server (with someone
else you trust) to be able to do recovery when you are too busy or on
vacations ?
Thanks Pavel
Pavel Šavara
Great news. Read below.
> Competition is a good thing.
>
> I'm gonna refresh the robocoderepository site anyways. It's a fun side
> project for me.
>
> I am quite busy with paid projects. However, I have been dedicating about
> an average of 8 hours a week on getting the new site up. If you've been in
> touch with Flemming, I'm sure he has probably said something about us being
> in contact regarding details and issues several times a week. I assure you
> that I am making progress and have not given up or paused the effort at all.
> I urge you to talk with Flemming and get a feel for how he perceives my
> progress on the new site is coming. I have shared most of the design and
> features with him. It may appear that nothing has been worked on - but this
> is the wrong impression.
>
> However, my focus has been lately on doing a full blown site at launch
> rather than the stripped-down bare essentials site that I was going to hurry
> out the door. Perhaps, I should switch focus back. I think that might be a
> very good idea.
>
> I just finished up some code this weekend that will allow for rewriting the
> bot and team JARs on the fly to insert UUIDs on old-format JARs. It will
> also insert some fields to enable auto-tracking of bot inheritance and to
> facilitate automated uploading of updated bots. Also, initial uploads of
> bots will automagically fill out many of the bot detail fields
> automatically. This same JAR interaction code is being used to re-instate
> all the bot detail records that were lost a while back. Unfortunately the
> data center outage this weekend prevented me from testing and then executing
> the re-instatement.
>
> The new site is very webservice focused. It will be easy for you to
> interact with the repository in any way you like - including fully
> synchronizing your own repository. The webservices might not be fully
> functional on launch since I'm deciding to switch back to doing a bare-bones
> initial launch. This initial launch will actually have more functionality
> than the current site.
>
> After I get the site launched. I will open up the repository source
> (probably at github: http://github.com/). I will welcome help on the site.
> It is a ruby on rails site. I will at least initially act as the final
> reviewer of site changes before pushing to production. As my trust in the
> abilities of others becomes validated, I will be happy to allow others to
> share in this responsibility.
>
> I'm also being intensely pressured to get this site switched over by my
> hosting service since the current site is causing some issues on the server
> due to the old code's interactions with updated services that it was not
> originally designed for.
>
> Please feel free to work on a competitive site. But, keep in mind that I am
> actually making good progress on the new site.
>
>
> See ya,
> Danno!
Danno
>
> But Dan Lynn is not responding to me. I do not wish to offend him. He
> served well, long time.
> Could we do something with it in the mid or long term?
fire
at the hosting facility. They were unable to use their backup
generators due to the damage.
This post on the hosting service's support forum is particularly
informative:
http://forums.theplanet.com/index.php?showtopic=90185&st=20&p=593010&#entry593010
The site was back up this morning. However, I have noticed it
bouncing up and down.
Sorry that I didn't respond to Pavel's email earlier. That email
account was routed thru that data center and I didn't receive the
email until this morning.
David Alves
robot-hosting portion is mostly done, but the RRAH server part is
mostly incomplete. I'd be happy to make a project for it on
sourceforge. I think an API to access robots is a great idea. My
thought on the RRAH traffic is that I'd like to get the server feature-
complete before transferring any traffic to it. Initially I was going
to use the same RRAH protocol, with perhaps a different version in the
future. (A protocol that reports what robocode version was used for
the battle would be great). I don't have a backup of all robots to
upload, but I have most of them. I will pay for the traffic and the
hosting. Voidious also contributed to pay for the current hosting. I'd
expect a relatively small amount of traffic but a large amount of data
that needs to be stored. I think the VPS has more than enough capacity
for the project though. My current plan allows 20GB of storage and
500GB of traffic per month. If we start to run out, of storage space I
will set up a system to archive older bots using Amazon S3. Voidious
already has root access to the server in case I am unavailable for
whatever reason.
Regards,
David Alves
Danno
I'm actually pursuing two versions at the moment. I'm working on the
stripped down version that simply replicates the current repository -
but with all features working. Simultaneously, I'm working on the
full-featured site. The big difference is that the full featured site
has all sorts of web 2.0 social networking (community) features.
I haven't really found a good way to provide the full-featured site in
an acceptable timeline. There is simply too much to do to make it
production ready. So, I'm thinking that it will be months off before
this sees the light of day.
The stripped down site, however, consists of just the core webservice
and website functionality. This has always been well segmented from
the full site. The few points of variance will be mostly in the
account management. I'll have to copy some of the old schema over and
modify the migration scripts so that the old user tables are
retained. I'll also setup a beta server with a copy of the database
so that you guys can play around with the new stripped-down site and
make sure that everything is working alright.
Next weekend, I hope to be able to restore the lost bot files into the
existing site using some of the code from the new site which
constructs bot records from data contained in the bot and team JARs.
I'll look back through my old emails with Flemming and see if I can
find some good ones discussing design issues to share with this
forum. I think the details regarding the webservice support will be
particularly interesting.
Danno
that I think should be ran past you guys too. Please comment if any
of the validations or assumptions are wrong or need refinement.
Validation occurs upon uploading to the repository. If validation
fails then the user is informed that their bot can not be uploaded
because it has failed validation and the various failures are listed.
This should help insure that the bots in the repository are valid bots
which can be downloaded and ran within robocode. Also, this should
filter out any spam or other misuses of the repository.
Validations:
1. File must be a valid ZIP archive (includes JAR and ZIP). This
means that my zip utility recognizes it as a valid zip.
2. Insure that uploaded files have valid filenames for download
links. If not then convert them into valid filenames (no spaces,
ASCII).
3. Fail if no file is found in the jar's index that ends with ".team"
or ".properties". Note that nested archives are not scanned - only
the topmost jar. Also note that hidden resource files with those
extensions found under the hidden "__MACOSX" dir (if re-zip'd on OSX)
in the archive index are ignored.
4. Verify that *.team or *.poperties at least have the minimal
required entries. Bot = {robot.description, robocode.version,
robot.java.source.included, robot.version, robot.author.name,
robot.classname}, Team = {team.members, team.author.name,
robocode.version, team.description, team.version}. Note that uuid
property will be inserted into the JARs if missing.
5. For bot JARs, verify that robot.classname refers to an actual class
included in the JAR.
6. For team JARs, verify that the bots specified by the
Note that the system treats JARs and ZIPs interchangeably.
Perhaps we will need to modify this validation process to support the
newer groovy, .net, ruby, etc. based bots. Do we have good validation
rules for each of these new bot formats?
Pavel Šavara
> Perhaps we will need to modify this validation process to support the
> newer groovy, .net, ruby, etc. based bots. Do we have good validation
> rules for each of these new bot formats?
It would be nice to agree some names of supported robot types as
pointed out by Maciej.
I would prefer to use standard java naming conventions including namespace like
net.sf.robocode.java.1.5 (this is about JRE required)
net.sf.robocode.scala.2.7.1
net.sf.robocode.groovy.1.5
net.sf.robocode.dotnet.2.0
net.sf.robocode.robocodesg.1.0
net.sf.robocode.fancy.robot.math.library.0.1
It should be list not single item as robot might need more of them.
It should also state which version of robocode is required.
- - - - -
.NET robots will be in form of .DLL. It could be bundled into zip.
It could also contain .properties file. (But properties may be also
compiled into DLL in form of assembly attributes.)
For other languages compiled to Java bytecode, I assume no difference.
I foresee pure dynamic robots in form of only single file source code
(for example groovy.) We will provide groovy friendly base classes and
robocode plugin which will handle execution of such robot. There will
be no user java code. (Actually we could do it for Java as well, that
robot will be compiled from single file in engine by jikes). It could
be packed usual way in zip with properties.
- - - -
Overall we are not far enough to tell you more now. As I see it we
need to do language extensions as modules. To have modules we need lot
of work which we are already working on.
It would be great if your new open-sourced site/engine could also
provide extension point, so that in the future your engine could be
extended by another language easily.
See you
Pavel
Maciej Hrynczyszyn
>> Perhaps we will need to modify this validation process to support the
>> newer groovy, .net, ruby, etc. based bots. Do we have good validation
>> rules for each of these new bot formats?
>
> It would be nice to agree some names of supported robot types as
> pointed out by Maciej.
> I would prefer to use standard java naming conventions including namespace like
>
> net.sf.robocode.java.1.5 (this is about JRE required)
[examples cut]
And if we decide on using OSGi this is already standardized as entries in
manifest file, like (modified from Scala Eclipse OSGi-based plugin):
Bundle-Name: Scala Plugin
Bundle-SymbolicName: ch.epfl.lamp.sdt.core;singleton:=true
Bundle-Version: 2.7.1.r14915-b20080506010100
Eclipse-LazyStart: true
Require-Bundle: org.eclipse.core.runtime; version=3.1.2
*Maybe* we could treat robots as OSGi bundles too, but I'd agree with
Pavel, it's definitely too early to decide.
> I foresee pure dynamic robots in form of only single file source code
> (for example groovy.) We will provide groovy friendly base classes and
> robocode plugin which will handle execution of such robot. There will
> be no user java code. (Actually we could do it for Java as well, that
> robot will be compiled from single file in engine by jikes). It could
> be packed usual way in zip with properties.
Exactly.
Maciej Hrynczyszyn,
Pavel Šavara
> it's definitely too early to decide.
overkill for robots.
Even OSGI in .NET is pain. .NET can't unload modules easily.
http://www-adele.imag.fr/Les.Publications/intConferences/CCNC2006Esc.pdf
So , 90% OSGI is blocker for .NET Robocode. I don't like that direction ;-)