Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
What solved the indexing problem of dxr on Lanedo ?
1 view
Skip to first unread message
Jean-Marc Desperrier
Feb 1, 2012, 1:58:48 PM2/1/12
to
Hi,
At the end of last year, there was some indexing problems on the dxr on
Lanedo. After checking again after Taras's last blog entry, I see now it
seems to work much better :
http://dxr2.lanedo.com/search.cgi?tree=mozilla-central&string=GfxContext
http://dxr.mozilla.org/mozilla/search.cgi?tree=mozilla-central&string=GfxContext
What solved it exactly ? Christian Dywan did refer to it being broken
because of the use of the latest llvm and clang, but Ehsan replied it
was working correctly with clang 3.0.
So it's not very clear which version should be avoided.
Another thing, a small bit of GUI nitpicking : the type of functions and
variables was added, which is good, but as a result it's more frequent
for the value to be split on 2 lines, and it's not always obvious it's
part of the same line. For example when seeing :
"class gfxContext *
nsSVGRenderState::GetGfxContext"
it's not obvious it's only one line that was split in two.
But anyway there's obviously some adjustments to do to handle overflow
better in that part.
Congratulation on the current progress anyway.
At the end of last year, there was some indexing problems on the dxr on
Lanedo. After checking again after Taras's last blog entry, I see now it
seems to work much better :
http://dxr2.lanedo.com/search.cgi?tree=mozilla-central&string=GfxContext
http://dxr.mozilla.org/mozilla/search.cgi?tree=mozilla-central&string=GfxContext
What solved it exactly ? Christian Dywan did refer to it being broken
because of the use of the latest llvm and clang, but Ehsan replied it
was working correctly with clang 3.0.
So it's not very clear which version should be avoided.
Another thing, a small bit of GUI nitpicking : the type of functions and
variables was added, which is good, but as a result it's more frequent
for the value to be split on 2 lines, and it's not always obvious it's
part of the same line. For example when seeing :
"class gfxContext *
nsSVGRenderState::GetGfxContext"
it's not obvious it's only one line that was split in two.
But anyway there's obviously some adjustments to do to handle overflow
better in that part.
Congratulation on the current progress anyway.
Ehsan Akhgari
Feb 1, 2012, 2:45:18 PM2/1/12
to Jean-Marc Desperrier, dev-stati...@lists.mozilla.org
On Wed, Feb 1, 2012 at 1:58 PM, Jean-Marc Desperrier <jmd...@gmail.com>wrote:
> Hi,
>
> At the end of last year, there was some indexing problems on the dxr on
> Lanedo. After checking again after Taras's last blog entry, I see now it
> seems to work much better :
> http://dxr2.lanedo.com/search.**cgi?tree=mozilla-central&**
> Hi,
>
> At the end of last year, there was some indexing problems on the dxr on
> Lanedo. After checking again after Taras's last blog entry, I see now it
> seems to work much better :
> string=GfxContext<http://dxr2.lanedo.com/search.cgi?tree=mozilla-central&string=GfxContext>
> http://dxr.mozilla.org/**mozilla/search.cgi?tree=**mozilla-central&string=
> **GfxContext<http://dxr.mozilla.org/mozilla/search.cgi?tree=mozilla-central&string=GfxContext>
>
> What solved it exactly ? Christian Dywan did refer to it being broken
> because of the use of the latest llvm and clang, but Ehsan replied it was
> working correctly with clang 3.0.
> So it's not very clear which version should be avoided.
>
clang 3.0 should be fine.
> What solved it exactly ? Christian Dywan did refer to it being broken
> because of the use of the latest llvm and clang, but Ehsan replied it was
> working correctly with clang 3.0.
> So it's not very clear which version should be avoided.
>
> Another thing, a small bit of GUI nitpicking : the type of functions and
> variables was added, which is good, but as a result it's more frequent for
> the value to be split on 2 lines, and it's not always obvious it's part of
> the same line. For example when seeing :
> "class gfxContext *
> it's not obvious it's only one line that was split in two.
> But anyway there's obviously some adjustments to do to handle overflow
> better in that part.
>
Please file a bug on this, it looks like a UI issue.
> But anyway there's obviously some adjustments to do to handle overflow
> better in that part.
>
--
Ehsan
<http://ehsanakhgari.org/>
Carlos Garnacho
Feb 1, 2012, 3:53:26 PM2/1/12
to Ehsan Akhgari, Jean-Marc Desperrier, dev-stati...@lists.mozilla.org
Hey :),
On mié, 2012-02-01 at 14:45 -0500, Ehsan Akhgari wrote:
> On Wed, Feb 1, 2012 at 1:58 PM, Jean-Marc Desperrier <jmd...@gmail.com>wrote:
>
revision. the problems Christian mentioned involved using more recent
clang/llvm, where API changes broke the clang plugin build.
>
>
> > Another thing, a small bit of GUI nitpicking : the type of functions and
> > variables was added, which is good, but as a result it's more frequent for
> > the value to be split on 2 lines, and it's not always obvious it's part of
> > the same line. For example when seeing :
> > "class gfxContext *
> > nsSVGRenderState::**GetGfxContext"
look into that.
Regards,
Carlos
On mié, 2012-02-01 at 14:45 -0500, Ehsan Akhgari wrote:
> On Wed, Feb 1, 2012 at 1:58 PM, Jean-Marc Desperrier <jmd...@gmail.com>wrote:
>
> > Hi,
> >
> > At the end of last year, there was some indexing problems on the dxr on
> > Lanedo. After checking again after Taras's last blog entry, I see now it
> > seems to work much better :
> >
> > At the end of last year, there was some indexing problems on the dxr on
> > Lanedo. After checking again after Taras's last blog entry, I see now it
> > seems to work much better :
> > http://dxr2.lanedo.com/search.**cgi?tree=mozilla-central&**
> > string=GfxContext<http://dxr2.lanedo.com/search.cgi?tree=mozilla-central&string=GfxContext>
> > http://dxr.mozilla.org/**mozilla/search.cgi?tree=**mozilla-central&string=
> > **GfxContext<http://dxr.mozilla.org/mozilla/search.cgi?tree=mozilla-central&string=GfxContext>
> > string=GfxContext<http://dxr2.lanedo.com/search.cgi?tree=mozilla-central&string=GfxContext>
> > http://dxr.mozilla.org/**mozilla/search.cgi?tree=**mozilla-central&string=
> >
> > What solved it exactly ? Christian Dywan did refer to it being broken
> > because of the use of the latest llvm and clang, but Ehsan replied it was
> > working correctly with clang 3.0.
> > So it's not very clear which version should be avoided.
> >
>
> > What solved it exactly ? Christian Dywan did refer to it being broken
> > because of the use of the latest llvm and clang, but Ehsan replied it was
> > working correctly with clang 3.0.
> > So it's not very clear which version should be avoided.
> >
>
> clang 3.0 should be fine.
We have stick so far to r132484 for clang, which isn't a final 3.0
revision. the problems Christian mentioned involved using more recent
clang/llvm, where API changes broke the clang plugin build.
>
>
> > Another thing, a small bit of GUI nitpicking : the type of functions and
> > variables was added, which is good, but as a result it's more frequent for
> > the value to be split on 2 lines, and it's not always obvious it's part of
> > the same line. For example when seeing :
> > "class gfxContext *
> > it's not obvious it's only one line that was split in two.
> > But anyway there's obviously some adjustments to do to handle overflow
> > better in that part.
> >
>
> > But anyway there's obviously some adjustments to do to handle overflow
> > better in that part.
> >
>
> Please file a bug on this, it looks like a UI issue.
Looks like an unintentional behavioral change in dxr.lanedo.com, I'll
look into that.
Regards,
Carlos
Jean-Marc Desperrier
Mar 5, 2012, 2:19:44 PM3/5/12
to
Carlos Garnacho a écrit :
>> Ehsan writes ;
to just take the final binaries from the clang/llvm site, and the
installation is much easier.
If it's not working, I think it's quite an important point to solve.
>> Ehsan writes ;
>> > clang 3.0 should be fine.
> We have stick so far to r132484 for clang, which isn't a final 3.0
> revision. the problems Christian mentioned involved using more recent
> clang/llvm, where API changes broke the clang plugin build.
This is an important point. If final 3.0 works properly, it's possible
> We have stick so far to r132484 for clang, which isn't a final 3.0
> revision. the problems Christian mentioned involved using more recent
> clang/llvm, where API changes broke the clang plugin build.
to just take the final binaries from the clang/llvm site, and the
installation is much easier.
If it's not working, I think it's quite an important point to solve.
0 new messages