Language Server Protocol really would need a competitor with a #plugin based architecture.

Then editor and analyzer could have:

1. A better memory and caching strategy.
2. Both faster performance and lower operation latency.

#LSP is IMHO is exactly like the worst ideas of lrzsz modified to work as a language analyzer.

#telescope is awesome with the #kernel tree #neovim

@fale @cgwalters how does bootc align with e.g. https://lwn.net/Articles/644675/ ? just interested...

The work on #bootc Is coming along very nice! This morning keynote by @cgwalters, Dan Walsh, and Stef Walter was very nice to see the current state of it in #Fedora and CentOS Stream. #devconf_cz

Was trivial to workaround though:

sudo dnf downgrade neovim
sudo dnf install 'dnf-command(versionlock)'
sudo dnf versionlock add neovim

Now:

❯ nvim --version | head -1
NVIM v0.9.5

No issues with 0.9.5 and no rush upgrade to 0.10.0, so all good as far as I’m concerned.

#neovim in #fedora 40 does this when opening a #lua file:

Error detected while processing BufReadPost Autocommands for "*":
Error executing lua callback: /usr/share/nvim/runtime/filetype.lua:35: Error executing lua: /usr/share/nvim/runtime/filetype.lua:36:
 BufReadPost Autocommands for "*"..FileType Autocommands for "*"..function <SNR>1_LoadFTPlugin[20]..script /usr/share/nvim/runtime/f
tplugin/lua.lua: Vim(runtime):E5113: Error while calling lua chunk: /usr/share/nvim/runtime/lua/vim/treesitter/language.lua:107: no
parser for 'lua' language, see :help treesitter-parsers
stack traceback:
        [C]: in function 'error'
        /usr/share/nvim/runtime/lua/vim/treesitter/language.lua:107: in function 'add'
        /usr/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:111: in function 'new'
        /usr/share/nvim/runtime/lua/vim/treesitter.lua:41: in function '_create_parser'
        /usr/share/nvim/runtime/lua/vim/treesitter.lua:108: in function 'get_parser'
        /usr/share/nvim/runtime/lua/vim/treesitter.lua:416: in function 'start'
        /usr/share/nvim/runtime/ftplugin/lua.lua:2: in main chunk
        [C]: in function 'nvim_cmd'
        /usr/share/nvim/runtime/filetype.lua:36: in function </usr/share/nvim/runtime/filetype.lua:35>
        [C]: in function 'nvim_buf_call'
        /usr/share/nvim/runtime/filetype.lua:35: in function </usr/share/nvim/runtime/filetype.lua:10>
stack traceback:
        [C]: in function 'nvim_cmd'
        /usr/share/nvim/runtime/filetype.lua:36: in function </usr/share/nvim/runtime/filetype.lua:35>
        [C]: in function 'nvim_buf_call'
        /usr/share/nvim/runtime/filetype.lua:35: in function </usr/share/nvim/runtime/filetype.lua:10>
stack traceback:
        [C]: in function 'nvim_buf_call'
        /usr/share/nvim/runtime/filetype.lua:35: in function </usr/share/nvim/runtime/filetype.lua:10>
Press ENTER or type command to continue

@epage ok, thanks, i'll check it out!

@alilleybrinker ok it was *that* idiomatic :-O thanks!

I sorted this out for the moment that changed the dependency to the form expected by cargo publish: https://crates.io/crates/tpm2_cli

So, main goal for 0.1.2 is to fix this glitch ;-)

When cargo publish -p tpm2_cli , I need to

tpm2_call = "0.1.1"

… while building locally:

tpm2_call = { path = "../tpm2_call" }

How to sort this out in “idiomatic manner”?

#rust #rustlang

There should be TryFrom equivalent for Option tho. In this example not having that adds only extra complexity… Like MaybeFrom ?

For this type of rigid decoding Rust’s type system is pretty efficient:

pub struct ReturnCodeError;    
    
impl TryFrom<u16> for ReturnCode {    
    type Error = ReturnCodeError;    
    
