Package: areas
areasARM64 andRISC-V (extensible)AssessmentSystem.areasis originally a fork fromJoão Damas'Automatic Observation and (grade) Calculation for (subroutine) Operations tool. It is a tool to automate student's grading in the assignments done during the Microprocessor and Personal Computers course unit.Differences with the original toolTo ease the communication between the backend server and the tool the output demanded changes. Output.txtand.csvfiles are now combined in a more complete.jsonfile. Structure of the.zipinput file is simplified. Unsupported data types such as long and double are now supported. A new input parameter - weight - is introduced.Table of contents1. Installation2. Developing3. Running4. Usage5. File syntax and structure5.1. Available data types5.1.1. Primitive data types5.1.2. Array data types5.2. subroutines.yaml5.3. tests.yaml5.4. submission.zip6. Results1. InstallationUsing Docker:dockerpullluist188/areas2. DevelopingTo develop the tool you must setup a Docker development environment to ease the dependencies installation and setup an isolated environment.Build the Docker development image:dockerbuild-fDockerfile.dev-tareas.Run the image with the shared folder:dockerrun-it-v$(pwd):/usr/appareasNote: if you are running MacOS with the M1 (or superior) chip you must add--platform linux/x86_64todocker buildanddocker run.3. RunningPlace the input files inside any directory.Run the image with a shared volume pointing to the input directory:docker run -v input:destination -it luist188/areas(you can learn more aboutdocker runusagehere)Run the alias command (assure you are using/bin/bash)areasor runpython main.pyin the tool's source.4. Usage$areas[-h]-srSR-tT-smSM[SM...][-gfdGFD][-ffdFFD][-grfGRF][-toutTOUT][-fpreFPRE]$areas[args]Options:--help, -h                Show help                                         [boolean]-sr <subroutines.yaml>    .yaml file containing subroutine declaration      [required] [string]-t <tests.yaml>           .yaml file containing the test cases              [required] [string]-sm <submission.zip...>   .zip files containing user submission             [required] [string array]-gfd <directory>          path to the directory to store temporary files(e.g., compiled binaries)                                                 [default:grading] [string]-ffd <directory>          path to the directory to store the grading foreach submission                                                           [default:feedback] [string]-tout <timeout>           float timeout value                               [default:2.0] [float]-fpre <precision>         floating point threshold for comparing floatingpoints in test cases                                                      [default:1e-6] [float]5. File syntax and structure5.1. Available data types5.1.1. Primitive data typesintlongfloatdoublecharchari(char represented as an unsgined intenger - similar to char but has to be used when printed characters are not ASCII characters)5.1.2. Array data typeschar*/stringarray intarray longarray floatarray doublearray chararray chari5.2. subroutines.yamlThe input file for the subroutine declaration has to follow a specific structure and syntax described as follows:foo:params:-int-array char-array int-array intreturn:-int-array intbar:params:-longreturn:-longEach subroutine has an optional parameter to define the subroutine architecture, the syntax is as follows:foo:architecture:armparams:-int-array char-array int-array intreturn:-int-array intBy default, if the architecture parameter is omitted, the system will assume ARM64 as the subroutine architecture. The available architectures are the following:arm- ARM64 architectureriscv- RISC-V architectureThe subroutine name has to match the.sto test and is case insensitive. Thus, the subroutinefooorbaris going to check any.sfile that matches its name case insensitive. All subroutines must contain an array of parameters,params, and an array of returns,return.5.3. tests.yamlThe input file for the test cases declaration has to follow a specific structure and syntax described as follows:bar:-inputs:-6outputs:-36weight:0.5-inputs:-5outputs:-25weight:0.5The root declaration of a test case must match the name declared in thesubroutines.yamlfile. Test cases have an array of inputs that has a list of outputs and a test weight. The sum of the test weights must be 1.0.5.4. submission.zipThe submissionzipfile must contain a.sfile in its root. For example, for the subroutinefooandbarthezipstructure should be as follows:submission.zip
├── foo.s
└── bar.s6. ResultsFor each submission file a.jsonfile is created in the feedback directory with the same name of the.zipfile. The file contains all information about compilation status and test cases. In addition, a simplified version of the result of all submissions is created in aresult.json. The content of the files look as follows:Filesubmission.json[{"name":"foo","compiled":true,"ok":true,"passed_count":2,"test_count":2,"score":1,"tests":[{"weight":1,"run":true,"input":[6,["-","+","+","-","-","+"],[1,2,3,0,1,-25],[13,2,8,4,5,25]],"output":["0",["12","4","11","4","4","0"]],"passed":true}]},{"name":"bar","compiled":true,"ok":true,"passed_count":2,"test_count":2,"score":1,"tests":[{"weight":0.5,"run":true,"input":[6],"output":["36"],"passed":true},{"weight":0.5,"run":true,"input":[5],"output":["25"],"passed":true}]}]Fileresult.json[{"submission_name":"submission","subroutines":[{"name":"foo","score":0},{"name":"bar","score":0.5}]},{"submission_name":"submission2","subroutines":[{"name":"foo","score":1},{"name":"bar","score":1}]}]LicenseMIT