Member type infer support and related type checker improvements

Purpose

This PR contains below improvements.

Infer member type from table constructor record literals
Support map as constraint type for table
Type checker improvements & bug fixes

Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[x] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #23058 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #23058   +/-   ##
=======================================
  Coverage   14.59%   14.59%
=======================================
  Files          51       51
  Lines        1411     1411
  Branches      219      219
=======================================
  Hits          206      206
  Misses       1189     1189
  Partials       16       16

Continue to review full report at Codecov.

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


[WIP] Custom formatted location list

Replaces the location list buffer with better aligned content:

Filename is removed and displayed in w:quickfix_title
Adds each item's sign to the sign column
Adds a fake gutter that displays the maker name, line number, and
column

This is similar to the example I posted in #325
Currently, there's a couple things that need to be addressed:

Documentation.
This is enabled through neomake#quickfix#enable().  The idea is that there would also be a disable() method.  It probably should be enabled/disabled with a variable.
There can be list items that point to a different buffer.  I think those items should just be prefixed with something like [buf:shortname] instead of adding a column for all items.  However, I only saw this happening with govet which looks like it was using a temporary buffer.
The quickfix window is not reformatted.  It might be nice to format the quickfix list so that the columns line up nicely and displays the makers.
If the location list is already visible, neomake's s:current_errors isn't populated for the current buffer when this script runs.  I haven't figured out why that is.

The main thing blocking this is I can't make this only run after Neomake finishes.  Something I thought about was possibly adding a dummy entry at the end of the list that isn't added to the buffer.  That way it can be distinguished from location lists created by other scripts.
Preview
Before:

After:

Before:

After:

Before:

After:

The quickfix window is not reformatted. It might be nice to format the quickfix list so that the columns line up nicely and displays the makers.

Yes, also possibly applying pathshorten() and some other things in the end.

If the location list is already visible, neomake's s:current_errors isn't populated for the current buffer when this script runs. I haven't figured out why that is.

Likely a bug then.  Might depend on the setting to open the quickfix/location list?!

The main thing blocking this is I can't make this only run after Neomake finishes. Something I thought about was possibly adding a dummy entry at the end of the list that isn't added to the buffer. That way it can be distinguished from location lists created by other scripts.

What about using the (badly named) NeomakeCountsChanged hook, either directly or by also looking for qf FileType events and then act accordingly?

I think I'd prefer the line/col first (before the maker): It is more compact in length (for the column width, in case of multiple makers) there, and also the maker's name is a good prefix for the error already.
In https://github.com/neomake/neomake/pull/325 my idea was to append it at the end  [maker]: it is useful to see quickly, but not really a category most of the time.
You might have put it to the beginning for some reason though?! :)

Likely a bug then. Might depend on the setting to open the quickfix/location list?!

My theory is that during the async post-processing, the buffer focus is changing temporarily due to the list changing.  So, this script is running beforehand.
I forgot to mention that this only seemed to happen with the Python maker.   Note to self: Now that I'm thinking about it, I'm using impsort.vim that does async highlighting and it might changing the buffer focus unexpectedly.

What about using the (badly named) NeomakeCountsChanged hook, either directly or by also looking for qf FileType events and then act accordingly?

As you mentioned, it would require also looking out for Filetype qf.  The combination is too magical for my liking.  Future changes to how the hooks are handled could break this too easily.
I'm actually starting to like my idea of adding a dummy entry to the list.  If this feature is enabled, the last entry would have an item with pattern set to {neomake} as the marker/signal, and the text could be a comma delimited list of the makers, or possibly even a string representation of a dict that contains extra information that can't be added to the setloclist() function.  This script would simply not add a line for it.

I think I'd prefer the line/col first (before the maker): It is more compact in length (for the column width, in case of multiple makers) there, and also the maker's name is a good prefix for the error already.

I actually want the fake gutter to be customizable.  I didn't go through with doing all that because I wanted to make sure this PR was acceptable in general first :P
An idea to make it more compact is to just truncate the maker name to 3-4 characters.  Then an optional maker_name_short key for the maker configs could be used if manual shortening is needed to make it less ambiguous.

In #325 my idea was to append it at the end [maker]: it is useful to see quickly, but not really a category most of the time.

I thought about this, but, it didn't seem right that if you wanted to know what maker emitted the message, you had to actually look for it instead of just knowing where to look in a designated space.  That would be annoying if the message is long and off screen, or if the surrounding text is dense enough to make it hard to see.

You might have put it to the beginning for some reason though?! :)

I was just keeping the order as signs | fold | number, where fold is the maker name.  No real thought went into the ordering :D

I'm feeling the pressure to finish this now 😜   I'll work on this a bit more today.

Any updates?
Please rebase it at least to make it easier to dogfood.

This now supports quickfix as well!
I went ahead with the dummy quickfix entry since it seemed like the most reliable way to pass along the maker names.  It resolved the issue I mentioned above with the python maker.
I haven't done the gutter customization yet because I couldn't think of a good way to do this without a lot of explanation.  I was thinking about using python-style formatting:
%(maker)s %(lnum)s:%(col)s

Then I would get the order by removing the (word)s from the string and replacing them with * so that it can be used in the printf().

This now supports quickfix as well!

Awesome!
Quick feedback/issue: probably because of the dummy entry in the end, my automatic resizing of the qf list is off by one now.. i.e. normally it would be resized for one entry, but now by the time of the resizing there are likely 2.  I am doing that mainly on FileType qf, but have not investigated yet.

Yeah that sounds like the dummy entry.  I like the dummy entry because it's a foolproof way to pass info around, but I'm not committed to the idea.  The alternative is maintaining that info in a script var and querying for it later.  The problem is that there wouldn't be an easy way to know if getqflist() is returning a list that's from Neomake.
We could just use the pattern key for each entry to hold the maker name (e.g. neomake:flake8), but I'm not exactly clear on what that field does and if using it will cause other issues.

I made it so that the maker name is attached to the list entry's text, but only if the custom qf is enabled.
I wanted to use the pattern field since that wouldn't be useful for Neomake, but it turns out that pattern overrides lnum.  I was going to try using something like \%15l\%(maker\)\? for the pattern field, but it seemed a little overboard to make Vim parse regex to jump to a line.

@blueyed Requesting a review.  I think this is working pretty well where it is, but I wanted to get your thoughts about attaching the maker info to the text.

@blueyed I'll fix the lint error.  Last detail for this is to add tests.  Do you have any suggestions for this?

Last detail for this is to add tests. Do you have any suggestions for this?

Not really.
Probably a new .vader file makes sense for this feature (include it in neomake.vader then).
integration.vader has the most diverse set of tests, where you might find a good base one.
Also rebasing makes sense, since tests have been improved a bit.
I recommend also to use my Vader fork for better tracebacks/error messages (https://github.com/neomake/neomake/pull/974).

Well I was wondering if Vader will have an issue with opening the quickfix window to get the contents.  I also just noticed that the maker config in the entry text is leaking into the text displayed in the message area.  Need to fix that.

Well I was wondering if Vader will have an issue with opening the quickfix window to get the contents.

Should be good.
Both as in opening it really (:copen) or accessing it through cgetlist().

You can run make tests/foo.vader to only run a particular file - that's what I do with a set of new tests usually.
And for the better Vader: you can symlink to it in tests/vim/plugins/vader.override.

Rebased on master.

Thanks!  I haven't had a a ton of time to work on the tests.  One day 😬

@blueyed I had some changes that I didn't push and a forced update was easier than sorting out the rebase.

@blueyed Sorry I sat on this for so long.  I added a couple basic tests.  It needs to improve, but I think it can be dealt with later since the tests at least ensure it doesn't disrupt the normal quickfix display.
Notes:

I couldn't test the fake gutter's syntax highlighting since that doesn't seem to be possible.
Found it strange that normal! didn't trigger CursorMoved.
Needs tests for multiple makers.
Needs tests for checking truncated maker names.

I guess I need to fix up the test.  Forgot to include it in neomake.vader.

I'll let you take a look at the tests.  Everything I try ends up not working or breaking other tests.  I keep getting this:
[EXECUTE] (X) Vim(let):E121: Undefined variable: g:neomake_test_postprocess_count

@blueyed I simplified the tests so that only the rendering is checked.  I couldn't get the tests to pass as mentioned above.
Looks like I still need to make some fixes for older versions of Vim, though.

It's good to have the tests simplified, although some integration test would be useful, too.
The previous ones looked to verbose though.
It should be much easier with https://github.com/neomake/neomake/pull/1050 - I'll wait until that is in.
Seems to be only one issue with vim73:

(112/150) [EXECUTE] (X) Vim(sign):E474: Invalid argument
function neomake#quickfix#FormatQuickfix..47_reset, line 2

Seems to be only one issue with vim73:

Also one issue with 7.4 because of matchaddpos().  It's a problem for 7.3, too.  It's concealed by the sign error.

Whats the best way to clear signs from the quickfix buffer?  I'm using sign unplace * buffer= because neomake#signs#ResetFile() seemed to always leave a sign behind on line 1.

Whats the best way to clear signs from the quickfix buffer?

The signs interface is weird, too (and I've local changes for it somewhere already).. :/
Which sign is left behind?  neomake#signs#ResetFile() gets used to indicate that signs are being replaced IIRC.  You then have to call CleanOldSigns (or similar).  IIRC some tests use it.
That should not really affect the qf buffer though, does it?
Why do you care about clearing (and placing) signs here?

Aww man, I actually wrote out a response for this but I must've closed the window before posting it.
I'm adding signs to the qf buffer opposed to using E, W, etc.  I also didn't want to add the sign characters in the buffer.  Would've required editing signs.vim to get the configured signs.  But, I mainly didn't want to deal with the highlighting for it.

You then have to call CleanOldSigns (or similar). IIRC some tests use it.

Thanks I'll look into this later.

Is this using a dummy entry still, or rather b:neomake_qf?
I am wondering since I would like to make Neomake (optionally?) not change any existing location (and quickfix?) list that is not owned by it, i.e. only if there is no location list yet, or it is owned by Neomake (see https://github.com/neomake/neomake/issues/1165#issuecomment-290394265).

I've rebased it against master locally, let me know if I should push it (about 3 minor conflicts, so you might want to do it yourself).

:sign unplace * buffer={nr} does not work in the Vim 7.3 build; you might have to remember the placed signs, and unplace them one by one there.
Like mentioned before, I have some improvements to the signs module, and it might be usable for this already in the current state to register and clear the signs in the qf window.

btw: Vim just added support for context to location/quickfix lists: https://github.com/vim/vim/commit/8f77c5a4ec756f3f866bd6b18feb6fca6f2a2e91.

Any updates on this? It would be really nice to have :)

@tweekmonster seems to be in (another) zone currently (which is fine :)).
Since this is the oldest open PR currently, and I also like this feature very much myself, I plan to pick it up  myself eventually (but there at least 3 other big things to get in first).
@petobens
Have you tried it?  (should be rebased on master though to get other improvements)
Do you feel like contributing and picking it up?

@petobens @blueyed I haven't been able to keep up due to personal and professional priorities.  I'd like to pick this back up, but I'm not sure when I'd be able to.  I really don't mind if someone would like to continue the work.

@blueyed @tweekmonster I would love to pick this up but unfortunately my vimscript skils are not good enough to do so...

Merged master, and adjusted it to handle makers with get_list_entries/process_output.

FWIW: the "next" branch contains both "automake" and this, in case you want to try it together with "automake".. ;)

