Ver código fonte

refactor: Start refactoring TODO

Read Roadmap.md as a start point for futures TODO
Marcelo Fornet 5 anos atrás
pai
commit
11e4e351de
7 arquivos alterados com 301 adições e 94 exclusões
  1. 1 1
      .gitignore
  2. 293 0
      Roadmap.md
  3. 0 9
      notes/similar-projects.md
  4. 0 43
      notes/sug.txt
  5. 0 5
      src/companion.ts
  6. 1 19
      src/core.ts
  7. 6 17
      todo.md

+ 1 - 1
.gitignore

@@ -3,7 +3,7 @@ node_modules
 
 # Extension
 *.vsix
-out
+out/
 
 # IDE
 .vscode/

+ 293 - 0
Roadmap.md

@@ -0,0 +1,293 @@
+# AcmX
+
+## Wiki
+
+Hacer wiki de acmx.
+Debe contener intro. (Tutorial con lo mínimo indispensable para echarlo a andar con poco esfuerzo).
+Idealmente links a algunos videos mostrando como usar la herramienta.
+Wiki explicando los features de esta herramienta y como configurarlos.
+
+## UX
+
+No configuration should be needed by default and it should work out of the box.
+
+## Support for multiple languages
+
+Diferentes configuraciones (con el ejemplo completo del workspace) donde se resuelva un problema en diferentes lenguajes (priorizar los mas importantes en acm).
+
+Incluir por defecto soporte para multiples lenguajes.
+
+Diferentes lenguajes, tanto para la solución, como para la solución bruta, generador, checker.
+Quizas hacer una wiki al respecto, como hacer configuraciones especiales.
+
++ C++
++ JavaP
++ Python
++ Rust / D / Kotlin (intentar construir ejemplos en estos lenguajes).
+
+Se puede hacer un proyecto, acmx-examples que contenga los diferentes ejemplos, y de donde se puedan copiar las diferentes configuraciones por lenguaje. Como parte de los integrations tests correr varios tests sobre los examples, seria bastante interesante.
+
+### Support for extra tools
+
+Estoy pensando que yo quiero tener acceso a testlib con auto-completamiento y potencialmente a la libreria de algoritmos, quizas a jngen tambien. pero por supuesto no se puede estar copiando todo el tiempo. Entonces seria bueno ver si se puede incluir como un environment y pasar los argumentos correspondientes.
+
+## Commands
+
+    Crear un problema nuevo.
+        Se debe crear dentro de:
+            solutions/orphans/problem/$name
+
+    Crear un concurso nuevo.
+        El nombre de los problemas deberia ser con letras en lugar de con numeros.
+        Intentar implementar un parser para pdf / sacar cantidad de problemas / nombres.
+            solutions/orphans/contest/$name
+
+    Fix testcase (este es un comando que se ejecuta con click derecho sobre los ficheros gen.in)
+
+    View code:
+        Cambiar la vista a ver el código.
+
+    Compile:
+        Compile only. Si hay error de compilación (o warning) debería mostrarlos.
+        Esto es la salida de error. Mostrar en el status bar: compilation failed (exit code) / compilation succeeded.
+
+    Open testcase:
+        Lista todos los testcases y abre uno en particular.
+
+    Run:
+
+    Stress:
+        Corre generador (si hay fuerza bruta correrlo también).
+        Para el stres testing se puede definir máximo tiempo corriendo o maximo numero de iteraciones.
+
+    Add brute solution:
+        Cuando hay brute solution, y esta enabled para los ficheros que no tengan salida usarlo como comparador. Idealmente solo compilar si es necesario.
+
+    Disable brute solution:
+        Aunque haya un brute solution en el environment, no usarlo.
+        Cuando le das click a una solucion que pueda hacer la funcion de bruto permitir la opcion, anhadir como brute force.
+        Cuando le das click al actual fuerza bruta permitir 
+
+    Upgrade:
+        Crea todos los ficheros necesarios para
+
+    Set checker:
+        Por defecto se usa token comparator
+
+    Submit:
+        Hacer un feature en el competitive companion que permita hacer submit automaticamente.
+        
+
+    Update contest:
+        Quizas sea util para reformatear mas cosas.
+
+## Tool structure
+
+Estructura de la carpeta donde se archivan todas las soluciones.
+
+    solutions/
+        orphan/
+            problems/
+                problem-name...
+            contest-name...
+        contest-name...
+
+Estructura de un problema
+
+    problem/
+        .attic/
+            config.json
+            ejecutables y demas ficheros que se generan.
+        testcases/
+            test$id.in
+            test$id.out
+            test$id.hand.in
+            test$id.hand.out
+            test$seed.gen.in
+            test$seed.gen.out
+            test$id.hand.brute.out
+            test$id.hand.sol.out
+        solution.cpp
+        gen.py
+        brute.cpp
+        checker.cpp
+
+### Problem config
+
+Habilitar un config para un problema en particular (`config.json`)
+    - time to time limit
+    - max memory (this will be enforced per p)
+    - si es interactivo o no.
+    - numero de casos de pruebas a generar en el stress.
+    - short circuit (correr hasta el primero que falle, o correr todos y luego hacer reporte).
+    - si esta habilitado o no el checker.
+    - hashsum de los ficheros compilados para no tener que volverlos a compilar.
+    - datos del problema (url probablemente) para hacerle queries al competitive companion
+        - metadatos descargados del problema / concurspo
+    - version del acmx donde se ejecuto
+
+Potencialmente crear un config para el concurso, tambien.
+Permitir editar estos json config en una interfaz comoda del vscode (como la de los settings).
+
+### Parsing information
+
+Cuando se parsea la informacion del competitive companion usar los limites de tiempo limite y memoria limite para la ejecucion del programa. Entonces hay varias opciones disponibles:
+
++ Usar tiempo limite global para el problema
++ Usar tiempo limite particular para el problema.
++ Usar tiempo limite descargado para el problema.
++ Usar tiempo limite descargado multiplicado por un factor. Quizas se puede incluso hacer que el factor sea dependiente de la plataforma.
+
+### Test case handling
+
+Manejar los testcases de una forma similar al chelper / jhelper, que permita manejar que testcases debe ser ejecutados y cuales no. Buttons: [All/None] Checkmark para marcar no marcar, permitir ver los testcases.
+
+Probablemente esto requiera de un boton para abrir la interfaz que permita manejar los testcases.
+
+### Run summary
+
+Se genera un resumen de los errores. El tiempo / memoria tamanho de entrada y de salida por cada caso de prueba, y si tuvieron algo por la salida de error. Imprimir la salida para todos los problemas (preferiblemente la salida resumida en caso de que sea muy grande).
+
+Permitir casos de pruebas que no tengan output, deben correr y no ser reportados como WA.
+
+### Smart copy
+
+Esto deberia ser una herramienta a parte de acmx, y basicamente lo que debe permitir es crear un fichero con todo el contenido de los includes en el caso de c++. Debe ser una herramienta con una extension en el vscode.
+
+### Generator
+
+Si hay un fichero que tenga prefijo gen, se usa para generar casos de pruebas. Se espera que ese fichero reciba una semilla (un entero de 32 bits) y genere de forma determinista un caso de prueba, esto es para lograr reproducibilidad.
+
+Tener ejemplos de generadores en diferentes lenguajes.
+Permitir cambiar la plantilla de los ejemplos.
+Se tiene un formato para poder compilar / ejecutar codigos en diferentes lenguajes.
+
+Se generan x casos de pruebas aleatorios y se ejecutan las soluciones en los mismos.
+Se corre el codigo en cada caso de prueba de forma independiente.
+
+Los casos de pruebas que se generan se quedan en el directorio sin ser borrados (el nombre es test$seed.gen.in). Crear un comando que con click derecho, si el fichero se llama test$seed.gen.in, poder convertirlo en hand$id.hand.in (donde id sea el maximo + 1)
+
+### Brute force
+
+Si hay fuerzas brutas disponibles, crear el ejecutable de la forma que exista disponible para ese lenguaje, generar preferiblemente los ejecutables en la carpeta `.attic`
+Cuando se ejecute
+
+### Interactive
+
+## Integration tests
+
++ Hacer test de cada funcionalidad.
++ Intentar hacer test en la nube usando todas las plataformas.
++ Probablemente necesite hacerme un mock-online judge, util para prober muchas funcionalidades, incluyendo integration tests con el competitive companion. Quizas en lugar de usar un mock online judge pueda usar una instancia del mog, esto suena como una buena idea.
+
+https://code.visualstudio.com/api/working-with-extensions/continuous-integration
+
+## Nightly
+
+Seria bueno tener features nightly que pueden no funcionar por plataforma.
+
+### Memory
+
+Tratar de medir la memoria probablemente esto se tenga que manejar de forma independiente por plataforma.
+En linux se puede usar runlim, o quizas algunos programas de rust que pueden conocer la memoria por subproceso.
+
+### Automatic submit
+
+Hacer submit desde esta aplicacion usando el competitive companion.
+Quizas sea necesario hacer una herramienta nueva, para no ser tan intrusivos en el competitive companion.
+
+https://developer.chrome.com/apps/sockets_tcpServer
+
+### Detect status
+
+Detectar el status del problema desde el competitive companion: Aceptado / Intentado / No intentado.
+Si es un live contest, intentar descargar mas datos. Como por ejemplo cuantos integrantes han resuelto cada problema. Si es un live contest, intentar hacer descargas mas frecuentes al comienzo de la competencia, y luego mas despacio. (Detectar contest virtuales en el codeforces).
+
+Mostrar algunos datos del problema quizas en un README.md o algo asi, que se cargue de forma bonita!
+Si es una competencia en vivo del codeforces se puede intentar hacer fetch al RatingChangeTool e intentar poner esos datos en el status bar. El predicted delta.
+
+## Others
+
+Hacer una herramienta en typescript que wrapee efectivamente la interaccion con los codigos, que permita, compilarlos, ejecutarlos con diferentes opciones y que se puede extraer informacion del mismo al final. Salida, salida de error, tiempo de ejecucion, errores, etc... Esta interfaz sera la empleada finalemente para ejecutar las soluciones en diversos lenguajes, fuerzas brutas, generadores, checkers.
+
+## Machine Learning features
+
+### TCGen
+
+Traer para aca los comentarios del tcgen.
+
+### Find complexity
+
+Detectar la complejidad de los problemas por el texto. 
+Fundamentalmente ordenar los problemas por dificultad, o sea, incluso aunque la complejidad no sea clara, el orden entre los problemas deberia ser util.
+
+### Classify per subject
+
+Intentar hacer un clasificador que prediga los temas y features de cada problema.
+
++ Temas generales (DP, Greedy, Geometria, String, Hashing, Graph, etc...)
++ Features particulares:
+        small to min
+        Accumulative array
+        suffix array
+        suffix automata
+        bipartite graph
+        maximum flow
+
+### Automatic error finder
+
+Tool to find most frequent errors.
+
+Idea: Download pair of solutions from codeforces of the form
+
+FAIL -> OK 
+
+and find diff between both codes. Try to learn which part of the codes changed.
+Ideally try to also suggest valid code.
+
+## Add nightly features to competitive companion extension
+
+Consider creating a separate extension
+
+## Competitive Companion features
+
++ Add MOG as valid online judge
++ Add Project Euler as valid online judge
+    Basically create a new folder to run solution since no testcase can be parsed.
+
+Competitive companion should send json files once it has all files ready to be sent.
+On the vscode end we can wait a 100ms timeout for all json files in case more files are coming.
+
+## Crawler de varios online judges
+
+Descargar problemas nuevos. Sobre todo para hacerle testing a los algoritmos de machine learning.
+Test cases / Statements / Metadata / Solution
+
+## Issues
+
+### First use not working
+
+When used for the first time it can't create a new folder with global attic. In that case it should specify to set the path to store all problems. Use by default some standard location like ~/.acmx/solutions so it always work, even after the first use.
+
+### Allow read / write to file
+
+Some times it is required that you should read and write from file, in that case set infrastructure so it works in this way. Probably copy file to the attic with given name, and run binary (read output from expected output).
+
+### Garbage files
+
+Right now on the mac competitive companion extension is creating two new files in the current directory which is not what is expected.
+
+### Real into expected
+
+Change extension of testcases from .real to .expected
+
+It can be:
+
+4.hand.output.out
+4.hand.expected.out
+
+### Remove .exe
+
+Remove .exe from the extension since I think it should work in all languages
+
+## Tests are not passing right now

