Add some tests and Travis integration #2
Conversation
|
I have enable travis integration on the mazefiles and the maze-tool repos.
As far as I can see, all the names should satisfy the [a..z0..9\-\.] requirement. I think that uppercase characters should be disallowed in maze filename because of the ambiguous treatment across filesystems.
In the root, files like README should be uppercase if desired but not enforced.
Peter Harrison
[email protected]
… On 20 Mar 2018, at 19:42, Miguel Sánchez de León Peque ***@***.***> wrote:
These would be the results as reported by Travis:
https://travis-ci.org/Peque/mazefiles/builds/356025295
I am currently checking basic stuff about the maze file formatting and correctness. I also check that the file name only contains characters in "a-z", "A-Z", "0-9", "-" and "". I could modify that to allow only lower case in names and either "-" or "". Although that would require some name changes if we wanted the tests to pass, of course. 😊
By the way, in order to enable Travis in your mazefiles repository you need to activate that service. It is free and you can register using your GitHub account. I can do that if you want, but I would require admin access to the repository.
You can view, comment on, or merge this pull request online at:
#2
Commit Summary
• Add some tests and Travis integration
File Changes
• A .gitignore (2)
• A .travis.yml (10)
• D classic/.gitignore (0)
• D halfsize/.gitignore (0)
• A test_mazes.py (125)
• D training/.gitignore (0)
Patch Links:
• https://github.com/micromouseonline/mazefiles/pull/2.patch
• https://github.com/micromouseonline/mazefiles/pull/2.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Okay, I will change that. Some tests will fail until all names satisfy the requirements, but I guess that is fine for now. I will also add a half-size example, as I have realized I removed the |
|
BTW: I will add some commits as "fixup" to previous commits, so when you think this is ready to be merged, tell me and I will first squash them. |
|
git cannot track empty folders. That is why the empty .gitignore was there. As long as there is something present, it will be fine.
I do not know of anyone with halfsize maze files. I will ask around.
Peter Harrison
[email protected]
… On 20 Mar 2018, at 22:35, Miguel Sánchez de León Peque ***@***.***> wrote:
Okay, I will change that. Some tests will fail until all names satisfy the requirements, but I guess that is fine for now.
I will also add a half-size example, as I have realized I removed the halfsize directory when deleting the .gitignore file inside it. I think I have a working basic maze image to maze text file script, which should help creating a collection of half-sized mazes (it would really be a pain to make those manually... 😂).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Wooops, I just changed the Yeah, I will update the README file too! Good idea to document this a bit. |
|
I do not think that is necessary. After all, the word "classic" and "halfsize" is already in the path as their respective parent directories. The Python script already checks for size consistency, according to the path (i.e.: 16x16 for files under "classic", 32x32 for files under "halfsize"). By the way, the half-size example I uploaded I found it here: http://www.ntf.or.jp/mouse/micromouse2014/MM2014recode01.html There are some other mazes from previous years, but it is definitely far from a complete collection. Only good news is that the script that I wrote seems to work fine with those images! (unless I missed something, the generated text file seems to be correct) 😄 |
|
OK. We will go with it as-is for now.
You sucked that data out of the image? Good job!
Peter Harrison
[email protected]
… On 20 Mar 2018, at 23:13, Miguel Sánchez de León Peque ***@***.***> wrote:
I do not think that is necessary. After all, the word "classic" and "halfsize" is already in the path as their respective parent directories. The Python script already checks for size consistency, according to the path (i.e.: 16x16 for files under "classic", 32x32 for files under "halfsize").
By the way, the half-size example I uploaded I found it here:
http://www.ntf.or.jp/mouse/micromouse2014/MM2014recode01.html
There are some other mazes from previous years, but it is definitely far from a complete collection. Only good news is that the script that I wrote seems to work fine with those images! (unless I missed something, the generated text file seems to be correct) 😄
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Updated the README file. Took the liberty of adding a "FAQ" section. Do you like it? About the image->text script yeah, it worked surprisingly well and was surprisingly easy (the current, very basic implementation is 60 lines of code). Still need to try it with not-so-clean images to see what happens. 😂 Will share it soon too! About marking the goal cell at (26, 5), I did not know that. Why is it important? Is not always the only section the mouse can reach that is open just like in the classic competition? (i.e.: no walls in that square/rectangle) Also, is that information provided to the contestants before the competition? As you can see, I am not very well informed about half-size competitions... 😅 Anyway, I will change that tomorrow! 😊 |
|
Marking the goal is only needed for the halfsize contest. The goal can be any single cell and its location is given to the contestants well in advance of the contest.
Since it can be any cell, there is no reason that it should not be halfway along a corridor or a single cell at the end of a cul-de-sac.
The contestant cannot rely on an open area.
Peter Harrison
[email protected]
… On 20 Mar 2018, at 23:46, Miguel Sánchez de León Peque ***@***.***> wrote:
Updated the README file. Took the liberty of adding a "FAQ" section. Do you like it?
About the image->text script yeah, it worked surprisingly well and was surprisingly easy (the current, very basic implementation is 60 lines of code). Still need to try it with not-so-clean images to see what happens. 😂 Will share it soon too!
About marking the goal cell at (26, 5), I did not know that. Why is it important? Is not always the only section the mouse can reach that is open just like in the classic competition? (i.e.: no walls in that square/rectangle) Also, is that information provided to the contestants before the competition? As you can see, I am not very well informed about half-size competitions... 😅
Anyway, I will change that tomorrow! 😊
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Okay, I will add the goal then. 😊 In the README you say goal cells are marked with an asterisk. I like a "G" more. Would you agree in using the letter "G" instead? We could also, for completeness, allow an "S" at the start cell, even if it is always at (0, 0), it could be useful for training/non-standard mazes. |
|
Sure. That makes it match the Japanese mazes.
… On 21 Mar 2018, at 18:53, Miguel Sánchez de León Peque ***@***.***> wrote:
Okay, I will add the goal then.
In the README you say goal cells are marked with an asterisk. I like a "G" more. Would you agree in using the letter "G" instead?
We could also, for completeness, allow an "S" at the start cell, even if it is always at (0, 0), it could be useful for training/non-standard mazes.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Pushed those changes. Tell me if there is anything else you want me to change. If everything looks good to you I will squash all the fixups before you merge. 👍 |
|
Hmmmm... I was thinking maybe we could be less restrictive. In example:
So at the end: the text maze format only specifies that goal cells are to be marked with a "G". Then, depending of the rules (if any), we apply that specification to all the maze files in the different directories. What do you think? |
|
In classic contest mazes, the goal is implicit. In the halfsize maze, it is explicit.
Thus, a contest halfsize MUST have a goal marked but no others need it. Without that, the record represented by a halfsize contest maze file is useless.
Training mazes implicitly have no specific goal. If they encompass the classic goal, it can be detected. If not, it is entirely at the discretion of the user whether the layout is classic or halfsize.
Peter Harrison
[email protected]
… On 21 Mar 2018, at 22:34, Miguel Sánchez de León Peque ***@***.***> wrote:
Hmmmm... I was thinking maybe we could be less restrictive. In example:
• We specify, as we do now, that the text maze format allows (but does not enforce) the use of "G" to mark goal cell(s).
• We can specify in the README that halfsize must have a goal cell marked, though (I added that check to the tests). This is to comply with the international rules. I understand that "classic" and "halfsize" directories should comply with international rules.
• But even classic mazes, they could have the goal cells (the four cells) marked with a "G", just like here: http://www.ntf.or.jp/mouse/micromouse2014/MM2014recode01.html
• Maybe we could even force all of the mazes to have the goal cell(s) marked with a "G". All classic mazes should have the four center cells marked with a G in that case. I think this could be a good idea.
• Being less restrictive allows for training mazes, for example, to have a goal cell marked anywhere. Or multiple goal cells which might even be separated. After all, training mazes do not have to comply with any international rules.
So at the end: the text maze format only specifies that goal cells are to be marked with a "G". Then, depending of the rules (if any), we apply that specification to all the maze files in the different directories.
What do you think?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
. . . And we could move any non-contest mazes, regardless of size, into training.
Peter Harrison
[email protected]
… On 21 Mar 2018, at 22:34, Miguel Sánchez de León Peque ***@***.***> wrote:
Hmmmm... I was thinking maybe we could be less restrictive. In example:
• We specify, as we do now, that the text maze format allows (but does not enforce) the use of "G" to mark goal cell(s).
• We can specify in the README that halfsize must have a goal cell marked, though (I added that check to the tests). This is to comply with the international rules. I understand that "classic" and "halfsize" directories should comply with international rules.
• But even classic mazes, they could have the goal cells (the four cells) marked with a "G", just like here: http://www.ntf.or.jp/mouse/micromouse2014/MM2014recode01.html
• Maybe we could even force all of the mazes to have the goal cell(s) marked with a "G". All classic mazes should have the four center cells marked with a G in that case. I think this could be a good idea.
• Being less restrictive allows for training mazes, for example, to have a goal cell marked anywhere. Or multiple goal cells which might even be separated. After all, training mazes do not have to comply with any international rules.
So at the end: the text maze format only specifies that goal cells are to be marked with a "G". Then, depending of the rules (if any), we apply that specification to all the maze files in the different directories.
What do you think?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Yeah, agree about moving non-contest mazes to training. That should be a separate pull-request though. I pushed the changes you requested in the README file too. Just to try to explain myself better one last time (I think maybe I did not the first time)... What I had in mind is:
But I understand if you want to exclude that from your collection. |
|
Actually, instead of moving non-contest mazes to |
|
By the way, I just finished packaging the software for image-to-maze-file conversion: https://github.com/Theseus/ommr Is it fine for you if I mention it in your README? Maybe potential contributors could benefit from it making their job a bit simpler. If you have some spare time and want to try it out I would appreciate some feedback! 😊 All the documentation (very short) is in the README file of the repository. |
|
That should work
… On 21 Mar 2018, at 23:01, Miguel Sánchez de León Peque ***@***.***> wrote:
Yeah, agree about moving non-contest mazes to training. That should be a separate pull-request though.
I pushed the changes you requested in the README file too.
Just to try to explain myself better one last time (I think maybe I did not the first time)... What I had in mind is:
• In the list that defines the file format, we only mention that a "G" can be written to mark goal cell(s).
• Bellow, when talking about the halfsize folder, we clearly specify that the "G" is a must and there is only one goal cell.
• In training mazes we could allow any configuration, not necessarily complying with classic nor halfsize international maze rules. Although that could be in a different folder... Here we could have a 50x50 maze, for example, or a 4x6 not contained in a 16x16 maze. Goal cells could be single, groups or even multiple and separated. No rules except to comply with the maze file format. 🤪
But I understand if you want to exclude that from your collection.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Yes. Include the link.
… On 22 Mar 2018, at 18:18, Miguel Sánchez de León Peque ***@***.***> wrote:
By the way, I just finished packaging the software for image-to-maze-file conversion:
https://github.com/Theseus/ommr
Is it fine for you if I mention it in this README? Maybe potential contributors could benefit from it making their job a bit simpler.
If you have some spare time and want to try it out I would appreciate some feedback! 😊 All the documentation (very short) is in the README file of the repository.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
That works really well.
I note that the default seems to be to assume halfsize rather than classic.
If it could cope with not having the right/bottom walls cropped, it would be possible to scrape images from web pages/sites and auto-convert them.
Peter Harrison
[email protected]
… On 22 Mar 2018, at 18:18, Miguel Sánchez de León Peque ***@***.***> wrote:
By the way, I just finished packaging the software for image-to-maze-file conversion:
https://github.com/Theseus/ommr
Is it fine for you if I mention it in this README? Maybe potential contributors could benefit from it making their job a bit simpler.
If you have some spare time and want to try it out I would appreciate some feedback! 😊 All the documentation (very short) is in the README file of the repository.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Excuse my ignorance but - how does pip know where to find ommr?
… On 22 Mar 2018, at 18:18, Miguel Sánchez de León Peque ***@***.***> wrote:
By the way, I just finished packaging the software for image-to-maze-file conversion:
https://github.com/Theseus/ommr
Is it fine for you if I mention it in this README? Maybe potential contributors could benefit from it making their job a bit simpler.
If you have some spare time and want to try it out I would appreciate some feedback! 😊 All the documentation (very short) is in the README file of the repository.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I just pushed the update in the README file. Tell me if there are any other changes you want me to do before squashing this.
Yeah, I already opened an issue for that. 😊 Are there any websites in particular you are thinking about scraping? I thought I could create a simple script to crop all images in http://www.ntf.or.jp/mouse/history/index.html and that should work well but then: it would only work for those images. Matching names between those images and your repo was another task that required some extra work. Would you help me with that last part if I did the first? 😉
I uploaded the package to the public PyPI repository. Once you have your |
|
No sites in particular spring to mind. Sometimes I find them on Japanese sites. If it were possible to just take an image link and feed it to the converter, that would be super convenient. For the lazy like me that is.
The NTF archive looks handy. It would be good to do a bulk conversion and compare with what we have. I can help with name reconciliation where I am reasonably sure I can work it out.
The names in my repos come from all over and are pretty cryptic in many caes. I would love to know what event some of the mazes actually represent.
… On 22 Mar 2018, at 22:52, Miguel Sánchez de León Peque ***@***.***> wrote:
Yes. Include the link.
I just pushed the update in the README file. Tell me if there are any other changes you want me to do before squashing this.
If it could cope with not having the right/bottom walls cropped, it would be possible to scrape images from web pages/sites and auto-convert them.
Yeah, I already opened an issue for that. 😊
Are there any websites in particular you are thinking about scraping? I thought I could create a simple script to crop all images in http://www.ntf.or.jp/mouse/history/index.html and that should work well but then: it would only work for those images. Matching names between those images and your repo was another task that required some extra work. Would you help me with that last part if I did the first? 😉
Excuse my ignorance but - how does pip know where to find ommr?
I uploaded the package to the public PyPI repository. Once you have your setup.py file configured it is really simple. 😊
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
About the cryptic names... I would prefer longer, explicit names like But I guess you do prefer shorter names, right? 😂 |
|
No. Explicit names are much better. Most of the originals for these files probably come from the days of 8.3 filenames and then they just got made more consistent.
I have no problem with longer names if they are well defined and consistent. Some of the Japanese names form their archive are a bit wordy though.
I will try and look through the pull request later. Busy couple of days here.
… On 22 Mar 2018, at 23:20, Miguel Sánchez de León Peque ***@***.***> wrote:
About the cryptic names... I would prefer longer, explicit names like japan-2011-expert-final instead of japan2011ef. It is easier to search for "final" than "f" (would give better results). And if you want to display shorter names, removing dashes and cropping words is always simpler than the reverse operation...
But I guess you do prefer shorter names, right? 😂
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Had to search what 8.3 filenames were. 😂 Great! No hurries, of course. 👍 |
|
Squashed everything into 4 commits to hopefully make the final review a bit easier. |
These would be the results as reported by Travis:
https://travis-ci.org/Peque/mazefiles/builds/356025295
I am currently checking basic stuff about the maze file formatting and correctness. I also check that the file name only contains characters in "a-z", "A-Z", "0-9", "-" and "". I could modify that to allow only lower case in names and either "-" or "". Although that would require some name changes if we wanted the tests to pass, of course. 😊
By the way, in order to enable Travis in your
mazefilesrepository you need to activate that service. It is free and you can register using your GitHub account. I can do that if you want, but I would require admin access to the repository.