Re: Welcome Luca Cavanna to the Lucene PMC
Congratulations, Luca! On Sun, Oct 22, 2023 at 5:08 PM Anshum Gupta wrote: > Congratulations and welcome, Luca! > > On Thu, Oct 19, 2023 at 10:51 PM Adrien Grand wrote: > >> I'm pleased to announce that Luca Cavanna has accepted an invitation to >> join the Lucene PMC! >> >> Congratulations Luca, and welcome aboard! >> >> -- >> Adrien >> > > > -- > Anshum Gupta >
Re: Welcome Luca Cavanna to the Lucene PMC
Congratulations and welcome, Luca! On Thu, Oct 19, 2023 at 10:51 PM Adrien Grand wrote: > I'm pleased to announce that Luca Cavanna has accepted an invitation to > join the Lucene PMC! > > Congratulations Luca, and welcome aboard! > > -- > Adrien > -- Anshum Gupta
Re: Welcome Luca Cavanna to the Lucene PMC
Welcome Luca! Mike On Sun, Oct 22, 2023 at 4:34 PM Tomás Fernández Löbbe wrote: > Congratulations Luca! > > On Sun, Oct 22, 2023 at 10:51 AM Michael Sokolov > wrote: > >> Congratulations and welcome, Luca! >> >> On Sun, Oct 22, 2023 at 1:42 PM Julie Tibshirani >> wrote: >> > >> > Congratulations Luca!! >> > >> > On Fri, Oct 20, 2023 at 1:45 AM Bruno Roustant < >> bruno.roust...@gmail.com> wrote: >> >> >> >> Welcome, congratulations! >> >> >> >> Le ven. 20 oct. 2023 à 10:02, Dawid Weiss a >> écrit : >> >>> >> >>> >> >>> Congratulations, Luca! >> >>> >> >>> On Fri, Oct 20, 2023 at 7:51 AM Adrien Grand >> wrote: >> >> I'm pleased to announce that Luca Cavanna has accepted an invitation >> to join the Lucene PMC! >> >> Congratulations Luca, and welcome aboard! >> >> -- >> Adrien >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: Code longevity statistics
IMO another factor is leaving stuff around because it takes effort to remove old things, effort that isn't fun like making claims to remove something that someone else may still like/use, and soliciting users "hey, is XYZ used?". No fun. Lucene has several roughly equivalent ways to do the same thing (like in highlighting). ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Sep 27, 2023 at 1:35 PM Stefan Vodita wrote: > Hi all, > > I came across an interesting article [1] on patterns of code evolution. I > got > curious, ran their analysis on the Lucene repo, and produced a breakdown of > lines of code per year and the chance of a line of code still existing > after > 5 years (see attached images). > > I think the big drop in the first plot corresponds to Solr moving to its > own > project. Not sure about the other jumps - maybe someone else has insight > there. > The second plot shows that there is relatively little churn in Lucene; 45% > of > the code written 5 years ago is still around. For many modern projects, > this > curve is a steeper exponential. In Lucene, it's closer to linear. The > article > argues that this could point to better design and more modularity, which > makes > it so code isn't rewritten much. > > Just a fun thing to share! > > Stefan > > [1] https://erikbern.com/2016/12/05/the-half-life-of-code.html > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Luca Cavanna to the Lucene PMC
Congratulations Luca! On Sun, Oct 22, 2023 at 10:51 AM Michael Sokolov wrote: > Congratulations and welcome, Luca! > > On Sun, Oct 22, 2023 at 1:42 PM Julie Tibshirani > wrote: > > > > Congratulations Luca!! > > > > On Fri, Oct 20, 2023 at 1:45 AM Bruno Roustant > wrote: > >> > >> Welcome, congratulations! > >> > >> Le ven. 20 oct. 2023 à 10:02, Dawid Weiss a > écrit : > >>> > >>> > >>> Congratulations, Luca! > >>> > >>> On Fri, Oct 20, 2023 at 7:51 AM Adrien Grand > wrote: > > I'm pleased to announce that Luca Cavanna has accepted an invitation > to join the Lucene PMC! > > Congratulations Luca, and welcome aboard! > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Welcome Luca Cavanna to the Lucene PMC
Congratulations and welcome, Luca! On Sun, Oct 22, 2023 at 1:42 PM Julie Tibshirani wrote: > > Congratulations Luca!! > > On Fri, Oct 20, 2023 at 1:45 AM Bruno Roustant > wrote: >> >> Welcome, congratulations! >> >> Le ven. 20 oct. 2023 à 10:02, Dawid Weiss a écrit : >>> >>> >>> Congratulations, Luca! >>> >>> On Fri, Oct 20, 2023 at 7:51 AM Adrien Grand wrote: I'm pleased to announce that Luca Cavanna has accepted an invitation to join the Lucene PMC! Congratulations Luca, and welcome aboard! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Luca Cavanna to the Lucene PMC
Congratulations Luca!! On Fri, Oct 20, 2023 at 1:45 AM Bruno Roustant wrote: > Welcome, congratulations! > > Le ven. 20 oct. 2023 à 10:02, Dawid Weiss a > écrit : > >> >> Congratulations, Luca! >> >> On Fri, Oct 20, 2023 at 7:51 AM Adrien Grand wrote: >> >>> I'm pleased to announce that Luca Cavanna has accepted an invitation to >>> join the Lucene PMC! >>> >>> Congratulations Luca, and welcome aboard! >>> >>> -- >>> Adrien >>> >>
Re: ByteBufferIndexInput.alreadyClosed creates an exception that doesn't track its cause
If the buffers are nonnull and the guard state is sane, it would have thrown the exception, like on incomplete views. If buffers or guard is invalidated, the indexinput was closed. The state of curFloatBufferViews would then not matter. Anyways: Indexinput is not allowed to be used by multiple threads, so it's a bug in your code. The code has state (position to read) and it is documented to be not thread safe. Uwe Am 22. Oktober 2023 14:37:06 MESZ schrieb Michael Sokolov : >Thanks, Uwe. The underlying exception in my situation was caused by >curFloatBufferViews being allocated and used before it was fully >populated. So I think it was an NPE, yes. I'll check your PR to see if >it would have hidden this? > >On Sun, Oct 22, 2023 at 4:57 AM Uwe Schindler wrote: >> >> Please read my other comments and the PR. The PR filters the cause of >> the NPE, if the NPE is caused by inernals of MMapDirectory it won't be >> exposed to anybody. >> >> If you use it in multiple threads and acidentally close one of the >> indexinputs, AlreadyClosedException is the only correct exception. Any >> cause like an internal signalling NPE is not useful and helps nothing. >> The PR explains this, so we won't add the NPE as cause. If the NPE is >> coming from outside MMapDircetory, it will be rethrown so you see it. >> >> I will merge the PR in a moment. >> >> Uwe >> >> Am 22.10.2023 um 01:37 schrieb Michael Sokolov: >> > Thanks for digging into this. I do think it will be helpful for >> > developers that blithely access the IndexInput from multiple threads >> > :) >> > >> > On Sat, Oct 21, 2023 at 3:53 PM Chris Hostetter >> > wrote: >> >> >> >> Uwe: In your PR, you should add these details to the javadocs of >> >> ByteBufferIndexInput.alreadyClosed(), so future code spelunkers understand >> >> the choice being made here is intentional :) >> >> >> >> : please don't add the NPE here as cause (except for debugging). The NPE >> >> is only >> >> : catched to NOT add extra checks in the highly performance sensitive >> >> code. >> >> : Actually the NPE is catched to detect the case where the bytebuffer was >> >> : already unset to trigger the already closed. The code uses setting the >> >> buffers >> >> : to NULL to signal cause, but it does NOT add a NULL check everywhere. >> >> This >> >> : allows Hotspot to compile this code without any bounds checks and >> >> signal the >> >> : AlreadyClosedException only when a NPE happens. Adding the NPE as cause >> >> would >> >> >> >> >> >> >> >> -Hoss >> >> http://www.lucidworks.com/ >> >> >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> -- >> Uwe Schindler >> Achterdiek 19, D-28357 Bremen >> https://www.thetaphi.de >> eMail: u...@thetaphi.de >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > >- >To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >For additional commands, e-mail: dev-h...@lucene.apache.org > -- Uwe Schindler Achterdiek 19, 28357 Bremen https://www.thetaphi.de
Re: ByteBufferIndexInput.alreadyClosed creates an exception that doesn't track its cause
Thanks, Uwe. The underlying exception in my situation was caused by curFloatBufferViews being allocated and used before it was fully populated. So I think it was an NPE, yes. I'll check your PR to see if it would have hidden this? On Sun, Oct 22, 2023 at 4:57 AM Uwe Schindler wrote: > > Please read my other comments and the PR. The PR filters the cause of > the NPE, if the NPE is caused by inernals of MMapDirectory it won't be > exposed to anybody. > > If you use it in multiple threads and acidentally close one of the > indexinputs, AlreadyClosedException is the only correct exception. Any > cause like an internal signalling NPE is not useful and helps nothing. > The PR explains this, so we won't add the NPE as cause. If the NPE is > coming from outside MMapDircetory, it will be rethrown so you see it. > > I will merge the PR in a moment. > > Uwe > > Am 22.10.2023 um 01:37 schrieb Michael Sokolov: > > Thanks for digging into this. I do think it will be helpful for > > developers that blithely access the IndexInput from multiple threads > > :) > > > > On Sat, Oct 21, 2023 at 3:53 PM Chris Hostetter > > wrote: > >> > >> Uwe: In your PR, you should add these details to the javadocs of > >> ByteBufferIndexInput.alreadyClosed(), so future code spelunkers understand > >> the choice being made here is intentional :) > >> > >> : please don't add the NPE here as cause (except for debugging). The NPE > >> is only > >> : catched to NOT add extra checks in the highly performance sensitive code. > >> : Actually the NPE is catched to detect the case where the bytebuffer was > >> : already unset to trigger the already closed. The code uses setting the > >> buffers > >> : to NULL to signal cause, but it does NOT add a NULL check everywhere. > >> This > >> : allows Hotspot to compile this code without any bounds checks and signal > >> the > >> : AlreadyClosedException only when a NPE happens. Adding the NPE as cause > >> would > >> > >> > >> > >> -Hoss > >> http://www.lucidworks.com/ > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > -- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: u...@thetaphi.de > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: ByteBufferIndexInput.alreadyClosed creates an exception that doesn't track its cause
Please read my other comments and the PR. The PR filters the cause of the NPE, if the NPE is caused by inernals of MMapDirectory it won't be exposed to anybody. If you use it in multiple threads and acidentally close one of the indexinputs, AlreadyClosedException is the only correct exception. Any cause like an internal signalling NPE is not useful and helps nothing. The PR explains this, so we won't add the NPE as cause. If the NPE is coming from outside MMapDircetory, it will be rethrown so you see it. I will merge the PR in a moment. Uwe Am 22.10.2023 um 01:37 schrieb Michael Sokolov: Thanks for digging into this. I do think it will be helpful for developers that blithely access the IndexInput from multiple threads :) On Sat, Oct 21, 2023 at 3:53 PM Chris Hostetter wrote: Uwe: In your PR, you should add these details to the javadocs of ByteBufferIndexInput.alreadyClosed(), so future code spelunkers understand the choice being made here is intentional :) : please don't add the NPE here as cause (except for debugging). The NPE is only : catched to NOT add extra checks in the highly performance sensitive code. : Actually the NPE is catched to detect the case where the bytebuffer was : already unset to trigger the already closed. The code uses setting the buffers : to NULL to signal cause, but it does NOT add a NULL check everywhere. This : allows Hotspot to compile this code without any bounds checks and signal the : AlreadyClosedException only when a NPE happens. Adding the NPE as cause would -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: ByteBufferIndexInput.alreadyClosed creates an exception that doesn't track its cause
Hi, I added long comment in the PR for all variants of that code (there are actually 4 variants because we have 4 implementations). Uwe Am 21.10.2023 um 21:53 schrieb Chris Hostetter: Uwe: In your PR, you should add these details to the javadocs of ByteBufferIndexInput.alreadyClosed(), so future code spelunkers understand the choice being made here is intentional :) : please don't add the NPE here as cause (except for debugging). The NPE is only : catched to NOT add extra checks in the highly performance sensitive code. : Actually the NPE is catched to detect the case where the bytebuffer was : already unset to trigger the already closed. The code uses setting the buffers : to NULL to signal cause, but it does NOT add a NULL check everywhere. This : allows Hotspot to compile this code without any bounds checks and signal the : AlreadyClosedException only when a NPE happens. Adding the NPE as cause would -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
