> On May 5, 2020, at 16:17, Chee Yong Teh wrote:
>
>
> Hi Andi,
>
> Ok I have changed the command to
>
> python -m jcc --version 7.1.4 --use_full_names --include
> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/smart-swapclear-public-release_daru.12.
> jar --include
Hi Andi,
Ok I have changed the command to
python -m jcc --version 7.1.4 --use_full_names --include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/smart-swapclear-public-release_daru.12.
jar --include /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/colt-1.2.0.jar
--include
On Tue, 5 May 2020, Chee Yong Teh wrote:
Hi Andi,
That’s third party library jar file that we try to wrap so we can call it from
python.
I don’t really know why they create a classes like that way.
Would you able to add an option to just only wrap classes under a package
like I want to
OK, thanks Chris.
The 24 hour rollup still shows many failures in the several classes, I’ll check
tomorrow
to see if that’s a consequence of the disk full problem.
> On May 5, 2020, at 1:41 PM, Chris Hostetter wrote:
>
>
> : And FWIW, I beasted one of the failing suites last night _without_
On Tue, May 5, 2020 at 12:37 PM Dawid Weiss wrote:
> > I read “promotion to TLP” as if this was some achievement that needs to
> be celebrated now.
>
> I honestly believe it is an achievement for a project to receive
> top-level status. It's a sign of having a community of users,
> committers
> I read “promotion to TLP” as if this was some achievement that needs to be
> celebrated now.
I honestly believe it is an achievement for a project to receive
top-level status. It's a sign of having a community of users,
committers and processes mature enough to empower its further
development.
> Question: When Lucene no longer has the Solr test suite to help catch bugs,
> how long time would it take from a Lucene commit, before Solr/ES Jenkins
> instances would have had time to produce a build and run tests? Would it be
> possible to setup a trigger in Solr Jenkins?
It depends how
HI Andi,
Please see below print out
-declares : {, , , , }
--declareNames : ['it', 'unimi', 'dsi', 'fastutil', 'h']
---declareName : it
---namespace : {}
---declareName : unimi
---namespace : {}
---declareName : dsi
---namespace : {}
---declareName : fastutil
---namespace : {}
--declareNames :
: And FWIW, I beasted one of the failing suites last night _without_
: Mike’s changes and didn’t get any failures so I can’t say anything about
: whether Mike’s changes helped or not.
IIUC McCandless's failure only affects you if you use the "jenkins" test
data file (the really big wikipedia
I don’t agree with the argument “Solr outgrew being a subproject of
Lucene”. I read “promotion to TLP” as if this was some achievement that
needs to be celebrated now. Solr didn’t become a TLP years ago because the
decision then was to merge with Lucene development, thinking they would
progress
On Mon, 4 May 2020, Chee Yong Teh wrote:
I'm in the processing of testing JCC to wrap third party library jar.
When I run JCC 3.7 I got the following error
Traceback (most recent call last):
File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File
On Tue, May 5, 2020 at 11:41 AM Jan Høydahl wrote:
As it is today, deveopers have had to do necessary Solr changes at the same
> time when doing changes in Lucene. This is not really fair to the (mainly)
> Lucene developers. It is not fair to Solr either, as such work might be
> done in a hasty
I see it often; I raised this in slack a few weeks ago. Kevin & Mike Drob
responded. It seems "gw clean" makes it go away. Still, this is annoying
and points to a problem we should address.
~ David
On Tue, May 5, 2020 at 8:40 AM Erick Erickson
wrote:
> I was doing quite a bit of building
Thanks for bringing it up Dawid.
I’ve asked myself the same question several times over the last couple of
years, and have kind of been waiting for someone to make the proposal :)
In my head, Solr has out-grown being a sub project of Lucene, like hadoop,
mahout, nutch and tika before it.
The
Personally I feel the burden of proof should not be why they should be
split up, but the other way - "what arguments can be made for keeping them
together?"
I would be curious if people can make the argument for keeping them
together...
-Doug
On Tue, May 5, 2020 at 10:29 AM Michael McCandless <
On Mon, May 4, 2020 at 2:13 PM Dawid Weiss wrote:
> This sounds like a decision has already been made.
>
> No. I plan to send a VOTE thread nonetheless. A vote thread is just
> that -- a vote. If majority decides both projects
> should stay together it's still a decision. A discussion without
On Mon, May 4, 2020 at 5:28 PM Gézapeti Cseh wrote:
I think separating the git repository and even the release schedules could
> be done under the same TLP.
>
It would solve most of the technical issues reflected in the first mail and
> there would be more time and data to
>
Hmm that is
Thanks Uwe and Mike. I’ll check Hoss’ rollups regularly this week, it’ll be
tomorrow (Wednesday) before Uwe’s changes get a chance to be reflected there.
And FWIW, I beasted one of the failing suites last night _without_ Mike’s
changes and didn’t get any failures so I can’t say anything about
I was doing quite a bit of building the assemble and dev tasks and never saw
this. Of course I was bouncing between and and gradle a lot and habitually
executed a "git clean -d -x -f”, don’t have a clue whether that’d be relevant,
though I rather doubt it is.
> On May 5, 2020, at 7:27 AM, Alan
Hi all,
In about 50% of my gradle precommit runs, I get a Solr compilation error that
looks like this:
/Users/romseygeek/projects/lucene-solr/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java:44:
error: BlockPoolSlice is not public in
Hi,
there was also a problem with the Windows Node. It ran out of disk space,
because some test seem to have filled up all of the disk. All followup builds
failed. I cleaned all Workspaces (8.x, master) and it freed 20 Gigabytes!
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
21 matches
Mail list logo
