Skip to content
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

Improve parsing/storage of warrior metadata #38

Open
ian-h-chamberlain opened this issue Jul 26, 2020 · 0 comments
Open

Improve parsing/storage of warrior metadata #38

ian-h-chamberlain opened this issue Jul 26, 2020 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@ian-h-chamberlain
Copy link
Member

ian-h-chamberlain commented Jul 26, 2020

It seems to be common practice to describe warrior strategy on multiple lines, e.g.

;redcode-94
;name Blur 2
;author Anton Marsden
;assert CORESIZE==8000
;strategy 0.5c scan, 0.25c SPL carpet -> DAT/DJN clear
;strategy Final version (for a while)
;kill Blur

This should be supported for all fields that may span multiple lines, which is probably really just strategy.


Various redcode standards exist in different warriors, e.g. recode-88, redcode-koth, plain ;redcode, etc. These should be handled and preserved by the metadata parser as well.


The kill directive seems to be koth specific, most likely to "obsolete" or replace an existing warrior? Up for debate whether this needs support. Preserving it is probably good though.


pMARS appears to support some debug directives:

;trace [off]            (*) toggle trace bit for following instructions
;break                  (*) set trace bit for next instruction
;debug [static|off]     (*) enable/disable setting [static] trace bits

Even if not implemented yet, these should probably be stored in the metadata and preserved in a load file.


Side note: Benj'sRevenge.red has an interesting question which appears to use the second name directive

;name Benj's Revenge 1.0
...
; Name obvious to those who know my son :-)
; (oops -- classic "Name" bug, but I like the new one too:)

It seems like, then, the canonical implementation uses the second one. What this means is probably that the TextMate grammar for syntax highlighting should also highlight the second one (use whitespace), and the metadata parser should warn for this kind of "bug" as the comment references.

@ian-h-chamberlain ian-h-chamberlain added the enhancement New feature or request label Jul 26, 2020
@ian-h-chamberlain ian-h-chamberlain self-assigned this Sep 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant