From Rett Berg to ~vdupras/duskos-discuss
sounds good, thanks On Wed, Apr 9, 2025 at 9:47 AM Virgil Dupras <hsoft@hardcoded.net> wrote: > > On Wed, 9 Apr 2025 09:29:09 -0600 > Rett Berg <googberg@gmail.com> wrote: > > So one danger is that you might "float" a whole bunch of stack values, > > which could cause future operations to behave differently than they > > would have (i.e. if they would have caused a stack underflow they now > > don't). > > > > I wonder if a more explicit "run this then print+clear remaining > > stack" could be added to more explicitly support this and avoid that > > particular pitfall (plus it makes it more interactive!)
From Rett Berg to ~vdupras/duskos-discuss
> In general, Forth is "dangerous". That being said, careful design can minimize those dangers. It's just that in Forth, those measures will generally be on a case by case basis rather than say "here! I have this global system forever making my Forth SAFE!" So - yes it's dangerous, but a sufficiently knowledgeable individual can minimize those dangers. That's what I thought, thanks. > it doesn't matter because you only need to call "ged" again and your editor will be exactly as it was, same buffers, same position. Whoa, that's surprisingly awesome > If there's a leak, the handler loop will continue working on top of it.
From Rett Berg to ~vdupras/duskos-discuss
Running forth code, which can modify its own environment, interactively. This community likes to live dangerously :D I'm curious -- if you fail to balance the stack can just that cause problems? I assume a host of other issues (including memory corruption and system crashes) can be caused by fat-fingering something, or is this safer than I'm assuming? - Rett On Wed, Apr 9, 2025 at 8:41 AM Virgil Dupras <hsoft@hardcoded.net> wrote: > > On Wed, 9 Apr 2025 07:30:22 -0700
From Rett Berg to ~vdupras/duskos-discuss
Nice, looks like it's working with a few bumps? I'll try and make the
init experience better soon -- I think having a basic .pvcignore
template with a few items is probably a good idea.
> And on that note, the other thread was talking about problems committing
zero-sized files. Why not just have every file listed in .pvcpaths but
without a diff be a zero-sized file?
That is a possible future solution. For now I'm avoiding complexity
and it's probably not really necessary (who really _needs_ a
zero-sized file?)
- Rett
From Rett Berg to ~vdupras/duskos-discuss
Hey Aaron, thanks for trying it out. The installation instructions are at https://lua.civboot.org#Installation. A few problems I saw: * you need "export LUA_PKGS=...." [1] * I think your make needs to specify LUA_VERSION=lua5.4 There isn't a "worked example" as of yet, though adding something like that directly into civboot for testing would be a very good idea. Until then, the sub-commands are documented at https://lua.civboot.org#Package_pvc Let me know if there's anything else I can help with and please feel free to let me know how it goes regardless,
From Rett Berg to ~vdupras/duskos-discuss
Okay, I just pushed an improvement and a **breaking change** to pvc. Breaking change: when you pull the new version you must manually rename the .pvc/branch/patch/ directories inside your branches to .pvc/branch/commit/ Why: These directories already contain more than patches: they also contain the snapshots. The fact that commits are represented as a patch file is already well stated since the file extension is .p. This change will improve the verbiage in the docs when one references a "commit" -- the "commit" refers to an indexed number in commit/, either a .p file or .snap/ directory (which can be created with patch files). The improvement: squash with no arguments is a simplified amend: it
From Rett Berg to ~vdupras/duskos-discuss
Hey Virgil, I've been playing with a few of my own workflows and just want you to know that I think squash has some bugs. One of my main workflows (amending/squashing the local commits to the tip) is not currently supported, so I'm working on fixing that and found several bugs. Also, I'm trying to think how I want pvc to handle things like inserting commits or re-ordering them, as that is sometimes something I want to do on development branches. I think it might be supported by a few core operations, but I need to think over the options. So ya, PSA don't use squash yet and amend is coming soon.
From Rett Berg to ~vdupras/duskos-discuss
Thanks, I've updated[1] the error message to be [path] is empty, which pvc does not support. Solution: Add a newline (or any other content) to the file, or delete the file.]]) I'll push to main relatively shortly. I'll also update the docs regarding pvc's limitations. - Rett [1]: https://github.com/vitiral/civlua.pvc/blob/main/color/patch/00/26.p On Sat, Apr 5, 2025 at 12:39 PM Virgil Dupras <hsoft@hardcoded.net> wrote:
From Rett Berg to ~vdupras/duskos-discuss
Thanks Virgil. Thanks for working through the limitations and possible bugs. I want to make sure you've seen this: https://lua.civboot.org#pvc-git It's my workflow with git+pvc and seems to work well. For your empty files could you just put a comment and/or newline in the file? I'm curious which files you have that need to be empty and why. There is at least one solution (missing files in .pvcpaths simply get created), but I'd still prefer to keep complexity out if possible. - Rett On Sat, Apr 5, 2025 at 11:08 AM Virgil Dupras <hsoft@hardcoded.net> wrote: >
From Rett Berg to ~vdupras/duskos-discuss
> Yes, syntax highlighting in Forth is fundamentally problematic, but with a few simple rules, it's going to work most of the time. I'm very curious if you could express these simple rules -- I'd love to hear them, especially with your breadth of experience crafting forth into a honed tool. I have trouble wrapping my head around how else you might attack this problem. I understand that you don't personally use syntax highlighting, but would you be interested in _some_ standardized solution that encodes forth syntax highlighting in Dusk? > because this OS' console isn't, most of the time, constrained by a puny serial line. All this "vt100" and "asciicolor" logic you have in civlua