New crate.io release

The current release on crate.io (0.0.14) does not contain the VisibilityRegion -> VisibilityResource  name and the related changes.
Have you planned creating a new release ?
Also I comment on versioning. I know it's stile a 0.* version, but other creates usually increment the minor version when a new breaking change is introduced (while 1.0 is not reached). The patch version is usually incremented on fixing some minor glitch, internal bugs or extending the api. Thus it allows dependents to pull in a version like "0.14" and "ignore" the patch version generally.
In you versioning the version "0.0.14" breaks this, so If I may suggest to use the minor version to be incremented as a rule of thumb while 1.0 is not reached. (https://doc.rust-lang.org/cargo/reference/semver.html)
Please keep up the great work. The crate seems really promising and I wish it got more popularity.

I agree a new release is overdue. I'm taking a short hiatus because I'm busy with personal things (moving!) but it wouldn't take much time to do a release. I'd also like to upload a more recent video of the demo project (including the new compute-based occlusion culling)
The handling of 0.0.x version numbers is treated similarly to 0.x version numbers according to https://doc.rust-lang.org/cargo/reference/semver.html#change-categories

Initial development releases starting with "0.y.z" can treat changes in "y" as a major release, and "z" as a minor release. "0.0.z" releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.

I think rafx-api could probably be stable enough in terms of API to be a 0.x.y but for the other crates at this point, I'm not making any attempt at avoiding public API changes. Once the API is more settled, I'll switch to 0.x.y.
Thanks for the encouragement, I'm looking forward to getting back to this. :)

Tried to publish 0.0.15, raft-assets and crates that depend on it can't be published currently because they rely on changes in distill that have not been published yet. I can ask around about this later on. Anyone just wanting to use rafx-api, the shader processor, and framework-level code should be set though.

Closing, no change for years

You might be interested in https://github.com/aclysma/hydrate and this branch https://github.com/aclysma/rafx/tree/use-hydrate that is using it. This will be brought over to the main branch soon.
While I probably will publish a crates.io release after this branch is brought over, I think because of the experimental nature of this crate and the high likelihood of having to make local changes to use it, it's better to use rust's crate-patching mechanism so that you have the latest code, and you can conveniently edit it.


Bring yapf action into line with Codesapces

On save, our Codespaces are configured to format python code using the google style version of yapf but our build and test action does not. This is causing a test failure with the addition of tests/resemble:golden_file_py.

Discussed offline. Closing, not relevant.


Wrong entity on EnergyManager

Since new update of HA i only see the wrong sensors (total instead of live data) in the Dashboard

I just updated my HA and had the same problem.
I just released 0.5.0, which contains more sensors. Can you update the integration? After the update, you need to delete the EnergyManager integration and add it again.

hi, sorry, wrote via iphone and wasnt able to add the entity.
I like to have the actual produced (same view as in EnergyManager) but im unable to use e.g. sensor.energymanager_powerproduced in the Dashboard of Energy from HA. Im only able to use pther entitys to see the summarization of produced or used power. Same for battery etc.

This is what i have to select.
For the produced (left side) i figured out that it should be the "power self consumed" Entitiy.

For the other ones as the Entitys with "Power" instead with "work" as the Work Entitys shows only the summarization

This is actually normal behavior for the home assistant energy management.
To view real time power usage, I think you have to use a different
visualization.
I use this card: https://github.com/JonahKr/power-distribution-card
Which looks at the power data.
On Sat, Oct 15, 2022, 20:31 M4ndaL0re @.***> wrote:

This is what i have to select.
For the produced (left side) i figured out that it should be the "power
self consumed" Entitiy.
[image: SolarWatt]
https://user-images.githubusercontent.com/114978337/196002459-fb249a97-6ac7-4cdb-bc7e-d849f00b45e3.png
For the other ones as the Entitys with "Power" instead with "work" as the
Work Entitys shows only the summarization
[image: SolarWatt2]
https://user-images.githubusercontent.com/114978337/196002576-54574a59-fcc6-4c79-9f77-7ed94aa3073d.png
—
Reply to this email directly, view it on GitHub
https://github.com/Mas2112/solarwatt-energymanager-homeassistant/issues/8#issuecomment-1279802977,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABJLAZU4YVTYIIPDLKD7OTWDL2AZANCNFSM6AAAAAARDT3FXQ
.
You are receiving this because you commented.Message ID:
@.***
com>

ok thx.


Allow inProject stacktrace filters to be configured

The vendor and .bundle filters work great for gem code, but we have some helper classes in our code base to DRY up common notification patterns that we would like to be ignored from the Bugsnag stacktraces and groupings.
This PR allows additional stacktrace filters to be added like so:
Bugsnag.configure do |config|
  config.stacktrace_filters << %r{^app/services/exception_notifier.rb}
end

Hi @phil-monroe, thanks for the contribution.  We typically try to minimise the amount of changes to configuration options to maintain parity across our notifiers, but we'll review this change and see if it's something we think could be beneficial.
In the meantime, you can edit your stacktraces in middleware or callbacks:
Bugsnag.before_notify_callbacks << Proc.new do |report|
  report.exceptions[0][:stacktrace].delete_if do |trace|
    /^app\/services\/exception_notifier.rb$/.match(trace[:file])
  end
end

Hi @phil-monroe, I may have misinformed you in my above answer.  What you seem to be wanting to do is to set inProject on the stacktrace using the same logic.
Bugsnag.before_notify_callbacks << Proc.new do |report|
  report.exceptions[0][:stacktrace].each do |trace|
	trace[:inProject] = false if /^app\/services\/exception_notifier.rb$/.match(trace[:file])
  end
end

Ah, neat! Didn't realize we had access to inProject in before_notify_callbacks . Thanks!

We ended up going with a middleware approach over before_notify_callbacks since before_notify_callbacks does not work with threaded applications (sidekiq - #417)
Here is our solution for reference:
class BugsnagIgnoreProjectLines
  def initialize(bugsnag)
    @bugsnag = bugsnag
  end

  def call(report)
    report.exceptions.each do |exception|
      exception[:stacktrace].each do |trace|
        trace[:inProject] = false if trace[:file] =~ %r{^app/services/maven/notifier.rb$}
      end
    end
  end
end

Bugsnag.configure do |config|
  config.middleware.use(BugsnagIgnoreProjectLines)
end


Updating Scoped SLDS to native SLDS

The static resource sfdo203 is no longer being used and has been removed from the package.
Critical Changes
Changes

The static resource "sfdo203", which is a scoped version of the Salesforce Lightning Design System, can now be deleted. Visualforce pages that were previously using the "sfdo203" static resource are now using the Salesforce included version of slds. To delete the static resource, go to Setup -> Custom Code -> Static Resources and click the "Delete" link to the left of the "sfdo203" resource.

Issues Closed

@smarovich can you please take a look at the changes section of this PR and let me know what you think? I was going to include instructions but the click path is different from lightning to classic.

@jjbennett So, there is an action they need to take (or can take)? If so, I say we provide basic instructions in Lightning UI (we only doc in Lightning UI now).

@smarovich updated with instructions.

Thanks @jjbennett. I made some minor edits to the release notes.  Looks good!


user

Did you check the post date on this article?

What's this?

It had a link to an article from 2013 about LFM and videos  - Close this :+1:

I pulled that after some people got in trouble bring it up in form, but
this was stating that on Jan 14? 2014 there where problems scrobbling, but
I again pulled that - so post must stick, what I close remains open?
whatever the case there is no communication, staff or whatever you want to
them are rude, not trying to make this work, but what do I know other than
I closed the issue nearly 3 hours ago - I am sorry for wanting to work
collectively and can not.
one other thing you should tell people that their issue/posts remain I got
3 message 1 hour. 50 mns, and 40 mins - burn me at the cross
okay good luck
On Wed, Jun 17, 2015 at 3:56 AM, David Šabata<EMAIL_ADDRESS>wrote:

Closed #641 https://github.com/david-sabata/web-scrobbler/issues/641.
—
Reply to this email directly or view it on GitHub
https://github.com/david-sabata/web-scrobbler/issues/641#event-333041411
.

@pink999 I'm sorry - I don't follow? I didn't mean to cause offence.
What exactly is the issue you are facing?

did I cuss you out, if not, no offense then ;p sorry late with this it "here" I do remember you, hey geek is right word for guy and gals that dig doing what you guys do right?
I do have an issue with lost fm (yes lost), nothing anyone can do about that, but the youtube isn't well (I have you right?) I posted, that has been my issues in past, not with you guys, you actually were very helpful, but the spot-mods as I call them think we are all developers?

I parse: our web-scrobbler not working, and @david-sabata somewhere resting and does not want to help a ~cute~ girl

Think of it for world peace and other cool stuff x

wake him up and tell him I fixed it - but really it appears to be trying to
work,
Pom Poms and cheering helped ----- "Goooo You Tube!"
"cute" plz - cool
West Coast strut that’s sweet as molasses
Knock you out with my cheap sunglasses
If you fixed it ~ thanks, but I think the cheerleading chants worked lol
See then  watch this neat stuff and store it - you can send to exel, but
you knew that , Have a great weekend x
https://www.youtube.com/watch?v=inavKm9r9cw
On Fri, Aug 21, 2015 at 2:38 AM, bes-internal<EMAIL_ADDRESS>wrote:

I parse: our web-scrobbler not working, and @david-sabata
https://github.com/david-sabata somewhere resting and does not want to
help a ~cute~ girl
—
Reply to this email directly or view it on GitHub
https://github.com/david-sabata/web-scrobbler/issues/641#issuecomment-133351841
.

I can't tell if this Bri person is an especially entertaining troll or a legitimate girl.

Either way, half of it I don't understand and half of it is really funny 😁

le tracker pour YouTube semble fonctionner, understand, you need to see my
papers?
a Troll? The Bridge Creatures? ever seen Troll Hunter?
Really now Troll - that is below belt  you rather have someone that's
"bitch, bitch, blah, blah,yada?"
Way ahead of you, you'd turn them off - correct (?).
okay it is settled, maybe its working on its own?
but perhaps if you would be so kind, maybe a look at it and you get another
surprise (geeks go figure?)
https://www.youtube.com/watch?v=WhGFwk58h34 (Run!) Great sub-titles!
lol my sister watches this stuff,
zombies are the fad in BC too, the ones that are cannibals, vampires are
cool <3
Really this is the problem with the world -- no fun, all tense over what?
Tight undies?
blame it Canada; Thank you.
On Fri, Aug 21, 2015 at 12:02 PM, David Šabata<EMAIL_ADDRESS>wrote:

Either way, half of it I don't understand and half of it is really funny
😁
—
Reply to this email directly or view it on GitHub
https://github.com/david-sabata/web-scrobbler/issues/641#issuecomment-133531815
.

https://www.youtube.com/watch?v=WhGFwk58h34
On Fri, Aug 21, 2015 at 1:00 PM, Sister Sister<EMAIL_ADDRESS>wrote:

le tracker pour YouTube semble fonctionner, understand, you need to see
my papers?
a Troll? The Bridge Creatures? ever seen Troll Hunter?
Really now Troll - that is below belt  you rather have someone that's
"bitch, bitch, blah, blah,yada?"
Way ahead of you, you'd turn them off - correct (?).
okay it is settled, maybe its working on its own?
but perhaps if you would be so kind, maybe a look at it and you get
another surprise (geeks go figure?)
https://www.youtube.com/watch?v=WhGFwk58h34 (Run!) Great sub-titles!
lol my sister watches this stuff,
zombies are the fad in BC too, the ones that are cannibals, vampires are
cool <3
Really this is the problem with the world -- no fun, all tense over what?
Tight undies?
blame it Canada; Thank you.
On Fri, Aug 21, 2015 at 12:02 PM, David Šabata<EMAIL_ADDRESS>wrote:

Either way, half of it I don't understand and half of it is really funny
😁
—
Reply to this email directly or view it on GitHub
https://github.com/david-sabata/web-scrobbler/issues/641#issuecomment-133531815
.

This issue needs to remain permanently open.

got it, the e-mails before your had virused or something, norton
caught shut dow, rebooted, locked, rebooted, running slow like dail up
days, full scan was full of threats?
so I am good, gone.
On Sun, Aug 23, 2015 at 9:42 AM, Jan Baykara<EMAIL_ADDRESS>wrote:

This issue needs to remain permanently open.
—
Reply to this email directly or view it on GitHub.

 The Bridge Creatures? ever seen Troll Hunter?
Really now Troll - that is below belt  you rather have someone that's
"bitch, bitch, blah, blah,yada?"
Way ahead of you, you'd turn them off - correct (?).
okay it is settled, maybe its working on its own?
but perhaps if you would be so kind, maybe a look at it and you get
another surprise (geeks go figure?)
https://www.youtube.com/watch?v=WhGFwk58h34 (Run!) Great sub-titles!
lol my sister watches this stuff,
zombies are the fad in BC too, the ones that are cannibals, vampires are
cool <3
Really this is the problem with the world -- no fun, all tense over what?
Tight undies?
blame it Canada; Thank you.
On Fri, Aug 21, 2015 at 12:02 PM, David Šabata<EMAIL_ADDRESS>wrote:

Either way, half of it I don't understand and half of it is really funny [image:
😁]
—
Reply to this email directly or view it on GitHub
https://github.com/david-sabata/web-scrobbler/issues/641#issuecomment-133531815
.


Match Maven Java SDK harness jar name format

Without this change, the Java SDK image Docker build fails because the beam-sdks-java-harness.jar does not exist. This jar is copied over and renamed from the harness build directory in the copyDockerfilDependencies task. The source file pattern needs to match the output jar artifact here.

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Make sure there is a JIRA issue filed for the change (usually before you start working on it).  Trivial changes like typos do not require a JIRA issue.  Your pull request should address just this issue, without pulling in other changes.
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.
[ ] Write a pull request description that is detailed enough to understand:

[ ] What the pull request does
[ ] Why it does it
[ ] How it does it
[ ] Why this approach

[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Alternatively, we could keep the current Gradle output format (harness-<VERSION>) and change copyDockerfilDependencies to match this.


Possible race in PG endpoint's commit handling

We should fix this at some point. IIRC it caused some issues when I tested it in development, but in general the way it works makes more sense than before. Must've introduced a bug.


Use BitOp or Bit32 libraries where available

Tested and got between 300 and 500 faster performance which I consider a HUGE amount.
I dont know why the commit looks so horrible but I just made a few minor changes

Hi Positive07,
Have you tested this in systems without the "bit" library? As far as I know, this line should fail:
if require "bit" or require "bit32" then

When you try to require a library which does not exist, it does not return false - it raises an error. You should be able to reproduce it by switching the order in the if: if require 'bit32' or require 'bit' then.
The appropriate way of doing this should involve pcall:
local ok, bit = pcall(require, 'bit')
if not ok then ok, bit = pcall(require, 'bit32') end
if ok then
  bit_or, bit_and, bit_not, bit_xor = bit.bor, bit.band, bit.bnot, bit.bxor
  bit_rshift, bit_lshift = bit.rshift, bit.lshift
else
  ...

I would do the changes myself, but I am travelling and can't do that at the moment. Can you add the change and make sure it works when the libraries are not present?

Thanks Kikito, you where right! it errored right away, fixed it as you suggested, I'll test this fix in a couple of hours and come back to confirm that it works

It works perfectly fine now

Thanks a lot, merged!

I have setup md5.lua in Travis so that tests can be run automatically in the three main envs (Lua 5.1, 5.2 & LuaJIT). This should make changes easier in the future.
I have also included you in the credits readme, released version 1.0.0 of the library, and published it in Luarocks. Thanks again!

Wow amazing! Thank you!

md5.lua Less than 824 bytes, MD5 is correct
If more than 823 bytes,md5 is wrong!
I am a novice, I can't find the reason.

Hi @lxss, please create a new issue instead of commenting on a closed one.

I'm sorry, I have just registered, don't know how to use
require "md5"
local md5 = require 'md5'
local str = "";
for i=1,823 do
str = str .. "1";
end
print(md5.sumhexa(str)); --823 correct
str = str .. "1";
print(md5.sumhexa(str)); --824 error

@lxss I have created an issue for you here: https://github.com/kikito/md5.lua/issues/4
I also have a couple questions, please answer them there.


Switch to Trove or something else for default caching

More memory golfing wheee

Solved with a stripped-down koloboke from @natanbc


publish to azure via "mvn azure-functions:deploy" doesn't support service principal

Repeat the problem:

login to azure through service principal (https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli?view=azure-cli-latest#logging-in-with-a-service-principal)
Run "mvn azure-functions:deploy" to deploy the function
Error like this "Failed to execute goal com.microsoft.azure:azure-functions-maven-plugin:0.2.0:deploy (default-cli) on project rsmgr-liquibase-func: java.io.IOException: clientId is null or empty" will be fired

@danyongliu can you please provide me with the functions documentation you are also following? The only link I see is for options to login via Azure CLI.

@danyongliu I will close this out for now. When ready, please come back with the above ask and we can continue.


Fix Style/HashSyntax cop error in case of implicit call message

echo 'JSON.method(:dump).(:a => 1)' | rubocop --stdin bug.rb --only Style/HashSyntax -d

An error occurred while Style/HashSyntax cop was inspecting bug.rb:1:20.
undefined method `end_pos' for nil
lib/rubocop/cop/style/hash_syntax.rb:275:in `argument_without_space?'
lib/rubocop/cop/style/hash_syntax.rb:256:in `autocorrect_ruby19'
lib/rubocop/cop/style/hash_syntax.rb:202:in `autocorrect'
lib/rubocop/cop/style/hash_syntax.rb:243:in `block (2 levels) in check'

Before submitting the PR make sure the following are checked:

[X] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[X] Wrote good commit messages.
[X] Commit message starts with [Fix #issue-number] (if the related issue exists).
[X] Feature branch is up-to-date with master (if not - rebase it).
[X] Squashed related commits together.
[X] Added tests.
[X] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[X] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thanks!


Remove Guava dependency

Fixes #16

It would be great if you abstract over the bits that are responsible for hashing and detecting uniqueness of changes. In the default implementation of this interface, you would use CRC32, but you would also allow third parties to modify the implementation.
In some cases, CRC32 may not be good enough, and I'm afraid that people will ask me (as a client of this library) to use a non-cryptographic hash like xxHash instead of CRC32. What do you think about the idea?

I'm reconsidering CRC32. I was thinking about including an implementation of Murmur3_128, which is what Guava was using before.
The only question to me is whether it's still worth making the hash algorithm configurable if I do that?

The only question to me is whether it's still worth making the hash algorithm configurable if I do that?

I think if you do it it would be a great design. Configuring the algorithm can be useful in many scenarios performance and correctness wise. For example, I would probably implement this with xxHash because I'd like to reuse the hashes created by the watcher, see https://github.com/scala/scala-dev/issues/548
A simple interface like abstract class HashMachine { def hash(p: Path): Hash } would work :smile:

Could Hash here be the hash you define in this PR? All I need is a wrapper around long.

It could be. If it's a concrete implementation a byte array would probably be the most flexible.


Uno::solve() should return the result

Ideally an std::optional<Result>, since there is no result to return if the functions cannot be evaluated at the initial point.
Reported by @worc4021.

Fixed in https://github.com/cvanaret/Uno/pull/111 without using std::optional.


Failed to execute 'observe' on 'ResizeObserver'

Hi, i have this problem, when component Scroller be unmounted.
Scroller.js:255 Uncaught TypeError: Failed to execute 'observe' on 'ResizeObserver': parameter 1 is not of type 'Element'.     at Scroller.js:255     at HTMLUnknownElement.callCallback (react-dom.development.js:147)     at Object.invokeGuardedCallbackDev (react-dom.development.js:196)     at invokeGuardedCallback (react-dom.development.js:250)     at safelyDetachRef (react-dom.development.js:17910)     at commitUnmount (react-dom.development.js:18333)     at commitNestedUnmounts (react-dom.development.js:18361)     at unmountHostComponents (react-dom.development.js:18648)     at commitDeletion (react-dom.development.js:18712)     at commitAllHostEffects (react-dom.development.js:19577)     at HTMLUnknownElement.callCallback (react-dom.development.js:147)     at Object.invokeGuardedCallbackDev (react-dom.development.js:196)     at invokeGuardedCallback (react-dom.development.js:250)     at commitRoot (react-dom.development.js:19816)     at react-dom.development.js:21402     at Object.unstable_runWithPriority (scheduler.development.js:255)     at completeRoot (react-dom.development.js:21401)     at performWorkOnRoot (react-dom.development.js:21324)     at performWork (react-dom.development.js:21229)     at performSyncWork (react-dom.development.js:21203)     at interactiveUpdates$1 (react-dom.development.js:21488)     at interactiveUpdates (react-dom.development.js:2268)     at dispatchInteractiveEvent (react-dom.development.js:5086)
Code.
<Scroller                         scrollRef={(ref) => {                             this.scroll = ref                         }}                         autoScroll={true}                         autoFrame={true}                         onScrollChange={(scroll) => {                             this.setState({ scroll: scroll })                         }}                     > ...                    </Scroller>

I have the same issue here:

Any progress on the solution? I can't figure it out

I believe #17 closes this issue, I've pushed a new version to npm


Grafana page timing out

I have installed Mainflux on DigitalOcean but the Grafana page is not opening

@sharmmoh1983 have you started the influxdb-writer service?

@manuio I have got it started but now no messages are appearing on Grafana.
{
"xhrStatus": "complete",
"request": {
"method": "GET",
"url": "api/datasources/proxy/1/query",
"params": {
"db": "mainflux",
"q": "SELECT "value" FROM "autogen"."messages" WHERE ("channel" = '64310c75-5f6a-4a9c-87df-e879edd99ca2') AND time >=<PHONE_NUMBER>000ms and time <=<PHONE_NUMBER>999ms",
"epoch": "ms"
},
"data": null,
"precision": "ms"
},
"response": {
"results": [
{
"statement_id": 0
}
]
}
}

@sharmmoh1983 From where are you accessing to the page?  From the UI or from http://localhost:3001/?

I am running UI on DigitalOcean

@sharmmoh1983 did you configured this URL: https://github.com/mainflux/ui/blob/master/src/environments/environment.prod.ts#L28?
If not you must set your cloud URL and rebuild a new UI image.

@manuio I am able to access grafana and UI and also tokens using Cloud  IP . So this thing will just make paths available? Also how can see messages I am sending to channel on Druflux UI
Also UI always pops up message gateway not found ,how to add  gateways ?

@sharmmoh1983 UI still in development and will be stable for release 1.0.0. The Gateway message pops up because you don't have all needed services running. I'll add more docs soon to explain how the setup all services for UI.
For now you can maybe set  the grafana URL here: https://github.com/mainflux/ui/blob/master/src/environments/environment.prod.ts#L28 and build a new image with make docker_ui: https://github.com/mainflux/ui/blob/master/README.md

@manuio  For running edge mainflux or gateways do we have to buy Mainflux device ?
Can we run edge/gateway binary on any Raspberry pi to connect to devices and Mainflux Cloud

@sharmmoh1983 no need for proprietary HW, Agent is HW agnostic.


Feature Request : Name of species in fasta output

Having the name of the species in the header when downloading a fasta sequences

Done


Add a tsconf.json file to the scripts folder that configures tsc to target ES5.

This is done in order to fix the getter/setter not available issue that appears when building
the project with the released version of VisualStudio 2015.

Me too, after adding this file to scripts, it build without a problem.
Deploying however, was not that simple, it deployed on windows phone device , ripple, but is giving "unable to read apk " when deploying to galaxy tab 3.
Since i believe this is an VS 2015 issue, guess i will have to dig harder.
Cheers


Remove notifications completely in reports scheduler

Signed-off-by: Joshua Li<EMAIL_ADDRESS>Description
see #210
removing notifications actions since common-utils will not include them in 1.2
Issues Resolved
https://github.com/opensearch-project/opensearch-build/issues/907
Check List

[ ] New functionality includes testing.

[ ] All tests pass, including unit test, integration test and doctest

[ ] New functionality has been documented.

[ ] New functionality has javadoc added
[ ] New functionality has user manual doc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #221 (005b78e) into main (b686df8) will decrease coverage by 9.00%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main     #221      +/-   ##
============================================
- Coverage     63.57%   54.57%   -9.01%
+ Complexity      296      294       -2
============================================
  Files            99       64      -35
  Lines          4115     2056    -2059
  Branches        628      234     -394
============================================
- Hits           2616     1122    -1494
+ Misses         1357      796     -561
+ Partials        142      138       -4

Flag
Coverage Δ

dashboards-reports
?

reports-scheduler
54.57% <ø> (+1.56%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...g/opensearch/reportsscheduler/metrics/Metrics.java
92.30% <ø> (-0.20%)
:arrow_down:

...nsearch/reportsscheduler/ReportsSchedulerPlugin.kt
100.00% <ø> (+11.76%)
:arrow_up:

...itions/report_settings/report_settings_helpers.tsx

...port_definitions/report_trigger/report_trigger.tsx

...main/__tests__/__utils__/main_utils_test_utils.tsx

...shboards-reports/public/components/utils/utils.tsx

...itions/report_trigger/report_trigger_constants.tsx

...rts/server/routes/utils/savedSearchReportHelper.ts

dashboards-reports/test/propsMock.js

dashboards-reports/server/routes/utils/helpers.ts

... and 25 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b686df8...005b78e. Read the comment docs.


🐛 BUG: Please enable R2 through the Cloudflare Dashboard. [code: 10042]

Which Cloudflare product(s) does this pertain to?
R2
What version of Wrangler are you using?
2.12.2
What operating system are you using?
Mac
Describe the Bug
Running create bucket:
wrangler r2 bucket create some-bucket
Returns:
[ERROR] A request to the Cloudflare API (/accounts/xxx
Please enable R2 through the Cloudflare Dashboard. [code: 10042]

R2 is active (just set it up before running this command (after trying to do it on the cloudflare dashboard without success).
It's probably a bug at the server and not wrangler itself, but I want to keep a record of this here

I get this too from the CF console after subscribing.

This looks like an issue in the backend, I will create an internal ticket for this

I think this was resolved, so I'll close it for now. If you're still running into issues feel free to comment with more details and we can investigate further.


Ultest not passing anything as parameters for rust

I've just ran :Ultest and it marked as running. In the end all were green but i noticed in the float window that it actually didn't test anything:

When I run :TestFile it runs normally the file.

Please paste the log as described in the issue template. Inside the log you'll also find the commands run for the tests, you may spot the issue there as I've no experience with rust

The logs are basically this for each test in the file:
09:36:23 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_patch_blueprint_forbidden-5797354233085674124 as exited with result {"id": "test_patch_blueprint_forbidden-5797354233085674124", "file": "/Users/augusto/projects/workflow-manager/src/tests/blueprint.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultestpxou4i89/__Users__augusto__projects__workflow-manager__src__tests__blueprint_rs/test_patch_blueprint_forbidden-5797354233085674124_out"}
09:36:23 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_patch_blueprint_forbidden-5797354233085674124
09:36:23 | DEBUG | Thread-22 | handle.py:forward:85 | Writing data to output file
09:36:35 | DEBUG | Thread-20 | handle.py:forward:85 | Writing data to output file
09:36:35 | DEBUG | Thread-20 | handle.py:forward:85 | Writing data to output file
09:36:35 | DEBUG | Thread-20 | handle.py:forward:85 | Writing data to output file
09:36:36 | DEBUG | Thread-22 | handle.py:forward:85 | Writing data to output file
09:36:36 | DEBUG | Thread-20 | handle.py:forward:85 | Writing data to output file
09:36:36 | DEBUG | Thread-20 | handle.py:forward:85 | Writing data to output file
09:36:36 | DEBUG | MainThread | processes.py:run:76 | Process test_get_blueprint-5797354233085674124 complete with exit code: 0

I don't know if its relevant but every time I open my project I'm seeing this in the messages:

Yep that's a problem though it's odd that you can do anything after. You have to run :UpdateRemotePlugins after installing and updating vim-ultest. Does is still happen after that?
The logs you pasted don't tell me anything useful. I understand there might be sensitive info in them so can you either make a dummy project to run and provide them from that or check them yourself for the command being run, you should see lines beginning with
Starting test process ...

along with the command being run, cwd and extra env variables

Yep that's a problem though it's odd that you can do anything after. You have to run :UpdateRemotePlugins after installing and updating vim-ultest. Does is still happen after that?

Yes. I've installed like this:
use({ 'rcarriga/vim-ultest', requires = { 'vim-test/vim-test' }, run = ':UpdateRemotePlugins' })

Also tried running manually. The error still shows in the messages.

Starting test process ...

I don't see any of this in the logs.

Also tried running manually. The error still shows in the messages.

Very strange, not really sure what the issue is there, could be a race condition related to https://github.com/neovim/pynvim/issues/341

I don't see any of this in the logs.

You have to run the tests to see the logs

You have to run the tests to see the logs

If you mean calling Ultest then yes. I ran them and as I said I only see what I pasted before (also tried with a sample project). If not, what should I do?

Can you paste the entire log file for the sample project?

13:41:57 | INFO | MainThread | logging.py:create_logger:101 | Logger created
13:41:57 | DEBUG | MainThread | __init__.py:__init__:44 | Handler created
13:41:57 | INFO | MainThread | tracker.py:_init_test_file:97 | Initialising test file /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group update_positions
13:41:57 | INFO | MainThread | tracker.py:_async_update:57 | Updating positions in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | file.py:parse_file_structure:25 | Converted pattern {'test': ['\\v\\s*%(async )?fn\\s+(\\w+)'], 'namespace': []} to {'test': [re.compile('\\s*(?:async )?fn\\s+(\\w+)')], 'namespace': []}
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test /Users/augusto/projects/actix_test/src/main.rs found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test index-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_i32-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test main-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get12-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get11-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get10-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get0-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get8-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get9-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get7-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get6-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get5-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get4-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get3-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get2-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get1-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_get-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_async_update:84 | New test test_index_post-5669078533932717095 found in /Users/augusto/projects/actix_test/src/main.rs
13:41:57 | DEBUG | MainThread | tracker.py:_remove_old_positions:129 | No tests removed
13:41:57 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group update_positions
13:42:21 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group update_positions
13:42:21 | INFO | MainThread | tracker.py:_async_update:57 | Updating positions in /Users/augusto/projects/actix_test/src/main.rs
13:42:21 | DEBUG | MainThread | file.py:parse_file_structure:25 | Converted pattern {'test': ['\\v\\s*%(async )?fn\\s+(\\w+)'], 'namespace': []} to {'test': [re.compile('\\s*(?:async )?fn\\s+(\\w+)')], 'namespace': []}
13:42:21 | DEBUG | MainThread | tracker.py:_remove_old_positions:129 | No tests removed
13:42:21 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group update_positions
13:42:26 | INFO | MainThread | __init__.py:run_nearest:128 | Running nearest test in src/main.rs at line 0
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering index-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_i32-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group index-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process index-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering main-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_i32-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_i32-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get12-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group main-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process main-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get11-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get12-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get12-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get10-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get11-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get11-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get0-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get10-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get10-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get8-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get0-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get0-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get9-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get8-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get8-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get7-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get9-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get9-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get6-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get7-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get7-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get5-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get6-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get6-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get4-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get5-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get5-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get3-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get4-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get4-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get2-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get3-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get3-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get1-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get2-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get2-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_get-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get1-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get1-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_register_started:288 | Registering test_index_post-5669078533932717095 as started
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_get-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_get-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group test_index_post-5669078533932717095
13:42:26 | DEBUG | MainThread | processes.py:run:50 | Starting test process test_index_post-5669078533932717095 with command ['cargo', 'test', '', '--', '--exact'], cwd = /Users/augusto/projects/actix_test, env = None
13:42:26 | DEBUG | Thread-4 | handle.py:forward:85 | Writing data to output file
13:42:26 | DEBUG | Thread-2 | handle.py:forward:85 | Writing data to output file
13:42:26 | DEBUG | Thread-4 | handle.py:forward:85 | Writing data to output file
13:42:26 | DEBUG | Thread-2 | handle.py:forward:85 | Writing data to output file
13:42:26 | DEBUG | Thread-4 | handle.py:forward:85 | Writing data to output file
13:42:26 | DEBUG | Thread-2 | handle.py:forward:85 | Writing data to output file
13:42:27 | DEBUG | Thread-2 | handle.py:forward:85 | Writing data to output file
13:42:27 | DEBUG | Thread-4 | handle.py:forward:85 | Writing data to output file
13:42:28 | DEBUG | Thread-4 | handle.py:forward:85 | Writing data to output file
13:42:28 | DEBUG | Thread-4 | handle.py:forward:85 | Writing data to output file
13:42:32 | DEBUG | Thread-4 | handle.py:forward:85 | Writing data to output file
13:42:32 | DEBUG | Thread-4 | handle.py:forward:85 | Writing data to output file
13:42:32 | DEBUG | Thread-4 | handle.py:forward:85 | Writing data to output file
13:42:32 | DEBUG | Thread-2 | handle.py:forward:85 | Writing data to output file
13:42:32 | DEBUG | Thread-2 | handle.py:forward:85 | Writing data to output file
13:42:32 | DEBUG | Thread-2 | handle.py:forward:85 | Writing data to output file
13:42:32 | DEBUG | Thread-4 | handle.py:forward:85 | Writing data to output file
13:42:32 | DEBUG | Thread-2 | handle.py:forward:85 | Writing data to output file
13:42:32 | DEBUG | MainThread | processes.py:run:76 | Process test_i32-5669078533932717095 complete with exit code: 0
13:42:32 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_i32-5669078533932717095 as exited with result {"id": "test_i32-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_i32-5669078533932717095_out"}
13:42:32 | DEBUG | MainThread | processes.py:run:76 | Process index-5669078533932717095 complete with exit code: 0
13:42:32 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering index-5669078533932717095 as exited with result {"id": "index-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/index-5669078533932717095_out"}
13:42:32 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_i32-5669078533932717095
13:42:32 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group index-5669078533932717095
13:42:33 | DEBUG | Thread-8 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-6 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-8 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-6 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-8 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-6 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-8 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-6 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-6 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-6 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-6 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-8 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-8 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | MainThread | processes.py:run:76 | Process main-5669078533932717095 complete with exit code: 0
13:42:33 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering main-5669078533932717095 as exited with result {"id": "main-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/main-5669078533932717095_out"}
13:42:33 | DEBUG | Thread-8 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group main-5669078533932717095
13:42:33 | DEBUG | Thread-8 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get12-5669078533932717095 complete with exit code: 0
13:42:33 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get12-5669078533932717095 as exited with result {"id": "test_index_get12-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get12-5669078533932717095_out"}
13:42:33 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get12-5669078533932717095
13:42:33 | DEBUG | Thread-12 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-10 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-12 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-10 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-10 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-10 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-10 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-10 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get11-5669078533932717095 complete with exit code: 0
13:42:33 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get11-5669078533932717095 as exited with result {"id": "test_index_get11-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get11-5669078533932717095_out"}
13:42:33 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get11-5669078533932717095
13:42:33 | DEBUG | Thread-12 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-12 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-12 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-12 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get10-5669078533932717095 complete with exit code: 0
13:42:33 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get10-5669078533932717095 as exited with result {"id": "test_index_get10-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get10-5669078533932717095_out"}
13:42:33 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get10-5669078533932717095
13:42:33 | DEBUG | Thread-16 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-14 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-14 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-14 | handle.py:forward:85 | Writing data to output file
13:42:33 | DEBUG | Thread-14 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-14 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get0-5669078533932717095 complete with exit code: 0
13:42:34 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get0-5669078533932717095 as exited with result {"id": "test_index_get0-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get0-5669078533932717095_out"}
13:42:34 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get0-5669078533932717095
13:42:34 | DEBUG | Thread-16 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-16 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-16 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-16 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get8-5669078533932717095 complete with exit code: 0
13:42:34 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get8-5669078533932717095 as exited with result {"id": "test_index_get8-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get8-5669078533932717095_out"}
13:42:34 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get8-5669078533932717095
13:42:34 | DEBUG | Thread-20 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-18 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-18 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-18 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-18 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-18 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get9-5669078533932717095 complete with exit code: 0
13:42:34 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get9-5669078533932717095 as exited with result {"id": "test_index_get9-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get9-5669078533932717095_out"}
13:42:34 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get9-5669078533932717095
13:42:34 | DEBUG | Thread-20 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-20 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-20 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-20 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get7-5669078533932717095 complete with exit code: 0
13:42:34 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get7-5669078533932717095 as exited with result {"id": "test_index_get7-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get7-5669078533932717095_out"}
13:42:34 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get7-5669078533932717095
13:42:34 | DEBUG | Thread-24 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-22 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-22 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-22 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-22 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-22 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-22 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get6-5669078533932717095 complete with exit code: 0
13:42:34 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get6-5669078533932717095 as exited with result {"id": "test_index_get6-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get6-5669078533932717095_out"}
13:42:34 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get6-5669078533932717095
13:42:34 | DEBUG | Thread-24 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-24 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-24 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-24 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get5-5669078533932717095 complete with exit code: 0
13:42:34 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get5-5669078533932717095 as exited with result {"id": "test_index_get5-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get5-5669078533932717095_out"}
13:42:34 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get5-5669078533932717095
13:42:34 | DEBUG | Thread-28 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-26 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-26 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-26 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-26 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-26 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get4-5669078533932717095 complete with exit code: 0
13:42:34 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get4-5669078533932717095 as exited with result {"id": "test_index_get4-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get4-5669078533932717095_out"}
13:42:34 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get4-5669078533932717095
13:42:34 | DEBUG | Thread-28 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-28 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-28 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | Thread-28 | handle.py:forward:85 | Writing data to output file
13:42:34 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get3-5669078533932717095 complete with exit code: 0
13:42:34 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get3-5669078533932717095 as exited with result {"id": "test_index_get3-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get3-5669078533932717095_out"}
13:42:34 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get3-5669078533932717095
13:42:35 | DEBUG | Thread-32 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-30 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-30 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-30 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-30 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-30 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get2-5669078533932717095 complete with exit code: 0
13:42:35 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get2-5669078533932717095 as exited with result {"id": "test_index_get2-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get2-5669078533932717095_out"}
13:42:35 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get2-5669078533932717095
13:42:35 | DEBUG | Thread-32 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-32 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-32 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-32 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get1-5669078533932717095 complete with exit code: 0
13:42:35 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get1-5669078533932717095 as exited with result {"id": "test_index_get1-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get1-5669078533932717095_out"}
13:42:35 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get1-5669078533932717095
13:42:35 | DEBUG | Thread-36 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-34 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-34 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-34 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-34 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-34 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | MainThread | processes.py:run:76 | Process test_index_get-5669078533932717095 complete with exit code: 0
13:42:35 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_get-5669078533932717095 as exited with result {"id": "test_index_get-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_get-5669078533932717095_out"}
13:42:35 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_get-5669078533932717095
13:42:35 | DEBUG | Thread-36 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-36 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-36 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | Thread-36 | handle.py:forward:85 | Writing data to output file
13:42:35 | DEBUG | MainThread | processes.py:run:76 | Process test_index_post-5669078533932717095 complete with exit code: 0
13:42:35 | DEBUG | MainThread | __init__.py:_register_result:299 | Registering test_index_post-5669078533932717095 as exited with result {"id": "test_index_post-5669078533932717095", "file": "/Users/augusto/projects/actix_test/src/main.rs", "code": 0, "output": "/var/folders/p3/z4h10jyj67s5wwty5lp8gn6w0000gn/T/ultest020djlle/__Users__augusto__projects__actix_test__src__main_rs/test_index_post-5669078533932717095_out"}
13:42:35 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group test_index_post-5669078533932717095
13:42:54 | DEBUG | MainThread | __init__.py:_handle_coroutine:60 | Starting job with group update_positions
13:42:54 | INFO | MainThread | tracker.py:_async_update:57 | Updating positions in /Users/augusto/projects/actix_test/src/main.rs
13:42:54 | DEBUG | MainThread | file.py:parse_file_structure:25 | Converted pattern {'test': ['\\v\\s*%(async )?fn\\s+(\\w+)'], 'namespace': []} to {'test': [re.compile('\\s*(?:async )?fn\\s+(\\w+)')], 'namespace': []}
13:42:54 | ERROR | MainThread | logging.py:__deferred_flog:62 | Error name 'recorded_tests' is not defined converting args to str f"Removing tests {[recorded for recorded in recorded_tests]} from {file_name}"
13:42:54 | DEBUG | MainThread | __init__.py:_handle_coroutine:80 | Finished job with group update_positions

I don't seem to be seeing any issues with rust tests, could you share the sample project you're using?

same issue

@y1rn Can you provide a sample project or point to an open source repo which I can use to reproduce locally?

@y1rn Can you provide a sample project or point to an open source repo which I can use to reproduce locally?

it works when double check this issue, without change any configuration and plugin update.

Hi,
I'm sorry for the delay. It was a hectic week.
Here's an example project.
Archive.zip

Ah I see now the issue. This is a vim-test bug, not vim-ultest. If you run TestNearest it will produce the same problem. I've submitted a PR to vim-test https://github.com/vim-test/vim-test/pull/635

Closing as the fix has now been merged


pyproto: remove inventory from implementation

This is a refactoring for #[pyproto] which uses dtolnay specialization instead of inventory as the underlying implementation.
The dtolnay specialization is done for a type PyClassProtocols<T: PyClass>. There are traits PyObjectProtocolSlots<T> etc. which are what get specialized. The default implementation is PyObjectProtocolSlots<T> for &'_ PyClassProtocols<T>, and the specialized implementation is PyObjectProtocolSlots<T> for PyClassProtocols<T>.
The traits with slot getter methods have been replaced by free functions to implement the slots, which the pyproto macro code directly uses.
It works out as slightly fewer LOC and also because all the protocols are known at compile time, the compiler should be able to optimise pyclass initialization better.
At the moment we lost the type checking we had with TypedSlot. If that's a concern I think I can reintroduce a type check in the slot defs in the macro code.
Follow-ups:

I think I can see a way to refactor the code further to implement #1206, but I'm not entirely sure it'll work out. So I stopped here for now which works nicely and I think is a nice simplification.
I think that we can make inventory an optional feature where it's only needed when users want multiple #[pymethods] blocks for a single PyClass. That'd be a nice simplification to remove overheads.

Awesome, thank you so much!
Though I don't think the inventory overhead is large, it seems good for me to have a simplified implementation.

The traits with slot getter methods have been replaced by free functions to implement the slots, which the pyproto macro code directly uses.

Aren't these changes actually unrelated to removing inventory? I like the way it flattens the ffi functions, though.
At a glance,  this PR looks almost OK for me.
I feel that we can make things simpler in pyo3-derive-backend/src/defs.rs, but am not sure and need to check it again.

Aren't these changes actually unrelated to removing inventory?

Sort of - I wanted the new specialised traits to provide &'static [PyType_Slot] lists. I ran into various issues with const fn unless I flattened the getter methods away.

I feel that we can make things simpler in pyo3-derive-backend/src/defs.rs, but am not sure and need to check it again.

I think I can hard-code some simplifications about the paths in defs.rs - I'll push a commit to do so.

I pushed a commit which puts the module path on the top-level Proto def rather than each slot def. This reduces repetition and LOC a bit.
As I think these defs might have to change again to implement #1206 in the way I imagine, I think it's not worth doing further refactoring right now.

@kngwyu ok if I merge this today before the release? It technically "breaks" any code using the #[doc(hidden)] public implementation details of pyproto (though hopefully that's nobody), so it could be nicer to release as part of a major version.

👍 will merge this shortly, then rebase the release and push it out!


Tts start reading as streaming the response

Requirements

[X] I have searched the issues of this repository and believe that this is not a duplicate
[X] I can confirm this feature request is not already implemented in the app

Description
The tts google engine have to wait till the response is fully generated to start reading it.
Possible solution
Please make so that it start reading while the response is being streamed and not wait till it's fully generated.
Additional context
No response

Keep it in mind maybe another tts app can be used even if we need to install a third part app.
Ps. Google tts engine isn't high quality and it will probably be for the best to use a separate app that have higher quality tts models.


[Install and run the dashboard] Need to update the doc

Description:
Doc : https://ei.docs.wso2.com/en/latest/micro-integrator/administer-and-observe/working-with-monitoring-dashboard/
Need to add "/bin" as following, under the section called "Install and run the dashboard ".
Open a terminal, navigate to the MI_DASHBOARD_HOME/bin directory, and execute the following command to start the dashboard server.

Fixed.
https://ei.docs.wso2.com/en/latest/micro-integrator/administer-and-observe/working-with-monitoring-dashboard/


dvtv extractor does not work

[x] I've verified and I assure that I'm running youtube-dl 2018.12.09

Before submitting an issue make sure you have:

[x] At least skimmed through the README, most notably the FAQ and BUGS sections
[x] Searched the bugtracker for similar issues including closed ones
[x] Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

What is the purpose of your issue?

[x] Bug report (encountered problems with youtube-dl)

dvtv extractor stopped to work recently. I think the site changed player.
https://github.com/rg3/youtube-dl/blob/master/youtube_dl/extractor/dvtv.py
$ youtube-dl -v https://video.aktualne.cz/dvtv/havlikova-zeny-vydelavaji-mene-nez-muzi-a-doma-je-ceka-druha/r~70ab783ef7af11e8bf040cc47ab5f122/
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'https://video.aktualne.cz/dvtv/havlikova-zeny-vydelavaji-mene-nez-muzi-a-doma-je-ceka-druha/r~70ab783ef7af11e8bf040cc47ab5f122/']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2018.12.09
[debug] Python version 3.6.4 (CPython) - Linux-4.18.0-2-amd64-x86_64
[debug] exe versions: ffmpeg 4.0.3-1, ffprobe 4.0.3-1
[debug] Proxy map: {}
[dvtv] 70ab783ef7af11e8bf040cc47ab5f122: Downloading webpage
ERROR: Could not find neither video nor playlist; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Definitely looks like the extractor needs to be updated.
This looks like a good place to start:
tracks: {"HLS":[],"DASH":[],"MP4":[{"src":"https:\/\/1053041200.rsc.cdn77.org\/migration\/d3\/1a7d31ea884d36c1b8ea98f6acf1e772_0720m_01_16.mp4","type":"video\/mp4","label":"720p"},{"src":"https:\/\/1053041200.rsc.cdn77.org\/migration\/d3\/1a7d31ea884d36c1b8ea98f6acf1e772_0360m_01_10.mp4","type":"video\/mp4","label":"360p","default":true},{"src":"https:\/\/1053041200.rsc.cdn77.org\/migration\/d3\/1a7d31ea884d36c1b8ea98f6acf1e772_0180m_01_6.mp4","type":"video\/mp4","label":"180p"}]}

It has direct links to the video in MP4 in various qualities.
Here's the full <script> block that it's in for anyone who wants to try:
<script type="text/javascript">

	BBXPlayer.id = 'embeddc0768de855511e49e4b0025900fea04';
			BBXPlayer.setup(
{
	autoplay: true,
	width: '782',
	preferredLang: ['cze', 'en'],
	language: 'cs',
	height: '440',	duration: 1484,
	title: 'Vondra o Českém století: Při pohledu na Havla mi bylo trapně',
	tracks: {"HLS":[],"DASH":[],"MP4":[{"src":"https:\/\/1053041200.rsc.cdn77.org\/migration\/d3\/1a7d31ea884d36c1b8ea98f6acf1e772_0720m_01_16.mp4","type":"video\/mp4","label":"720p"},{"src":"https:\/\/1053041200.rsc.cdn77.org\/migration\/d3\/1a7d31ea884d36c1b8ea98f6acf1e772_0360m_01_10.mp4","type":"video\/mp4","label":"360p","default":true},{"src":"https:\/\/1053041200.rsc.cdn77.org\/migration\/d3\/1a7d31ea884d36c1b8ea98f6acf1e772_0180m_01_6.mp4","type":"video\/mp4","label":"180p"}]},
	adverttime: -1,
	mediaid: 'dc0768de855511e49e4b0025900fea04',
	ads: true,
	single: true,
	startTime: 0,
	debug: true,
	plugins: {
						playedTicks: { },
		tracking: { },
		Etrack: { },
		settings: {
			qualities: { }
		},
		measuring: {
			streamInfo: {
				programID: 'dc0768de855511e49e4b0025900fea04',
				programName: 'Vondra o Českém století: Při pohledu na Havla mi bylo trapně',
				programType: 'video',
				series: htmldeentitize('video'),
				programDuration: 1484,
				videoID: 'dc0768de855511e49e4b0025900fea04'
			},
			services: {
				gemius: {
					playerID: 'embeddc0768de855511e49e4b0025900fea04',
					accountID: 'zU2aoeepfyJK4blK4Y4azGZUDmyNkcMAjJOP1xqs2rD.r7'
				}
			}
		},
			}
}
);
	BBXPlayer.runSetup();

</script>

Source is the first test video in the extractor: http://video.aktualne.cz/dvtv/vondra-o-ceskem-stoleti-pri-pohledu-na-havla-mi-bylo-trapne/r~e5efe9ca855511e4833a0025900fea04/


gray text for mask, black text for entered characters

This seems like it may be too much work as you would have to do something on each key press. For example, a date mask:
YYYY-MM-DD
then you start typing:
2013-11-DD
but it would do something like this under the hood:
< span class="blacktext" >2013-11-< /span >< span class="graytext" >DD< /span >
Or is this not a reasonable request?
If this is not possible how do i have the mask always show up as YYYY-MM-DD and then become "____ - __ - __" when i click in the input? (clearMaskOnLostFocus: false) and something else i would assume...
Thanks

@aveyD ,
There is the colormask now


Affix errors when clicking start new world

I started a brand new instance (AT Launcher) and added ONLY Apotheosis and it's required dependencies. It throws a number of affix errors as noted in the quote below. This is triggered when I click on "Single Player" from the main menu (it also happens when I delete a world, or when I click "Create New World").
I have seen other similar issues listed, but not a bare-bones case. Is this expected?
Thanks
latest.log
MC: 1.20.1
Forge: 47.3.5
Full Mod List:

Apotheosis-1.20.1-7.4.0
ApothicAttributes-1.20.1-1.3.6
Patchouli-1.20.1-84-FORGE
Placebo-1.20.1-8.6.2

Errors:

[13/08/2024 19:19:14 PM] [Render thread/ERROR] Insufficient number of affixes to satisfy the loot rules (ignoring backup rules) of rarity apotheosis:mythic for category helmetRequired: 3; Provided: 2
[13/08/2024 19:19:14 PM] [Render thread/ERROR] Insufficient number of affixes to satisfy the loot rules (ignoring backup rules) of rarity apotheosis:mythic for category bootsRequired: 3; Provided: 2
[13/08/2024 19:19:14 PM] [Render thread/ERROR] Insufficient number of affixes to satisfy the loot rules (ignoring backup rules) of rarity apotheosis:ancient for category bowRequired: 5; Provided: 4
[13/08/2024 19:19:14 PM] [Render thread/ERROR] Insufficient number of affixes to satisfy the loot rules (ignoring backup rules) of rarity apotheosis:ancient for category crossbowRequired: 5; Provided: 4
[13/08/2024 19:19:14 PM] [Render thread/ERROR] Insufficient number of affixes to satisfy the loot rules (ignoring backup rules) of rarity apotheosis:ancient for category pickaxeRequired: 5; Provided: 4
[13/08/2024 19:19:14 PM] [Render thread/ERROR] Insufficient number of affixes to satisfy the loot rules (ignoring backup rules) of rarity apotheosis:ancient for category shovelRequired: 5; Provided: 4
[13/08/2024 19:19:14 PM] [Render thread/ERROR] Insufficient number of affixes to satisfy the loot rules (ignoring backup rules) of rarity apotheosis:ancient for category shieldRequired: 5; Provided: 4
[13/08/2024 19:19:14 PM] [Render thread/ERROR] Insufficient number of affixes to satisfy the loot rules (ignoring backup rules) of rarity apotheosis:ancient for category helmetRequired: 4; Provided: 2
[13/08/2024 19:19:14 PM] [Render thread/ERROR] Insufficient number of affixes to satisfy the loot rules (ignoring backup rules) of rarity apotheosis:ancient for category bootsRequired: 4; Provided: 2

Duplicate of #1051


Small Caps

I have a font that supports small caps but can't figure out how to use those small caps in the pdf. I tried hacking in and modifying the .json Flags property to include Small Caps flag (1 << 18) but no effect. Any Idea?

I was not familiar with that smalls caps descriptor flag, and am not quite sure how OpenType implements small caps. If the font simply replaced lower case letters with small caps, one could use AddFont() as in this example. If the font supports Unicode small caps I think a code page file would need to be made for it. I have seen an FPDF add-on solution that generates its own small caps and provides a new method for Cell(),  but that would not take advantage of native small caps.

I was able to create a custom font that froze Small Caps into the lowercase letters using this tool:
https://github.com/twardoch/fonttools-utils/tree/master/pyftfeatfreeze

Excellent tool -- I am glad to learn of it.
If you care to write up a short summary I will put it into gofdpf's documentation.


Repeating socket disconnected error when webpack process killed

Type:

[x] bug
[ ] feature
[ ] enhancement
[ ] question

Environment:

OS: macOS
Browser: Chrome
Library Version: v1.1.0

I'm going to open a PR:

[ ] yes
[x] no

Description:
Awesome plugin! Thanks for writing it.
Seems like when the webpack (v4) in development+watch mode process gets killed the socket is not being closed causing the extension's background script to keep throwing errors trying to connect. It doesn't stop trying until webpack is ran again and the socket is available.
Here's a link to where it happens in the code.

I marked that I'm not going to open a PR but I'd be happy to work on it when I have some time if you can't.

@ybentz do you have a workaround for the time being?

Sorry, haven't had the time to try so for now I just ignore the errors.

I forked this, deleted the code that tries to reconnect, and converted one warning message to a regular log entry. This gets rid of the errors from when you stop the watch process. I am not sure what other side effects it might have. Use at your own risk. You can add this version to your project via yarn remove webpack-extension-reloader && yarn add -D https://github.com/rhaksw/webpack-extension-reloader.git
My process for developing extensions is now,

NODE_ENV=development webpack --watch
Hit the reload icon on the extension's box in chrome://extensions/ (or Load unpacked if I haven't yet loaded the folder)
Reload any impacted pages
Develop as normal, steps 2 and 3 happen automatically

I'm also able to suspend my machine and come back to it without having to redo steps 1-3, running Ubuntu 19.04.

I dug into this a little deeper and it appears this type of error cannot be hidden. I guess the hint in the code Attempting to reconnect (tip: Check if Webpack is running) is suggesting the fix would be to check if Webpack is running before attempting the connection. Since I am developing extensions alongside a website, I often have another instance of webpack running for the site. I'm not sure how to check if webpack is running for a specific project. Perhaps there is a way to do it.
For now, the choices appear to be,

ignore the errors
clear the errors manually after stopping and starting webpack
use the fork I made above which prevents reconnects, and manually reload the extension + impacted pages in Chrome whenever you restart webpack

I prefer #3 because it's easy to remember to click reload once in the beginning, and the WebSocket connection errors make it harder for me to know if there were errors happening in my own extension's background page.

Hello, thanks for the feedback and sorry for the delay, it has been a tough year for me :(
So why let the socket keep on retrying to connect and why I think this isn't a bug:
First, there's no way to differentiate if it went down by an error or you simply killed webpack process.
Second, I can try to send a SIGKILL to the socket inside the extension and make it stop retrying, but when you run the webpack again, how to restart it? Remember the extension will be totally isolated if it's not connected anymore. You will need to remove the extension and add it again (not good)
The error there appears because is a network error. Although the exception is catch to not show the annoying red text, Chrome wil show network errors a side of the JS one (no way on JS side to not make it show)
As there's no good solution for this, just ignore it, whenever you connect again the socket will successfully connect to webpack-extension-reloader and all will be fine :)


Artifact 'aspectjrt' does not come transitively in development

But does in production. See "TODO" in HugoPlugin's project.dependencies block.

I'm suffering from the same problem. I had to add compile 'org.aspectj:aspectjrt:1.8.5' to my android project. Is this mandatory?
I added the dependency, because I was getting the following message in my build:
classpath error: unable to find org.aspectj.lang.JoinPoint (check that aspectjrt.jar is in your classpath)
Info:
hugo-plugin:1.2.1
android gradle plugin 1.1.3


Impossible to train if mask images have less than 5 regions

This seems to be a feature and not a bug, but this is very problematic for datasets in which images contain only one object to segment.
Suggested solution: make an option in the training GUI to change the value of models.train.rescale or models.train.min_train.masks

good point, I've set min_train_masks option to 1 for the train GUI please pip install git+https://github.com/mouseland/cellpose.git to try it out


Cursor theme not set properly

Adwaita is set as cursor theme instead of Breeze.

Fixed with: 4a1d2ee2ec47e2139a9bf6ea7b828b5d431ec167


Update Readme and add references in notebooks

Purpose

...

Does this introduce a breaking change?

[ ] Yes
[ ] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Get the code

git clone [repo-address]
cd [repo-name]
git checkout [branch-name]
npm install

Test the code

What to Check
Verify that the following are valid

...

Other Information

Handled message formats, standardized display messages, corrected file names


The main window opens each time when a message comes on Linux Mint 19.3

My Setup

Operating System: Linux Mint 19.3 Tricia
App Version: 2.17.9
Installation type: from Linux Mint default repository (UI)

[    ] I have tested with the latest version
[ x ] I can simulate the issue easily

Description

The main window opens each time when a message comes. It's very noisy.
Steps to reproduce:

Launch application.
Minimize to tray.
Wait until a message comes.

Current Behavior

The main window of application opens the main window each time when a message comes.
Expected Behavior

The application opens only on demand.

This is weird, I don't think this happens in other linux distros (never heard of it anyway). Doesn't happen in catalina too. Needs more investigation.

Same problem on macOS Mojave 10.14.5 with app version 2.17.9.

Please test if the latest release did solve this. If not please reopen the issue or create a new one and tell us. I will be closing this one for now.
Thank you!


code review: potential thread safety issue in cache.go

I have been working with the cache code over the last few days (see #5689) and have noticed some lines in the cache code that appear to be lacking thread safety:
In particular:
https://github.com/influxdata/influxdb/blob/master/tsdb/engine/tsm1/cache.go#L61-L62
contains these lines:
e.values = e.values.Deduplicate()
e.needSort = false

It appears the assumption in the code is that every thread will observe those two statements executing in that order. In other words, that the deduplicated e.values will be assigned before e.needStore is set to false.
However, AFAICT these lines are not guarded with any kind of memory barrier or synchronization. Indeed, this comment in one of the ultimate callers of these lines (https://github.com/influxdata/influxdb/blob/master/tsdb/engine/tsm1/engine.go#L435-L438) indicates that locks are not held precisely to avoid inducing lengthy delays in concurrently executing code.
The problem is, however, that without some kind of synchronization construct, a CPU is free re-order the assignments so that the assignment to needsSort  actually happens before the assignment to values - at least from the perspective of concurrently executing threads/goroutines.
One implication of this is that a query might obtain a reference to an undeduplicated values slice when it is expecting to receive a reference to a deduplicated slice. I can't actually predict how this would manifest itself in user level symptoms, but it might be worth considering whether some thread safety disciplines need to be applied to this code.

/cc @jwilder
@jonseymour I think we may just need to add a cache lock to cache.Deduplicate.  The engine lock referred to in WriteSnapshot is no the same lock as the Cache one.
e.deduplicate has two callers, c.Deduplicate and c.merged. c.merged already acquires the c.mu lock.

Yep, I have added a lock to Cache.Deduplicate, but only around the updating of c.store. The de-duplication itself is still done outside of the lock, but on a clone of the original which won't be visible to another thread.

Not sure I agree that there is a problem here.  Those statements should never be re-ordered because they are executed in the same goroutine and re-ordering them would change the behavior of the program.  This would violate the Go memory model: https://golang.org/ref/mem#tmp_2

The statements about "re-ordering them would change the behavior of the program" is true, but only for the gorourtine in which the occur. So yes, from the perspective of a single go-routine (the one executing the statements) the two statements must appear to execute in the specified order.
They key part of the Go memory model that applies in this case are these words;
"Within a single goroutine, there is no concurrency, so the two definitions are equivalent: a read r observes the value written by the most recent write w to v. When multiple goroutines access a shared variable v, they must use synchronization events to establish happens-before conditions that ensure reads observe the desired writes."
This is the problem here - other go routines executing accessing the same data structure "must use synchronization events to establish happens-before conditions that ensure that reads observe the desired writes" (per the memory model)

@jonseymour but all this seems to be a moot point if there is simply a lock put on cache.Deduplicate, no? Since at that point only one goroutine will be able to access c.store at any given point.

The problem with doing that is that it locks out every other goroutine from access to that snapshot for the duration of the deduplication process which @jwilder has already determined (correctly, I believe) to causing severe performance issues in high load situations.
The reason is, if the lock goes around the body of the entire method then that lock is in the request path of virtually every write and query request. With the lock in the position I have placed it, the lock is held for the small possible amount of time and requests will not be impeded during the expensive phase of the deduplication.

@jwilder I've created a test case that uses the go race detector to demonstrate the race condition I was concerned about and is the subject of this report.
greywedge2:tsm1 jonseymour (3)$ git checkout b8f7f3c
Note: checking out 'b8f7f3c'.

greywedge2:tsm1 jonseymour (3)$ GORACE=history=1000 go test -race cache_race_test.go
==================
WARNING: DATA RACE
Read by goroutine 65:
  github.com/influxdb/influxdb/tsdb/engine/tsm1.(*Cache).merged()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache.go:253 +0x3bd
  github.com/influxdb/influxdb/tsdb/engine/tsm1.(*Cache).Values.func1()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache.go:209 +0xa3
  github.com/influxdb/influxdb/tsdb/engine/tsm1.(*Cache).Values()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache.go:210 +0x142
  command-line-arguments_test.TestCacheRace.func1()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache_race_test.go:42 +0x90

Previous write by goroutine 114:
  [failed to restore the stack]

Goroutine 65 (running) created at:
  command-line-arguments_test.TestCacheRace()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache_race_test.go:43 +0xaf8
  testing.tRunner()
      /usr/local/Cellar/go/1.5.3/libexec/src/testing/testing.go:456 +0xdc

Goroutine 114 (running) created at:
  command-line-arguments_test.TestCacheRace()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache_race_test.go:52 +0xb7e
  testing.tRunner()
      /usr/local/Cellar/go/1.5.3/libexec/src/testing/testing.go:456 +0xdc
==================
==================
WARNING: DATA RACE
Read by goroutine 65:
  runtime.slicecopy()
      /usr/local/Cellar/go/1.5.3/libexec/src/runtime/slice.go:110 +0x0
  github.com/influxdb/influxdb/tsdb/engine/tsm1.(*Cache).merged()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache.go:276 +0x86c
  github.com/influxdb/influxdb/tsdb/engine/tsm1.(*Cache).Values.func1()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache.go:209 +0xa3
  github.com/influxdb/influxdb/tsdb/engine/tsm1.(*Cache).Values()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache.go:210 +0x142
  command-line-arguments_test.TestCacheRace.func1()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache_race_test.go:42 +0x90

Previous write by goroutine 114:
  [failed to restore the stack]

Goroutine 65 (running) created at:
  command-line-arguments_test.TestCacheRace()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache_race_test.go:43 +0xaf8
  testing.tRunner()
      /usr/local/Cellar/go/1.5.3/libexec/src/testing/testing.go:456 +0xdc

Goroutine 114 (running) created at:
  command-line-arguments_test.TestCacheRace()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache_race_test.go:52 +0xb7e
  testing.tRunner()
      /usr/local/Cellar/go/1.5.3/libexec/src/testing/testing.go:456 +0xdc
==================
==================
WARNING: DATA RACE
Write by goroutine 114:
  github.com/influxdb/influxdb/tsdb/engine/tsm1.(*entry).deduplicate()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache.go:61 +0xbd
  github.com/influxdb/influxdb/tsdb/engine/tsm1.(*Cache).Deduplicate()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache.go:155 +0xc5
  command-line-arguments_test.TestCacheRace.func2()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache_race_test.go:50 +0x76

Previous read by goroutine 10:
  github.com/influxdb/influxdb/tsdb/engine/tsm1.(*Cache).merged()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache.go:253 +0x3bd
  github.com/influxdb/influxdb/tsdb/engine/tsm1.(*Cache).Values.func1()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache.go:209 +0xa3
  github.com/influxdb/influxdb/tsdb/engine/tsm1.(*Cache).Values()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache.go:210 +0x142
  command-line-arguments_test.TestCacheRace.func1()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache_race_test.go:42 +0x90

Goroutine 114 (running) created at:
  command-line-arguments_test.TestCacheRace()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache_race_test.go:52 +0xb7e
  testing.tRunner()
      /usr/local/Cellar/go/1.5.3/libexec/src/testing/testing.go:456 +0xdc

Goroutine 10 (finished) created at:
  command-line-arguments_test.TestCacheRace()
      /Users/jonseymour/ninja/go/src/github.com/influxdb/influxdb/tsdb/engine/tsm1/cache_race_test.go:43 +0xaf8
  testing.tRunner()
      /usr/local/Cellar/go/1.5.3/libexec/src/testing/testing.go:456 +0xdc
==================
PASS
Found 3 data race(s)
FAIL	command-line-arguments	1.183s

To reproduce yourself, execute the following commands:
git checkout b8f7f3c
GORACE=history=1000 go test -race cache_race_test.go


Strange behaviour with ActiveRecord

After enabling arel_extensions some of my tests started failing, specifically ones verifying the results meet a certain order. If I remove the gem, the tests pass. The strange behaviour I'm seeing is:
> Job::Task.ordered.pluck(:position)
=> [1, 2, 3, 0]

> Job::Task.ordered.to_sql
=> "SELECT \"job_tasks\".* FROM \"job_tasks\" ORDER BY \"job_tasks\".\"position\" ASC"

> Job::Task.ordered.first.position
=> 0

> Job::Task.ordered.last.position
=> 3

> Job::Task.ordered.map {|t| t.position }
=> [1, 2, 3, 0]

> ActiveRecord::Base.connection.exec_query(Job::Task.ordered.select(:id,:position).to_sql).to_a
=> [{"id"=>118, "position"=>0}, {"id"=>115, "position"=>1}, {"id"=>116, "position"=>2}, {"id"=>117, "position"=>3}]

> Job::Task.ordered.select(:id,:position).to_a
=> [#<Job::Task id: 115, position: 1>, #<Job::Task id: 116, position: 2>, #<Job::Task id: 117, position: 3>, #<Job::Task id: 118, position: 0>]

Is this a known issue? Any hints on how I can dig deeper to understand what may be causing this?
TIA

Upon closer inspection, this may be related to the postgresql visitor as it's the only arel-extensions code being executed, as per the trace: https://gist.github.com/cpinto/cd84e67bdbb48e706a05fa0ce94b6f6f

I'm just learning Ruby/Rails so this may be off: what I found is that this change causes the problem, by reseting the order array: https://github.com/Faveod/arel-extensions/commit/b3f0e7112b22edabd67c67136290d2bd1275d03b.
I can't seem to find a bug report attached to the patch.
When the method visit_Arel_Nodes_SelectStatement is called, the collector.value is ["",[]]. I'm not sure what's causing it. However if I change the if statement from this:
if !collector.value.blank? && o.limit.blank? && o.offset.blank?
to this:
if !collector.value.reject{|e| e.blank?}.blank? && o.limit.blank? && o.offset.blank?
I get the intended result.
Could this be related to any recent changes in AR?

Hi Celso,
Thank you for bringing this issue to us.
It appears it has been some changes on the use of the collector in ActiveRecord/Arel.
As you pointed it out, the collector.value is now an array that contains the sql query string and the different bindings.
I just push a new commit on git, that should support this new behavior.
Regards,

@jdelporte thank you very much for looking into this.