decompme / decomp.me Goto Github PK

• when loading the page, an invalid compile request is submitted (only contains a null compiler config)
• the scratch's compiler config is not selected in the dropdown (it's always the first one in the list)
• selecting a new compiler config invokes the compiler command as it should, but it uses the old config, not the one that was just chosen
• ctrl+or ctrl- to change browser zoom setting breaks the page
• (opinion) the list of compiler configs shouldn't be reloaded every time you focus back on the webpage

It would be nice to have a way to view a changelog on the site (perhaps next to the GitHub button at the top-right). Extra points if we put a little notification bubble on it if there have been unseen changelog updates since the previous visit!

Also we should consider if we really want version numbers - there's a 0.2 milestone here on GitHub but I'm unsure if version numbers are really worth it for a website.

The database should have a notion of "original context", which is just a copy of the originally submitted context that never changes. We'll need to be able to eventually diff against it to determine changes that were needed in the context for matching.

compiler_wrapper should, upon each invocation, create a sandbox for the compiler and tear it down after the process is finished. Alternatively, we could have a persistent sandbox that we use. We can try different approaches and see how it goes if we're not sure what to do

By session, by ip, whatever

decomp.me code:
(deferred till next version)

• Better parameter validation (make sure things look sane, aren't too large)
• Limit API calls by IP and session
• Think about security and sandboxing

Server:

• Follow django production checklist
• Set up postgresql on webserver
• Set up nginx on webserver

optionally, instead of asm

Allow users to create forks from scratches

• Add the fork button to the scratch view and allow anyone to click it to create a fork
• ctrl+s forks for non-owners? (I wanna ask people if this inconsistency with hotkey behavior will be confusing - probably fine though)
• Store the parent scratch into the new scratch and provide a link to the scratch's parent on the front-end

Provide some pop-up interface for interactively configuring supported compiler flags, rather than just picking from a dropdown list.

e.g. select GCC or IDO, then an -O level, a -g level, and any -f flags.

Related to #27.

The backend now puts stderr from the compiler into an "errors" field in the compile response object. We should add a read-only panel to the scratch view to show the user these errors.

So you can see a full line of text without selection dragging to the right

The client should change \r\n to \n upon sending requests. IDO hates \r, and so should we.

We should better explain to the user that a compilation failed, and perhaps why, if it's not too difficult without imposing a security risk of some kind.

This has been brought up as a user metric (total time spent), but I'm not sure I personally think it's a good idea to have it on the website. I was wondering what others think.

Even if we don't display time spent on the website, there may be other uses for tracking time spent on individual functions and such. However, this might be hard to do..not sure

Given a compiler configuration, c context, c code, and target asm (in the case of a slug-less compile request), cache the compilation result on the server and/or the client so we don't have to invoke the compiler every time this same request is recieved.

I imagine for things like trying and undoing small changes over and over, this could really dramatically improve the UX of the app. Not to mention that anyone loading a scratch page will get a near-instant result on the screen immediately, in the case of server-side caching.

https://github.com/simonlindholm/decomp-permuter/compare/decompme

https://discord.com/channels/688807550715560050/859699601971609610/867037644431818812

We should take advantage of the PATCH functionality we discussed earlier on Discord and allow the owner of a scratch to update the c code, context, and/or compiler configuration. I think this would be as simple as calling the existing PATCH endpoint via a new button that is only enabled for the creator of the scratch.

some conflict between the django auth and our session stuff

Add arch field to Compiler so we can begin to support other arches. We'll be able to use this when invoking asm-differ to get diffing for other arches as well

rather than having it hard-coded in the settings python file.

Note: this issue refers to decomp.me having a 'permute' button that runs the permuter on your code, not the already-implemented permuter CLI feature that allows uploading code to decomp.me.

Allow users to view / edit c context in the scratch view via a collapsible text panel

Sometimes the context is 200kb or more, so we should really avoid sending the context to the backend if it hasn't changed.

We need to make sure the backend's version matches the front end's context in order to bypass sending it, so my idea is to have the backend to hash the context and give the hash to the front end. The front end will hash it whenever it needs to make a compile request. If the hashes match, it'll send a signal for the context instead like unchanged. When the scratch is saved, the backend can return the updated hash so the client always knows what's up.

how do

For owners (first visit to the scratch), they can save their scratch or fork it.
For non-owners, they can fork the scratch.

For now, let's consider the implementation of the fork button but perhaps not add the feature until the next iteration

When a user submits a scratch, we should make sure that we can 1. compile the context with 0 errors and 2. assemble the target asm into an object

If we don't do this and the context is broken somehow, it'd be a huge pain for the user to figure out later on

If the expanded context puts the C code off the bottom end of the screen, you are unable to scroll down to view the remaining code.

https://decomp.me/scratch/MeTIZ

^ An example on my screen.

At scratch creation time, we should compile the context in isolation and ensure we get no errors. If any errors come up, tell the user and don't create the scratch.

It's probably deadly simple

Currently, there's not really any visual distinction between various elements of the site. We should give things borders and probably change the background to be a gray instead of solid black.

• Visual distinction between UI elements
• Less harsh color scheme (slightly less contrast)
• Potentially go with less of a retro look and something more modern instead
• Any other changes people see fit

There's a lot of potential functionality that can be added by having project awareness in scratch creation.

If decomp.me had a local clone of a github repo, it could theoretically provide the asm source and context for a function and only require the user to enter the function name. We could even index all the scratch-able functions for a repo and give the user some sort of autocomplete functionality when they're typing the function name.

This is a future thing, but I'm logging it now since it will be important for the original goal of the site.

that encourages the user to share the URL in the former case and also says "fork successful" in the latter case

We have word wrap on now, but we should figure this out anyway and maybe make word wrap a user option instead

• padding on .log
• display:block on log so it can scroll (or make it so the log/diff combo itself can be scrolled?)
• label for the source code so it doesn't look like the context label applies to it
  - [ ] "Compiling..." text on the toolbar when we are waiting for a compile request to go through
• make compile button un-pressable and visually disabled while a compile request is going through
  - [ ] "unsaved changes" text somewhere if the scratch was changed after page load
  - [ ] maybe have a general status text field that shows "unsaved changes" / "compiling" / etc
• #60
• make the context window size draggable (on the bottom edge)
• allow dragging the code vs diff slider further on both directions
• show warnings checkbox (enabled by default) that, when disabled, hides the log except for compilation failure
• change aesthetic (standardize fonts, remove glow, make things more uniform)
• there are issues scrolling the code area when the context is open
• #61
• #62

To help people create scratches manually, we should have a preset chooser that configures the common settings for a project. Presets can be organized by compiler and listed underneath each one in a dropdown or just in a flat dropdown list of their own.

Easiest way for me to reproduce this is to load up a scratch and then hold down a key, e.g. / to add a bunch of slashes. After ~3 the cursor jumps to the bottom of the editor.

I feel like this has something to do with the setState value/set being shared/reused with the editor, i.e. the value of the editor is set via setCCode. If the call to setCCode is removed, then the problem disappears - however the value of cCode is not set so the value being past to the compiler, so it's not a solution.

we can probably prepend .set noreorder to target asm before building it, or maybe there's an assembler flag

Or at least provide some mechanism for loading compiler configs into the database

This should happen only when the scratch is requested. This will require some db changes to store the original text the user gives us.

The frontend should attempt to parse warnings/errors emitted by the compiler on specific lines and display warning/error squiggles on those lines. We should also show warnings/errors in their own box similar to vscode, as functions can get lengthy,

See https://microsoft.github.io/monaco-editor/api/modules/monaco.editor.html#setmodelmarkers

Sometimes the client sends us a context file which has tons of unnecessary stuff. Determining what's unnecessary is a bit tricky, but I think one can at least remove all function definitions with relative certainty and replace them with function declarations. We should really be doing this, since it'll make the diff results easier to handle as well. Any other ways to prune the context should also be considered.

Make sure no one sends us anything too insanely massive at least

also, disable the button after it's pressed so it doesn't allow multiple requests at once