    fn try_from(value: u16) -> Result<Self, Self::Error> {    
        Self::from_repr(if value & RC_FMT1 != 0 {    
            value & (0x3F + RC_FMT1)    
        } else if value & RC_WARN != 0 {    
            value & (0x7F + RC_WARN)    
        } else if value & RC_VER1 != 0 {    
            value & (0x7F + RC_VER1)    
        } else {    
            // RC_VER0    
            value & 0x7F    
        })    
        .ok_or(ReturnCodeError)    
    }    
}    

A crate for #TPM 2.0 library protocol, or beginnings of it: https://gitlab.com/jarkkojs/tpm2_library/

Sub-crates:

1. tpm2_call for TPM 2.0 library protocol shenanigans.
2. tpm2_cli for a command-line interfaces.

Development process:

• https://www.conventionalcommits.org/en/v1.0.0/
• https://semver.org/
• Signed-off-by’s.

I aim to do cli first as Linux tied but it could also have e.g. Windows backend. tpm2_call will be portable between operating systems.

#TPM2 #Rust #rustlang

Not really a real project. I've been ad-hoc scripting with #python since 2005, and wanted to learn how to "devops" a properly pipeline at #gitlab, with a release ending to the #pypi: https://pypi.org/project/eth0/

PS. I deleted 0.1.0 tag and release from pypi, because the tag was not signed ;-) you could never trust it...

So for my TPM2 crate I was thinking to rename the project Git as tpm2_library and have sub-crates tpm2_call for protoco and tpm2_cli with a sub-command tpm2cli rc.

Is it acceptable to name for consistency sake the sub-crate directory as tpm2_cli but generate an executable as tpm2cli?

Root project’s name inherits from https://trustedcomputinggroup.org/resource/tpm-library-specification/

#Rust #rustlang #TPM2

I initiated my own #TPM2 #Rust crate partly because the output given by tpm2_rc_decode does not give back the mnemonic of a return code.

Here’s the example from its man page:

tpm2_rc_decode 0x1d5
tpm:parameter(1):structure is the wrong size

So I wrote my return code decoder, and here’s how it works with the previous example:

target/debug/examples/tpm2rc 0x1d5
TPM_RC_SIZE

The Git-repository is available here: https://gitlab.com/jarkkojs/tpm2_call

I’m not going to add any code this crate dealing with /dev/tpm0. Instead the plan is to implement command buffer builder and parser with similar high-level ideas as I’ve done in the #Linux #kernel.

#rustlang

📣 Only 2 days (today and tomorrow) left to get your talk proposals in for the All Systems Go! 2024 CFP.
The clock ⏲️ is ticking!
🏃‍♂️ Hurry over to get yours in: https://cfp.all-systems-go.io/all-systems-go-2024/cfp

@protman @rnbastos For instance: for one X-series ThinkPad acquired from work few years ago, Lenovo's onsite repair guy had to visit me three times during a two year period, just to switch the keyboard.

We became familiar enough that I still greet him, if I run into him on the street ;-)

@protman @rnbastos With more recent ThinkPad's, after IBM sold laptop manufacturing to Lenovo, the build quality has been steadily decreasing.

I've never used auto-complete (be it with or without AI) and I hit keyboard hard so with modern ThinkPads, usually in a year or less, I start accidentally pull keys out of the keyboard when typing.

With Mac's laptop keyboards this has not happened but they have problems of their own, mainly keys getting stuck all the time into pressed position.

I guess I'm too rough and violent for modern laptop keyboards 🤷

1. Forking in traditional open source community is a strongly considered act. I think the current "fork even your grand mother" trend inherits from many new Rust developer previously being Web/JavaScript developers.
2. Forking is not engineering. Engineering is innovating within constraints. For instance, Firefox has some of the code re-engineered in Rust. Bringing Rust to an existing open source project is difficult and tedious task, and also hard to rationalize to the existing community, but that is what Engineers do. It is an engineering problem by definition.