New bug and CR for the NFS thing (still testing) code.illumos.org/c/illumos-gate/+/4717

→ CODE REVIEW 4717: 18076 NFSv4.0 Client Receives NFS4ERR_DELEG_REVOKED (NEW) | illumos.org/issues/18076

jbk I've been putting in just "raacktop:BSR-nnnnn"

or something like that. my keyboaard eeems to be doubling keys etc.

gwr: but it seems to only accept a single value

I think that may be by design. Pick one?

If the story is complicated, I'd just put that in the issue comments

Yeah, that field is single valued

i guess i'll pick one and leave the rest in the comments

I'm having trouble reproducing that NFS v4.0 bug. If anyone wants to try out the fix I have up, go ahead.

gwr building ... as I was able to replicate issue consistently, I expect to get decent test results too.

tsoome I saw your test results in the issue. Thanks.

thanks for fix:)

Any of the EU folks want to +1 the CRs? code.illumos.org/c/illumos-gate/+/4717

→ CODE REVIEW 4717: 18076 NFSv4.0 Client Receives NFS4ERR_DELEG_REVOKED (NEW) | illumos.org/issues/18076

I still have feeling that the fact that server has to send out error is bug in our client:)

[illumos-gate] 18039 i40e TX ring freezes when given invalid MSS value -- Jason King <jason.brian.king⊙gc>

.... one of these days, I swear I'm going to rewrite opengrok in rust...

jbk: it's not really going to help

if it means not running tomcat, that alone would be worth it

is it a load on the server that would be alleviated by writing it in a language that compiles to machine code?

the memory consumption of the jvm explodes pretty easily/quickly..

ah

garbage collector stunned?

and instead of spending time trying to find the magic jvm tunables to make it behave sensibly

i mean that a stunned garbage collector could fail to collect garbage

the best solution for src.illumos.org, is to login to github/do the beta thing if necessary, and use their code search instead.

i have a local opengrok instance running on my home server

(for a few other repos as well)

since afaik they solve the problem with tree-sitter where they can (faster than opengrok, especially if it still uses ctags!!), and by having microsoft amounts of compute

so updating is sloooooow and painful..

AFAIK, opengrok does still use ctags

jbk: I gave up on opengrok in general when it became clear I needed to be able to search the gcc codebase

which opengrok can just never ingest

it's not even worth trying

and that was before dram became golddust

[illumos-gate] 18032 fssnap: address of NULL pointer 'sidp' -- Toomas Soome <tsoome⊙mc>

there are some rust crates that provide the same sort of indexes opengrok uses, so for indexing at least, it'd mostly be a matter of parsing the source (and I guess adding all the revision data if you want that, i'm skipping it)

i wonder if i should one day try to write my own codesearch engine

(i have eyes bigger than my mouth when it comes to code projects)

I wrote myself a cscope replacement, that does what you're talking about using the tree-sitter rust crates

I paid 0% attention to performance, and it's on the far end of acceptable

what is the far end of acceptable

history is something I think is important in opengrok-type uses though

LXGHTNXNG: indexing is pretty slow, search is fast unless regexps

it literally just asks tree-sitter where stuff is and mandhandles them into a database

ah

the cute thing is because it's mine and for me, I can add tacky rules finding mdoc references to functions as references to functions, etc. :)

and mapfiles

nice when emacs M-? finds the full-ish set of references

jbk: are you sufficiently good at name mangling, that you could construct a regular expression matching those functions taking `int8_t`?

jbk: I guess that's the way to learn how things look on the ABI side

i'm not sure you could do a regex.. you might be able to demangle and search for 'signed char' or 'unsigned char'

there's also `char` as a third type, because C++

that's why I was hoping we could maybe tell int8_t apart from the base type :\

the name mangling for c++ is soooo complicated...

though could also maybe make a modified libdemangle to identify

i keep meaning to redo the C++ bits to match what clang did which builds a tree basically and then generate the resulting text

which would probably be better for that...