Memory issues fixes

Generalizing Accumulators, FastTemplate
Custom pdfs that require RooHistFunc (main memory issue when histograms have large number of bins)
Possibly also generalize hist. pdf interpolators for double vs floating-point precision
Also contains adjustments done to toy generation and likelihood scan binning (use edge values instead of bin center), but could be reverted.

@hroskes @meng-xiao @carolhungwt: You might want to follow the progress in this PR as well.

Hi Ulascan, thanks for preparing this. I'll need to some time to look through everything in details, but perhaps some general comments first. We have to be a bit careful changing the existing code to make sure that the current behaviour does not change (unless there's a really good reason to change it) and that we don't introduce any performance hits. So for example I see changes to parts of the code not related to fixing this RooDataHist inefficiency, and if possible these should be reverted. And for example with the FastTemplate/Histo classes I see that you have changed the way the integrals are calculated. If possible I would have preferred to leave as much of this code unchanged as possible, but if the changes are really needed for your case it may be better to leave the old FastTemplate classes as they were and have your modified versions as something completely new.

Since this PR is still open, I think it would be worth trying to get this in. @usarica , It would probably help to split up the PR into separate ones to allow for better digestion of what is going on. I see 3 general areas which don't overlap too much

The python models - including the new models
The additional classes - eg  The FastTemplateFunc
Modifications to accumulators and to the main routines (some of which are necessary, some which seem more taste based)

I would say the first two could easily be separated into separate PRs which could nearly immediately be accepted. The 3rd would need a bit more consideration but again to separate it from the other two would very much help.

I include @hroskes as well in the discussion since he also worked on the PR.
We can separate those, and make two PRs, but some of the modifications in (3) were actually based on practical evidence from the HIG-17-011 analysis (which is now going to the CWR). The modifications to the accumulators do not really affect anything, we extensively tested this in HIG-17-011 before going to approval with combination. Their generalization to different types is needed to support FastTemplate addition/subtraction without converting between float and double types back and forth, which could potentially cause lag in a code that can be handled through function calls by reference.
Would you please be more specific about which ones you think are taste based? We are open to suggestions. If you are concerned about the nll->nll+nll0 offset, we gave the reasoning during the presentation that it is often very confusing to have two slightly different meanings for nll0 (log likelihood of initial conditions)  and nll (log likelihood of minimum - nll0). This was especially confusing in the past (in HIG-14-018 analysis) when we changed the initial conditions of 2D observed likelihood scans and tried to merge several such scans when there were convergence issues at different points of the scan. This caused us to lose a couple of days to try to debug and later realize nll actually subtracts nll0. The reasoning was therefore not to complicate the definition of nll by subtracting nll0 from it, avoid unnecessary debugging time to understand it without going into the combine package code itself.
Do any other changes cause concern, for compatibility either now or in the future?

The only two taste based items were indeed the nll0 issue and the centring of the points in the scan of multidimfit. For the latter, I see the option is added to include or not the endpoints so it should be fine. As we already discussed, for the nll0, this is just a case of documentation and in fact removing this constant part can help when the nll is large (since its arbitrary anyway!). Others have used these branches before and have not seemed to suffer the same confusion. For both of these two the (new) documentation will need to be updated to account for these changes so it would be easier to deal with parts which are transparent to the user vs parts which aren't.
In general, I don't see any issues with the PR however, splitting the PRs will help also merge them into the new 81x branch and keep the history a little easier to follow so I would appreciate the split as suggested above.

For nll0, we can revert this change if this will cause confusion in other analyses.
Indeed for other additions, we always kept the default to be the same and added an option for an alternative treatment.
We can work on splitting the PR as you request, but I am just concerned that we may have to create a PR to a PR. If the concern is to merge it in 81x branch, we would be happy to make a separate PR for it; it is not clear to us however if this is also a request to us.

