CLI interface for codeAbbey
Back to General discussions forum
Hi!
I've been recently using codeAbbey in an enviroment where I can exclusively use tools which work in a terminal. Unfortunetly, the browsers which render to a tui dont support javascript and codeAbbey requires javascript to submit solutions to problems.
So I hacked together a simple cli interface as a python script. Currently it only supports submiting solutions, primarly because doing much else would require parsing html which is a pain so I didn't feel like doing it.
I will note that I assumed POSIX (and more consequentially freeDesktop), but I am of the belief that the only people who would willingly use
either cmd or powershell as an interactive sessions are masochists (nothing wrong with that, so am I)
so oh well. Also note that the script currently does not support multi site workflows well
(specifically you most likely will want to set $ABBEY_SESSID_FILE as otherwise you can only be
logged in into one site at a time)
Also, is there any possibility of extending the api? Honestly just being able to add a param to get the data in a easly serializable format (json or similar) would be more than enough, though I'm not sure how complex that would be.
Hi Friend! I feel sorry for probably i still don't know your name to address you properly :)
As you probably already figured out, javascript is not exactly necessary, it just does some annoying tricks to help with the interface etc. So probably your "hack" should be pretty fine.
Also, is there any possibility of extending the api?
yep, for sure. I'm just a bit confused - which data you want to get? there is a separate endpoint to get problem text
somewhere (perhaps it is /index/task_text/problem-name) - though it is source in markdown, i'm not sure it is better
or worse for you. Input data are also served now by separate endpoint. Eh... perhaps /index/task_preparedata, right?
I guess you normally use both of them getting full response as data... not sure where you would like json as in both
cases there are no any "fields" or something - just data.
there is a separate endpoint to get problem text somewhere [...] - though it is source in markdown, i'm not sure it is better or worse for you.
Actually that would be somewhat nice, though it doesn't appear to be in the public source tree :P
Markdown is quite readable raw and basic formatting
would be somewhat easy to implement and displayed
with SRG escapes (see console_codes(4) )
Input data are also served now by separate endpoint. Eh... perhaps
/index/task_preparedata, right?
I'm already using that, mostly since its more convenient to run code locally. I actually even have a command to get the data, either so that it can be fed into the solution manually or to view.
Honesty the current workflow of this plus lynx works fine for me (aside from some broken filters, but I want to first investigate that a bit more and comprehensively report, though editing the url manually would work I think), but extending the script into a tool which can be used by itself (so viewing tasks, the list of tasks and other's submissions at minimum, forums would be nice too) would require getting some structured data, either extracting it from the html or using routes which the public source tree does not contain.
Again, this is not a big priority for me and a decent excuse to practice scraping :3