Marathon Local Tester

86 posts Mon, Feb 22, 2021 at 05:14 PM in General Marathon Discussions

Since MM118, marathon local testers use a common code infrastructure, which was created to make the usage and the development of new MM testers easier and standardized.
This article summarizes the available command line options:
https://www.topcoder.com/thrive/articles/marathon-local-tester-parameters
Please, use this thread for generic questions related to marathon local tester usage.

View: Threaded  |  Flat
+4

Comments

  • 19 posts Mon, Feb 22, 2021 at 07:39 PM

    We will have upvotes soon, but until then, take one from me!

    +1

    +1
  • 1 posts Fri, Mar 5, 2021 at 08:04 AM

    Is it intentional that this "common code infrastructure" is not included in the local testing tools that are available from the problem statement?
    Or is this an oversight?

    As of MM124, there doesn't seem to be a way of obtaining the source code for the MarathonTester base class short of decompiling the tester.jar.

    +0
  • 86 posts Fri, Mar 5, 2021 at 04:54 PM edited Mar 5, 2021 at 04:55 PM

    @fetetriste said:
    Is it intentional that this "common code infrastructure" is not included in the local testing tools that are available from the problem statement?
    Or is this an oversight?

    It was an oversight, and I guess the common insfrastucture source code has been added now.

    +1
  • 86 posts Tue, Jan 4, 2022 at 12:41 PM edited Jan 4, 2022 at 04:55 PM

    Recently @nika suggested a new feature:

    @nika said:
    What interactive visualizers are really missing is some way to look at previous/arbitrary turn. Usually done with slider (1 to max_turn), up/down button and a text field to specify turn number.
    Here are some examples from AtCoder (you need to enter output to see it in action):
    https://img.atcoder.jp/future-contest-2022-qual/f4ca7c3336de23e5c8d1338981e38375_en.html
    https://img.atcoder.jp/ahc006/c21daebb77aa4d38d65f4d7f7c7249.html
    https://img.atcoder.jp/ahc007/a855b6a456c9892b747e147001b0f89.html

    Now that visualizer/tester supports some advanced features, would be very nice to have this one as well, shouldn't be too hard either.

    Other members (@JacoCronje, @sullyper, @dimkadimon) contributed with ideas and @eulerscheZahl shared an interesting solution:

    @eulerscheZahl said:
    As it bothered me for a while already, I decided to look into the viewer topic.
    My first idea was to store the individual states as svg but I couldn't find a library that fully fitted my needs. So I wrote my own decorator around the Graphics2D class. The idea is to intercept all graphics calls, store them and forward them to an existing graphics implementation. On seed 2 this takes about 300MB of RAM. I got it down below 200MB by changing a few lines in the grid drawing code. Apart from that I didn't touch the code specific to this challenge.
    You can find a proof of concept attached. Please note that it's by no means a usable product: I broke the pause function and probably the image export and manual mode as well. And I only implemented the part of the graphics API that was needed for the current game. But it shows how it could be done.
    Another feature I'd like to see in the future: show the stdin+stdout for each frame so that you can copy it to your IDE and reproduce a certain scenario.

    https://github.com/eulerscheZahl/TopcoderViewer

    As this discussion started in MM131 forum, which I guess is not visible for everyone, I am moving it to this thread.

    I already started working on this feature last week, also using a decorator around Graphics2D (same idea shared by @eulerscheZahl). It should still take me some time to finish a working version though.

    +1
  • 86 posts Tue, Jan 11, 2022 at 08:29 PM edited Jan 12, 2022 at 09:09 AM

    Here is a BETA version of the "REPLAY" feature.
    Links to the updated visualizers for a few past matches (just let me know if you would like to test in another problem):

    MM131 - StopTheElves
    https://drive.google.com/uc?export=download&id=1denRwFeu7phwmUsJVJHL8xPEZIiTjl5h

    TCO21 Final - CoinCollector
    https://drive.google.com/uc?export=download&id=1ryUXA0byv1l4lPC6w9CzmE4k8RF6xgaA

    MM123 - Jewels
    https://drive.google.com/uc?export=download&id=1gTCtXEB1iOcoa9g1fn6nYsp_H_KgVYWI

    The source code is inside the JAR file. Just expand it (like a ZIP) if you want to check the code, compile from the source, or make any changes.


    The goal of the "replay" feature is to allow moving back to previous states in the visualizer (currently is only possible to pause, resume and move a single step).
    It should work for any problem that uses an animated visualizer (interactive or not).

    There are 3 ways to control:

    • Clicking in the buttons (in the bottom right).
    • Clicking or dragging the slider: move to an intermediate point, based on where the click was.
    • Using the keyboard:
      • SPACE: Pause / Resume.
      • HOME: Move to the first frame.
      • END: Move to the last frame.
      • LEFT arrow: Move to the previous frame (-1).
      • RIGHT arrow: Move to the next frame (+1).
      • DOWN arrow: Rewind 10 frames (-10).
      • UP arrow: Advance 10 frames (+10).

    There are two other buttons to decrease / increase the delay between frames.

    It is possible to disable this feature (which consumes memory, but not that much, at least in the tests I made so far) by using the command parameter -nr (or -noReplay).
    When replay is disabled, only SPACE and LEFT arrow works.

    Another detail, the "delay" must be enabled. If delay is set to zero (-dl 0), the replay won't work.
    Note that depending on the visualizer there could be more frames than turns/steps.


    Not direct related, but I would like to mention another tester parameter: -na (or -noAntialiasing).
    Depending on the machine you are using, it can speed up a lot the visualizer's painting process (in exchange for a lower render quality).
    It has been available for quite some time, but I think many competitors are not familiar with.
    Now with the "replay" feature, this parameter can be useful to allow faster navigation.

    +8
  • 39 posts Wed, Jan 12, 2022 at 08:28 AM

    This is great! Very smooth and functional.
    I would probably swap UP/DOWN buttons with each other, increasing turn number with UP seems more natural.

    +1
  • 86 posts Wed, Jan 12, 2022 at 08:46 AM edited Jan 12, 2022 at 09:53 AM

    Thanks for the feedback @nika!
    And for the feature suggestion!

    I was unsure about which direction UP and DOWN should go.
    I thought about a text file, in which UP moves towards the beginning.
    But simply UP for increasing makes more sense.

    EDIT: I just updated the post and the visualizers. Now UP moves forward 10 frames and DOWN rewinds 10 frames.

    +1
Sign In or Register to comment.