It needs to be profiled/optimized probably, since it appears to add a lot of sluggishness (when used often / with automaking).

This is next / coming soon(™) - the last time I've tried it it had a decent set of conflicts already - looking forward to solve them.
IIRC performance is an issue here also - especially since #1167 has been merged by now.

Yay for diff coverage reports: https://codecov.io/gh/neomake/neomake/pull/924/diff

I would like to get this into master soon.
The only remaining question might be how to configure it.
It might be good after all to explictly opt in via neomake#quickfix#enable(), and then we can enhance / integrate it from there?!

I would like to get this into the neomake#configure namespace eventually - similar to how it is used with automake, but it needs a bit of refactoring then.

:fireworks:
Thanks a lot, @tweekmonster!

Follow up in https://github.com/neomake/neomake/issues/1698.

Hi @blueyed. I want to try this new feature but I can't seem to get it working. I have the following settings in my vimrc:
call neomake#quickfix#is_enabled()  " enable experimental quickfix formatting
let g:neomake_python_enabled_makers = ['flake8', 'mypy']
let g:neomake_python_flake8_args = ['--ignore=E402,W503']
let g:neomake_python_mypy_args = ['--ignore-missing-imports',
            \ '--follow-imports=skip', '--python-version', '3.6']

However when I run neomake on the following file:
def f(x: int) -> int:
    return x
print(f([5]))

I see only see the following line in the quickfix:
bar.py|5 error| Argument 1 to "f" has incompatible type "List[int]"; expected "int"

