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!)

> 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.

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

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

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,

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

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.

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:

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:
>

> 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