db

Auto-Upgrade for HTTP Preview This val is experimentally testing if we can use an LLM to determine if an old-style HTTP val needs to be upgraded for the new HTTP runtime, currently in preview. You can read more about the breaking change and upgrade proccess here: https://blog.val.town/blog/http-preview/#breaking-changes In some light testing, it seems like ChatGPT 3.5 and 4o both are bad at this task, so I'm pausing experimenting with this for now. Example output from 4o: [ { "name": "harlequinChickadee", "probabilityUpgradeNeeded": true, "reason": "The current code structure has several functions and program logic outside the main handler, including word selection, game state management, and SVG generation. These parts would not re-run with the new runtime, potentially affecting functionality. They need to be moved inside the handler to ensure consistent behavior across requests." }, { "name": "redElephant", "probabilityUpgradeNeeded": "100%", "reason": "The initialization of `fs` and `vscode` objects should occur \n inside the handler in the new runtime in order to ensure that they are \n freshly created for each request. This is critical since the new runtime \n does not rerun code outside of the handler for each request.." }, { "name": "untitled_indigoNightingale", "probabilityUpgradeNeeded": false, "reason": "The code initializes and configures the Hono app outside of the handler, but it does not appear to have any stateful logic that would need to be re-calculated with each request. Each request will call the handler provided by Hono and should behave the same in the new runtime." }, { "name": "untitled_pinkRoundworm", "probabilityUpgradeNeeded": true, "reason": "The functions `addComment` and `getComments` as well as the initialization \nof the KEY variable perform actions that are intended to be run per request. These need to be moved \ninside the relevant HTTP handler to ensure the behavior remains consistent in the new runtime." }, { "name": "untitled_harlequinIguana", "probabilityUpgradeNeeded": false, "reason": "The provided code defines the handler directly without any side effects or additional code outside the handler. The behavior should remain the same in the new runtime." }, { "name": "untitled_moccasinHeron", "probabilityUpgradeNeeded": false, "reason": "The code outside the handler is just a constant string declaration, which does not change behavior between requests. The handler itself handles requests correctly and independently." }, { "name": "untitled_maroonSwallow", "probabilityUpgradeNeeded": false, "reason": "All the code, including the check for authentication,\n is inside the handler function. This means the behavior will stay \n the same with the new runtime." }, { "name": "wikiOG", "probabilityUpgradeNeeded": true, "reason": "The function `getWikipediaInfo` defined outside of the handler makes network requests and processes data for each request. In the new runtime, this function would only be executed once and cached. To ensure the same behavior in the new runtime, this function should be moved into the handler." }, { "name": "parsePostBodyExample", "probabilityUpgradeNeeded": false, "reason": "All the code is inside the handler, so the behavior will remain consistent in the new runtime." }, { "name": "discordEventReceiver", "probabilityUpgradeNeeded": false, "reason": "All the relevant code for handling requests and logging input is inside the handler.\n No code needs to be moved for the new runtime to function correctly." } ] Feel free to fork this and try it yourself! If you could get it working, it'd be a big help for us as we upgrade the thousands of HTTP vals. Future ideas: Better LLM (Claude 3.5) Better prompt More examples JSON mode having it reply with upgraded code send pull requests to users with public vals that probably need upgrading

Forked from janpaul123/semanticSearchTurso

Forked from janpaul123/semanticSearchBlobs