I should say mypy somewhere right? (at least that's what i gathered from the original screenshots).
Btw if i add a long line (>80 columns) at the . top like this:
# asdlksadjasldk jaskld asdjas kldasjdkl asdjasld kjsadkl saj dklasdja skld jasklas
def f(x: int) -> int:
    return x
print(f([5]))

and run neomake again then I only see
bar.py|1 col 80 warning| E501 line too long (83 > 79 characters)

which is the flake8 warning (i expect to see both flake8 and mypy).
Thanks in advance for the help (for your awesome work with this plugin!)

You should use call neomake#quickfix#enable().

Not sure why you do not see flake8 + mypy.  Is it in the list, but not visible maybe? I.e. something would be wrong with auto-resizing the list (also changed recently).

Yep, that was it (in both cases). Mmm is there any plan to improve the formatting a bit?

From your comparison:

I think the buffer name should get the same highlight (blue)
the mypy one looks off: it should have an error sign
Don't you like the line/col formatting/enhancement?

In general:
You should not use set relativenumber in the qf window (we should ensure that it is handled correctly, i.e. enforce :setlocal number norelative).

There is no plan to improve this, and @tweekmonster has been silent about his work since a while.
We need to progress from there/here.

Also the entries nr is not displayed at all.
I think it could be appended to the short maker name, or get its own column, e.g. between maker name and line/col info?
This would make sense for the shellcheck maker, whose short name is "SC" and therefore e.g. "SC2089" would be displayed as with the entry's text - where I would like to remove it from.

Feels like we should create a meta issue or project for this after all.


[Documentation] Add reference to accessList in the docs/examples

What is needed?
In our repo we are using Safe as the entity holding funds for some of our agents. For some contract interactions, it failed since the parameter accessList was missing (see this for rationale, transaction fails due out-of-gas error).
We realized it was missing from the references below:

https://github.com/folia-app/eip-2929
https://ethereum.stackexchange.com/questions/123750/how-to-implement-eip-2930-access-list

I would suggest adding a reference to this in the README of this repo and/or somewhere else in the documentation.
Background
For reference, here is the relevant PR where we add accessList (link).

since the parameter accessList was missing

Where should we add the parameter?

We add the parameter to the TxParams object, see https://github.com/gnosis/prediction-market-agent-tooling/pull/379/files#diff-1d1cce5700d8a183511739e11739daa01a18da8a7ea20d6b65303fc837bb19a0L132.
I'm not saying you should change anything in the code, I would add a hint to the reader (on any README file) saying that access_list might be required when executing transactions with Safe's having multiple signers.

I would add a hint to the reader (on any README file) saying that access_list might be required when executing transactions with Safe's having multiple signers

Why it might be required? It could be more optimal, and maybe required in an edge case, but in my personal case I was never forced to use it


Parent folder .acl is not consulted, even if local .acl does not specify permissions

Given a folder contains a .acl file specifying permissions to a file inside that folder, but does not say something about permissions to the folder itself:
<#owner>
    a acl:Authorization;
    acl:agent <https://angelo.veltens.org/profile/card#me>;
    acl:accessTo <./file.ttl>;
    acl:mode acl:Read, acl:Write, acl:Control.

The parent folder grants all access for the same agent as default (acl:default)
Actual behaviour:
Both, the folder and the file.ttl are unreachable for the agent (403 Forbidden).
Expected behaviour:
Since the .acl does not specify access control for the folder, the parent folder .acl should be checked and access granted to the folder (granted by parent .acl) and to the file.ttl (granted by the folder's .acl).

Yes, this has been discussed in the specification, and it is actually the intended behaviour. Here is the spec issue, pointing to timbl's comment on this:
https://github.com/solid/specification/issues/55#issuecomment-536092174

Should'nt at least file.ttl be accessible, since permission is excplicitly granted? Do you know about any specification or NSS improvments, so that ACLs that do not mention the container itself are prevented?

It sounds like it could be enforced by a shape to not get into that kind of situation, but other than that, I'm not aware of that.
But please mention the problem in solid/specification#55 so we can look into it in that context.


Gas fee volumes

Description

Implemented daily and hourly gas fee volume.
Added endpoint /gas/volume to retrieve gas fee volume
Added tables:

tx_gas_fee_volume_day
tx_gas_fee_volume_hour

Added stored procedure:

update_gas_fee_volume

closes: #186

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Wrote unit and integration
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

commit history contains already merged files.


ui: tags related options not visible for public IP and maybe some other resources

ISSUE TYPE

Bug Report

COMPONENT NAME

UI

CLOUDSTACK VERSION

4.17.0

CONFIGURATION

N/A
OS / ENVIRONMENT

N/A
SUMMARY

UI for adding, removing resource tags is not visible in the public IP view.
This could be an issue with some other resources as well which support resource tags

STEPS TO REPRODUCE

1. Log in to UI
2. Go to details of a public IP

EXPECTED RESULTS

Tags related UI should be visible

ACTUAL RESULTS

Tags related UI is not visible

Fixed in https://github.com/apache/cloudstack/pull/6650


cache validators

to improve performance on large number of validations

Pull Request Test Coverage Report for Build 974945725

0 of 9 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 974581893:
0.0%

Covered Lines:
123

Relevant Lines:
123

💛  - Coveralls

Pull Request Test Coverage Report for Build 974945725

9 of 9 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 974581893:
0.0%

Covered Lines:
123

Relevant Lines:
123

💛  - Coveralls


:command output is not aligned

When you type :command, when the command names are long, the formatting is not pretty. It does a partial job of tabularizing but that fails when the names are big. Is it possible to either remove alignments and just show it normally or do some logic to format it correctly depend on the max length size?
uc_list function in ex_docmd.c handles this. Please let me know if you have feedbacks on the PR.
I created a PR https://github.com/vim/vim/pull/876 if it helps. If you have an alterative suggestion please let me know. If you see the :function output you will notice that it is clean. I think :command should also follow the suit.

Did the patch 8.1.1860 help in any way?

Yes, it did! I will close this issue.Thanks @lacygoill .

Since the issue was fixed, then this todo item is no longer relevant:
https://github.com/vim/vim/blob/21829c5f2c86cd525c8468121b4fc54c5d75bf6e/runtime/doc/todo.txt#L1567-L1569

Since the issue was fixed, then this todo item is no longer relevant:
https://github.com/vim/vim/blob/21829c5f2c86cd525c8468121b4fc54c5d75bf6e/runtime/doc/todo.txt#L1567-L1569


added build_binary_tree_from_parentArray

Added the  Filename as
Changes Proposed  in the PR. Describe
I am assuring that the file is not redundant and making the Pull Request

[x] Yes

Read {% include Contributing.md %}

Congratulation 🎉  Your Pull request has been merged!


[CI] Try fix api test error

Purpose of the pull request
Fix the error in https://github.com/apache/dolphinscheduler/pull/13378
Remove unnessnary log output of test container and upgrade the test container's version according to docs in https://www.testcontainers.org/supported_docker_environment/logging_config/
Adding WorkerGroupAPITest to CI.
Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

(or)
If your pull request contain incompatible change, you should also add it to docs/docs/en/guide/upgrede/incompatible.md

@SbloodyS PTAL


Document 'chronoctl' CLI and migrating from BoltDB to etcd

[ ] chronoctl CLI
[ ] Migrating from BoltDB to etcd

Duplicate of #2620


Add date range filter

Would be good if provided some date range filter (between this and that date).
Thanks

Sure I will add date filter however it will be time-consuming owing to implementing the filter across all log data providers.

I'll implement on the log providers if you like.
Can you take care of the UI?
I'm thinking on two fields (start date + time and end date + time). what od you think?

Thank you @ricardodemauro, I've added initial codes for the date range filter. Please check out the dev branch. I will finish the required JS codes tomorrow.

Alright. I`ll do some coding during the weekend.

@ricardodemauro  could you please review this commit. I've added the date filter but act like OR clause instead of AND clause.

Please upgrade to version 2.0.1.


Add visibleItems() method

Returns an array of data objects that are currently visible, handy to implement item selection / mark as read etc.
Simply keep a ref to the table to use it. It uses, in order, the props "i", "id" or the key to allow the user to provide ids for the table rows.
Not sure if the test setup suits your tastes?

Small nit, plus squash these two commits, keep everything squashed to one commit, and rebase, and this is good to go.


Validation States

Basically, I think it'd be cool to implement this stuff in this library using hasError, ng-messages, $error, etc.  I have a working implementation in a project with custom bootstrap templates that I can pull from, but I'll need to make it a little more bootstrap-standard.
I think part of the problem with this is that, while bootstrap's validation state styling (.has-success, .has-error, etc.) for outlining the controls and coloring the labels is pretty straightforward, how error messages are done (in the case of the docs, it uses the help-block) are far from standard.  Even in my own fairly bootstrap-standard project, I've pulled the errors out into tooltips instead of inline help-blocks so the form isn't constantly resizing.  Nevertheless, I think just including
s or s in the help-block would be a pretty good default go-by.
Any thoughts?

Ok I just realized there's totally already a hasError wrapper in here.  So I guess this is now mainly just about reporting error messages via ng-messages and $error.

@SteveShaffer yeah, it's just matter of extending the fucntionality to support .has-warning & .has-success
You might help us by submitting a PR, o even better, along with a JSBin example for the website :smile:

I wonder if it would be better to implement this in a separate plugin where the class names are configurable so it could be used with more than just bootstrap :-)

+1 @kentcdodds that would be better!
@SteveShaffer there are some plugin examples available if you're up to the challenge :smile:

This is also related to issue https://github.com/formly-js/angular-formly-templates-bootstrap/issues/46

Ya I might be up to the challenge.  I'll add it to my todo list.
@kentcdodds What do you have in mind in terms of a "plugin"?  Like a separate project or something like a manipulator in angular-formly or something else?  Even with the class names configurable, it'll likely still make some pretty bootstrap-specific assumptions about the structure of the DOM (although there's technically not much guidance on what "standard" bootstrap-style validation help text is).
I've been toying with using tooltips instead of inline DOM elements so the forms don't grow and collapse as the errors turn on and off.  Perhaps we could use some simple-enough tooltips that they could work with any framework?

You, different project, maybe a manipulator or wrapper, however you want to do it (I'd probably do a manipulator because I like them better than wrappers). You might do something like this

As a quick solution I came up with the following custom wrapper:
formlyConfigProvider.setWrapper({       name: 'bootstrapHasErrorHasSuccess',       template: [         "
",         "<formly-transclude></formly-transclude>",         "
"       ].join(' ')     });

That's very similar to this wrapper which is built-in to the bootstrap templates. But you've added some custom functionality for your use case which is exactly what angular-formly is meant to allow you to do :+1:

@kentcdodds Angular formly actually helped us a lot. I just wish I had more time and experience to be able to contribute as well.


Unbind imagesLoaded event

When masonry component is unmounted before finishing all imagesloaded callback, the callback still triggers the bound function. In my case, since I called setState in the function, I got a following warning.
Warning: Can only update a mounted or mounting component. This usually means you called setState, replaceState, or forceUpdate on an unmounted component. This is a no-op.

In order to fix this issue, I added unbinding code to componentWillUnmount.

Hi @y310 Thanks for this.
I'm currently looking at the code and believe that the repeated calls to imagesLoaded is actually a mistake.
this.imagesLoaded() should be called once on mounting only, so there should only be a single ref (which will simplify this PR).
I'm sorry to ask, are you interested in submitting another PR once i finish the changes? Otherwise I can do it.

edit: ignore me. Looks like imagesloaded does not listen for images added after it's been initialised.

Thanks for merging! Yeah, seems like imagesloaded requires to be called on update as well.


Removing 390Hz noise from LRS SLITLESSPRISM data

Some MIRI subarrays exhibit 390Hz noise in the pixels within a group.
We roughly knew about this from the LRS TSO commissioning
paper, but Michael Ressler did some great investigative work and showed
that there is a clear 390Hz noise in the group-level data which has a
fixed waveform but has a varying phase. I did some testing myself and
determined the waveform for the LRS SLITLESSPRISM subarray and wrote
code to find the phase. Interestingly, I found that the phase remains
constant within an integration, and while the phase varies a bit between
integrations, I noticed that it has cyclical variations with a period of
8 integrations (in at least one dataset). I couldn't figure out a clean
way to deterministically compute the phase however, so I just fit it in
my added code.
I had hoped that this would improve the high-frequency noise I've
observed in LRS spectra (the noise is in the final transit/eclipse
spectra). However, I have found that the 390Hz step seems to have nearly
zero impact on the transit/eclipse spectrum, while the related
MIRI-specific GLBS code I added at the same time also has little impact.
That said, I don't think I'm the only one who would want to investigate
this effect, so I am still contributing these edits to allow others to
investigate the impact on their data and allow for potential further
improvements.
I will note that this code was only built with the LRS SLITLESSPRISM
subarray in mind and has been tested on several such observations, but a
few other subarrays also exhibit a similar noise pattern. I don't have
any such observations to test the code on, so for now this step should
only be applied to LRS SLITLESSPRISM data.

I'll also point out that it's theoretically possible that this 390Hz noise removal could be combined with separate background observations to try to avoid self-subtraction. I believe early attempts at using separate background observations after the science observations were not very successful, but perhaps there'd be more success with the inclusion of this 390Hz noise removal code applied to both the science and calibration observations.

What's the timeline on this PR? No hurry, just curious.

It'll probably only take me an hour or two to make all the required edits, just need to find the time to get around to that

Codecov Report
Attention: 183 lines in your changes are missing coverage. Please review.

Comparison is base (5be7e90) 57.72% compared to head (dd9da00) 56.94%.

Files
Patch %
Lines

src/eureka/S1_detector_processing/remove390.py
9.82%
156 Missing :warning:

src/eureka/S1_detector_processing/ramp_fitting.py
16.66%
15 Missing :warning:

src/eureka/S1_detector_processing/s1_process.py
0.00%
11 Missing :warning:

src/eureka/lib/smooth.py
75.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #556      +/-   ##
==========================================
- Coverage   57.72%   56.94%   -0.79%
==========================================
  Files          96       97       +1
  Lines       11660    11858     +198
==========================================
+ Hits         6731     6752      +21
- Misses       4929     5106     +177

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Do you have an idea how your code compares to the 390 Hz correction, which is implemented in jwst==1.13 (https://github.com/spacetelescope/jwst/pull/7857)?
Couldn't we just use what the jwst pipeline does?

@sebastian-zieba, I haven't done a whole bunch of testing yet, but I did do a test recently with jwst==1.13.4 and found that there was still significant 390Hz noise after starting with my previously downloaded _uncal files. I'll run another test or two to double-check that the emicorr step is being run (and re-download the _uncal files if I need to). I've also already contributed to a few papers that reference this new Eureka! feature, so I still want to add this code (at least for now) so that the results of those papers are reproducible.


Upgrade target to es2020

Is your feature request related to a problem?
All built files are targeted es5, which compiles all async/await calls to some "polyfilled" version. This makes debugging PostHog quite hard as the stack traces are not complete. async/await has been supported for a long time and only breaks in IE11. Could I submit a PR upgrading the tsconfig.json to use es2020?
Related sub-libraries

[x] All of them
[ ] posthog-web
[ ] posthog-node
[ ] posthog-react-native

@hansottowirtz good call, you can either wait for https://github.com/PostHog/posthog-js-lite/pull/189 to be merged on the main branch or make a PR on top of it, since it is a new major version, we are fine doing this change, thanks btw.


Expandable row don't match table width

Detailed description
Colspan value in Table expandable row is calculated base on [attr.colspan]="model.data.length + 2" link which is causing expandable container to not match width of Table if there is <5 items in model.data

Steps to reproduce the issue

Create carbon table with 2 expandable rows
Expand expandable row
Check if width of expandable row match table width

Additional information
Example with 4 items in model.data

Example with 5 items in model.data

Related to #275

+1
I was just about to report the same issue.
I guess that instead of model.data.length, it should be something like model.data[0].length which refers to number of columns in table data. Thanks.


redundancy attributes logic removed

Description
To remove redundant attributes in target.dao of notification service
Type of change

[*] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Refactor (existing code being refactored)
[ ] This change requires a documentation update

Submission Checklist

[*] Build Verified
[*] Bundle Verified
[*] Lint passing
[*] Unit tests passing
[*] Integration tests passing
[ ] Change logs generated

Additional Notes:

Please generate change logs (run rush change) and add to the PR. Thanks.

Closing this without merging due to inactivity. Please reopen and address outstanding review comments if it's still required.

After talking to @bahavar we know this PR change will not affect any existing customers - confirmed by @hassankhokhar and @bahavar
We would like to merge it into the main branch.

@komushi just realized I had not published my review therefore my above comments related to this PR were not viewable.

Closing due to lack of activity.


Replacing URLs with links in PR diff view creates confusion

Not sure if this is a bug or a feature but GitHub Redefined changed the https://example.com/ into a example.com link, which created a great amount of confusion when I was referencing the lack of https and trailing slash, linking to the line, which turned out to have both of these things, just not visible on my machine.
And if that is a feature, could we a) maybe disable it for diff's b) make it configurable?
Thanks!

Yes that’s involuntary. I sent a PR

Same thing happened again - with extension:

Incognito:

Source

Thanks @pawelad! I sent a new PR. I had mistakenly undone the protection


MISP export

Tram is super useful and could cover the gap between unstructured information and structured information in a TIP like MISP. Thanks for the work! Looking at the code, if we extend WebAPI to add a new export function, I suppose that's the best way to do a MISP export to push the result in a MISP instance. We might extend the MISP objects to add the information contained in tram. Let me know if this make sense and we will start to work on it.

That makes sense to us, let us know if any problems occur. We are happy to see the community is interested and willing to aid in making the tool better!

This sounds good to me as well. Feel free to assign me to a pull request when you want your code reviewed, or if you have any questions about the code. Will keep the issue open for now until an initial pull request comes in, thanks!

Sorry in advance for being off topic, but it is so cool to see such collaboration and engagement! Great example to the rest of the community! Happy Holidays...


Use easy_thumbnails_tags instead

If you're willing to require easy_thumbnails 2.4.1 or higher, it now includes a fix to enable the thumbail tag to be loaded via {% load easy_thumbnails_tags %} instead of {% load thumbnails %}. This fixes a namespace conflict where other 3rd party libraries have defined their own templatetag called "thumbnails". sorl-thumbnail is an example of such library.
For example, one of my third party apps required solr-thumbnail, which caused django-cms blog's {% load template %} to load the solr one, instead of easy_thumbnails, resulting in errors.

Thanks for the heads up! Probably we can fit this into 0.9 release

For search-ability
This issue would manifest itself  as
TemplateSyntaxError: Invalid block tag on line 22: 'endif', expected 'empty' or 'endthumbnail'. Did you forget to register or load this tag?

The error results because the solr-thumbnail tag is loaded instead of easy_thumbnails.


Update no-ip.sh

Little Fix

I think this modification is okay to go.
no-ip has provided ipv6 detect api actually. and it returns raw output as well.
see more on this ip-detection


Auto-updating mechanism / Rolling Release

Have you considered going "rolling release"?
I'm just wondering because whenever there was a new sauer release it felt like we lost a good 30% of the playerbase to the outdated version.
That aside, it would also make the game more dynamic since you can feed content like new maps to the users on a more regular basis and you can correct bugs.
I'm sure there are technical implications, so maybe other people are more suited to continue this discussion.

As a side note: Red Eclipse has a .bat/sh file for the update mechanism https://github.com/red-eclipse/base/tree/master/bin
Imo that looks really painful to maintain. Perhaps we can cooperate with the Red Eclipse Community to find a (better) common solution? :)

Better solution:
https://github.com/inexor-game/code/wiki/Release-and-build-strategy
Idea: use npm to ship and update inexor

Besides the packaging we need to have an automatic way of versioning.
So the first step will be to let all CIs set the version for the package.
Now we have different possibilities to calculate the version (reminder: numbers are for machines, names are for people)

Increment the version on each push to the master branch

Pro: easiest, does not require complex calculations just on every closed PR update the version
Con: no support for semantic versioning (no info about the impact of the changes in the version number)

Calculate the semversion based on the PR description ("#bigbump", "#bump", "#fix" or sth similar)

Pro: semantic versioning
Con: needs a tool checking whether there has been a closed PR.
Pro: Less often a decision about the impact has to be made than 3.

Calculate the semversion based on the commits pushed to master (each commit has to have a category/quality assessment attached, see 2.)

Pro: Semantic versioning
Con: needs a tool (but calculates it on easier reachable info than 2)
Pro: The tool is already written
Con: every commit needs to have a categorized commit message (?)
-> automatic verification needed

I don't know whether we should first do 1) and in a second step switch to 3) or do 3) directly, since 1) requires to read the amount of commits made to the master branch and similarily 3) requires just a simple script to run and return the version.

This is a copy of the wiki entry of Fohlen:
Release and build strategy
The following article addresses main concerns and how to solve them during alpha release phase (current).
The pad for this article can be found here.
Short release system
Proposed system will bring releases more often and fast:

every approved PR will bring a new release
depending on it's severity, the release is either a patch, minor or major according to semver
major releases will be called out for new Inexor series (names)

The Inexor installer
The following proposal should make it easy for everyone to obtain Inexor:

the core client and server will be npm modules

shipped via npm/update
built for Ubuntu 16.04 and Windows only for now
x64 is enough for now we think
building and publishing could/should be done via Travis and Appveyor

how is it possible to ship build stuff from conan?

flex will be a npm module

flex has a standalone user interface
is opened by default in a Browser when core is not installed
contains: Install, Manage Plugins, Manage Instances

Release plan, why
We've been seeing a much decreased rate of commitment to Inexor, mainly because "the average user" cannot see/touch/use Inexor at all. That should be changed.
What's to be done:

for team organisation: priorise tickets
build a fast release cycle/system
add the Flex UI
go on with usual tickets (Refactoring, CEF bugs)
add the information on the website!

Graphical illustration

Maintain new releases
Since not everything will be done automagically right in the beginning, we gonna start out maintaining the first few releases manually.
Bundle name
The default bundle name for now is generated by CPack, whereas the VERSION will be appended with an -alpha suffix
Building with CMake
Invoke conan with scope create_package=1 and then use make package install the usual make install.
This will make a new inexor-..tgz archive.

(repost https://github.com/inexor-game/code/issues/400#issuecomment-304734941)
1. Updating
So Inexor Flex is planned to update Inexor core.
Flex can maybe get updated via a .sh/.bat file.
How are we updating Node.js?
NOT updating Node.js or expecting the users to do it manually is unacceptable.
2.  Packaging problem
This doesn't fix the packaging problem for Linux or Windows (at all?).
Quote Wiki: "built for Ubuntu 16.04 and Windows only for now"
So it's highly limited on which Linux Distributations you can run it and we might get non producable  "but it's working on my machine" bugs because of different Ubuntu versions AND we exclude all other Linux users which aren't Ubuntu users. Doesn't look like a solution. We are back were we started on Linux: Building for each and every distro binaries (not do-able) or exclude people (not acceptable). And if we are starting to build specific binaries, we could host distro specific files/repositories in the first place. Remember where we started this entire discussion?
Snapcraft as proposed by Fohlen previously or Flatpak (as favored personally be me #395) or another container-alike packaging format seems to be the only sophisticated, long-lasting solution on Linux. Everything else might improve a few things here and there, but is not solving it at the root of the problem, plus creating likely new problems on every step of the way. Snapcraft/Flatpak also having their updating services, solving the update problem as well. Also solving it in a widely adopted and tested way.
I'm sure we would find an good updating solution on Windows as well if we don't rush it. We are mostly a 4-core-team-member show and I feel sometimes like we want to do too much in parallel. Concentrating on doing it from the ground up might be better.  What we are doing right now in parallel is getting it build for some, have it complicated and error prone to run for everyone, and working on it to get it packaged for some.
3.  End-user dependency
On Windows we seem to settle even more on Node.js/npm as an end-user dependency, right? (#364) How else should this setup work without a pre-installed Node.js/npm? And if we are starting again to ship Node.js/npm as we previously did with our platform repository (https://github.com/inexor-game-obsolete/platform) how are we supposed to update these via npm? (Back at problem 1.)

(repost #400 (comment))
I don't believe we can deliver a rolling release system with 0.9.0. A lot of tasks have to be done until we get to this point. So this topic shouldn't the main focus of 0.9.0.
Until now the main focus were Flex, CEF and RPC/Tree, which are big goals already and all of them still needs work to be completed. I would suggest to focus on these and bring them into a stable state first before targeting another huge goal.

On 1.
flex will also be updated via npm.
true, one needs to update node.js as well. a bat on windows and a script on linux are enough for this (Since we are targeting Windows 7+, nodejs is retrievable via powershell and/or chocolate)
On 2.
Well the wiki is wrong.
On windows we don't have any problem.
Actually on windows there gets a Inexor-version-alpha.exe and a Inexor-version-alpha.7z created every time Appveyor finishes.
NPM would just replace the need to download and unpack it manually and do it automatically.
On linux it might seem more complicated at first sight but it isn't:
With conan we have every dependency build and packed.
So it can work as self-contained package like on windows.
Or are there any edge-cases im not aware of? It's the same as linking everything statically. Is linking everything statically a portable linux binary?
The only problematic thing is CEF. since we do not have its dependencies build with conan, so we can't ship them in a self-contained package easily.
The clean way is to port CEF to conan. since thats a lot of work CEF is limiting us to the OSes its build for.
As we fix CEF, we make Inexor truely portable.
On 3.
we could create an installer which download node.js and excutes our download procedure somewhen in the beta stage.

@aschaeffer
I don't think going rolling release is actually that far fetched.
Yes, sure we had different plans for 0.9.0 but CEF, Flex and RPC/Tree are all more high-level features than the rolling release system is.
Since we're working bottom-up it would make sense imo to tackle this first.
So the ordering is:

make the build system more stable
make testing / distribution easy (rolling release)
add features and systems (CEF, flex, ..)

On @Croydon's comment

Initially, the users must update Node.js manually (in alpha stage). Later on we can use recipes (such as linux packages or windows installers) to automate all the hassles of the batch scripts and updating Node.js. One step at a time is probably the best way to go.
From my expierence, these systems do not cover platforms as large as Inexor. It is the best concept, yes, but it is simply overkill. That's why none of us, in all these years, was able to produce a satisfying solution with them. (maybe in the future snapcraft could work). Building only for Ubuntu 16.04 in alpha stage will mean that we don't have to test so many linux distributions. Again, this is one step at a time. Who says we wouldn't want support on more platforms? Starting with the system that has the biggest market share however is not a bad idea.
Of course, Node.js will be an end user dependency. What's so bad about that? If you install other games on Windows, they will prompt you to install the whole Visual Studio SDK. Compared to that, an 11 MB big scripting environment, with which you can modify the game to it's core, seems quiet a good deal.

On @aschaeffer
I do think that rolling release should be the absolute focus of 0.9 release. This will finally make it possible to test Inexor (including ourselves), and will most likely get new/old(inactive) users back into Inexor.
We're so close to getting all the fancy technologies working, but we still ain't able to get Inexor running standalone (without miyards of dependencies).
Once rolling-release is working, we can improve Inexor in a very fast speed, with the difference that users can actually test our game and give feedback (mostly sums up what @a-teammate said)
We've been discussing these issues for years now, and is the reason that Inexor commitment is decreasing (because there is "none" result that you could see).
It's also been the main feedback that I have been receiving by a lot of people, that it is so hard to even test Inexor, which is why most of them give up with Inexor.
This is why I think focusing on a stable build and distribution system should be our top priority.

The InexorCore packages for each individual platform get published as follows:

this updates the npm modules @inexor-game/core_windows32, @inexor-game/core_linux32, @inexor-game/core_windows64 and @inexor-game/core_linux64 and pushes its corresponding .zip files to GitHub/releases
Details

The PR quality checks are enforced by GitHub: passing builds on Travis and Appveyor (but we could add other ones as well).
Travis tags a new version just by taking the last tag it can find and increment its minor version.
Travis and AppVeyor create packages using CMake (or more precisely its CPack part)

If you cmake with -DCREATE_PACKAGE=1 you get the same result.

We need Quality checks for InexoFlex as well! Currently InexorFlex is part of the inexor-game/core_.. package (well, the linked submodule of the code repo is).
Any ideas how to detach the InexorFlex general part from the updater? Or is there another solution?

Off-Topic:
Btw I think we should rename https://github.com/inexor-game/code to https://github.com/inexor-game/core now, shouldnt we?

@a-teammate [Off-Topic]: Yes, we should. Please create a new issue for this!

This is definitely done, see #452

Now we need a wiki page for that :)

That's true, maybe we should add reopen this until someones transfers this into a wiki page?

I opened a new issue for writing a documentation: #493


HELP

Hello and thank you for this library!
I want to push data Json
from api openweathermap to firebase can you help me how can I do that?
Thanks!

I don't know but you can look at the examples and test and adapt yourself.


Invalid interaction application command

So, when I tried to reply to interaction, this showed up :

This is my code :
client:on("slashCommandsReady", function()
for _,i in pairs(fs.readdirSync("./commands")) do
  local fileName = string.sub(i, 1, #i - 4)
      local commandModule = require("./commands/" .. i)
          print("Loading " .. fileName)
          local commandSlash = client:slashCommand({
            name = fileName,
            description = commandModule.desc,
            options = commandModule.options,
            callback = function(ia, params, cmd)
            ia:reply("yes")
              --commandModule.execute(client, ia, params)
            end
          })
          print("Loaded " .. fileName)
          local succes, error = pcall(function()
              commandSlash:publish()
          end)
          if not succes then
          print("Failed to publish " .. fileName)
          print(error)
          else
          print("Published " .. fileName)
          end
end
end)

I don't know what your code is doing here.
do print(client:slashCommand ... ), second argument tells the error

I don't know what your code is doing here. do print(client:slashCommand ... ), second argument tells the error

It just simply replies "yes" to interaction.

That is not related to the issue.
Tell me what issue discordia istelling you

That is not related to the issue. Tell me what issue discordia istelling you

That print(client:slashCommand ... ) just shows Id and then crashes bot

Can't help until you tell me the issue discordia is telling you.
local commandSlash, err = client:slashCommand({
            name = fileName,
            description = commandModule.desc,
            options = commandModule.options,
            callback = function(ia, params, cmd)
            ia:reply("yes")
              --commandModule.execute(client, ia, params)
            end
          })
          print(commandSlash, err)

          print(commandSlash:publish())


Feature Request: Hotkey or button to jump to the active note's position on the calendar

Thank you for the ability to quickly move forward and back between existing notes across different time frames (daily, weekly, monthly, quarterly, yearly) using the same hotkey based on what's opened. If there are gaps in my calendar, it likely means there wasn't anything important to note, thus this feature is a game-changer compared to the functionality of other calendar-dedicated and core Daily Note plugins already. You have my gratitude.
One change I would love to see:
Simply put: A hotkey and/or button to highlight and show the "currently open note" on the calendar, supporting all time frames.
Some thoughts:

This allows one to visually see relevant entries based on what is currently opened.
Easily jump to the quarter or year view by presenting the first month of that period on the calendar (since they go beyond the monthly calendar).
A simple slow highlight fade in and out after jumping would be appreciated, but not required. With show on calendar, Daily jumps to month and highlights day, of course. Weekly could highlight the entire week and fade away. Month, quarter, and yearly jumps highlight the entire calendar quickly.

Workflow Example:

Open the current weekly note.
Navigate to previous weeks. Now currently in a weekly note from a few months ago.
Hit "Show on Calendar" to open the relevant month and highlight the currently opened week on the calendar.
See the days of that week, including if they had notes or not, as well as the month, quarter, and year at a glance.
Click "Show Today" to jump back to the present.

All of this in mere seconds. Quick. Easy. Simple.

Extended Functionality (not a priority):

Not what I'm asking for, but additional ideas. The above is already more than enough to see benefits.

Hotkeys to navigate up and down the time frame hierarchy based on the active note (e.g., from daily to weekly, weekly to monthly, etc.). It can also be referred to as zooming in and out.

This could potentially be implemented in one of the following ways as options if it doesn't exist (based on what's currently opened and active): When attempting to move up or down timeframes based on the current note...

Prompt the user with "___ doesn't exist. Would you like to create a new note?" if the desired time frame doesn't have an existing note.
Automatically create a new note for the desired time frame if one doesn't exist without prompting.
If a valid note isn't opened and active, do nothing.

Coupled with the ability to navigate back and forth between existing entries with keyboard only, whew. It would simply feel incredible to fly through the calendar. Not necessary, but just a thought. I am not experienced enough in coding, so I humbly request the main feature above. Thank you for all you've contributed thus far! Sorry if this is more convoluted than it needs to be.

thank you for feedback and ideas
zoom in/out is really great idea - will definitely add it
A have a question re open in calendar functionality
I was considering to auto adjust calendar view based on active note - so if you opened a note several months in path calendar view will automatically switch to that month. This way no additional hotkeys needed. On other hand calendar that is not adjusting might be good as well - you have control which month is is there and with hotkeys can quickly switch.
Would like to hear your opinion on what makes more sense for you

Hello, thank you for your consideration. In my opinion, auto-adjusting the calendar to reflect the active note sounds more intuitive. I only assumed you had your reasons for this and wanted to request additional functionality. That would be much simpler to implement 🙂

Great, I'll add this in next release

Released in 1.3.0


[BREAKING] Test: Organize, improve and provide new helpers

This PR includes:

Organization of test helper files into dirs by functionality
Minor enhancements (recommended to be reviewed by commit)
Small new additions: clock mock, execution target, pct numbers helper

Closing; the contract updates and reorganization have been finished through #39, and other JS-related logic has been brought to parity in the base repo.
Re-organization will happen after, or with, #30.


Create area tests utilizing the interesting polygon archive

Came across this quite excellent dataset of polygons: https://github.com/LingDong-/interesting-polygon-archive
Would like to enable loading them and parameterizing the unit tests with them.

Polygon
Added
Notes

eberly-10
⚠
Holes

eberly-14
⚠
Holes

elgindy-1
✅

gray-embroidery
✅

held-1
⚠
Holes

held-12
✅

held-3
⚠
Holes

held-7a
✏
TODO

held-7b
✏
TODO

held-7c
✏
TODO

held-7d
✏
TODO

mapbox-building
✏
TODO

mapbox-dude
⚠
Holes

matisse-alga
⚠
Holes

matisse-blue
⚠
Holes

matisse-icarus
⚠
Holes

matisse-nuit
✏
TODO

mei-2
⚠
Holes

mei-3
✏
TODO

mei-4
⚠
Holes

mei-5
✏
TODO

mei-6
⚠
Holes

meisters-3
✏
TODO

misc-discobulus
⚠
Holes

misc-fu
⚠
Holes

seidel-3
✏
TODO

skimage-horse
✏
TODO

toussaint-1a
✏
TODO

Some of them have holes which I'm not yet supporting, will be good to have those identified for when those are supported but in meantime I could still use them and just take the outer boundary, although I will need to do a little work to get the correct area for the test.


feat Made task timeout configurable

Delete the stats for data size, since it would cost too much time but useless
Make task time out configurable since when it's common to analyze a quite huge table that the default 10 min is not suitable

Proposed changes
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall

run buildall


Add new expected results files for Simba JDBC driver.

These are equivalent to the expected results files for the Apache JDBC driver.
The main differences are in formatting.

Krystal, please review these expected results files.

LGTM +1

Krystal, Thank you for the review.


Determine recommended gameserver based on player location

We can use<EMAIL_ADDRESS>to determine the location of the player and then mark the closest server as recommended.

Geography based on the IP may not be important. The server with the lowest average ping might be the best heuristic to determine the "closest" server.


Wrong results without error if saved_trimmed = true

Description of the bug
Hi, I find a wired thing that if saved_trimmed = true used when I using fastp as trimmer, the mapped reads reduced a lot.  Take OMICS_356_21 as an example, the M reads goes from 100.6M to 64.7M if I set saved_trimmed to true without any other parameter change.  And both 2 pipeline finished successfully with " [main] INFO  nextflow.Nextflow - -[nf-core/rnaseq] Pipeline completed successfully -".  Does anyone know why？
Many thanks

Command used and terminal output
Read trimming options
trimmer              : fastp
extra_fastp_args     : --length_required 50 --cut_by_quality3 3 --cut_by_quality5 3 --cut_window_size 4 --cut_mean_quality 15
Alignment options
min_mapped_reads     : 5
Quality Control
rseqc_modules        : inner_distance,read_distribution
Process skipping options
skip_umi_extract     : true
skip_pseudo_alignment: true
skip_markduplicates  : true
skip_bigwig          : true
skip_stringtie       : true
skip_dupradar        : true
skip_qualimap        : true
skip_biotype_qc      : true
Relevant files
No response
System information
No response

I find the problem. That is mainly becasue the version I used is 3.14.0. This is a bug that saved_trimmed is also transferred as save_merged setting, which makes the –out1 and –out2 files to be incorrect for the mapping step.


Installer manifest is not a valid yaml file

https://raw.githubusercontent.com/sakasakiking/FusionX/main/Manifest/Installer_Manifest.yaml
unidentified alias "*Segoe" (20:24)

 17 |     - Fixed many UI issues.
 18 |     - Now we can set the spacing between the game deta ...
 19 |     - Add a default app background.
 20 |     - Iconfont: **Segoe Fluent Icons** is needed.
-----------------------------^
 21 |   - Version: 1.0
 22 |     RequiredApiVersion: 2.6.0

Thank you for letting me know. I'll remove it.


dx-file-uploader options in Angular2

To help us process the issue more efficiently, please provide the following information:

Specify the version of the devextreme-angular and devextreme packages you are using.
typescript version: 4.4.x
devexteme version: 16.2
devextreme-angular version: 2
Specify the type of the issue (check one with "x"):
[ ] bug Report
[ ] feature request
[ x ] support inquiry

Hi,
I am using dx-file-uploader and I'm unable to find the option to call callback function after the file is uploaded. i tried using this:
<dx-file-uploader
                            #fileUploader
                            uploadUrl="https://js.devexpress.com/Content/Services/upload.aspx"
                            [multiple]="false"
                            accept="images/*"
                            uploadMode="instantly"
                            (Uploaded)="fn"
                            (UploadError)="errFn"
                        ></dx-file-uploader>

Please let me know what options can I provide over here.
Thanks.

We don't process questions related to the DevExtreme UI widgets specifics in this repository. If you have any questions regarding your scenario or widget behavior, please submit a support request to our support center. There, you will get your question answered in a short time frame.


Optimistic updates: Withdraw rewards

Is your feature request related to a problem? Please describe.

As a user
I want to see the remaining withdrawable rewards to update immediately after claiming them
So I feel comfortable that my action worked.
Describe the solution you'd like

Update the claimable rewards immediately
Describe alternatives you've considered

Additional context

is there some way we can use the action modals to help make this happen by default instead of having to manually implement this for every tx type?

all success txs should also trigger get balance and query txs (besides the individual action)

But that would not be optimistic and only get called after each block. So in the worst case there is 5s delay for the update. We still need to update the state after a tx is sent.


Update Anthropic Client

Anthropic changed their python sdk - making this code line outdated.
https://github.com/EleutherAI/lm-evaluation-harness/blob/4fbbd60fa3573dcbf61eb79492f772adeb969157/lm_eval/models/anthropic_llms.py#L50

Would love to know if this might help - https://github.com/BerriAI/litellm
~Simple I/O library, that standardizes all the llm api calls to the OpenAI call
from litellm import completion

## set ENV variables
# ENV variables can be set in .env file, too. Example in .env.example
os.environ["OPENAI_API_KEY"] = "openai key"
os.environ["ANTHROPIC_API_KEY"] = "anthropic key"

messages = [{ "content": "Hello, how are you?","role": "user"}]

# openai call
response = completion(model="gpt-3.5-turbo", messages=messages)

# anthropic call
response = completion("claude-v-2", messages)

cc: @lintangsutawika @guijinSON


Convert azure devops pipeline to yaml

https://devblogs.microsoft.com/premier-developer/converting-classic-azure-devops-pipelines-to-yaml/

Fixed by #362


Official web site: Chrome Privacy Error

Your connection is not private
Attackers might be trying to steal your information from tyrian.wizawu.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_DATE_INVALID

It's odd... The certification should be provided by GitHub. I don't know why there is a stuck.

It's odd... The certification should be provided by GitHub. I don't know why there is a stuck.

More information:
This server could not prove that it is tyrian.wizawu.com; its security certificate expired 4 days ago. This may be caused by a misconfiguration or an attacker intercepting your connection. Your computer's clock is currently set to Sunday, June 13, 2021. Does that look right? If not, you should correct your system's clock and then refresh this page.
Proceed to tyrian.wizawu.com (unsafe)

The date on my system is absolutely right. I used a VPN service to access your site. The same error. It's something wrong with your site, not us.

I never serve this site on my own. It's completely on GitHub Page.

I've reported it to GitHub. We can just wait.

The SSL problem is fixed now. Thanks for notice!


Containers that are attached to multiple networks sometimes don't bevome valid upstreams

To reproduce the problem, see the following setup:
The proxy is in a ntweork called "frontend". The app is in the "frontend" as well as the "backend" networks. The proxy doesn't detect any upstreams for the configured matchers.
If the app is not in the "backend" network, it is picked up correctly.
If I rename "backend" to "x_backend", it is picked up correctly! Apparently, it picks up the alphabetically first tenwork the container is attached to. My workaround was to rename my networks to "01-frontend" and "02-backend" but I think this is a funny hack, not a great solution.
It's happening around here, I suppose: https://github.com/invzhi/caddy-docker-upstreams/blob/ae857aaf46ad2ec13c80b826388454efd20dcd2a/upstreams.go#L112

@heinebold Could you provide the docker-compose.yml?

I created a compose.yml that contains everything you need to reproduce, fully inlined.
You should get an error for the container attached to two networks with the file as is, and make the container work by renaming the backend to something like z_backend or the frontend network to something like a_frontend.
compose.yml (remove .txt ending, github complained)

Thanks for your feedback.
I added a label com.caddyserver.http.network to specify the network.
Would you like to test and give me some feedback?

Thank you! Yes, of course, I'll experiment a bit in the evening (I'm only using it in a side project, it has to wait till my regular work is done)
I had kind of expected it to work just independent of the network / in all networks, but this implementation is probably the safest one wrt unexpected behavior.

It works, but with one bug/problem: If the network is created via docker compose, you have to specify the final name of the network, which is the name you gave it, prefixed with the compose project's name.
In my example file, it doesn't work with com.caddyserver.http.network: frontend, you'd have to specify com.caddyserver.http.network: example_frontend, which would break once you touch the name of the project.

Thank you, this is very valuable firsthand information. I will try to optimize this issue.

Thank you very much, this works great!


pull request for e2e test at 01/27/2017 03:56:11

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


LUCENE-10526: add single method to mockfile to wrap a Path

Currently "new FilterPath" is called from everywhere, making it impossible for a mockfilesystem to use a custom subclass.
See JIRA for full description.
The use case here is to e.g. allow WindowsFS to wrap with a custom subclass that checks for special characters that windows doesn't allow. But today it can't do that since there is code everywhere doing the wrapping.
This PR adds a single method wrapPath() to FilterFileSystemProvider to do this wrapping, and refactors everything to use it.

@gautamworah96 care to take another look? I think fixing the tiny nit was helpful to our tests. now it is easier for tests to wrap a path with one of these mock filesystems explicitly, as they don't have to deal with URI class or pass around FileSystem objects. thanks!

Thanks for reviewing, and good luck improving the act-like-Windows!


Windows installation instructions

While installing COW on Windows, I ran into the following issues/deviations when compared to the instructions @ https://csvw-converter.readthedocs.io/en/latest/
It might be useful to split the installation instructions up between Windows and Mac.

It's important to create a COW folder and open command prompt in there.

Terminal is not a windows term, replace it with Command Prompt (right-click on start and select command prompt or left-click start and type cmd and press enter).

Source bin/activate doesn’t work, had to cd Scripts and then activate, and THEN go back to the main folder.

Also worth noting that there's no example CSV (imf_gdppc.csv) in the files anymore! I'd suggest including it again, or telling people to create it themselves (which I ended up doing).

If you don't create a COW folder, all the files and folders will just be thrown in your root. That's not really a problem but it's a lot less cluttered if they're in a folder.
Agree with everything else. Thanks!

It doesn't seem this is an issue right now, if it comes up again, then I think it might be handy to add Windows installation instructions.


Size Classes

Hi there, this control is really great, unfortunately does not work well when using size classes if you set an initial size class any/any with a particular size and then you want to set a different size when in compact/regular size class it does not update according to the actual size class.

@ed-mejia Hi! Supported size class! https://github.com/ykyouhei/KYShutterButton/releases/tag/1.0.4

Hey!... @ykyouhei
I was looking around and seems it's not working quite right yet... I have the same issue with another lib and I tried to look at your "support size classes" commit  but couldn't find anything that give me a hint about it...
You can check this screen from the actual sample project to find out is not being displayed correctly on the simulator, but it is on the IB screen

@ed-mejia
Hi! Fixed a bug. https://github.com/ykyouhei/KYShutterButton/commit/71f1140b5620a3eb67b04efe544363c9ea27034d
https://github.com/ykyouhei/KYShutterButton/releases/tag/1.0.4

Works great! thanks @ykyouhei 👍


Compile makes wrong assumption about a type

Bug Report
🔎 Search Terms
type inference

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about bugs that aren't bugs

⏯ Playground Link
Playground Link
💻 Code

type FooOrBar = "foo" | "bar"

function process(array: boolean[]) {
    let myValue: FooOrBar = "foo"
    array.forEach((value) => {
        myValue = "bar"
    })
    if (myValue === "bar") { // <-- this should not lead to an error
        //
    } else {

    }
}

🙁 Actual behavior
the compiler says that 'myValue' cannot be "bar"
🙂 Expected behavior
the compiler realizes that 'myValue' can be "bar" as well as "foo"

There’s a template for exactly this issue, but sigh people only seem to click it accidentally for unrelated issues…
Duplicate of #9998.

I see. I missed that template indeed. Thank you.
Interesting how I never ran into that issue up until now.

Yep, everyone hits it at some point.  It’s not great, but the alternatives aren’t necessarily any better, as covered in #9998.


Not able to pass Normalized "face_landmarks" as an input stream to custom calculator

I'm trying to add new calculator to mediapipe facemesh module to crop the eye regions. I have created a new calculator and am able to pass the input image to the custom calculator (able to do normal processing on the image as well) and i tried to pass the normalized landmark along with the image but the app is getting crashed.
this is the custom calculator:
node {
calculator: "BackgroundMaskingCalculator"
input_stream: "NORM_LANDMARKS_TEMP:face_landmarks"
input_stream: "IMAGE_CPU:throttled_input_video_cpu"
output_stream: "OUTPUT_VIDEO:output_video_cpu"
}
If am adding the following lines in the GetContract app is crashing
if (cc->Inputs().HasTag("NORM_LANDMARKS_TEMP")) {
cc->Inputs().Tag("NORM_LANDMARKS_TEMP").Set();;
}
Initially i got some errors and i have resolved it by importing the headers. Now am not getting any errors during build. But the app is getting crashed.

Hi @midhulavijayan, Could you please share the error logs and your code repo to understand the issue much better. Thanks!

Hi @sgowroji, i have installed the app using bazel command and while checking it is crashing. Could you pls tell me how to get the error logs?

anks for the reply. I have already modified some of the face mesh
functionalities as per my requirement. I am passing laterality as a side
packet to show some particular connections (that part is working). I am
attaching the mediapipe folder here.
mediapipe.zip
https://drive.google.com/file/d/1ibUIT1LqDu_AHg1JzFyl885e2uZk2GlT/view?usp=drive_web
I have build it using "bazel build -c opt --config=android_arm64
mediapipe/examples/android/src/java/com/google/mediapipe/apps/facemeshgpu:facemeshgpu"
and installed using "adb install
bazel-bin/mediapipe/examples/android/src/java/com/google/mediapipe/apps/facemeshgpu/facemeshgpu.apk"
In the above project folder if comment line no: 83 in
"mediapipe/graphs/face_mesh/subgraphs/face_renderer_gpu.pbtxt", the app is
working fine. (83rd line commented below)
node {
calculator: "BackgroundMaskingCalculator"
#input_stream: "NORM_LANDMARKS_TEMP:face_landmarks"
input_stream: "IMAGE_CPU:throttled_input_video_cpu"
output_stream: "OUTPUT_VIDEO:output_video_cpu"
}
I think the problem is with passing "face_landmarks" or accessing it.
Thanks and Regards
Midhula Vijayan
On Wed, Apr 7, 2021 at 1:07 PM GowrojiSunil @.***>
wrote:

Hi @midhulavijayan https://github.com/midhulavijayan, Could you please
share the error logs and your code repo to understand the issue much
better. Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/mediapipe/issues/1851#issuecomment-814680356,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJMCR23M2SXVDJC7HJITSM3THQDSZANCNFSM42QETPTQ
.

--
Regards,
Dr. Midhula Vijayan

Hi,
I have resolved the issue by passing "multi_face_landmarks" instead of "face_landmarks"

Glad your resolved and Thanks for sharing your fix. We are closing this issue.


About data preprocessing

Hi, I am interested in your repo ActionRecognition, and trying to run codes.
However, in you 'experiment.md' file, about Preprocessing
3. Segment number of frames into equal size blocks(frame number/sequence
length L). Randomly select one frame from each block to compose L length
video clip

Is this that if there are 35 frames for one video, then if the L is 5,
it is divided into 1-5, 6-10 , ... , 31-35, which is 7 blocks and get
random 7 frames which are each from first to last blocks then make 7 frames video?
If my understanding is right, I'd like to know why doing this.
Also, is there any way to get sequence length L? Is it fixed? which number you chosed?
p.s. If possible, can you let me know the threshold for discarding videos with too few frames in below description.
2. Extract video to 5 FPS and down sample resolution for each video
and discard videos with too few frames

Hello, thank you for your interests 😄.
L is the length of each video clip after preprocessing, and we set it as a fixed number for simplicity. In your example, the original video contains 35 frames (with FPS=5) will be divided into 5 chunks, and each chunk will contain 7 frames, then we randomly pick one frame in each chunk to compose a 5-frame video clip. We chose L=10 in our experiments.
As for the threshold, if L=10, then an original video containing less than 10 frames (after converting to FPS=5) will be discarded.


Component: RelativeDatePicker, props -> format doesn't support latin literal "T", only cyrillic literal "T"

For example:
<DatePicker
    format="YYYY-MM-DDTHH:mm:ss" // T is latin
/>

console print the following error: "The token "DDTHH" is not supported by the Date field. Please try using another token."
and ui of DatePicker will be broken and show something like this: 2024-07-DDTHH:00:00
<DatePicker
    format="YYYY-MM-DDТHH:mm:ss" // T is cyrillic
/>

ok

сс @ValeraS

Any text inside brackets will be used as is. In your case use this format="YYYY-MM-DD[T]HH:mm:ss"


Add read and a write options

And additionally refactored a few small bits to satisfy my OCD

I think all comments are addressed/fixed now… My vim setup is doing vet and lint checks on every save, so that's covered :wink: Will look at adding some tests tomorrow, don't have more time this evening...

@kniren added (and updated) the tests. Think all should be good now, but let me know if you feel differently. Thx!


Allow enumerating all server variables

Add a managed interface for enumerating all server variables.
Follow up to #562 which added a managed interface for fetching one server variable.

Triage decision: We won't really need this.


Code | Alphabetic Pattern 83

@aryashah2k Kindly assign this one to me.

@aryashah2k Kindly assign this one to me.


Improve performance of all screens using OptionsList

Details
We were rendering a very large initial set of data for anything using the OptionsList. I can't remember why it was set up like that, but removing it doesn't seem to have any negative effects so far.
Fixed Issues
Fixes https://github.com/Expensify/Expensify/issues/155388
Tests

Click on the magnifying glass icon
Verify that the Search screen loads quickly

Tested On

[x] Web
[x] Mobile Web
[x] Desktop
[x] iOS
[ ] Android

Screenshots

Web

Mobile Web

Desktop

iOS

Android

Tests well on web so far. Checking native platforms to be sure this doesn't explodey anything.

Android performance before:
[Wed Mar 10 2021 11:15:20.526]  DEBUG    Timing:expensify.cash.search_render 3671
Android performance after:
[Wed Mar 10 2021 11:14:12.636]  DEBUG    Timing:expensify.cash.search_render 189

Also, it might be nice to add a new timing graph in the dashboard for this new event.

wonder if its a good idea to keep a small number here? From my brief testing the timing difference is trivial

I'm not sure why we should? But I'm assuming there is some default initial number so I think we can just leave this for now 🤷♂

Added it to the dash

But I'm assuming there is some default initial number so I think we can just leave this for now 🤷♂

I also assumed this, but after looking for some time (and testing some values), I don't think this is the case.
But yeah, it's not necessary so lets leave it.


feat(civil3d): nest offset alignments in parent alignments

What package are you referring to?
Civil3d connector and converter
Is your feature request related to a problem? Please describe.
Currently, offset alignments are being treated usually as if they were centerline alignments.
This means on receive, they are created without being linked to a parent alignment, which can be an unacceptable condition if a user specifically wants to send a parent alignment with its offset and then changes the parent alignment after receive (which wouldn't change the offset alignment, and woudl require manually rebuilding the received offset alignment as an offset of the parent).
Describe the solution you'd like
Offset alignments when sent without their parent should be received as centerline alignments.
Offset alignments when sent with their parent should be received as offset alignments.
Additional context
This is similar to how hosted elements behave in revit, and would require some refactoring of the connector to store host element relationships if a parent alignment is created first and offset created in the same conversion, making sure they are doubly created during the flatten cycle.

Closing this ticket as we are moving to Jira to reduce noise. You can access it there.


Strange "Behavior Spec" behavior

Hello.
I tried the last 2.0-SNAPSHOT of kotlinspec (built from this commit). I have next code:
class Test : BehaviorSpec() {
    init {

        Given("test") {

            When("when 1") {
                println("when 1")

                Then("test 1") {
                    println("test 1")
                }
                Then("test 2") {
                    println("test 2")
                }
            }

            When("when 2") {
                println("when 2")

                Then("test 3") {
                    println("test 3")
                }
                Then("test 4") {
                    println("test 4")
                }
            }
        }

    }
}

And there are outputs:

oneInstancePerTest = true     |     oneInstancePerTest = false
when 1                        |     when 1
when 2                        |     when 2
when 1                        |     test 1
when 2                        |     test 2
test 1                        |     test 3
when 1                        |     test 4
when 2
test 2
when 1
when 2
test 3
when 1
when 2
test 4

May I am wrong, but I think when block must be running separately just for inner then block:
when 1 -> test 1 -> test 2
when 2 -> test 3 -> test 4

so I can write something like that:
Given(a user try to login)

    When(login was failed)  // mock request, configured via Mockito, returns error, valid for this `when` block
        Then(show error for user)

    When(login is success) // the same mock request returns success, valid for this `when` block
        Then(store auth token)
        Then(redirects user to main)

I'd expect this for oneInstancePerTest = false :
when 1 -> test1
when 1 -> test2
when 2 -> test3
when 2 -> test4

The order could obviously be different with multiple instances, however the when block should be executed before each then block, what is not the case.

This does seem strange, especially if when 2 could side effect data declared in the init method and you only want this side effect to occur when running when 2 tests

I'm wondering the logic of multiple WHEN in one GIVEN{}. Because I wrote the following code in my demo:
class MyBehaviorSpec: BehaviorSpec() {     init {         given("a stack") {             val stack = Stack<String>()             println("new-stack ")            when("an item is pushed") {                 println("when-push ")                 stack.push("kotlin")                 then("the stack should not be empty") {                     println("then-check-1 ")                     stack.isEmpty() shouldBe false                 }             }             when("the stack is popped") {                 println("when-pop ")                 stack.pop()                 then("the stack should be empty") {                     println("then-check-2 ")                     stack.isEmpty() shouldBe true                 }             }         }     } }
It came out that all WHEN got executed first, and all codes inside THEN{} after that. So the first stack-empty-check failed here. Is that we shouldn't put multi WHEN inside a GIVEN?
The output is like this:
`
new-stack
when-push
when-pop new-stack
when-push
when-pop
then-check-1
java.lang.AssertionError: expected: false but was: true
Expected :false
Actual   :true
----- call stack ------
new-stack
when-push
when-pop
then-check-2
`

Any news on this? With 2.0.3 we still have the same problem as described above.
I could reproduce it not only with BehaviorSpec but also with FeatureSpec. All feature clauses are executed before all scenario clauses.

I think oneInstancePerTest affects things, but isn't the root cause. I'm looking into it.

Any news on this? This effectively makes the behavior spec unreliable in its current form.

There's something more fundamental at work with interceptSpec, I think.
For example, if you have two specs of type FunSpec, and each is override val oneInstancePerTest = false, and each one having a override fun interceptSpec defined.  Then  the interceptSpec of the first spec to execute is called, but not the second.

The whole oneInstancePerTest thing was a mistake in my opinion. It means the underlying implementation problematic, as you have to re-create and re-run lambdas from the test scopes. I note that Spek doesn't offer this feature, probably because it's more hassle than it's worth.

This is fixed in 3.0.0 RC1.
If you have the time, please give it a try. There are some breaking changes that should be aware of by reading the changelog here: https://github.com/kotlintest/kotlintest/blob/master/CHANGELOG.md

The RC build(s) don't appear to be in Jcenter or maven central.  Do you have a snapshot repo?
I also tried building/installing locally, but it seems the  project doesn't have the usual publishToMavenLocal task.

There was an issue with maven central so RC1 went missing but RC2 is there
now.
On Mon, 26 Mar 2018, 00:47 Kirk Stork<EMAIL_ADDRESS>wrote:

The RC build(s) don't appear to be in Jcenter or maven central. Do you
have a snapshot repo?
I also tried building/installing locally, but it seems the project doesn't
have the usual publishToMavenLocal task.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/kotlintest/kotlintest/issues/163#issuecomment-376013543,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAtZGic-PSY8VnAHjEX8NJl3cR9An3Zzks5tiCyLgaJpZM4MjIaz
.


[question] jwt decode on gcc 10 is throwing an error at build

Describe the impediment
I am trying the decode method form the example, but on build i get this error
couldn't deduce template parameter 'json_traits'

and this
no matching function for call to 'decode(std::string*)

Trying to obtain
The code implementation which needs attention.
Desktop (please complete the following information): (Include/Attach if Applicable)

OS: MacOS Monterey 12.1
Compiler gcc
Version 10.3.1 arm-none eabi

Additional context
  std::string token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXUyJ9.eyJpc3MiOiJhdXRoMCJ9.AbIJTDMFc7yUa5MhvcP03nJPyCPzZtQcGEp-zWfOkEE";
  auto decoded = jwt::decode(token);

Logs (Include/Attach if Applicable)
Click to expand log
[build] /Users/rares/Documents/Projects/pico/esp8266-template/main.cpp: In function 'int main()':
[build] /Users/rares/Documents/Projects/pico/esp8266-template/main.cpp:41:36: error: no matching function for call to 'decode(std::string*)'
[build]    41 |   auto decoded = jwt::decode(&token);
[build]       |                                    ^
[build] In file included from /Users/rares/Documents/Projects/pico/esp8266-template/main.cpp:14:
[build] /Users/rares/Documents/Projects/pico/esp8266-template/include/jwt-cpp/jwt.h:3596:27: note: candidate: 'template<class json_traits, class Decode> jwt::decoded_jwt<json_traits> jwt::decode(const typename json_traits::string_type&, Decode)'
[build]  3596 |  decoded_jwt<json_traits> decode(const typename json_traits::string_type& token, Decode decode) {
[build]       |                           ^~~~~~
[build] /Users/rares/Documents/Projects/pico/esp8266-template/include/jwt-cpp/jwt.h:3596:27: note:   template argument deduction/substitution failed:
[build] /Users/rares/Documents/Projects/pico/esp8266-template/main.cpp:41:36: note:   candidate expects 2 arguments, 1 provided
[build]    41 |   auto decoded = jwt::decode(&token);
[build]       |                                    ^
[build] In file included from /Users/rares/Documents/Projects/pico/esp8266-template/main.cpp:14:
[build] /Users/rares/Documents/Projects/pico/esp8266-template/include/jwt-cpp/jwt.h:3608:27: note: candidate: 'template<class json_traits> jwt::decoded_jwt<json_traits> jwt::decode(const typename json_traits::string_type&)'
[build]  3608 |  decoded_jwt<json_traits> decode(const typename json_traits::string_type& token) {
[build]       |                           ^~~~~~
[build] /Users/rares/Documents/Projects/pico/esp8266-template/include/jwt-cpp/jwt.h:3608:27: note:   template argument deduction/substitution failed:
[build] /Users/rares/Documents/Projects/pico/esp8266-template/main.cpp:41:36: note:   couldn't deduce template parameter 'json_traits'
[build]    41 |   auto decoded = jwt::decode(&token);
[build]       |                                    ^

Can you please share what commit you are using and the includes you are using? 🙏
I very recently played with this so I want to make sure I know exactly where to look so we can resolve this quickly!

I am using the commit from 10 hours ago 97c8782605570c45b15183a270b39d16323068e8 and i am using the jwt-cpp folder, i already have the json one with version 3.10.5

Also, i am not sure i am importing the OpenSSL correctly, i have like this but when i try to use anything from it i have this error: undefined reference to "method's name
target_include_directories(${PROJECT_NAME} PUBLIC ${CMAKE_SOURCE_DIR}/include)
target_compile_options(${PROJECT_NAME} PUBLIC "-Wno-psabi")

target_include_directories(${PROJECT_NAME} PRIVATE ${CMAKE_SOURCE_DIR}/src)

set(OPENSSL_ROOT_DIR "/usr/local/opt/openssl")
find_package(OpenSSL REQUIRED)

target_link_libraries(${PROJECT_NAME}
  OpenSSL::SSL
)

i already have the json one with version 3.10.5

Do you mean you are trying to use https://github.com/nlohmann/json?

i am not sure i am importing the OpenSSL correctly

You'll want both targets https://cmake.org/cmake/help/latest/module/FindOpenSSL.html#imported-targets
https://github.com/Thalhammer/jwt-cpp/blob/3bd600762a70faccc7ec1c2dacb999cba6c6ef5e/CMakeLists.txt#L92
Since you are using CMake, how are you including JWT-CPP in your project?

If your project is open source, feel free to share I might see something if I can poke around 😄

Hey, i added the JWT-CPP files in include, but i am not sure it will work with my type of project, is an IoT device, and to get the time i use an RTC, but i made a workaround and i implemented something similar to a JWT.
This is the repo: https://github.com/RaresAil/rpi-pico-esp-cpp

That's an exciting project! I've never tried using this JWT-CPP for IoT so I am not sure what to expect.
I am sorry it did not work for you use case.
If the issue is no longer relevant feel free to close it :)

Thank you for your help 😄

I'd like to reopen this.
ESP SDK Supports wolfSSL and Exceptions so we should be able to support it (that said I think we should get a noexcept mode done at some time in the future).
The error you are seeing is because you tried to pass a pointer to a string to decode. The error log shows the line is
auto decoded = jwt::decode(&token);

Removing the &, so it reads like the example you posted should fix the error.

I am not using ESP SDK, the IoT project is made from 0, and i already implemented a custom functionality for HS256 signing 😞


Settings Menu behaviour when in image view

Start in Albums View
Open Settings so that Settings sidebar is open
Open an album
Click on Settings Menu Entry
Settings are opend
-> Good

Start in Albums View
Open Settings so that Settings sidebar is open
Open an album
Open an Image (image view)
Click on settings menu entry
Header title change from image name to "Settings"
Settings are NOT opend
-> Bad

click browser back button
Settings are opened with Albums Header Title

There are two ways to fix this. One is to fix the displaying of Settings in the photo view, the other is to hide the sidebar in anything but the albums view :wink:. My guess is that whoever wrote this code didn't consider the possibility of invoking Settings in the photo view. There's a reason why the cogwheel is only visible in the albums view, after all.


Remote cfg_if! macro dependency

The standard builtin cfg!() macro is actually cleaner and also less code.

cfg_if! would be more useful if there were multiple possible implementations, but since the implementations are only switched on or off, it doesn't add any value.
https://doc.rust-lang.org/std/macro.cfg.html

@luizirber  if it's ok for you can merge

Thanks for the PR, @dralley!
The main issue is that cfg! requires all codepaths to be valid, and this is what is making the tests fail in CI. You can get the same failures locally by running cargo build --no-default-features, when none of bz2/flate2/xz2 crates are available and so there are compilation errors.

@luizirber Fair point - it appears this is not as easy as I initially though, or at least the benefits will not be as great once finished.
I'll close this, and if there's a better way I may reopen, but I don't immediately see one.

Thank for your interest on this project @dralley


Type inference for batch operations

Right now, batch operations like batchGet do not provide type inference, and simply resolve to any. Will this be supported in the future, or is there an underlying technical reason as to why this is not the case?
My team relies on batch operations extensively in our scheduled workloads, and not having type safety for these operations is a big reason why we haven't migrated to DynamoDB Toolbox yet.

This has been resolved as of V1, closing it out.


Learn words that should never be checked

In GitLab by @jakebeal on Feb 1, 2019, 21:07
Some words won't be in the dictionary, but shouldn't be tagged, such as the names of people and companies. Let the robot learn these words.

In GitLab by @jakebeal on Jun 17, 2019, 10:51
assigned to @nwalczak

In GitLab by @jakebeal on Jun 17, 2019, 10:51
This might already be done by the spell-checker "learn" feature? Validate and commit.

In GitLab by @nwalczak on Jun 26, 2019, 10:43
If terms aren't in the dictionary, analyze won't pick them up.  This will just get picked up by the spellcheck feature.  There is a button "add to spellcheck dictionary", which will ignore the term, and these additions are saved by user and reloaded.

In GitLab by @nwalczak on Jun 26, 2019, 10:43
closed


UT got scratch page issue with rolling driver

🐛 Describe the bug
TestCommonXPU::test_out_bincount_xpu_int64
2024-07-11T08:48:47.7389771Z FATAL: Unexpected page fault from GPU at 0x56443f92d000, ctx_id: 1 (CCS) type: 0 (NotPresent), level: 3 (PML4), access: 1 (Write), banned: 1, aborting.
Versions
Driver: 914.30 with envs: export NEOReadDebugKeys=1, export DisableScratchPages=1
Bundle: 0.5.1
torch-xpu-ops: https://github.com/intel/torch-xpu-ops/commit/01d4375a5bf6766fbdf0be2c1a3630105fc8b6a9
pytorch: 2f21c45513b13f238a18afaab2f98456399d76a3

The issue is fixed in the latest Pytorch and torch-xpu-ops bundle. Verified using the test machine as well as the following env:
PyTorch: 28b0ad4f4616497e9e297d3970992aad1d3cba44  (July. 23)
torch-xpu-ops: 5f4970b4aa6ef47a695baf01d5533d106fc69b82 (July. 23)

Driver (level-zero): 1.3.29735.27-914~22.04

$ PYTORCH_TEST_WITH_SLOW=1 pytest -v test_ops_xpu.py -k test_out_bincount_xpu_int64

collected 14706 items / 14705 deselected / 1 selected

test_ops_xpu.py::TestCommonXPU::test_out_bincount_xpu_int64 PASSED                                                                                [100%]

In view of that, I will close this issue.