From Noah Pederson to ~sircmpwn/public-inbox
--- index.html | 1 + 1 file changed, 1 insertion(+) diff --git a/index.html b/index.html index 4da6259..21953c3 100644 --- a/index.html +++ b/index.html @@ -161,6 +161,7 @@ type Person union {Customer | Employee | TerminatedEmployee} <dd><a href="https://github.com/n8ta/bare-rb">bare-rb</a></dd> <dt>Rust</dt> <dd><a href="https://git.sr.ht/~tdeo/serde_bare">serde_bare</a></dd> <dd><a href="https://git.sr.ht/~chiefnoah/bare_proc">bare_proc</a></dd> <dt>Scheme</dt> [message trimmed]
From Noah Pederson to ~sircmpwn/public-inbox
On Wed Feb 21, 2024 at 2:15 PM CST, Jiri Vlasak wrote: > I agree with improving the draft. I am a bit scared about "adding a few > sections", though. I would like to keep BARE as simple as possible. > > Would for example adding "3.4 Invariants" be sufficient? After looking through this again, I think the ambiguity is actually in how to handle an overlapping union identifier/discriminant or enum value in a schema parser-generator. I propose we add a sentence to union and enum paragraphs in "3.3 Semantic Elements" that explicitly tells parsers how to handle cases where the discriminant/value would otherwise overlap:
From Noah Pederson to ~sircmpwn/public-inbox
On Wed Feb 21, 2024 at 2:15 PM CST, Jiri Vlasak wrote: > > I see you updated/republished the draft RFC as well, thank you! > > Yes. I also finally asked ISE for publication in independent stream [1]. Awesome! Let me know if there is anything I can do with this. > > I'm currently working on a schema parser-generator for BARE: > > > > https://git.sr.ht/~chiefnoah/bare-rs > > Nice. When ready, please, don't forget to send patch to update > baremessages.org [2], thanks.
From Noah Pederson to ~torresjrjr/public-inbox
On Sun Feb 25, 2024 at 9:22 AM CST, Byron Torres wrote: > * b931bd13 nvim: use floating window > * abfb2ca8 rewrite symbol resolution; achieve neovim compat > > Would you like to give me feedback on them using your neovim setup? That does appear to have fixed my issue in neovim! > The floating window could be resized and whatnot, but I'll probably > leave it for someone else to improve upon. It should work now. It's a bit large, but more annoying is the > [Process exited 0]
From Noah Pederson to ~torresjrjr/public-inbox
On Wed Feb 21, 2024 at 4:07 PM CST, Byron Torres wrote: > plugin/haredoc.vim Line 85 does have `endfunction`, so that's werid. Yeah, the more I look at it the more I think this is either some subtle incompatible change neovim has made to its vimscript or a bug. > If you are willing to debug this and send a patch, I'd be happy to merge > it. Otherwise, I'll try Neovim this weekend. I tested it in vim 8 and it worked fine, which confirms my hunch that it's a neovim specific bug. I'll keep digging.
From Noah Pederson to ~torresjrjr/public-inbox
There appears to be some issue with vim-haredoc on Neovim v0.9.5: Failed to source `/home/noah/.local/share/nvim/lazy/vim-haredoc/plugin/haredoc.vim` vim/_editor.lua:0: FileType Autocommands for "hare"..script nvim_exec2() called at FileType Autocommands for "hare ":0../home/noah/.local/share/nvim/lazy/vim-haredoc/plugin/haredoc.vim, line 86: Vim(function):E126: Missing :endfu nction # stacktrace: - vim/_editor.lua:0 _in_ **cmd** The Haredoc function is not particularly complicated, so I'm not sure what is actually going on. I'm happy to send over patches if we can figure it out (or maybe this is a neovim bug?).
From Noah Pederson to ~sircmpwn/hare-users
On Tue Feb 20, 2024 at 11:47 PM CST, Ember Sawady wrote: > regardless, it's not the end of the world if we aren't able to stay > under a floppy disk - worst case scenario, we just have to do the > releases on sets of two disks :) I'd say it would also be nice to ship an assembler with it so it can theoretically be installed and used on an air-gapped system. Splitting up hare, qbe, and as onto one floppy and the stdlib onto another or something would be fine with me! I was hoping to purchase the floppy edition of Hare when it became available. It's cute and also kinda funny, though I worry about the supply chain of floppy disks being a problem :)
From Noah Pederson to ~sircmpwn/public-inbox
> When I started working on BARE, I asked Drew if I can use his public > mailing list for work. He agreed and I am glad he looks over the BARE > development by just reading emails. The same goes for all the others who > contribute to BARE. I would stick with this mailing list. Sounds good. I see you updated/republished the draft RFC as well, thank you! I'm currently working on a schema parser-generator for BARE: https://git.sr.ht/~chiefnoah/bare-rs As part of that development, I've come across a few ambiguities.
From Noah Pederson to ~sircmpwn/public-inbox
On Sat Feb 3, 2024 at 3:51 PM CST, Jiri Vlasak wrote: > I am going to rewrite some formulations and send again to Independent > Submission Editor (ISE) for publication in Informational track. ISE was > my first contact in IETF and recommended to try publishing BARE in the > Standard track, but from the responses in the ART mailing list and > communication with IETF, I don't think that will happen. > > If you want to track the work, see > > https://git.sr.ht/~qeef/draft-devault-bare/ > > As always, I am sorry for being so slow.
From Noah Pederson to ~sircmpwn/public-inbox
I'm wondering if there's any desire to further the BARE draft RFC through the process of getting properly standardized. It's been awhile since I've read through the process, so I'm not sure if the existing draft can be unarchived, but I'm interested in reviving this and trying to push it through. I figured I would check in here first, especially as it might be possible to revive the existing draft. ~ngp