Add extension: RubyFS #2338
Add extension: RubyFS #2338
Conversation
(extensions.json wasn't updated yet)
github-actions
bot
added
the
pr: new extension
|
Wow, thanks to the three failed checks that made me look like a terrible GitHub user... Working on that now. |
|
"thoroughly reviewed the code" I say, as three of my checks fail immediately... |
|
Issues fixed! |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
My apologies, one of the checks (I'm pretty sure) failed for one reason, which was because TL;DR, I'll remove the Half of me expected to be sworn into Hell for writing an extension with an LLM, but maybe TurboWarp extension developers are nicer than I perceived. |
That perception was probably my fault, sorry. |
Just saw this lol... If you actually mean this, I can kiss goodbye to LiFS in the TurboWarp Extension Gallery, because as I said, this extension is almost completely LLM-generated. Although, I can't say I didn't expect this. |
I do, but I was a bit harsh. @Brackets-Coder is pretty kind, maybe they can overrule me here? |
|
While I'm not opposed to the constructive and supportive use of AI in a developer's workflow, I don't think Turbowarp as a whole accepts extensions generated entirely with AI, mostly because large projects generate with AI deteriorate in quality and functionality. If this extension still proves functional and has no glaring issues, then I'm not opposed to merging it (unless there's a serious licensing problem I'm not aware of), but then again we don't like extensions generated entirely with AI. |
I am yet to develop an entire project with LiFS (however I might with an expansion of one my of in-development Scratch games), but from my testing, every block works, and stress testing completed successfully. You can even turn on console logging if some blocks don't work. I don't really find an issue with LLMs creating extensions, but your claim on projects developed by AI deteriorating is valid, and has happened to me before -- but not with LiFS. Sorry if I sound stupid right now (I probably am). |
|
Your thumbnail's pretty awesome! |
Thank you! I made it in Canva. |
NOTE: This breaks the banner! I'll rename the banner next, shouldn't take me a long time.
Hopefully this one works(?)
We all have to start from somewhere; I made several failed PRs (#1492, #1495 and #1995 were some of the worst) before I could get anything merged. |
Read the first PR and a Fetch+ extension with a built-in CORS proxy would be pretty nice. |
|
Hi @Brackets-Coder @PPPDUD — quick ping: all checks pass and I’ve audited/fixed the earlier issues. I manually tested all core blocks (create/open/list/copy/delete, import/export) and ran the built-in integrity test (PASS). I used LLMs to assist testing/debugging but I personally reviewed the code, and everything seems to work. Could you re-check and approve if everything looks OK, or let me know any remaining changes? Thanks! |
|
What in the world does "consolidated version" mean and how is it relevant for new users reading the description? |
These were leftovers from previous versions. A few versions back, all RubyFS blocks were consolidated to drop the block count. It has since been removed. There is no non-consolidated version available for RubyFS. |
I see now, thanks. |
|
I hate to restart projects completely, but RubyFS will either have a performance overhaul or I will remake the engine to cut all ties with rxFS. Why do I want to cut ties with rxFS?I feel like my current method of coding RubyFS makes it ten times slower than it should be. I guarantee there's some secret in JS that will make RubyFS run a lot faster, but a rework is likely required. I have a 'habit' of restarting or stopping projects if they're not optimized enough or I feel like I can't maintain it well in its current state (which it's the latter for RubyFS). What might happen to RubyFS?Currently, RubyFS is on the road to a full rebrand and versioning change to be annually released with checkpoints (so I don't need to make PRs every single time I update RubyFS, instead I can do it every three to six months via checkpoints), and since there's already 30 commits on this PR, I might as well either rebase it to be exactly the same as upstream and remove all commits, or remake the PR. I want to rebrand RubyFS because I think some users might get confused and think RubyFS is associated with the Ruby programming language. Safe to say, you probably shouldn't review right now, no sense in doing that until the rework is done... let's hope that brings the filesize down too. Over 1,000 lines is a little bit overkill for a Scratch extension, don't you think? |
I am going to be very frank with you here. You're overthinking this. You've rebranded two times, you've drafted and undrafted over and over again, you've created a pre-planned release schedule, and apparently you wrote way too much code. It's one tiny component that might or might not get merged into TurboWarp, and it's not going to be the end of the world if you flop at this. Nobody's going to look down on you just because you got rejected. |
I feel as if I need to constantly improve RubyFS. I know there has to be some kind of way to speed it up, and since I'm developing an actual project that relies on RubyFS, I need to make sure it's the best so not only me but others can rely on it too. I already have the speed overhaul done, and I might add more features. I initially rebranded LithiumFS/LiFS because it was named from the extension being lightweight. RubyFS is no longer lightweight (especially if we're talking about file size), and I'm rebranding RubyFS because somebody's going to think it's associated with Ruby. I designed the new versioning system with checkpoints in able to 'counter' myself from opening too many PRs and pestering the TW maintainers every single RubyFS update. i don't think I'm going to completely remake RubyFS, because rxFS was a good template to start with and I feel it'll take too much of my time to reinvent the wheel. I feel as if I need to make RubyFS the 'Apple' of TurboWarp extensions. There's always going to be something wrong with this extension because it's vibe-coded, and I'm trying to fix every one of them... but that resulted in 40 commmits in this PR. I feel like I'm being too sloppy when I don't even know how PRs fully work yet. I won't be pushing any more commits (and I might fully rebase the fork to remove all previous commits for brevity) until I have everything sorted out. i don't want to pester you guys with the same AI slop over and over and over again. |
You are not being too sloppy. You are not pestering us. And your first extension will not be some dazzling success. Awesome products come from throwing lots of stuff at a wall and seeing what sticks. If you concentrate on a single unproven concept, there's a very large chance that your work will go to waste. Try stuff. Explore. Learn new languages. Copy something and make it faster. If you fail, there's still a thousand more ideas to test. |
RubyFS might soon be cancelled or deprecatedAs more and more features are drafted for RubyFS, it starts to break that rule in the Extensions Gallery of "just one utility. RubyFS started as a lightweight file system extension like rxFS, and ended up as a full POSIX FS simulator with permissions, file tagging, metadata, RAM, and more features than you can count. I know of people who could actually use this (one being me), and if a basic user like me wants a utility like this, there's bound to be a lot more; however, RubyFS is turning into a broader utility extension the more I develop it. God, I need to focus on my grammar. What's going to happen to RubyFS?One of these five things might happen to RubyFS:
As I lose confidence and the motivation to continue maintaining RubyFS, it's continuously shifting to the third option, especially with the community of TurboWarp and Scratch mods in general, where people hate on some vibe coders without knowing why they're vibe coding in the first place. As commits increase and waits get longer, my chances here are slowly draining, and RubyFS was bound to be closed in the first place. But I didn't post this to be a sob story, so I won't talk about it here. I've previously drafted a system to show and hide advanced blocks that'd be consistent with the project, but that required injecting a variable directly into the Stage sprite, which is against policy. Or maybe there's some kind of super-easy shortcut that dismisses this post entirely. Since there was just a What's peculiar is that RubyFS was soon going to get some kind of access control system. I realized that's where I should probably cross the line at "general utility". At its current status, RubyFS is extremely likely to be cancelled. I guess there will never be an rxFS killer. |
You made it POSIX-like? That's actually pretty impressive.
Have you ever considered that the LLM might be trying to maximize engagement? ChatGPT wastes my time constantly and makes stuff up, probably so that I'll pay for their ChatGPT Plus service (I don't).
If you're talking about me, I was just feeling like being mean that day. Please don't take it personally.
Unfortunately, I don't think that there's an API for that.
ACL would be kind of interesting, actually. |
I feel like it's more Unix-like than POSIX-like, but at this point, it can be whatever it wants to be. I realized that most of the main features (RAMdisk, file tagging, metadata, etc.) could just be done with only file CRUD operations (immaturity coming in hot).
I've been waiting for somebody to figure that out. I've experienced the same issue, but this one isn't nearly as obvious. I know Gemini doesn't do it because they helped me create a working extension with two prompts, and that's a modification of the Dictionaries extension (fun fact: once I finished this PR, I planned to create one for that extension too). Gemini is my primary model for that reason, but on longer chats (which is how RubyFS was made), it starts to deteriorate. I've kept it in check for a while, but it just went liquid-brain mode for this specific update.
No, it's not you. I have pages of Discord chats on official Scratch mod servers where people are just blindly insulting me for using AI to code an extension for me. They don't know the context of why I'm coding it with AI and not writing it myself, I guess they start to see red when they see "AI" and "extensions" in the same sentence.
I saw SharkPool's text engine extension had it in some kind, and I thought, "Hey, one more reason RubyFS could (possibly) be merged! Let me try that!"... little did I know I was breaking another rule trying to code that rule fix in.
It would deny writing to directories like |
|
I know what I want to do with RubyFS now. RubyFS will be completely remade and named 'CobaltVDisk'. Most of the features that can be replicated with plain file CRUD operations will be removed in CobaltVDisk. This PR will be closed, and a new one will be made as a draft (because I'm still coding for it). My motivation to continue is back. CobaltVDisk will start out as rxFS, but before the first commit is added, its structure will be significantly changed for performance enhancements to cut ties with rxFS on release. Everything that I thought I could do better with RubyFS will be done with CobaltVDisk. CobaltVDisk's versioning schemeEvery CobaltVDisk version will be released every three months as a cumulative update, also known as a Checkpoint. If a CobaltVDisk update were to be pushed now, its version would be CobaltVDisk, version 25H2.1 or CobaltVDisk, version 25H2 (Checkpoint 1). This resolves the issue of "one PR every RubyFS update" because when the PR is marked ready for review, all bugs will have been fixed. Any new features will be added per Checkpoint. |
No, see Simple3D, Augmented Reality, and my flagship extension PRs (such as #1974). Even four thousand lines is perfectly reasonable if it gets the job done well. Also, you seem to be struggling with the problem of development "burn-out" and high expectations for yourself. I've been there too. You need to be easier on yourself because development is hard, and unfortunately life only gets harder the longer you live. While I didn't want this to turn into a lecture on motivation, I do think when attempting to tackle a large project like this you should try to do one part at a time. Plan out tiny milestones and focus on only one milestone at a time. If necessary, take breaks up to several months to clear your head and get a fresh perspective. Even with all of that, I find that a useful piece of wisdom to apply to projects like this is knowing when to call it quits and say "it's good enough," because the truth is (and I don't know if you've discovered this yet), is that it will never be perfect, so you have to finish and publish when it's "good enough." If you persevere, you will learn so many things from this experience that you can carry into every area of life and that's when I personally think programming is the most fun. |
I'll execute these strategies on CobaltVDisk. Most of the RubyFS features could be executed the same, with just more files created by the developer of the project who used the extension, especially the RAM Disk. CobaltVDisk features will be something you can not use files reliably to replicate, and will be used conservatively to keep the file size down. I'm trying to bring down features like these because RubyFS as-is would break the rule of "one general utility only". RubyFS is more of a "Unix storage simulator" than a filesystem extension, especially because it has RAM. You could just code in RAM in the Scratch project itself. I try to keep high expectations for myself because I don't just want RubyFS to be the everyday "AI slop". I push my models to develop a better extension -- it at least needs to be better than rxFS. If RubyFS is going to be AI slop, it needs to be the finest AI slop you've ever read, full stop. |
|
I think you can move your discussion of ai slop to somewhere else |
5 participants
New Extension: RubyFS (
rubyFS)This PR introduces RubyFS, an unsandboxed extension that provides a robust, in-memory filesystem environment for TurboWarp projects.
RubyFS is an advancement of the original rxFS concept, designed to give creators more control and security within their virtual file structures.
Key features
The following features distinguish RubyFS from the existing
0832/rxFS2extension, justifying its inclusion as a separate extension rather than a modification:Technical compliance
MIT) and is GPLv3-compatible.Scratch.translateused to exist prior to this PR's creation, but is no longer included here because it caused a required check to fail.Note on this code's origin
Almost the entirety this extension were developed with the assistance of an AI programming tool. I have thoroughly reviewed the code, performed extensive testing, and verified that it meets the required safety and functionality standards before submitting this PR. I used to have a tester program, but I suck at resource management and I reset my PC without backing it up.