+ 0 - 9
notes/similar-projects.md

@@ -1,9 +0,0 @@
-# Ecosystem
-
-* [CHelper](https://github.com/EgorKulikov/idea-chelper/)
-* [JHelper](https://github.com/AlexeyDmitriev/JHelper)
-* [Caide](https://github.com/slycelote/caide)
-  * [codeforces post](https://codeforces.com/blog/entry/18838)
-* [Ineffable](https://codeforces.com/blog/entry/19083)
-* [Hightail](https://codeforces.com/blog/entry/13141)
-* [Competitive-Companion](https://github.com/jmerle/competitive-companion)

Diferenças do arquivo suprimidas por serem muito extensas
+ 0 - 43
notes/sug.txt


+ 0 - 5
src/companion.ts

@@ -13,11 +13,6 @@ export function startCompetitiveCompanionService(){
     app.post('/', async (req: any, res: any) => {
         const data = req.body;
 
-        // console.log(`Problem name: ${data.name}`);
-        // console.log(`Problem group: ${data.group}`);
-        // console.log('Full body:');
-        // console.log(JSON.stringify(data, null, 4));
-
         res.sendStatus(200);
         let contestPath = newProblemFromCompanion(data);
         await vscode.commands.executeCommand("vscode.openFolder", vscode.Uri.file(contestPath));

+ 1 - 19
src/core.ts

@@ -197,24 +197,6 @@ export function testcasesName(path: string){
             map( function(tcpath) { return removeExtension(tcpath); });
 }
 
-// function testcases(path: string){
-//     return testcasesName(path).map(function (name){
-//         let inp_fd = openSync(join(path, TESTCASES, `${name}.in`), 'r');
-//         let out_fd = openSync(join(path, TESTCASES, `${name}.out`), 'r');
-
-//         let inp_buffer = new Buffer(getMaxSizeInput());
-//         let out_buffer = new Buffer(getMaxSizeInput());
-
-//         readSync(inp_fd, inp_buffer, 0, getMaxSizeInput(), 0);
-//         readSync(out_fd, out_buffer, 0, getMaxSizeInput(), 0);
-
-//         return [
-//             inp_buffer.toString(),
-//             out_buffer.toString()
-//         ];
-//     });
-// }
-
 export function upgradeArena(path: string) {
     // Create brute force solution
     let brute = join(path, 'brute.cpp');
@@ -468,7 +450,7 @@ export function testSolution(path: string){
         return new SolutionResult(Verdict.NO_TESTCASES, undefined, undefined);
     }
 
-    // Proccess all testcases in sorted order
+    // Process all testcases in sorted order
     testcasesId.sort();
 
     // Run current test case first (if it exists)

+ 6 - 17
todo.md

@@ -1,25 +1,14 @@
-# List of TODO
+# TODO
 
+* Go over the Roadmap.md and convert in TODO
 * When a new view is activated (after run or view:code) close all open tabs. (also (maybe) collapse everything not related to the problem)
-* Implement parser for codeforces-gym/codechef/atcoder/matcomgrader/coj (which are most popular online judges currently)
 
 * [005](/src/core.ts): Restrict brute in time, and capture errors
   * Allow stopping a running program (such as sol.cpp/brute.cpp/gen.py/etc...)
 * [007](/src/extension.ts): How can I have access to new process created using `openFolder`?
-* Add Telegram group join link in the Readme
 * Add gif to README. Gif should be a tutorial (how to use).
 
-## QUICK TODO
-
-* Test and provide example using other languages.
-* Copy to clipboard (smart copy in the future with tool suggested by jcg) (Find in examples, create shortcut)
-
-## Settings
-
-Particular settings (per problem) configuration on current workspace.
-This can be done creating such configurations globally and updating them per workspace (only problem here is that in one workspace might coexist several programs so best answer is probably creating a config file inside each problem and access them through cool UI settings provided by VSCode. This can be done since GitLens already do that.) Store also problem name on this config file, maybe URL.
-
-* Make a new command to open particular settings of a problem
-
-* [ ] Allow multiple solutions. (Don't check on this case. Try to figure out if this is the case)
-* [ ] Is interactive (Don't check on this case. Try to figure out if this is the case)
+* Change icon
+* Add better instructions
+* Find is there is a better way to handle the structure of all the solutions.
+    https://code.visualstudio.com/docs/editor/multi-root-workspaces