Ok sounds good. So, revert the nll0 and we will better document the names (or add an option there if it would help with the default behaviour as it is without this PR as you've done with the other additions) and split the PR.
I was planning to merge into the 81x branch as I have been doing with other updates. Don't worry about separate PRs for that.

Thank you very much. We can work on this in the next couple of days, hopefully before Monday.

Thanks, and thanks for the hard work in making these edits.
On Wed, May 24, 2017 at 11:52 PM, Ulascan Sarica<EMAIL_ADDRESS>wrote:

Thank you very much. We can work on this in the next couple of days,
hopefully before Monday.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cms-analysis/HiggsAnalysis-CombinedLimit/pull/370#issuecomment-303874404,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABhK27z4LzJp8Tdxw6pf5kSacH2G6npDks5r9LSegaJpZM4MhEO-
.

@usarica Was there any progress made here on splitting the requests?

Hi Nick and Andrew,
We apologize for the long delay.  We will try to avoid this situation in the future by making PRs more frequently and making sure they are short and to the point.
We see that in the meantime there's been further development on something similar, CMSHistFunc.  We expect FastTemplate and FastHisto to be backwards compatible, so CMSHistFunc should still work fine.  Ideally, there shouldn't be two classes that do the same thing, and the two classes should be merged somehow.  We'd prefer to merge the PR now, rather than wait any longer for more differences to appear.
We tried as much as possible to separate the changes from each other, as you requested, but at some point (going back to the Run 1 analysis) it was too difficult to deal with things we don't remember.  We ended up with 5 branches:
HZZ_run1: from the end of the run 1 analysis.  This includes changes from all three groups, unfortunately.  Everything else is on top of that.
combine-options-changes: HZZ_run1 plus some commits reverting the changes to the combine options and adding command line options.  The default behavior should be the same as it is now.  Here's the comparison with HZZ_run1
python-and-new-pdfs: what its name says, except that this is a somewhat older version of the new pdfs that doesn't rely on the new FastTemplate implementation. Comparison with HZZ_run1.
fasttemplates-accumulators-etc: changes to accumulators and update of FastTemplate and pdfs.  Comparison with python-and-new-pdfs.
final: merge of all three, because combine-options-changes adds an accumulator which becomes a template in fasttemplates-accumulators-etc.
We hope this is broken down enough to be simpler to digest.  Please let us know if you need anything else from us.
We just force pushed final into this PR.  If you prefer, we can make intermediate PRs with combine-options-changes followed by python-and-new-pdfs; both intermediate steps should work.
We are in the process of preparing further developments, and we'll keep in close communication with you on those, but we'd prefer to close on this PR before anything else.
Regards,
Ulascan and Heshy

The links were not done properly in my last message.  I edited on github, you can check the links there.

Hi Ulascan, Heshy,
Thanks for the work, I'm ok with almost all of the changes. Personally I would still like to see fitting-time benchmarks with the changes to FastHisto/Template for existing analyses as well as validation that numerical results are unchaged. I'm trying to check this myself for a few different datacards now but it appears there's a few problems:
cd data/tutorials
text2workspace.py simple-counting-experiment.txt
Traceback (most recent call last):
  File "/home/agilbert/CMSSW_TEST/CMSSW_7_4_7/bin/slc6_amd64_gcc491/text2workspace.py", line 53, in <module>
    raise RuntimeError, "Physics model %s in module %s not found, or not inheriting from PhysicsModelBase" % (physModName, physModMod)
RuntimeError: Physics model defaultModel in module HiggsAnalysis.CombinedLimit.PhysicsModel not found, or not inheriting from PhysicsModelBase

I'm able to make a workspace if I give a specific physics model, however for TH1 shape-based workspaces there's a problem trying to run combine:
combine -M MultiDimFit /afs/cern.ch/work/a/agilbert/public/ws_new.root
>>> including systematics
>>> method used to compute upper limit is MultiDimFit
>>> random number generator seed is 123456
Computing limit starting from observation
Constraints of type SimpleGaussianConstraint: 66
Caught exception vector::_M_range_check: __n (which is 26) >= this->size() (which is 26)

Can someone check this?
cheers,
Andrew

Hi Andrew,
Thank you very much for the feedback. Would you be able to provide us with the commands so that we trace the issue? How can we create the workspace file ws_new.root?

I put the whole directory for the cards here: /afs/cern.ch/work/a/agilbert/public/tt
In tt/125 can do  text2workspace.py -o ws_new.root -P HiggsAnalysis.CombinedLimit.PhysicsModel:multiSignalModel --PO "map=^.*/ggH$:r[0,0,20]" -m 125 combined.txt.cmb to produce the workspace. Wouldn't normally specify the multiSignalModel here, but this is just to work around the first issue temporarily.

Hi Andrew,
Just to give an update on this error: I traced the call down to cacheutils::CachingPdf::eval. It looks like realFill_(data, *hit.first) fails. However, it looks like instead of calling cacheutils::CachingPdf::realFill_, the program calls cacheutils::OptimizedCachingPdfT<PdfT,VPdfT>::realFill_.
Is this expected?
Does this problem not occur in the current implementation, without this PR?
When I force the call to cacheutils::CachingPdf::realFill_, I get
CachingPdf::eval: realfill()?
cacheutils::CachingPdf::realFill: data.numEntries()?
cacheutils::CachingPdf::realFill: n=24
cacheutils::CachingPdf::realFill: nonZeroWEntries_=67174400
cacheutils::CachingPdf::realFill: nonZeroW_.size()=0
What is nonZeroW_?
Somehow I suspect this happens independent of the implementation, but could it be a side effect of having to specify the model? Maybe this bug is reproducible if you specify the model in current combine code?

Yes, for standard TH1-based cards combine uses FastVerticalInterpHistPdf2 that has an optimized caching pdf implementation, so the code is doing the correct thing by calling OptimizedCachingPdfT. nonZeroW_ is keeping track of the entries in the dataset with non-zero weight, it gets used as an optimisation later to skip evaluating the pdf when it's not needed. Everything works fine in the current version of combine - so it's very likely there is something in this PR causing the problem.
I doubt it's anything to do with having to specify the model - specifying the model in the current version of combine doesn't lead to any issues.

Hi Andrew,
I found the issue. This is when calling &hpdf_.cache.GetBinContent(end), where end_ is last bin +1.
I will try to fix the calls to end now.

  Ulascan you can pull it.
I still see the issue when running combine.  Also (and I assume this is related) the output of w.Print() is different between the current 74x-root6 and this PR.  Both are attached.
74x-root6
final

Both issues should be fixed now.

I'm still getting the output of w.Print() to be different than before.  It's the same as the one I sent before as "final".
output_1e30c14.txt
On the other hand, the final result of the fit is identical in both cases:
>>> including systematics
>>> method used to compute upper limit is MultiDimFit
>>> random number generator seed is 123456
Computing limit starting from observation
Constraints of type SimpleGaussianConstraint: 66
RooRealVar::r = 1.31082 +/- 0.714598  L(0 - 20)

 --- MultiDimFit ---
best fit parameter values:
   r :    +1.311
Done in 0.00 min (cpu), 0.00 min (real)

Confirm the issues are fixed - however GetBinContent is called elsewhere, in particular the new CMSHistV.h, so presumably would also have to be fixed - however I'd prefer it is this could be fixed without changing the way GetBinContent has to be called.
It also appears something is still broken in text2workspace.py - if I do text2workspace.py -o ws_new.root -P HiggsAnalysis.CombinedLimit.PhysicsModel:multiSignalModel --PO "map=^.*/ggH$:r[0,0,20]" -m 125 combined.txt.cmb as above the physics model is not being applied correctly. The scaling r is applied to all signal processes not just ggH. If I change the name of the POI: `text2workspace.py -o ws_new.root -P HiggsAnalysis.CombinedLimit.PhysicsModel:multiSignalModel --PO "map=^.*/ggH$:r_ggH[0,0,20]" -m 125 combined.txt.cmb`` then a segfault occurs. Neither issue appears in the current release.
Another minor issue, it looks like TH1-based workspaces created with the current branch of combine will no longer be readable once this new branch is merged in, an exception like Caught exception vector::_M_range_check: __n (which is<PHONE_NUMBER>) >= this->size() (which is 0) is thrown which I guess is because of the underlying changes to the storage data format. @nucleosynthesis - how bothered are we about this?

Ok, I see the problem in python, both issues you mention are the same problem.  If no option is given for a process I default to super
https://github.com/hroskes/HiggsAnalysis-CombinedLimit/blob/final/python/PhysicsModel.py#L169-L170
which gives r for signal and 1 for background.  The previous behavior was to default to 1 for everything.  For a signal process, if r doesn't exist, the result is a segfault.
I prefer super in principle, since it would work nicer in the case where you have multiple base classes, but to maintain backwards compatibility, my proposal is to add a magic option "map=[regex]:super" that gives the super() version for anything matching that, and set the default to 1 as before.
The other option is to break backwards compatibility, but give a more transparent error (maybe require all signal processes to be specified, or raise an error if they're not).

The first suggestion is in my final branch, Ulascan you can pull.

Yes, please don't break backwards compatibility - it's a legitimate use to not to specify the scaling of every signal.

Ok, I updated the PR, also applying the 'end' fix to CMSHistV.

Ok thanks, I'll have to test it, though it's still not totally clear to me why the change is needed in the first place, or whether any other code might be affected by the same underlying change. There are also a couple of other calls to GetBinContent in the repository that may or may not be affected. To be honest I would have preferred not to have all these changes that don't seem essential to solving the original problem, i.e. simply allowing the type of the FastHisto storage to be templated.
I think given the number of issues that have surfaced already today I'd propose to postpone merging this into either the 74X or 81X branches until a thorough validation has been completed. From my side I can validate quite a lot with own cards, but we might want to ask the contacts to also take a look at their respective analyses. Sorry that this is dragging on a bit, but I think it's best to be cautious with changing code that is used so widely.

Hi Andrew,
I do not understand this proposal. The only change is the what GetBinContent(end) corresponds to, and we already proceeded with HIG-17-011 with these changes and have observed no changes.

Yes, but please appreciate that combine is used by a very large number of people in CMS, and one analysis does not typically cover all possible use cases. It's good that everything was consistent for HIG-17-011 but we've already seen a number of problems today that would have affected other analyses if we hadn't checked first.  We still have the situation that the output of RooWorkspace::Print seems to have changed for example - maybe this is completely harmless but we need to be certain.

Is there any way we can help further with these checks?

Hi,
I know we've been sitting on this for a long time.  Is there any way these changes can get merged?  Otherwise our analyses will just keep diverging from the official version and the problems will get worse.
Please let us know if there are any further tests or changes you need from us.
Heshy

Hi Heshy, sorry for the delay - I don't think there's anything else we need from your side, just on us now to take care of the merge and complete the validation against existing combine output. Will try to make some progress soon.
cheers, Andrew

Hi Andrew,
We had a lot of progress on the spline pdfs I mentioned previously, and I think they are now ready for a merge as well (checks done by @carolhungwt as part of her analysis).
Since it only involves merging new pdfs, may I kindly ask if the https://github.com/usarica/HiggsAnalysis-CombinedLimit/tree/splinepdfs branch can also be merged into this PR, rather than making another PR? I fear that it will again take some time to merge it.

Hi ulascan,
I should think if the other branch Contains only new pdfs and has already
been tested it would be quicker to put a separate PR for it.
Best
Nick
On 22 Oct 2017 13:27, "Ulascan Sarica"<EMAIL_ADDRESS>wrote:

Hi Andrew,
We had a lot of progress on the spline pdfs I mentioned previously, and I
think they are now ready for a merge as well (checks done by @carolhungwt
https://github.com/carolhungwt as part of her analysis).
Since it only involves merging new pdfs, may I kindly ask if the
https://github.com/usarica/HiggsAnalysis-CombinedLimit/tree/splinepdfs
branch can also be merged into this PR, rather than making another PR? I
fear that it will again take some time to merge it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cms-analysis/HiggsAnalysis-CombinedLimit/pull/370#issuecomment-338473542,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABhK21TW4013EDAAeOclJc-pzbQzB3AQks5suzSXgaJpZM4MhEO-
.

Hi Nick,
Ok, Then should I open the PR from this other branch, with the note that it should be merged after PR #370 (this PR)?

Hi Ula,
Sure if it depends on #370, add a note in the new PR to merge sequentially.
This will make sure that Andrew can finish the checks on #370 and then we
can merge the new PR on top easily.
Nick
On Sun, Oct 22, 2017 at 1:33 PM, Ulascan Sarica<EMAIL_ADDRESS>wrote:

Hi Nick,
Ok, Then should I open the PR from this other branch, with the note that
it should be merged after PR #370
https://github.com/cms-analysis/HiggsAnalysis-CombinedLimit/pull/370
(this PR)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cms-analysis/HiggsAnalysis-CombinedLimit/pull/370#issuecomment-338473963,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABhK21ysS17_VGCRmg7vKOeaIxkKQT0dks5suzYJgaJpZM4MhEO-
.

Hi Nick,
Ok, opened PR #417 with the note after its description.


fix:Unpredictable movements of the dates in the date picker included …

…in the table widget; are decreased by 1 day #25081
Description

[!TIP]
Add a TL;DR when the description is longer than 500 words or extremely technical (helps the content, marketing, and DevRel team).
Please also include relevant motivation and context. List any dependencies that are required for this change. Add links to Notion, Figma or any other documents that might be relevant to the PR.

Fixes #25081
or
Fixes https://github.com/appsmithorg/appsmith/issues/25081

[!WARNING]
If no issue exists, please create an issue first, and check with the maintainers if the issue is valid.

Automation
/ok-to-test tags=""
:mag: Cypress test results

[!CAUTION]
If you modify the content in this section, you are likely to disrupt the CI result for your PR.

Communication
Should the DevRel and Marketing teams inform users about this change?

[ ] Yes
[ ] No

SCREENSHOTS:

Video:Fixing the issue

Summary by CodeRabbit

New Features

Introduced test cases for adding new rows and editing date columns in the table widget.

Bug Fixes

Improved the date selection logic in the table widget to ensure consistent and correct date formatting.

Chores

Added a utility function to retrieve the current date in ISO format with a specific timezone offset.

I would assume the changes in DateCell.tsx do sovle the issue. However I'm not quite sure your test is usefull though I do not know well that testing framework.
Does the test fail before the correction? That would be a good way to check if the test is actually appropriate.
Yea I have checked with the earlier version that was showing a wrong date the test was failing ,later I have modified it and the test is working correctly ,you can verify the cypress testing in the provided link
https://www.loom.com/share/9fb9ef73c7484678840f6ae7d513ada0?sid=3ffcbde5-ed06-4a8c-897c-a852acff4dbb

Sure for me it seems ok

Sure for me it seems ok

@benjamindonze but it seems the merging is still in blocked stage

Well I don't know your processes for merging PR and so, personally I'm just a user that reported a bug I did approve the PR though I don't know if it has any effect as I'm have no specific access rights on this project

hello @Nikhil-Nandagopal ,could you please review the pr

@jsartisan please review this PR. Here is the internal PR
@Harshithazemoso you have written the test using JS ext, please use TS instead.

@jsartisan please review this PR. Here is the internal PR
@Harshithazemoso you have written the test using JS ext, please use TS instead.

@somangshu all the specs are in js ext so I followed the same format ,should I update that ?

I see an error in the build
Error: There's new test files in JS
🔴 There's new test files in JS, please port to TS and re-trigger Cypress tests:
1. app/client/cypress/e2e/Regression/ClientSide/Widgets/TableV2/AddNewRowEditColumn_spec.js

@jsartisan isint that a problem?

@somangshu Seems like there is some check that requires new cypress tests to be in typescript.
@Harshithazemoso Can we write the test in typescript? It help us pass the build check

@somangshu Seems like there is some check that requires new cypress tests to be in typescript.
@Harshithazemoso Can we write the test in typescript? It will help us pass the build check

@jsartisan made the changes can you review it now

Rerunning tests here

Few improvements needed on cypress spec -

Use variables or constants for data and selectors to improve maintainability and readability. ex - Please use [data-testid="t--property-pane-back-btn"] from common locators ie editPropBackButton
_addNewRow instead of .t--add-new-row from app/client/cypress/support/Pages/Table.ts
Use updated helpers from aggregateHelpers
instead on get and click use GetNClick
Move date logic into helper functions or utilities to keep test code clean and focused on test logic.
Write description explaining the spec and what kind of scenario is being tested for more readability
Please use better locators wherever possible.
ex cy.get(".DayPicker-Day--today > .bp3-datepicker-day-wrapper").click();). Use parent or some other locator to click
Remove commented code

hello @ApekshaBhosale made the changes ,can you please review it now

@Harshithazemoso the test that you have written has failed.
AssertionError: Timed out retrying after 60000ms: Expected to find element: `//div[contains(@class,'t--property-control-allowaddingarow')]//input[@type='checkbox'] | //label[text()='Allow adding a row']//input[@type='checkbox']`, but never found it.
    at AggregateHelper.GetElement (cypress/support/Pages/AggregateHelper.ts:256:26)
    at PropertyPane.TogglePropertyState (cypress/support/Pages/PropertyPane.ts:199:17)
    at Context.eval (cypress/e2e/Regression/ClientSide/Widgets/TableV2/AddNewRowEditColumn_spec.ts:32:19)

cc @jsartisan

@Harshithazemoso the test that you have written has failed.
AssertionError: Timed out retrying after 60000ms: Expected to find element: `//div[contains(@class,'t--property-control-allowaddingarow')]//input[@type='checkbox'] | //label[text()='Allow adding a row']//input[@type='checkbox']`, but never found it.
    at AggregateHelper.GetElement (cypress/support/Pages/AggregateHelper.ts:256:26)
    at PropertyPane.TogglePropertyState (cypress/support/Pages/PropertyPane.ts:199:17)
    at Context.eval (cypress/e2e/Regression/ClientSide/Widgets/TableV2/AddNewRowEditColumn_spec.ts:32:19)

cc @jsartisan

@somangshu can you check now

@ApekshaBhosale if you give an approval, I run the test internally.
Or let me know if you want me to run it before you can review.

@ApekshaBhosale if you give an approval, I run the test internally. Or let me know if you want me to run it before you can review.

hello @somangshu its been more than a week there is no update about the pr review

@ApekshaBhosale please check this out!

@nidhi-nair ,@somangshu can you please assign a reviewer for this ticket

@Harshithazemoso apologies, the test still fails with the same error on internal test run.
We will have to close this PR now because the change seems to be more involved.

hange seems to be more involved.

Hello @somangshu ,
Thank you for letting me know about the test results. Could you please provide more details about the specific issue causing the test to fail,The test cases are running fine in my local and  understanding the root cause will help me address it more effectively. Additionally, I would like to know more about why the PR needs to be closed and any next steps we should consider or are there any improvements that needed to be taken care of ?

@Harshithazemoso its the same cypress failure as before.

@Harshithazemoso its the same cypress failure as before.

@somangshu yeah you have mentioned about this change seems to be more involved right ,Can I know additional details about this ?

Since the test keep failing to understand what is happening we need to debug this internally. We know that there is some difference that comes up in local vs github action run.
We do not have the bandwidth to pick this up right now and you dont have the right permissions to check this throughly, hence decided to close it for the time being.

Since the test keep failing, to understand what is happening we need to debug this internally. We know that there is some difference that comes up in local vs github action run. We do not have the bandwidth to pick this up right now and you dont have the right permissions to check this throughly, hence decided to close it for the time being.

Okay ,Somangshu
Thanks for your response

Does it all mean that the issue about the dates won't be fixed now?

Right now there is a workaround available.
We are currently in the process to add a team to address widget based issues, it can be prioritised then.


vNEXT Input System Refactoring and Cleanup

Refactored InputSystem to accept custom InputAction types.

Now all raised events require an InputAction as a parameter.

Cleaned up IMixedRealityInputSystem.

Could there be an InputAction.None? Or would null represent no action?

Null represents no action.

But for the most part, you'll want to use an Input Action if you're using the Input System.
It helps abstract the input you'll be getting from other input sources, controllers, etc.  That way you don't have to wire up unique events for every controller input.

Need to abstract out / remove the #IF UNITY_WSA code to avoid future multi-vr breaking

That doesn't exactly pertain to this PR. Let's open an issue and address that specifically.
This PR only addresses the updates to Input Actions and their usage in the Input System


Improve startup time by storing plugin function in module variable instead of using tagging and inspect

I've created benchmark that compares your current approach with the one I'm suggesting.
You can run this with pytest and with pytest-benchmark installed. But here's the result on my machine
----------------------------------------------------------------------------------------- benchmark: 2 tests ----------------------------------------------------------------------------------------
Name (time in ns)                   Min                     Max                    Mean                 StdDev                  Median                 IQR            Outliers(*)  Rounds  Iterations
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
test_strategies[store]         277.6878 (1.0)       12,090.6252 (1.0)          306.9411 (1.0)          77.6767 (1.0)          285.0002 (1.0)        5.2505 (1.0)      13192;46481  199721          16
test_strategies[tag]       139,222.0001 (501.36)   436,723.9890 (36.12)    147,089.0559 (479.21)   23,119.3189 (297.64)   140,545.0021 (493.14)   772.4993 (147.13)        77;2841399           1
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

(*) Outliers: 1 Standard Deviation from Mean; 1.5 IQR (InterQuartile Range) from 1st Quartile and 3rd Quartile.
============================================================================= 2 passed in 3.77 seconds ==============================================================================

As you can see your current approach is  almost 500 times slower.
I can see only one reason for not changing that - which is some user could have defined this _store variable, but
1. This can be mitigated by using some more or less unique name.
2. You already have this problem in class decorators. Because if user for some evil reason had class attribute _nvim_plugin you would overwrite it.
So you already have the same problem with exactly the same solution (using unique name).
Notice that for 100 functions the time that is needed to find tagged function is more than 100 ms. That's 100 ms of startup time of neovim. For me neovim startup time is about 300-400 ms. That means that for users, that use a lot of python plugins (or plugins that exports a lot of functions) this can be significant portion of startup time. And that's one of the things that I like about vim/neovim. That is so fast to start. Another 100 ms would make it even better.

Very nice. I don't think anyone's attached to the current approach. Are you willing to send a PR? cc @bfredl @tarruda

@justinmk Okay, It seems that working late isn't good for me, because I've mistakenly thought that 139,222.0001 ns is 139 ms, but in fact it is 139 us, which isn't that bad. But I'm still enthusiastic about relative performance improvement. I will try to create pull request later.

@purpleP Ok, first thing to do would be to verify that startup time of nvim improves after making the change. Else the change won't be worth it.

Well, I'll do that just for fun (if I would have time) and you can decide wether you want to merge it or not.


Denser result view on queries

Provide an option to hide/exclude the date and project labels from the results of a query.
As an example, in the query below I'm pulling a list of tasks that all have the same date:
   name: Highest Priority & Date
   filter: "today"
   sorting:
      - priority
      - date
   group: true

The result has a line in between with a "Today" calendar marker showing that the task is due today.

Since the query is already explicitly limiting the results to tasks with a 'today' due date, there's no need to take up the space by adding all those extra lines.
Having a flag to control whether or not these metadata lines are included (because project shows up as well if group:true is omitted) would be very handy.

Nevermind. I just found the feature toggle in the settings. I swear I looked before I submitted this,


bug: sytnatical errors was raised in options3 fixed

Related error
[Error - 5:10:38 PM] Request textDocument/semanticTokens/full failed.
  Message: Internal error
  Code: -32603
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `TerminalLBrack`,
 right: `TerminalLParen`', /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cairo-lang-parser-2.0.2/src/parser.rs:1946:9
Caught panic in LSP worker thread.

@karasakalmt Not sure I see the issue...

@shramee can you please open it in VSCode I got the error above from the Cairo1.0 plugin

Aah, Starklings uses Cairo 2.

We should rename to Starklings Cairo 2 now 😂


Unable to enable<EMAIL_ADDRESS>unit

With following container linux config:
systemd:
  units:
    - name<EMAIL_ADDRESS>      enabled: true

The service is not being enabled after install:
# systemctl status wg-quick@wg0
●<EMAIL_ADDRESS>- WireGuard via wg-quick(8) for wg0
   Loaded: loaded<EMAIL_ADDRESS>disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:wg-quick(8)
           man:wg(8)
           https://www.wireguard.com/
           https://www.wireguard.com/quickstart/
           https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
           https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8

Ignition logs:
# journalctl --all --identifier=ignition | tee ignition.log
-- Logs begin at Tue 2019-06-25 09:11:18 UTC, end at Tue 2019-06-25 11:00:02 UTC. --
Jun 25 09:11:24 localhost ignition[415]: Ignition v0.32.0-1-gca11a02
Jun 25 09:11:24 localhost ignition[415]: reading system config file "/usr/lib/ignition/base.ign"
Jun 25 09:11:24 localhost ignition[415]: no config at "/usr/lib/ignition/base.ign"
Jun 25 09:11:24 localhost ignition[415]: parsed url from cmdline: ""
Jun 25 09:11:24 localhost ignition[415]: no config URL provided
Jun 25 09:11:24 localhost ignition[415]: reading system config file "/usr/lib/ignition/user.ign"
Jun 25 09:11:24 localhost ignition[415]: parsing config with SHA512: 3725a8e2e2a48cfa401debf096c7043f7c9c05e42e2ad046ece6029e7787df6ca2bf9f652399744f98c2be3baf9f2353456ff55fa64baca891e74c6256983a2b
Jun 25 09:11:24 localhost ignition[415]: disks: disks passed
Jun 25 09:11:24 localhost ignition[415]: Ignition finished successfully
Jun 25 09:11:24 localhost ignition[449]: Ignition v0.32.0-1-gca11a02
Jun 25 09:11:24 localhost ignition[449]: reading system config file "/usr/lib/ignition/base.ign"
Jun 25 09:11:24 localhost ignition[449]: no config at "/usr/lib/ignition/base.ign"
Jun 25 09:11:24 localhost ignition[449]: files: compiled without relabeling support, skipping
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(1): [started]  creating or modifying user "core"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(1): executing: "/usr/sbin/usermod" "--root" "/sysroot" "--password" "*" "core"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(1): [finished] creating or modifying user "core"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(2): [started]  setting password for "core"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(2): executing: "/usr/sbin/usermod" "--root" "/sysroot" "--password" "*" "core"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(2): [finished] setting password for "core"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(3): [started]  adding ssh keys to user "core"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(3): [finished] adding ssh keys to user "core"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(4): [started]  creating or modifying user "root"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(4): executing: "/usr/sbin/usermod" "--root" "/sysroot" "root"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(4): [finished] creating or modifying user "root"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(5): [started]  adding ssh keys to user "root"
Jun 25 09:11:24 localhost ignition[449]: files: createUsers: op(5): [finished] adding ssh keys to user "root"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(6): [started]  writing file "/etc/cni/net.d/10-wg.conf"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(6): [finished] writing file "/etc/cni/net.d/10-wg.conf"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(7): [started]  writing file "/etc/cni/net.d/99-loopback.conf"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(7): [finished] writing file "/etc/cni/net.d/99-loopback.conf"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(8): [started]  writing file "/etc/wireguard/wg0.conf"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(8): [finished] writing file "/etc/wireguard/wg0.conf"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(9): [started]  writing file "/var/lib/iptables/rules-save"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(9): [finished] writing file "/var/lib/iptables/rules-save"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(a): [started]  writing file "/etc/containerd/config.toml"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(a): [finished] writing file "/etc/containerd/config.toml"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(b): [started]  writing file "/etc/ssh/sshd_config"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(b): [finished] writing file "/etc/ssh/sshd_config"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(c): [started]  writing file "/etc/hostname"
Jun 25 09:11:24 localhost ignition[449]: files: createFilesystemsFiles: createFiles: op(c): [finished] writing file "/etc/hostname"
Jun 25 09:11:24 localhost ignition[449]: files: op(d): [started]  processing unit "locksmithd.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(d): [finished] processing unit "locksmithd.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(e): [started]  masking unit "locksmithd.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(e): [finished] masking unit "locksmithd.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(f): [started]  processing unit "docker.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(f): [finished] processing unit "docker.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(10): [started]  enabling unit "docker.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(10): [finished] enabling unit "docker.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(11): [started]  processing unit "iptables-restore.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(11): [finished] processing unit "iptables-restore.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(12): [started]  enabling unit "iptables-restore.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(12): [finished] enabling unit "iptables-restore.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(13): [started]  processing unit "wg-quick.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(13): op(14): [started]  writing unit "wg-quick.service" at "etc/systemd/system/wg-quick.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(13): op(14): [finished] writing unit "wg-quick.service" at "etc/systemd/system/wg-quick.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(13): [finished] processing unit "wg-quick.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(15): [started]  enabling unit "wg-quick.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(15): [finished] enabling unit "wg-quick.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(16): [started]  processing unit "containerd.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(16): op(17): [started]  writing systemd drop-in "10-disable-cri.conf" at "etc/systemd/system/containerd.service.d/10-disable-cri.conf"
Jun 25 09:11:24 localhost ignition[449]: files: op(16): op(17): [finished] writing systemd drop-in "10-disable-cri.conf" at "etc/systemd/system/containerd.service.d/10-disable-cri.conf"
Jun 25 09:11:24 localhost ignition[449]: files: op(16): [finished] processing unit "containerd.service"
Jun 25 09:11:24 localhost ignition[449]: files: op(18): [started]  processing unit "sshd.socket"
Jun 25 09:11:24 localhost ignition[449]: files: op(18): op(19): [started]  writing systemd drop-in "10-sshd-port.conf" at "etc/systemd/system/sshd.socket.d/10-sshd-port.conf"
Jun 25 09:11:24 localhost ignition[449]: files: op(18): op(19): [finished] writing systemd drop-in "10-sshd-port.conf" at "etc/systemd/system/sshd.socket.d/10-sshd-port.conf"
Jun 25 09:11:24 localhost ignition[449]: files: op(18): [finished] processing unit "sshd.socket"
Jun 25 09:11:24 localhost ignition[449]: files: op(1a): [started]  processing unit "30-wg0.network"
Jun 25 09:11:24 localhost ignition[449]: files: op(1a): op(1b): [started]  writing unit "30-wg0.network" at "etc/systemd/network/30-wg0.network"
Jun 25 09:11:24 localhost ignition[449]: files: op(1a): op(1b): [finished] writing unit "30-wg0.network" at "etc/systemd/network/30-wg0.network"
Jun 25 09:11:24 localhost ignition[449]: files: op(1a): [finished] processing unit "30-wg0.network"
Jun 25 09:11:24 localhost ignition[449]: files: files passed
Jun 25 09:11:24 localhost ignition[449]: Ignition finished successfully

FYI, this issue happens only on Edge, the only channel that includes wireguard.

My first guess is that ignition does not work with systemd preset, when it tries to deal with instantiated systemd units.
Related issues: https://github.com/coreos/ignition/issues/586 https://github.com/systemd/systemd/pull/9901
However, Flatcar edge has already systemd v241, and the systemd PR https://github.com/systemd/systemd/pull/9901 is already included in v241.
So I'm not completely sure.

I'm having this issue too running Flatcar Edge

first get a status
#systemctl status<EMAIL_ADDRESS>then active the wg-conf
#systemctl start<EMAIL_ADDRESS>this will work ...

this works now on flatcar-stable, beta and alpha


Vignette calibration problem

I am running vignetteCalib on my own dataset - just 30 images to test the approach.
The program produces only black vignette and following output:
Load Dataset samples_vignette3/: found 30 files in folder /images; assuming that all images are there.
Input resolution: 856 480
Input Calibration (fx fy cx cy): 338.125397 194.108505 269.381378 83.858086 1.000000
NO RECTIFICATION
Reading Photometric Calibration from file samples_vignette3/pcalib.txt
Reading Vignette Image from samples_vignette3/vignette.png
PhotometricUndistorter: Invalid vignette image size! got 0 x 0, expected 856 x 480. Set vignette to 1.
Dataset samples_vignette3/: Got 30 files!
SEQUENCE NAME: samples_vignette3/!
plane image values<PHONE_NUMBER>0.000000 - -10000000000.000000!
0.000000 residual terms => -nan
0.000000 residual terms => -nan
plane image values<PHONE_NUMBER>0.000000 - -10000000000.000000!
0.000000 residual terms => -nan
0.000000 residual terms => -nan
...

the output is in the same fashion until the end.
Any idea what might be wrong with my dataset?
Is it possible that it does not work because it is not composed from video capture? (I can only get exposure times for the third column of times.txt when shooting images one by one with the camera)

Hey @fairf4x , Did you end up finding the solution for this? I am also trying to do vignettecalib and pcalib for my camera. For vignette calib, is there a certain way that you need to move the camera or is it just arbitrary? For pcalib, I have no idea where to even get started. Do you know what exactly to do for this?
Thanks in advance.

I didn't manage to produce vignettecalib using vignetteCalib yet, but I was able to produce a pcalib.txt file from my own dataset using responseCalib. I will try to explain the process.
Suppose you have a directory with your dataset called sweepData and you want to use responseCalib to create pcalib.txt for you.

the directory sweepData should have following content:

sweepData:
   camera.txt
   images.zip
   times.txt

camera.txt should contain camera calibration as described here
My camera.txt look like this:

0.39500631 0.40439271 0.31469786 0.17470434 1.0
856 480
none
856 480

It can be written by hand on condition you know the intrinsic parameters for your camera.

images.zip should be an archive of jpg files with names in format: XXXX.jpg where XXXX is imageID (leading zeroes starting with 0000)

times.txt is a text file with three whitespace separated columns:
imageID timestamp exposureTime
Where timestamp is a POSIX time and exposureTime is a real number denoting exposure time in ms

Calling responseCalib like this:
./responseCalib /path/to/data/sweepData/

should produce directory with pcalib.txt

Hey @fairf4x , First off thanks for the response. I understand camera.txt. As per images, i looked at a sample dataset here (https://vision.in.tum.de/data/datasets/mono-dataset?redirect=1) which had a constant image with increasing exposures. What did you use? Also, how did you get the times.txt file or the corresponding data in it?
Thanks in advance.

Hey @fairf4x , So, I used videocapture and v4l2 to get the images with different absolute exposure values. But I am not sure how to get the exposure in msec. I looked at the difference between POSIX time of any consecutive frames and it is always constant(0.67sec (1/15th of a s)as my camera only does 15 fps). Did you have different msec exposure values or about the same?
Thanks in advance.

Hi, I did not capture video. I am experimenting with drone camera so my control over the camera settings is limited. For "sweep" dataset I was using a simple ROS node that automatically shoots a picture after some interval (i.e. 1.5s)
and increases exposure of the camera between -3.0 and +3.0 with step 0.5. The values -/+ 3.0 are bounds for  the camera exposure given by the drone API. I wasn't able to figure out units used here.
My only idea about how the dataset should look like comes from investigation of the sample datasets. Framerate of "sweep" datasets seems to be 10 fps and exposure values are varying from as low as 0.0597894751 to 19.2336845398. This might be in ms. However when I tried to change scale of exposure times in my own dataset (e.g. by multiplying with 100) it did not seem to have any effect on the result of responseCalib. I suspect that the units are not important here.

Thanks for that, @fairf4x . So, I tried out some sample videos/images. I used different sample sizes and scenarios (for the camera). All of them had 12-14 "-nan"s in the front and then regular numbers in the pcalib.txt. In general the numbers are increasing but the distribution of the numbers was not like 0 to 255 like they had in the example. My numbers started from around 60 and went to 255. What were your pcalib.txt numbers like? Did you get any "-nan"s at all? What did your image/video have? Do you have any suggestions that would give me a better pcalib?
Also, did you figure out how to do the vignette calib?
Thanks for your help. I appreciate it.

@vannem95 Inverse of gamma is captured as G(x) which is dumped as '.png' images as the optimization progresses. If there are no images with very low exposure times, they are set to 0 (and hence the inverse of the value is Not a Number). You could solve this by adding images with very low exposure times (preferably, lots of them)
@fairf4x  change the camera.txt to :
0.39500631 0.40439271 0.31469786 0.17470434 1.0
856 480
crop
856 480
ie., none --> crop and this solved a similar problem for me.

@anilprasadmn Thanks. I will try that out. By the way, do you know how to perform vignettecalib?

@vannem95 Yes, I got the vignette calibration working.

Can you tell me the procedure?

You need the pcalib.txt from the responsecalib as an input for vignettecalib. The steps are as described by @fairf4x .
Create a folder with images.zip (or just a folder by the name 'images') of the aruco marker images along with pcalib.txt, camera.txt and  times.txt. (similar to the folder structure for responsecalib with the addition of pcalib.txt )  Once you have this, you can run the vignettecalib on this dataset ( mind the trailing slash )

@anilprasadmn Also are we supposed to move the camera around like they did in the narrow_vignette video?

Yes, you need to essentially tile all of the visible portion of your image view with the marker grid (which is 5 times the markers size, since this region is used for calculation. make sure its a plane)

@anilprasadmn  Cool. Thank you so much for helping out. One last thing, when i did cmake and make, the vignettecalib executable didn't get built in the bin folder like playdataset and responsecalib. Did it get built for you?

You need to have aruco installed for the vignettecalib to be compiled. (It is included in the Thirdparty folder and instructions can be found in the mono dataset github description page)

@anilprasadmn Great. Thank you so much for your help, anil.  Attached is the terminal output i am getting:
Load Dataset /home/vivek/sweepData/: found no in folder /images; assuming that images are zipped.
got 9999 entries and 9999 files from zipfile!
Input resolution: 640 480
Input Calibration (fx fy cx cy):<PHONE_NUMBER>50<PHONE_NUMBER>50<PHONE_NUMBER>00<PHONE_NUMBER>88 0.089228
Out: Crop
Output resolution: 640 480
new K:<PHONE_NUMBER>50<PHONE_NUMBER>50<PHONE_NUMBER>50<PHONE_NUMBER>88
old K:<PHONE_NUMBER>50<PHONE_NUMBER>50<PHONE_NUMBER>00<PHONE_NUMBER>88
FOV Undistorter: Warning! Image has black pixels.
Reading Photometric Calibration from file /home/vivek/sweepData/pcalib.txt
PhotometricUndistorter: Could not open file!
Dataset /home/vivek/sweepData/: Got 9999 files!
loaded 9999 images
init RMSE =<PHONE_NUMBER>47! 	Irradiance 17.220422 - 28.188419
init done
optG RMSE = 30114.734982! 	Inv. Response 28233.615821 -<PHONE_NUMBER>51
OptE RMSE = 27962.417690!  	Irradiance 8.876896 - 28.295072
resc RMSE = 30.205212!  	rescale with 0.001080!
optG RMSE = 29.293719! 	Inv. Response 21.915380 - 297.203783
OptE RMSE = 28.536765!  	Irradiance 0.008563 - 0.029328
resc RMSE = 25.127685!  	rescale with 0.880537!
optG RMSE = 24.489668! 	Inv. Response 17.835236 - 250.958528
OptE RMSE = 23.868996!  	Irradiance 0.007119 - 0.024561
resc RMSE = 24.928692!  	rescale with 1.044396!
optG RMSE = 24.297015! 	Inv. Response 17.647475 - 249.256340
OptE RMSE = 23.681357!  	Irradiance 0.007059 - 0.024371
resc RMSE = 24.908544!  	rescale with 1.051821!
optG RMSE = 24.277392! 	Inv. Response 17.628362 - 249.083994
OptE RMSE = 23.662233!  	Irradiance 0.007053 - 0.024351
resc RMSE = 24.906394!  	rescale with 1.052580!
optG RMSE = 24.275297! 	Inv. Response 17.626335 - 249.065543
OptE RMSE = 23.660191!  	Irradiance 0.007052 - 0.024349
resc RMSE = 24.906168!  	rescale with 1.052661!
optG RMSE = 24.275076! 	Inv. Response 17.626123 - 249.063598
OptE RMSE = 23.659976!  	Irradiance 0.007052 - 0.024349
resc RMSE = 24.906144!  	rescale with 1.052670!
optG RMSE = 24.275053! 	Inv. Response 17.626100 - 249.063394
OptE RMSE = 23.659953!  	Irradiance 0.007052 - 0.024349
resc RMSE = 24.906142!  	rescale with 1.052671!
optG RMSE = 24.275051! 	Inv. Response 17.626098 - 249.063373
OptE RMSE = 23.659951!  	Irradiance 0.007052 - 0.024349
resc RMSE = 24.906142!  	rescale with 1.052671!
optG RMSE = 24.275051! 	Inv. Response 17.626098 - 249.063371
OptE RMSE = 23.659951!  	Irradiance 0.007052 - 0.024349
resc RMSE = 24.906142!  	rescale with 1.052671!
I am using a 15fps logitech 9000 quickcam pro on which i am changing the absolute exposure from 1 to 10000 using uvc drivers. My images is a bent cardboard covering the glossy floor. The exposure in my times.txt is 1000/(absolute exposure){just a guess. don't know how to get the exposure in msec}. Do you see any obvious mistakes i might be doing [or] any suggestions to solve this issue?
Thanks in advance

Can you also provide the times.txt with a sample image?
The value in the 3rd column should be exposure in ms. [shutter speed/ 1000 if you are using v4l2. I read exposure through the exif data since had issues with v4l2] #4

Here is the times.txt:
1492802212.15 0000 0.100010
1492802212.21 0001 0.100020
1492802212.28 0002 0.100030
1492802212.35 0003 0.100040
1492802212.41 0004 0.100050
1492802212.48 0005 0.100060
1492802212.55 0006 0.100070
1492802212.61 0007 0.100080
1492802212.68 0008 0.100090
1492802212.75 0009 0.100100
1492802212.81 0010 0.100110
1492802212.88 0011 0.100120
1492802212.95 0012 0.100130
1492802213.01 0013 0.100140
1492802213.08 0014 0.100150
..
..
..
1492802886.62 9983 62.500000
1492802886.82 9984 66.666667
1492802887.02 9985 71.428571
1492802887.22 9986 76.923077
1492802887.42 9987 83.333333
1492802887.62 9988 90.909091
1492802887.82 9989 100.000000
1492802888.02 9990 111.111111
1492802888.22 9991 125.000000
1492802888.42 9992 142.857143
1492802888.62 9993 166.666667
1492802888.82 9994 200.000000
1492802889.02 9995 250.000000
1492802889.22 9996 333.333333
1492802889.42 9997 500.000000
1492802889.62 9998 1000.000000
I do not have control over exposure in msec. Here are my options on v4l2:
vivek-Precision-T1700: v4l2-ctl --all
Driver Info (not using libv4l2):
Driver name   : uvcvideo
Card type     : UVC Camera (046d:0990)
Bus info      : usb-0000:00:1d.0-1.3
Driver version: 4.4.49
Capabilities  : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04200001
Video Capture
Streaming
Extended Pix Format
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
Width/Height      : 640/480
Pixel Format      : 'YUYV'
Field             : None
Bytes per Line    : 1280
Size Image        : 614400
Colorspace        : sRGB
Transfer Function : Default
YCbCr Encoding    : Default
Quantization      : Default
Flags             :
Crop Capability Video Capture:
Bounds      : Left 0, Top 0, Width 640, Height 480
Default     : Left 0, Top 0, Width 640, Height 480
Pixel Aspect: 1/1
Selection: crop_default, Left 0, Top 0, Width 640, Height 480
Selection: crop_bounds, Left 0, Top 0, Width 640, Height 480
Streaming Parameters Video Capture:
Capabilities     : timeperframe
Frames per second: 15.000 (15/1)
Read buffers     : 0
brightness (int)    : min=0 max=255 step=1 default=128 value=128
contrast (int)    : min=0 max=255 step=1 default=32 value=32
saturation (int)    : min=0 max=255 step=1 default=32 value=32
white_balance_temperature_auto (bool)   : default=1 value=1
gain (int)    : min=0 max=255 step=1 default=0 value=206
power_line_frequency (menu)   : min=0 max=2 default=2 value=2
white_balance_temperature (int)    : min=0 max=10000 step=10 default=4000 value=0 flags=inactive
sharpness (int)    : min=0 max=255 step=1 default=224 value=224
backlight_compensation (int)    : min=0 max=2 step=1 default=1 value=1
exposure_auto (menu)   : min=0 max=3 default=3 value=1
exposure_absolute (int)    : min=1 max=10000 step=1 default=166 value=10000
exposure_auto_priority (bool)   : default=0 value=1
focus (int)    : min=0 max=255 step=1 default=0 value=0
led1_mode (menu)   : min=0 max=3 default=3 value=3
led1_frequency (int)    : min=0 max=255 step=1 default=0 value=0
disable_video_processing (bool)   : default=0 value=0
raw_bits_per_pixel (int)    : min=0 max=1 step=1 default=0 value=0

Here is why i went with that formula(exposure in msec = 1000/absolute exposure).
https://buildyourown.wordpress.com/2009/07/16/skype-logitech-quickcam-pro-9000/
The author of this post said the exposure range is 1/1000 to 1/5 of a sec and earlier versions had 1/10000 to 1/10 of a sec. The range seems to be 5 to 1000 and 10 to 10000 and the range i see on absolute exposure is 1 to 10000. So, i went with 1/10000 to 1/1 of a sec and i have no idea if it's wrong or right. I couldn't find a way to set the shutter speed.

Here is the responsecalib output when i run this dataset:
Load Dataset /home/vivek/sweepData/: found no in folder /images; assuming that images are zipped.
got 9999 entries and 9999 files from zipfile!
Input resolution: 640 480
Input Calibration (fx fy cx cy):<PHONE_NUMBER>50<PHONE_NUMBER>50<PHONE_NUMBER>00<PHONE_NUMBER>88 0.089228
Out: Crop
Output resolution: 640 480
new K:<PHONE_NUMBER>50<PHONE_NUMBER>50<PHONE_NUMBER>50<PHONE_NUMBER>88
old K:<PHONE_NUMBER>50<PHONE_NUMBER>50<PHONE_NUMBER>00<PHONE_NUMBER>88
FOV Undistorter: Warning! Image has black pixels.
Reading Photometric Calibration from file /home/vivek/sweepData/pcalib.txt
PhotometricUndistorter: Could not open file!
Dataset /home/vivek/sweepData/: Got 9999 files!
loaded 9999 images
init RMSE =<PHONE_NUMBER>90! 	Irradiance 17.052605 - 28.258626
init done
optG RMSE = 29638.453328! 	Inv. Response 29438.359313 -<PHONE_NUMBER>51
OptE RMSE = 27373.314080!  	Irradiance 8.413489 - 28.229015
resc RMSE = 23.514413!  	rescale with 0.000859!
optG RMSE = 22.805304! 	Inv. Response 17.747669 - 256.516364
OptE RMSE = 22.224789!  	Irradiance 0.006380 - 0.023291
resc RMSE = 22.093410!  	rescale with 0.994089!
optG RMSE = 21.540971! 	Inv. Response 16.254162 - 244.782224
OptE RMSE = 21.003272!  	Irradiance 0.005987 - 0.022036
resc RMSE = 21.879997!  	rescale with 1.041742!
optG RMSE = 21.333924! 	Inv. Response 16.050825 - 242.683461
OptE RMSE = 20.801489!  	Irradiance 0.005926 - 0.021826
resc RMSE = 21.857195!  	rescale with 1.050751!
optG RMSE = 21.311701! 	Inv. Response 16.029667 - 242.455629
OptE RMSE = 20.779821!  	Irradiance 0.005919 - 0.021804
resc RMSE = 21.854945!  	rescale with 1.051739!
optG RMSE = 21.309507! 	Inv. Response 16.027596 - 242.433079
OptE RMSE = 20.777682!  	Irradiance 0.005919 - 0.021801
resc RMSE = 21.854728!  	rescale with 1.051837!
optG RMSE = 21.309296! 	Inv. Response 16.027396 - 242.430903
OptE RMSE = 20.777476!  	Irradiance 0.005919 - 0.021801
resc RMSE = 21.854707!  	rescale with 1.051846!
optG RMSE = 21.309276! 	Inv. Response 16.027377 - 242.430694
OptE RMSE = 20.777456!  	Irradiance 0.005919 - 0.021801
resc RMSE = 21.854705!  	rescale with 1.051847!
optG RMSE = 21.309274! 	Inv. Response 16.027375 - 242.430674
OptE RMSE = 20.777454!  	Irradiance 0.005919 - 0.021801
resc RMSE = 21.854705!  	rescale with 1.051847!
optG RMSE = 21.309273! 	Inv. Response 16.027375 - 242.430672
OptE RMSE = 20.777454!  	Irradiance 0.005919 - 0.021801
resc RMSE = 21.854705!  	rescale with 1.051847!

Here is the image with the highest exposure.

@anilprasadmn Thoughts?

Your times.txt is not apropriate:

1492802212.15 0000 0.100010
It should have been in the format of the datasets provided. Have a look at them, it will help you figure out  the best practice to capture data.
ie.,  framenumber, timestamp,exposuretime

Make sure that there are no change in the scene (such as moving people casting shadows on the setup) when you are capturing the data. The setup looks fine (but could be brighter; again, best practice is to mimic the authors setup)

Good catch. Can't believe i missed that. Thanks a lot. appreciate it.

hey @anilprasadmn , so that change didn't affect the result. i tried the calibs on a logitech c920. the calibs were very similar to the 9000 cam and i kept getting nans. but using a vignette image i found in one of the dso/dso-ros forums i got dso-ros to work barely. it fails if i dont move it very slowly. does it work fine for you? also do you know by chance how to output the pose of the camera? thanks in advance

@vannem95  Not all of the datasets I  captured succeeded in converging and returning a valid result. [nor was I able to reproduce it with enough confidence.] So give it a couple of tries, read the paper multiple times and you need some luck as well.
Prune your input data and scene to get better convergence. [look at the partial results that are dumped to get an idea of what might going wrong]
Vignette are specific for the lens. Since, they are not very critical (errors in it don't necessarily change the position of the energy functional) you could make do with a generic one. (for instance, my camera has an drastically different response to the authors, the images are brighter near the edge, in which replacing one with the other it will be worse than not giving it in)
I too face a similar problem and was hoping that @fairf4x would revert back with his results (whose thread we seem to have hijacked). I am using a Omnivision OV5674 sensor with a wide angle sunnex lens. I would like to see datasets with global shutter (so that I know what to blame for the errors)
Pose of the camera is dumped in results.txt

I see that results.txt is a by product of dso. Also, when i run dso_ros, it either crashes or i quit it and i don't get any outputs other than the pangolin window. do i have to remove pangolin to see the results.txt file?

I needed to solve some issue with vignetteCalibration. I am using exposure times from EXIF information for my dataset images multiplied by 1000 (in order to obtain time in ms as suggested by @anilprasadmn).
Still it produces the same output:
plane image values<PHONE_NUMBER>0.000000 - -10000000000.000000!
0.000000 residual terms => -nan
0.000000 residual terms => -nan

Is there some simple way to check whether the aruco markers are recognized?

by the way, is using a fisheye lens a requirement for dso_ros? @anilprasadmn

Is there some simple way to check whether the aruco markers are recognized?

Before you get to "plane image values<PHONE_NUMBER>0.000000 - -10000000000.000000!" stage, detected AR markers should have been displayed for your visual inspection. Run the play dataset to check if the format is appropriate.

I suspect that images might not read in your case, you could modify the code a bit to check if each image is being read correctly. In line 228 of src/main_vignetteCalib.cpp make these modifications:
`	for(int i=0;igetNumImages();i+=imageSkip)
{
printf("Currently operating on image number %d with skip of %d.\n", i, imageSkip);
std::vectoraruco::Marker Markers;
ExposureImage* img = reader->getImage(i,true, false, false, false);
//cv::imshow("DEBUG", img);
  cv::Mat InImage;
  cv::Mat(h_out, w_out, CV_32F, img->image).convertTo(InImage, CV_8U, 1, 0);
  delete img;
          printf("h_out,w_out = %d,%d ;\n",h_out,w_out);
          printf("img size = %d,%d ;\n",InImage.rows, InImage.cols);

  MDetector.detect(InImage,Markers);
  if(Markers.size() != 1) continue;
  `

This should produce some debug info such as:

Currently operating on image number 757 with skip of 1.
h_out,w_out = 540,768 ;
img size = 540,768 ;
Currently operating on image number 758 with skip of 1.
h_out,w_out = 540,768 ;
img size = 540,768 ;
plane image values 30.626350 - 280.600342!
458994165.000000 residual terms => 223.750198
458994165.000000 residual terms => 25.215351

do i have to remove pangolin to see the results.txt file?
No. actually there are switches within the code which let you publish the pose. They aren't exposed and you will have to find it and enable them.

is using a fisheye lens a requirement for dso_ros?
No. Fisheyes track more points and loose tracking less often. So its preferred.

@fairf4x  what camera are  you using? global shutter by any chance?

Thanks @anilprasadmn. I can confirm that aruco markers are not recognized.
The test Markers.size() != 1 is always true on my dataset.
I suspect that OpenCV somehow does not read the images because of some format mismatch (maybe sRGB vs RGB issue?).
My images are in this format:
$ identify 0000.jpg
0000.jpg JPEG 856x480 856x480+0+0 8-bit sRGB 64.4KB 0.000u 0:00.000

Compared to author's dataset:
00000.png PNG 1280x1024 1280x1024+0+0 8-bit RGB 256c 581KB 0.000u 0:00.000

My camera does not have global shutter - it is built-in camera onboard Parrot Bebop drone. This is also the reason I can not set absoulute exposure time - only relative to automatic exposure [-3.0,+3.0].

In my case identify produces:
$identify 0001.jpg 0001.jpg JPEG 1024x720 1024x720+0+0 8-bit sRGB 49.2KB 0.000u 0:00.000
So sRGB shouldn't be an issue.

Hi @anilprasadmn!
What would you say is a good value for RMSE after photometric calibration?

@vannem95 Hi, how did you get the exposure time(times.txt) with varying values? if possible, could you share more details, please? thank you in advance.

Can anyone tell me how to make times.txt file I tired to make but did'nt understand how to make that file. ?

@DxsGeorge that sounds reasonable  (sorry, had missed your update)
@TengFeiHan0  I had used a rasbeerrypi cam with varying exposure times to get the task done (I took a couple of images and didn't' use them before getting the correct image, since the camera needs time to adapt to the commands)
@Maheshwariraghav112 you need to set the exposure times programatically to a camera which allows for such functionality

@anilprasadmn  Hey, I am new to this field can you elaborate more how to begin to make this file ?

Ideally, you  need a global shutter industrial camera to implement the work described here [DSO].
refer to https://picamera.readthedocs.io/en/release-1.10/recipes1.html
That will explain how you can build a setup with raspberry pi cam (cost effective alternative) The camera exposure can be varied using the API and the same value recorded to the times.txt file (you will have to verify that the exposure has actually changed with manual inspection)

@anilprasadmn  Thanks for you response, by the way I am using fisheye camera is it not possible to make the same file with this camera.?

@Maheshwariraghav112 ,
I had used a flat camera as well as a fisheye. A considerable part of the fisheye view might get cropped for active region, DSO supports fish eye camera (also, try out the new stereo-DSO algorithms that are available: I haven't used them personally)
You need to generate the times.txt while you capture  these images.
Generating vignette.png and pcalib.txt is an iterative process to be honest.  use the initial guess [I even cheated by manually 'fixing' the pcalib to force it to be monotonous the first time, I didnt' get the result, which occurs due to some variation]

@anilprasadmn  Thanks,
But how to begin to make times.txt.. ?

@anilprasadmn ,
Hey can you tell me how you generated the pcalib.txt file i am unable to generate this file.

@vannem95 @fairf4x  @anilprasadmn Hey, can you guys help me to make pcalib.txt files for my own dataset . I don't understand from where to begin to make pcalib.txt file also don't know about response callibration file. Your guidance may help me to proceed further. Thanks

@anilprasadmn and @fairf4x
Thanks for you nice discussion.
I am facing this problem during responseCalib, It produce nan for RMSE, like this:
Dataset ../data/: Got 5069 files!
loaded 5069 images

init RMSE = 0.000000! 	Irradiance 99.690471 - 194.882620
optG RMSE = 0.000000! 	Inv. Response 0.000000 - 0.000000
OptE RMSE = -nan!  	Irradiance<PHONE_NUMBER>0.000000 - -10000000000.000000
resc RMSE = -nan!  	rescale with inf!
optG RMSE = -nan! 	Inv. Response<PHONE_NUMBER>0.000000 - -10000000000.000000
OptE RMSE = -nan!  	Irradiance<PHONE_NUMBER>0.000000 - -10000000000.000000
resc RMSE = -nan!  	rescale with -nan!
optG RMSE = -nan! 	Inv. Response<PHONE_NUMBER>0.000000 - -10000000000.000000
OptE RMSE = -nan!  	Irradiance<PHONE_NUMBER>0.000000 - -10000000000.000000
resc RMSE = -nan!  	rescale with -nan!
optG RMSE = -nan! 	Inv. Response<PHONE_NUMBER>0.000000 - -10000000000.000000
OptE RMSE = -nan!  	Irradiance<PHONE_NUMBER>0.000000 - -10000000000.000000

I generated exposure time from frame rate, it is constant exposure time =1/fps, because I have no control on camera.
My time.txt file is look like:
00000<PHONE_NUMBER>.0000000 0.03336666666666667
00001<PHONE_NUMBER>.0333667 0.03336666666666667
00002<PHONE_NUMBER>.0667334 0.03336666666666667
00003<PHONE_NUMBER>.1001000 0.03336666666666667
00004<PHONE_NUMBER>.1334667 0.03336666666666667
00005<PHONE_NUMBER>.1668334 0.03336666666666667
00006<PHONE_NUMBER>.2002000 0.03336666666666667
00007<PHONE_NUMBER>.2335668 0.03336666666666667
00008<PHONE_NUMBER>.2669334 0.03336666666666667
00009<PHONE_NUMBER>.3003001 0.03336666666666667
00010<PHONE_NUMBER>.3336668 0.03336666666666667
00011<PHONE_NUMBER>.3670335 0.03336666666666667
00012<PHONE_NUMBER>.4004002 0.03336666666666667
00013<PHONE_NUMBER>.4337668 0.03336666666666667
00014<PHONE_NUMBER>.4671335 0.03336666666666667
00015<PHONE_NUMBER>.5005002 0.03336666666666667
00016<PHONE_NUMBER>.5338670 0.03336666666666667
00017<PHONE_NUMBER>.5672336 0.03336666666666667
00018<PHONE_NUMBER>.6006002 0.03336666666666667
00019<PHONE_NUMBER>.6339670 0.03336666666666667
00020<PHONE_NUMBER>.6673336 0.03336666666666667
00021<PHONE_NUMBER>.7007003 0.03336666666666667
00022<PHONE_NUMBER>.7340670 0.03336666666666667
....................................................
Why RMSE is nan?
Is it possible to use responseCalib using my data?
I think you can solve my problem.

Hey @vannem95 can you share the source code of how you manage to create the time.txt file, I am using Blackfly GigE camera which has its own sdk on ros, I have successfully ran DSO with it, now I want to Integrate pcalib.txt to it for which I need time.txt file.
It would be great if someone can help me with it also
Thanks In Advance!

Hey, I figured out how to do pcalib.txt, nbut my results are weird, I am getting increase in values above 255 then comming back to 255, and first value as -nan.
Any ideas guyz, I really need some help here!
-nan 0.0304538314123542 0.0532701038711612 0.0973080141093104 0.156690146818502 0.220751005359101 0.292986692145073 0.373694556240523 0.45514403503921 0.541656394544099 0.632458457390751 0.728630655905973 0.828901594723918 0.953413774217377 1.17297301257366 1.53600174650937 1.88197897275722 2.10340276001252 2.27160208018437 2.4398599349328 2.63548934595587 2.86546655198378 3.09696328603177 3.33520747332946 3.58589287280338 3.86105776004936 4.17223260647411 4.51173712186661 4.84353455714835 5.14937245902436 5.4519650543975 5.77553287405983 6.11957715899787 6.44923027745495 6.76530323294952 7.09803427372118 7.39863090814452 7.71762282258766 8.04495203876262 8.38710655952352 8.72780427083243 9.10671068684482 9.46949923108282 9.83349431065804 10.220238101358 10.611935651745 11.0352694493227 11.4636251463296 11.9442236773381 12.3962763804501 12.8126684296959 13.2384394993186 13.6281013223075 14.0490866890382 14.4814688186822 14.8564161516929 15.2269598401561 15.60367172709 15.9649642683161 16.408531281038 16.9186887513718 17.5022932644952 17.9447663069619 18.3564640192061 18.7358918547836 19.092524425528 19.5125674601545 19.897162954508 20.3051000339393 20.7951631028953 21.3172244125528 21.8383373665387 22.3651908506346 22.8667609548543 23.2907159941569 23.760804328802 24.2594255947039 24.7805161565785 25.3275051877564 25.9525384219184 26.4911390961724 26.9823796479313 27.5757702473881 28.1322489267019 28.7058847762242 29.3362915378107 29.991848063365 30.5533996368009 31.1582597645561 31.745692817288 32.3172079031137 32.9218577054369 33.4956526017897 34.0305096307196 34.5946928789133 35.0960551450268 35.6074576693945 36.0876110769148 36.5806822059886 37.1483023547553 37.6253461616793 38.0135094143769 38.5231526445709 39.0340449592008 39.7131543687314 40.2626610098294 40.8763326083638 41.4778131969877 42.0608591615766 42.7491460848786 43.456065412856 44.164431114127 44.7532456733705 45.4141485049408 46.0695228624551 46.7075497705972 47.3643227895572 48.1539013924751 48.8280201562931 49.4052937431112 50.0326498075791 50.6113680537477 51.1767379629253 51.99256602539 52.5930259639489 53.1979903534724 53.9019926631801 54.5719774364767 55.2047972588925 55.8441856028447 56.3083148832278 56.7409361200905 57.1666332269683 57.5690218308593 58.0595210396775 58.6007384762221 59.0882462694996 59.468659228219 60.0311789088329 60.5426653263757 61.2192491541708 61.9305164551431 62.5637948556103 63.2537273612489 63.9968746124892 64.6388905911771 65.5063227193005 66.3638657498418 67.2704986394642 68.2228566413857 69.1878893769369 70.0756048169885 70.9920013771768 71.874070369246 72.6146318745793 73.3215584314173 73.7503522141941 74.4130441792747 74.7564080084991 75.2648339414856 75.9795211050058 77.0510541839377 78.1593933960293 79.4724449253786 80.5730833695956 81.6525536808565 82.6160229282421 83.5511642891004 84.4782391397034 85.751711158446 87.2297414735214 88.8847880168709 90.6701298512634 92.6126709130491 94.8883228502796 97.0619043464824 99.3030244873319<PHONE_NUMBER>47837<PHONE_NUMBER>09888<PHONE_NUMBER>12629<PHONE_NUMBER>57538<PHONE_NUMBER>5954<PHONE_NUMBER>97724<PHONE_NUMBER>99196<PHONE_NUMBER>54058<PHONE_NUMBER>13359<PHONE_NUMBER>92498<PHONE_NUMBER>29198<PHONE_NUMBER>13085<PHONE_NUMBER>97458<PHONE_NUMBER>23742<PHONE_NUMBER>26457<PHONE_NUMBER>5307<PHONE_NUMBER>93619<PHONE_NUMBER>93196<PHONE_NUMBER>64565<PHONE_NUMBER>96383<PHONE_NUMBER>84487<PHONE_NUMBER>98293<PHONE_NUMBER>1062<PHONE_NUMBER>58618<PHONE_NUMBER>54827<PHONE_NUMBER>74072<PHONE_NUMBER>4412<PHONE_NUMBER>58102<PHONE_NUMBER>53741<PHONE_NUMBER>22248<PHONE_NUMBER>68862<PHONE_NUMBER>25747<PHONE_NUMBER>22462<PHONE_NUMBER>13342<PHONE_NUMBER>95573<PHONE_NUMBER>37311<PHONE_NUMBER>75763<PHONE_NUMBER>82984<PHONE_NUMBER>9227<PHONE_NUMBER>48075<PHONE_NUMBER>94483<PHONE_NUMBER>35472<PHONE_NUMBER>7445<PHONE_NUMBER>54976<PHONE_NUMBER>52737<PHONE_NUMBER>157<PHONE_NUMBER>74875<PHONE_NUMBER>4833<PHONE_NUMBER>74357<PHONE_NUMBER>1911<PHONE_NUMBER>7664<PHONE_NUMBER>37221<PHONE_NUMBER>97099<PHONE_NUMBER>09313<PHONE_NUMBER>73465<PHONE_NUMBER>32814<PHONE_NUMBER>53259<PHONE_NUMBER>36107<PHONE_NUMBER>01845<PHONE_NUMBER>29116<PHONE_NUMBER>11186<PHONE_NUMBER>36935<PHONE_NUMBER>99467<PHONE_NUMBER>36065<PHONE_NUMBER>4699<PHONE_NUMBER>25926<PHONE_NUMBER>05669<PHONE_NUMBER>48955<PHONE_NUMBER>79944<PHONE_NUMBER>81443<PHONE_NUMBER>70419<PHONE_NUMBER>3017<PHONE_NUMBER>41733<PHONE_NUMBER>03493<PHONE_NUMBER>77419<PHONE_NUMBER>46908<PHONE_NUMBER>20149<PHONE_NUMBER>10075 255

[I  might be wrong here; this was my reasoning and what gave me results in practice]
The NaN occur due to zero increase in illumination with increased shutter time leading to some issues with numerical stability, so  you can change this to zero '0'.
Also, following the same logic, values greater than 255 doesn't make sense.  You have two options [Manual fix]:
A. For values in your output which are greater than 255, replace them with that value. [this is what I used]
B. resize the values by the greatest number.
This should be followed by a further cleaning to make the function monotonic (ie., non decreasing) [wrote a small program t o to do this]
Once this clean up is completed, use this as the initial guess for the response calibration, and the program will refine it to be accurate.
I had done this process twice to get to the value. This problem is due to the numerical instability of the convergence and will happen when we don't have the right initial guess for the pcalib (and relatively bad data due to unresponsive camera.) This is solved by iterating over the guess of pcalib aka response calibration.
One other trick I found when I had to deal with unresponsive cameras (I had initially used PiCam aswell for this task) is to set an exposure, take some pictures and drop them, before getting the target picture [I used to take 4 pictures and throw them since I found that the exposure gradually varied, even though the PiCam data logs claimed that the exposure had been updated.]
Hope this helps.

hi!
I am using realsense d435i to test dso_ros.And I can only get a rosbag.
Could you please tell me how to get time.txt or images with rosbag?
thank you guys so much.

@fairf4x I have the same result,do you know how to solve it?
Markers.size() != 1 is always true on my dataset.


Remove() in propertylist.go not removing from List

https://github.com/AssetMantle/modules/blob/ed62da973c6f414265ccff0662a378e4d3feb484/schema/lists/base/propertyList_test.go#L188-L190

resolved


Porcupine with react native voice

Have you checked the docs and existing issues?

[X] I have read all of the relevant Picovoice Porcupine docs
[X] I have searched the existing issues for Porcupine

SDK
Android
Porcupine package version
3.0.2
Framework version
React Native 0.71
Platform
Android
OS/Browser version
Android 13+
Describe the bug
Hey, i found a issue with use of porcupine and react native voie.
My Plan: porcupine start listening -> detect keyword -> porcupine stop listening -> update a state variable ("initVoice"->true) -> screen useEffect -> if initVoice && Voice: load all listeners -> in the initVoiceHook in UseEffect -> if true: start react native voice recording.
I have the following listeners: onEnd, onResult and onError.
So. Everything works well till "start react native voice recording."- Process
Steps To Reproduce
Problem: The listeners wont get triggered when the user Stops talking. Like i sayd the recording starts but never stops.
The strange part is: when i try it without porcupine, everything is working well. Listeners are correct called-> so i thought it must be because the a Listener conflict between porcupine and rn voice. Thats because i first stopped porcupine listening, then update the state and then in the custom Hook start the recording (So there can not be a render conflict)
wired — heute um 14:50 Uhr
// here is my code:
// first start the porcupine listener
export const startListening = async (
updateInitVoice: (value:boolean) => void
) => {
console.log("Start Listening Function called...");
try {
if (!porcupineManager) {
console.log("Create new PorcupineManager instance")
porcupineManager = await PorcupineManager.fromBuiltInKeywords(
PORCUPINE_API_KEY,
[BuiltInKeywords.JARVIS],
(keyword:number) => {
console.log("Detected Keyword!");
startRecordingProcess(updateInitVoice)
},
errorListening
);
}
await porcupineManager?.start();
}catch (e:unknown) {
if (e instanceof Error) {
console.error("Error while listening occurred", e);
}
}
};
// ...so i stop the porcupine listener and update the state...
const startRecordingProcess = (
updateInitVoice: (value:boolean) => void
) => {
stopListening()
.then(() => {
updateInitVoice(true);
})
};
// ... then activate the listeners...
useEffect(() => {
if (Voice && initVoice) {
console.log("Voice Listener active...");
Voice.onSpeechError = onSpeechError;
Voice.onSpeechResults = onSpeechResults;
Voice.onSpeechEnd = onSpeechEnd;
  return () => {
    Voice.destroy()
      .then(() => {
        Voice.removeAllListeners();
        console.log("Remove Listeners in useEffect...");
      })
  }
}

}, [initVoice]);
// ... then start the speech process in the hook... (start Speech just call Voice.start with a few logs -> every time successfuly...
export const useInitVoice = () => {
const [initVoice, setInitVoice] = useState(false)
const updateInitVoice = (value:boolean) => setInitVoice(value);
useEffect(() => {
if (initVoice) {
startSpeech()
.then(() => {
console.log("Speech initialized...")
});
}
}, [initVoice]);
return { initVoice, setInitVoice, updateInitVoice }
}
Expected Behavior
But as i mentioned,the listeners wont get active. what did i overseen?

Do you encounter the same issue in our official react native demo? If not, I would suggest you continue debugging your application as it is difficult at this point to determine if this is an issue with our package or your application.

I do see that you're calling startRecordingProcess every time you detect a keyword. This may cause some of the issues you are experiencing.
(keyword:number) => {
console.log("Detected Keyword!");
startRecordingProcess(updateInitVoice)
},

Closed due to inactivity


Ensure build works with latest contract-build and contract-metadata

The build is failing with errors about missing argument. The argument is for a container image name which we don't support.

@xermicus I am going to merge this since the build is broken. Let me know if you have any concerns and we can address them later.


Pagination doesn't seem to be updating as expected

Hi
I've just implemented the pagination mixin for this and I seem to be getting an issue with the number of pages being returned.
I am storing a lot of the required parameters in a Vuex store (per_page, total etc.) and storing the data attribute after an axios call.  We are then filtering this data, which basically re-runs the above and updates my store values for total etc (this is returned by the api).  From what I can tell, my store and data is being updated as expected.
However, the number of page links is not being updated. For example, on initial load there are 150 results, and the per_page value is set to 10, so it returns 15 pages.  When I filter them, it then goes down to 18 results, so should be split across 2 pages.
The data filters down, and going to page 2 shows the last 8 results, however links for all 5 pages still show.  This only seems to happen in our production environment - when running in dev on my machine it works fine, when running a production build on my machine it works fine, but in our main production server it doesn't update.
Does anyone have any idea why this might happen, or where I might even begin to start debugging this?  I can send sample code tomorrow if needed

FYI, an update to v2.0.0.beta-4 has solved this, think it was sorted in https://github.com/ratiw/vuetable-2/pull/515


Revert "Revert "Revert "Revert "test pr"""" - 69

[Auto generated]
Number: [#69]

github-gitlab-webhook-server: Closing issue for PR: Revert "Revert "Revert "Revert "test pr"""".
PR was closed.


feature request: way to handle errors emitted by the pg client

Right now it's possible for the pg client to emit errors that crash the process, for example connection terminated unexpectedly errors

oh sorry, I forgot that we could pass in our own client


Json formatter does not output passed or ignored checks when specified.

https://github.com/aquasecurity/defsec/blob/0d66c2f264b27ea8ee78ee3601ac0fa3bd88dad6/pkg/formatters/json.go#L13
This is surely a bug - it stops the json outputer displaying failed or ignored checks even when the arguments are specified. (I tested with a locally patched version of the package and the json outputs seems to work as expected. (I didnt run any tests)
    for _, result := range results {

Good spot, thanks @JoeButler99


Eliminate Newtonsoft.Json

Your dependency on Newtonsoft.Json and use of Stream goes counter to everyone's use of System.Text.Json and IBufferWriter<>
Describe the solution you'd like
Now that System.Text.Json is netstandard2.0 you should get rid of Newtonsoft.Json
Additional context
it creates dangling references that I do not want to carry around
The core cosmos API should limit itself to IBufferWriter<> and Span<T> and expose typed serialization as extensions

System.Test.Json is not yet released. We will evaluate once its ready.
CosmosJsonSerializer implementation can be provided to CosmosClient to use even today to leverage the power of those libraries.

It cannot be implicitly.
There is no public setter for the default serializer, and not all the methods have stream equivalents. See CosmosStoredProcedure.ExecuteAsync

You can set the CosmosJsonSerializer via the CosmosClientBuilder.
CosmosClient cosmosClient = new CosmosClientBuilder("http://localhost", "SuperSecretKey").UseCustomJsonSerializer(new CustomJsonSerializer).Build()

When using the Cosmos SDK in ASP.NET Core 3.0 and .NET Core 3.0 today, we have to use Newtonsoft.Json, for its JsonPropertyAttribute to rename Id to id. Using System.Text.Json.Serialization attributes does not work. For example:
[Newtonsoft.Json.JsonProperty(PropertyName = "id")]
public string Id { get; set; }

IMO we should be able to use the native System.Text.Json.Serialization.JsonPropertyNameAttribute to rename properties for serialization. Same goes for Ignore, etc.

What is the long term plan for the Newtonsoft dependency? I can see it was removed in v4 and then put back in via https://github.com/Azure/azure-cosmos-dotnet-v3/pull/1144. This seems like a bit of a backward step given that a tidy dependency tree is likely to be a key motivation to upgrade.

For v4 we are following the Azure Core SDK guidelines which removes all newtonsoft dependencies. @ealsur please correct me if I'm wrong.

Correct, the idea is for it to be completely removed.
Currently V4 still has it due to some internal processes still depending on it, but it's not used while interacting with user data.

We have swagger generated c# classes that use Newtonsoft json attributes like [JsonProperty(PropertyName = "id")] mainly and converters like [JsonConverter(typeof(StringEnumConverter))]
The serializer in System.Text doesn't handle nullable enums. And appeared to have issues with StringEnum conversion (seemed to generate a string representation that was off-by-one enum, but I need to look more into this one).
Anyone know when System.Text serializer will work as smoothly as Newtonsoft wrt (nullable) StringEnums? If that is resolved, then we could consider moving to System.Text serializers, but we still have reliance on generated classes that use newtonsoft attributes, so we'd have to transform all the associated json attributes too.
To avoid the above concerns, is there consideration for how easy will it be for us to have Cosmos continue to use Newtonsoft serializer in Cosmos SDK v4?
Will the 'legacy' Newtonsoft-based serializer be available as a CosmosSerializer in SDK v4 or as an external package? It sounds like it won't, because it is to be eliminated, correct? So going from SDK v3 to v4 would really be a breaking change. Will we need to implement a CosmosSerializer which uses Newtonsoft under the covers (copy and rename the one from SDK v3)?

In Cosmos SDK v4 there will be a client option that will let you set a  custom Cosmos Serializer. This will allow you to set Newtonsoft as the serializer. The benefit of this is you can pass in any version of Newtonsoft, and there won't be any version conflicts.

Even if the main Azure.Cosmos v4 package uses Newtonsoft at runtime dynamically it shouldn't have a package dependency on it as that brings it in even when not used, see https://github.com/Azure/azure-cosmos-dotnet-v3/issues/37

The goal is for V4 not to have any Newtonsoft.Json dependency.

Any idea where we can find update on status and/or plans of Azure.Cosmos V4 package, since the latest package is in-preview ... I was wondering if it is a good choice to use it as is, or stay at V3.

My guess is since the v4 preview is so old that it will change significantly before it comes out of preview (if it ever does...)

The current recommendation is to use v3 for all production scenarios. There currently isn't any update/release planned for v4 SDK.

Tracking this in #2533


Automated CI builds for Windows, macOS & Linux x64

Automatically build self-contained releases using CI services.
Windows builds use AppVeyor and are saved as a .zip archive build artifact.
macOS and Linux builds use Travis and are uploaded to transfer.sh as a .tar.gz archive.
All builds are x64.

I set up both Travis and Appveyor on the repo and kicked off builds!


Design prototype on Figma using angular material components

Figure out how to do it

Started figma course at Alura: https://unibb.alura.com.br/dashboard

Finished Figma course.


Mobile: Tap bot message to reply and @mention that person on Messenger

Describe the solution you'd like
Tapping the webhook on mobile results in eg. @username (Full Name)#0000 to be copied to the message box, useful for quickly mentioning that user. If such a tag is given, it should @mention the person on Messenger
Additional context
#0000 could probably be rstripped off the string sent to messenger
The solution currently works if only full names are presented, but the #0000 is sent to Messenger which makes it look a little awkward. v5.0.3
Related to #447

Should be working in v5.0.0, but I'll test it.
https://github.com/miscord/miscord/blob/e03bc8d77cac6256d20b82ba0d339013f0b7021a/src/messenger/handleMentions.ts#L11


Remove InfiniBand actions

Description
It aims to clean up slurmd, removing unnecessary actions (e.g. InfiniBand).
How was the code tested?
The code was tested using the GitHub actions test workflow.
Related issues and/or tasks
ASP-2711
Checklist

[x] I am the author of these changes, or I have the right to submit them.
[ ] I have added the relevant changes to the README and/or documentation.
[x] I have self-reviewed my own code.
[ ] All requested changes and/or review comments have been resolved.

This looks great!
Only thing is that I don't think we should merge this pull request until we fix the issues with the integration tests. I know what the issue with the integration tests are, and it has nothing to do with you removing the infiniband-related code. It has to do with the fact that the integration/relation endpoint for the slurmdbd charm has changed. Let's fix that before merging this pull request.

Thanks @NucciTheBoss! I agree with you! Let's wait until the integration tests are fixed.


Im getting some unusual errors

Traceback (most recent call last):
File "main.py", line 6, in
from prsaw import RandomStuff
File "C:\Users\ansh0\AppData\Local\Programs\Python\Python38-32\lib\site-packages\prsaw_init_.py", line 1, in
from .PRSAW import *
File "C:\Users\ansh0\AppData\Local\Programs\Python\Python38-32\lib\site-packages\prsaw\PRSAW.py", line 2, in
from apiclient import APIClient, APIRouter, Get, endpoint
ImportError: cannot import name 'APIClient' from 'apiclient' (C:\Users\ansh0\AppData\Local\Programs\Python\Python38-32\lib\site-packages\apiclient_init_.py)
I dont think this is an issue with my code

so was this actually solved?


New tag?

We have been using the latest master of multisheller for some time in https://github.com/robotology/robotology-superbuild/blob/fb89c965a3f6046eabcefa0eb01ceb126c94918c/.github/workflows/generate-conda-packages.yaml#L74, and it is working fine. Could it make sense to tag a new release that includes https://github.com/wolfv/multisheller/pull/8 ? Thanks!

sure, we can do that! Are you interested in being a co-maintainer? I think we could move this repo over to mamba-org and maintain it together if you want

I just tagged 0.2.0
Let me know what you think about moving this to mamba-org :)

sure, we can do that! Are you interested in being a co-maintainer? I think we could move this repo over to mamba-org and maintain it together if you want

Ok! Moving to mamba-org is fine to me.

alright, you've got maintainer rights, too now. feel free to do any changes you'd like :)

I'll also make a conda-forge release.


Azure Storage Explorer fetch failure

Preflight Checklist

[X] I have installed the latest version of Storage Explorer.
[X] I have checked existing resources, including the troubleshooting guide and the release notes.
[X] I have searched for similar issues.

Storage Explorer Version
1.19.1
Platform
Windows
OS Version
Windows 10
Architecture
x64
Build Number
20210425.1
Regression From
don't know
Bug Description
Unable to retrieve child resources.
Details:
{
"name": "FetchError",
"message": "request to http://<IP_ADDRESS>:10000/devstoreaccount1?include=metadata&comp=list failed, reason: connect ECONNREFUSED <IP_ADDRESS>:10000",
"stack": "FetchError: request to http://<IP_ADDRESS>:10000/devstoreaccount1?include=metadata&comp=list failed, reason: connect ECONNREFUSED <IP_ADDRESS>:10000\n    at ClientRequest. (C:\Users\StanWrobel\AppData\Local\Programs\Microsoft Azure Storage Explorer\resources\app\node_modules\node-fetch\lib\index.js:1461:11)\n    at ClientRequest.emit (events.js:310:20)\n    at Socket.socketErrorListener (_http_client.js:426:9)\n    at Socket.emit (events.js:310:20)\n    at emitErrorNT (internal/streams/destroy.js:92:8)\n    at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)\n    at processTicksAndRejections (internal/process/task_queues.js:84:21)",
"type": "system",
"errno": "ECONNREFUSED",
"code": "ECONNREFUSED"
}
Steps to Reproduce

Launch Storage Explorer
Open Storage Accounts->Emulator->Blob Containers

Actual Experience
Failed to connect.   I have Storage Blob Data Owner permission.   It worked yesterday.
Expected Experience
Expect to see 'ingestiondata' container.
Additional Context
No response

I am having the same issue using https.
Unable to retrieve child resources.
Details:
{
"name": "FetchError",
"message": "request to https://<IP_ADDRESS>:10000/devstoreaccount1?include=metadata&comp=list failed, reason: connect ECONNREFUSED <IP_ADDRESS>:10000",
"stack": "FetchError: request to https://<IP_ADDRESS>:10000/devstoreaccount1?include=metadata&comp=list failed, reason: connect ECONNREFUSED <IP_ADDRESS>:10000\n    at ClientRequest. (C:\Program Files (x86)\Microsoft Azure Storage Explorer\resources\app\node_modules\node-fetch\lib\index.js:1461:11)\n    at ClientRequest.emit (events.js:310:20)\n    at TLSSocket.socketErrorListener (_http_client.js:426:9)\n    at TLSSocket.emit (events.js:310:20)\n    at emitErrorNT (internal/streams/destroy.js:92:8)\n    at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)\n    at processTicksAndRejections (internal/process/task_queues.js:84:21)",
"type": "system",
"errno": "ECONNREFUSED",
"code": "ECONNREFUSED"
}

@opsuotr @AyushmatiGit are y'all trying to work with an emulator? If yes, then you will need to start the emulator before using it. I ask/say this because http://<IP_ADDRESS>:10000/devstoreaccount1 is indicative of trying to work with an emulator. If you are not, then please let us know. Thanks.

@MRayermannMSFT I am using Azurite. I have followed the instructions from different sections of the document below:
https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azurite?toc=/azure/storage/blobs/toc.json#install-and-run-the-azurite-docker-image
https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azurite?toc=/azure/storage/blobs/toc.json#certificate-configuration-https
https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azurite?toc=/azure/storage/blobs/toc.json#https-connection-strings
https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azurite?toc=/azure/storage/blobs/toc.json#connect-to-azurite-using-https
As @opsuotr mentioned, connection using Http works fine, but connection using Https throws errors.

@AyushmatiGit did you start Azurite? Are you able to access it from other tools/by using the storage SDK against it?

Closing due to lack of response. If you are still having problems, please either open a support ticket from the portal, or open a new issue here. Thanks.


Replace with placenames ontology CSIRO-enviro-informatics/placenames-profile

Fixes #1

Closed because this approach loses the history. I'll have another go at Git knitting


Feature Request: Add isCloseToPercentage to numbers

In my current project i need to check values with an offset which is a percentage value. So i need to calculate the offset like this:
        double actualSum = 101d;
        double expectedSum = 100d;
        //should differ only within 0.5 percent
        double percentage = 0.5d;

        double calculatedOffset = percentage * expectedSum / 100;
        assertThat(actualSum).isCloseTo(expectedSum, offset(calculatedOffset));

Can we create a convenience method to encapsulate that calculation so that it would look like this
assertThat(actualSum).isCloseToPercentage(expectedSum, offset(0.5d));

Having started with implementing this i think it is better to use it that way
assertThat(9.0).isCloseTo(10.0, Percentage.percentage(0.5));

Ok but I suggest to use withinPercentage to be consistent with the existing API.

I see that isCloseTo is only in RealNumbers which is not up to date anymore because every number has this method now. I would like to update this by pulling this method to Numbers. Therefore a refactoring of Numbers is needed.
class Numbers<NUMBER extends Number & Comparable<NUMBER>>

@joel-costigliola Do you see any problems with that?

I am almost finished so do you mean that way?
assertThat(9.0).isCloseTo(10.0, Percentage.withinPercentage(0.5));
assertThat(9.0).isCloseTo(10.0, Assertions.withinPercentage(0.5));

Yes, Assertions.withinPercentage delegating to Percentage.withinPercentage

Just to be sure, if you want to express that actual is close to expected by less than 5%, you would write:
assertThat(9.0).isCloseTo(10.0, withinPercentage(5));

right ?

Yes. Basically it is just a convenience method so that the following is the same:
assertThat(9.0).isCloseTo(10.0, offset(0.5));
assertThat(9.0).isCloseTo(10.0, offset(10.0*0.05));

:+1:


Updates for EVMConnect support (with EthConnect cross-compatibility)

Support the TransactionUpdate type of websocket payload - which just updates the operation, while leaving it in Pending status (rather than marking it success/fail)
Support events with an 0x12345: address prefix on the signature

Codecov Report

Merging #923 (d1cff97) into main (3ae7ba8) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #923   +/-   ##
=======================================
  Coverage   99.97%   99.97%
=======================================
  Files         299      299
  Lines       19475    19483    +8
=======================================
+ Hits        19470    19478    +8
  Misses          4        4
  Partials        1        1

Impacted Files
Coverage Δ

internal/blockchain/ethereum/ethereum.go
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Backport gdk4-win32 to 0.5

See #1103

This commit should be backported as well

https://github.com/gtk-rs/gtk4-rs/pull/1171 should be backported as well once it lands

https://github.com/gtk-rs/gtk4-rs/commit/b48d8cc4909039a39f21c64ea7f12424006080b3 is also needed to fix the windows msvc CI

yay! gdk-win32 0.5 release coming? :)

https://crates.io/crates/gdk4-win32 \o/