-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues related to a new challenge #19
Comments
Hi, it's great that you're looking to use this for a new game :D GitHub issues work best when there's one feature per issue, so I've split out your suggestion for running in a cloud VM into #20. I think there are a few security considerations which will make it tricky (I don't want people to be able to hack your VM just by posting an answer!), but it's a nice target! Could you provide more detail on what running a tournament forever would look like? How would scoring work after there are thousands of past games? Or are you thinking of fixed-round tournaments which automatically trigger one-after-another (e.g. 30-game tournament, then another 30-game tournament, etc.?) Finally, there shouldn't be any need to There certainly is a lot of locking-down here but it should be possible to get any feature working within those restrictions. Can you specify what feature they tried to implement which needed |
Infinite tournaments are merely for cloud convenience, so I don't have to tunnel in and restart them every few hours. And as for scoring, I'd prefer to have access to scores for each game so I can run my own statistical tests and joining with other tournaments and such on them. And as for the security, I contacted the author some more, and it turns out eval wasn't needed in the end, so I surmise the security dismantling wasn't needed. I wasn't able to get whether modifications to the framework are required, but okay... |
In that case I'd suggest setting each tournament to a single game (or a handful), and triggering those tournaments externally (e.g. set up a crontab schedule every 10 minutes or something). The high-level structure could be:
This has several advantages over an infinite tournament. For one, if a game crashes somehow, the next will continue without issues. For another, if there are any memory leaks or similar issues they won't build-up, because the whole process will be killed off and started anew for each batch. Also since the crontab will automatically avoid running while a previous run is ongoing, you can be sure it won't build up into a massive number of simultaneous games. For the other changes you mention, if you have specific features in mind please request them by raising issues. And forked repository owners are free to make Pull Requests if they have something they want to contribute back! |
The reason I had to delete the security stuff or whatever that was because I couldn't figure out how to pass a boolean down somewhere deep in the code. (I wanted an option to enable/disable all entries and was too frustrated to figure out why even a simple |
I'm currently looking at implementing my upcoming challege in this framework: https://codegolf.meta.stackexchange.com/a/16415/43363
First, I'd like to have a way of configuring tournaments to run forever, and an easier means of programmatically extracting scores from each game within a headless context (like, say, in a cloud VM).
Second, the author of one of the forks told me that part of the framework security mechanisms had to be dismantled for the contest (more specifically, eval()) to run correctly, though the details about why specifically were rather light. I'm not interested in doing something similar, so perhaps try to upstream his less destructive changes and figure out why?
The text was updated successfully, but these errors were encountered: