Add restrictions for property name generation for Angular and Polymer

Both Angular and Polymer place restrictions on property names. Angular ignores properties beginning with '$' in equality checks. Polymer serializes DOM attributes to properties and thus requires names to match their restrictions (Only alpha-numeric chars and must begin with a lowercase alpha).
This restricts the property renaming passes to the set of characters permitted by the frameworks.
cc @mprobst, @justinfagnani
Fixes #1371

LGTM. I'll bring it in for testing.


Rename STG_CMP_Header

This component causes many failures when doing push upgrades. Every other component is fine. It forces us to re-run the push a number of times.

**lurch: attach W-010203

Tracking W-010203


Return empty work in case EOS comes early

android.mediav2.cts.CodecDecoderTest#testOnlyEos
android.mediav2.cts.CodecDecoderTest#testOnlyEosNative
With above test cases, EOS comes but decoder not started
yet. In this case, we need to return empty work to prevent
timeout issue in codec2.0 framework.
Tracked-On: OAM-102475
Signed-off-by: Chen, Tianmi<EMAIL_ADDRESS>

@dyang23 , @yuanjunhuang, @zhangyichix , could you please take a review?
Thanks,


2 tags (1 incorrect) being added when using jquery ui autocomplete and autoFocus=true

When using jquery-ui with taggle, if the autoFocus=true then bad things happen. The autoFocus option automatically selects the first item in the list as the user types in tags. If the user then presses the ENTER key the item is added as a tag. The problem is that its added twice - once by the select callback on autocomplete (expected behavior) and an extra time by the taggle plugin (unexpected behavior).
For example if you have tags cats, dogs, fish and the user searches for ca with autoFocus=true then cats will be highlighted. Upon pressing ENTER, cats AND ca are added as tags.

Can you provide a jsfiddle with the issue?

This is mostly jQuery specific. You basically want to hand over control to the autocomplete plugin, so in that case you can add the tags programmatically in the select function. The only caveat is that you have to add a fake submitKey value like so.
I'll update library so you can provide an empty array instead of passing [-1] but for now, that looks closer to what you wanted.


Show modal when pomodoro finish time

Describe new feat
Add modal when finish pomodoro timer with a button to stop "beep" and restart sounds
Referencies
No response

ref #606


support mousemove event in PanResponder

https://github.com/taobaofed/react-web/blob/master/Libraries/PanResponder/injectResponderEventPlugin.web.js#L24
PanResponder move event is currently not supported via mouse events

any idea why topMouseMove don't work ?

MouseMove is really different with touchmove.

yeah I know it's tricky. Would React Responder code help for this? Do you have some plan to try to implement it soon? or do you want me to take a look (if so, any idea where to investigate / what to do ?)
Thanks


Complete  the unittests for the POVMPostProcessor class

As part of #37.

I accidentally added the commit bc19ab8 in this branch

I accidentally pushed the commit bc19ab8 in this branch

Yes I saw. That's okay :+1:


fix: Linux process cleanup

varanny was creating defunct processes on Linux as it was not properly waiting and reaping the processes it spawned, these changes fix that

+1 verified on Windows.


BizTalk Documenter 2013 R2 - Timeout expired error.

Hello,
we are getting below error when trying to generate a Document for one of our application. Rest of the other applications are able to generate the output just fine.
If anyone has faced the problem and knows the solution, it is greatly appreciated.
Thanks in advance.
_---------------------------
Error Generating Documentation
Timeout expired.  The timeout period elapsed prior to obtaining a connection from the pool.  This may have occurred because all pooled connections were in use and max pool size was reached.
OK
---------------------------_

Hello,
I have multiple Applications deployed on BizTalk server. This error occurs only in one of the Application.
I have tried to generate the documenter CHMs individually for Integrations in this particular application.
I tried to modify the source code to troubleshoot but there is a DLL version dependency error.

Hello, the same happens to us when creating documentation for one of our BizTalk applications. It is the only one that causes the problem. It seems that Documenter encounters and issue with some of the artifacts in the application that causes it to leak SQL connections and exhausts connection pool. It remains exhausted until restarting the Documenter.

@jankena  Could you isolate which artifacts that caused the errors?

@Dijkgraaf .. I debugged the source code and located the root cause. This happened when schema was very complex, including multiple Imports too.
The code piece where all Schemas and Maps (we were using XSLT mapping) are read from SQL and converted to XML before being documented causes the TimeOut error.
I changed the code to exclude Schemas and Maps for that particular Application. With this change I was able to document other artifacts at least.
Hope this helps you with fix. I was in little rush to wrap it up so did not try to debug and fix the problem itself.


DPL-950 - As a Long Read Samples Extraction user (Hermione) I would like to be able to import NT barcodes directly into Traction without using Samples Extraction to remove a dependency and save time

User story
As a Long Read Samples Extraction user (Hermione) I would like to be able to import NT barcodes directly into Traction without using Samples Extraction to remove a dependency and save time
Who are the primary contacts for this story
Hermione / Steve
Who is the nominated tester for UAT
Hermione / Long Read
Acceptance criteria
To be considered successful the solution must allow:

[ ] when visiting the reception page there should be an option to import tubes from Sequencescape OR to modify the reception to import plates and tubes together (ideal)
[ ] Users should be able to import multiple tubes
[ ] When those tubes are imported the human readable barcode (NT) should be used (not ean13 barcode)
[ ] The user to be able to reprint the barcodes using the existing traction template.
[ ] update Resolve Operations to improve performance https://vitejs.dev/guide/performance.html

Dependencies
This story is blocked by the following dependencies:

#<issue_no.>
sanger/#<issue_no.>

References
This story has a non-blocking relationship with:

#<issue_no.>
sanger/General-Backlog-Items#316

Additional context
Add any other context or screenshots about the feature request here.

Mockup
Reception_Sequencescape_tubes.pdf

Sequence flow diagram


Fix nil pointer dereference in template subscription

Proposed changes
This PR fixes nil pointer dereference in template subscription.
Types of changes
What types of changes does your code introduce to the project: Put an x in the boxes that apply

[X] Bugfix (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)
[ ] Update only documentation, not any source code.

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of
them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before
merging your code.

[X] I have read the CONTRIBUTING doc
[X] I have signed the CLA
[X] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in downstream modules

Further comments
ngsi template subscription --ngsiType v2 --type Thing

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7ead99]

goroutine 1 [running]:
github.com/lets-fiware/ngsi-go/internal/ngsicmd.setSubscriptionValuesV2(0xc0000b3e80, 0xc0000ed180, 0xc0000cc640, 0x0, 0x413a3d, 0xc000200b68)
        /home/ksmainte/go/src/github.com/fisuda/ngsi-go/internal/ngsicmd/subscriptionsV2.go:468 +0x2039
github.com/lets-fiware/ngsi-go/internal/ngsicmd.subscriptionsTemplateV2(0xc0000b3e80, 0xc0000ed180, 0x7fff31dd5401, 0x2)
        /home/ksmainte/go/src/github.com/fisuda/ngsi-go/internal/ngsicmd/subscriptionsV2.go:407 +0x74
github.com/lets-fiware/ngsi-go/internal/ngsicmd.subscriptionsTemplate(0xc0000b3e80, 0xc0000ee500, 0xc0000ee820)
        /home/ksmainte/go/src/github.com/fisuda/ngsi-go/internal/ngsicmd/subscriptions.go:150 +0x33c
github.com/lets-fiware/ngsi-go/internal/ngsicmd.glob..func10(0xc0000b3e80, 0x2b, 0x58)
        /home/ksmainte/go/src/github.com/fisuda/ngsi-go/internal/ngsicmd/ngsi.go:360 +0x2b
github.com/urfave/cli/v2.(*Command).Run(0xb70fc0, 0xc0000b3100, 0x0, 0x0)
        /home/ksmainte/go/pkg/mod/github.com/urfave/cli/v2@v2.2.0/command.go:164 +0x4dd
github.com/urfave/cli/v2.(*App).RunAsSubcommand(0xc000082600, 0xc0000b2dc0, 0x0, 0x0)
        /home/ksmainte/go/pkg/mod/github.com/urfave/cli/v2@v2.2.0/app.go:427 +0xa49
github.com/urfave/cli/v2.(*Command).startApp(0xb78160, 0xc0000b2dc0, 0x7fff31dd5484, 0x8)
        /home/ksmainte/go/pkg/mod/github.com/urfave/cli/v2@v2.2.0/command.go:279 +0x6bb
github.com/urfave/cli/v2.(*Command).Run(0xb78160, 0xc0000b2dc0, 0x0, 0x0)
        /home/ksmainte/go/pkg/mod/github.com/urfave/cli/v2@v2.2.0/command.go:94 +0x9cd
github.com/urfave/cli/v2.(*App).RunContext(0xc000082480, 0x93a0d0, 0xc0000aa010, 0xc0000b4000, 0x7, 0x7, 0x0, 0x0)
        /home/ksmainte/go/pkg/mod/github.com/urfave/cli/v2@v2.2.0/app.go:306 +0x810
github.com/urfave/cli/v2.(*App).Run(...)
        /home/ksmainte/go/pkg/mod/github.com/urfave/cli/v2@v2.2.0/app.go:215
github.com/lets-fiware/ngsi-go/internal/ngsicmd.Run(0xc0000b4000, 0x7, 0x7, 0x9332a0, 0xc0000ae000, 0x9332c0, 0xc0000ae008, 0x9332c0, 0xc0000ae010, 0x0)
        /home/ksmainte/go/src/github.com/fisuda/ngsi-go/internal/ngsicmd/ngsi.go:69 +0x317
main.main()
        /home/ksmainte/go/src/github.com/fisuda/ngsi-go/cmd/ngsi/main.go:44 +0xdf

Coverage remained the same at 100.0% when pulling 74dbfbed67dc498a05d1b73fc4a1722050053d39 on fisuda:fix/templeate into 9bb4e48e41222e0277c6dd87946ac4470e0a20b5 on lets-fiware:main.


[Error] QA Script

Hi Marc,
I'm getting this error when I try to run the script. I haven't looked into the python script yet.

Let me know if i'm doing anything wrong.
Thanks!
 I thought I mentioned the specifics.
Script Name: checkfamily.py
GlyphsApp Version: Version 2.3 (895)

Could you update to 2.4b (924)
I'm very sorry for the delay in replying.


[WIP] Feature/13/homescreenwidget v2

see #15

Currently this does not support Lists stored on the internal storage

Todo:

[ ] Configurationscreen Overhaul
[ ] List reordering
[ ] List switching

Just tested it, works as expected so far :) Thanks !
I just fixed List reordering. Can you allow me to push on your PR ?
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork

Or if you prefer I can do a PR on your fork. Which do you prefer ?

@lolo-io you should already be able to make edits to this branch, as per link you posted maintainers should be able to make edits

Yes my bad the rejected push was due to a bad github config on my side.
I've pushed list reordering on your pr branch. I use the same code that is used to reorder lists when an item is checked/unchecked within the app.
I have refactored it as a fiunction of ListItem.


Plans to release ASR finetuned-models

Hi,
Thanks for the toolkit! I was wondering if there are plans to release the ASR finetuned models (or it is already there but I missed it). If not, are you accepting PRs on the ASR finetuned models by the community? Thanks in advance!
Jeff Hsu

Hi @Splend1d .
We are working on this and please stay tuned for this!
Thanks you for your interest.


Remove read permission from private repositories

Feature Description
Currently, when a repository is marked private, its permissions on the host filesystem are still drwxr-xr-x. It would be nice if this were not the case and the read permission for other users was removed as it would allow the privacy of repositories to be maintained when displaying the git repositories with an alternative front-end such as cgit.

Thanks for the suggestion, the storage of the git repos are treated as internal to git and not meant to be used by any other tool. There is also a potential plan to eventually shard the directories so it wouldn't be in the user/repo format anymore.


Ensure packages up-to-date on iOS build

iOS builds rely on package dependencies and associated build artifacts
(pubspec.lock, .packages files) to be up-to-date.

Fixes #8361


Add legit-developer

Related issue

What changes does this PR do?
Screenshots (If any)
Questions

Closing due to inactivity feel free to reopen.


[Map] CDOM-CBP3-CollisionCourse

Variations of this map are in the wrong order. cdom-cbp3-collisioncourse_v2.zip should be the main one.

URL: https://unrealarchive.org/maps/unreal-tournament-3/classic-domination/C/cdom-cbp3-collisioncourse_24a42b74.html
Hash: 24a42b744351fd8b45569088d53e865f6e88a139
Current name: CDOM-CBP3-CollisionCourse

Switched variations around


add support to manage server/client ssl profiles & basic source address translation setting

Adds some new optional properties to thef5_vip resource:

snat_pool
client_ssl_profile
server_ssl_profile

Used like so:
f5_vip 'myvip' do
  address 'vipaddress'
  port 'vipport'
  protocol 'protocol' # TCP default
  pool 'mypool'
  snat_pool :automap
  client_ssl_profile: 'client.cert'
  server_ssl_profile: 'server.cert'
end

Like enabled_status on the f5_pool resource, snat_pool defaults to a :manual value which means the resource ignores this setting on the load balancer.  Alternatively, it can be set to :none, :automap, or the String name of an existing (i.e. already defined) SNAT pool.
client_ssl_profile and server_ssl_profile are also optional and only take effect when they are specified.
Readme has been updated with usage here and here

While all the tests pass there are some soap serialization errors which I'm working on and need resolved before finalizing this PR.

updated and integration tested against BIG-IP 11.6.1 Build 0.0.317 Final then rebased onto master.
the syntax of the SOAP serialization threw me at first but these last two commits should fix it up to be stable against that version of BIG-IP.


Interop tests override logs

npm run wpt -- webdriver/tests/interop writes a chromedriver log file but it seems to be overwritten for each test.
cc @Lightning00Blade

I think what you want to mention is that they are overwritten in the GitHub Actions.

It was locally


add +: slices

I'm unclear whether these changes need to be also in the asciidoc version, or if that happens automatically.  Or perhaps we should wait until after the switchover to asciidoc and do it only there.

I think it is worth discussing at the next LDWG meeting, exactly when Madoko -> AsciiDoc conversion happens.
Fortunately, for text paragraphs with little or no markup, it usually makes no difference.  That said, the changes are so extensive for Madoko->AsciiDoc that I expect if that change is made before this PR, some small changes may be required in this PR.  I think small changes to a PR like this to update it will not be wasted effort.


pip-compile and pip-sync across OS

If I run pip-compile on ipython on a Mac, the requirements.txt contains appnope which is a Mac-only library and hence the pip-sync fails on linux when doing source installs.
I use a Mac with python3.6 and my CI/CD runs on ubuntu python3.6. My workflow is as follows:

Add a dependency to requirements.in, and run pip-compile on the Mac to generate the pinned requirements.txt
Commit the pinned requirements.txt to the git repo
Checkout and run pip-sync on CI/CD or a target machine for installation
This has been working fine.
My package depends on jupyter, which internally needs ipython.

Currently, I am trying to install the package into a machine where only source installs are possible. In this case, I get an error when appnope is being installed that it supoprts Mac only.
I'm trying to understand what is the expected usage in such cases ? How do I avoid this issue ?
Notes:

ipython uses appnope for darwin
appnope's setup.py has a check for darwin
Installing appnope with a source distribution (tar.gz) on linux fails. Installing it with wheel succeeds.

So, my pip-sync fails when I do a source only installation for all my packages.
Environment Versions

OS Type: MacOS 10.13 for pip-compile Centos7 for pip-sync
Python version: $ python -V: Python 3.6.4 :: Anaconda, Inc.
pip version:  $ pip --version: pip 9.0.1
pip-tools version: $ pip-compile --version: pip-compile, version 3.5.0

Steps to replicate
mac$ echo "ipython" > /tmp/req.in

mac$ pip-compile /tmp/req.in
#
# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile /tmp/req.in
#
appnope==0.1.0            # via ipython
backcall==0.1.0           # via ipython
decorator==4.4.0          # via ipython, traitlets
ipython-genutils==0.2.0   # via traitlets
ipython==7.4.0
jedi==0.13.3              # via ipython
parso==0.4.0              # via jedi
pexpect==4.7.0            # via ipython
pickleshare==0.7.5        # via ipython
prompt-toolkit==2.0.9     # via ipython
ptyprocess==0.6.0         # via pexpect
pygments==2.3.1           # via ipython
six==1.12.0               # via prompt-toolkit, traitlets
traitlets==4.3.2          # via ipython
wcwidth==0.1.7            # via prompt-toolkit

appnope is added here. but installing it in linux from source fails:
centos$ pip install appnope
Collecting appnope
  Downloading https://files.pythonhosted.org/packages/87/a9/7985e6a53402f294c8f0e8eff3151a83f1fb901fa92909bb3ff29b4d22af/appnope-0.1.0-py2.py3-none-any.whl
Installing collected packages: appnope
Successfully installed appnope-0.1.0

centos$ pip install appnope-0.1.0.tar.gz
Processing appnope-0.1.0.tar.gz
    ERROR: Complete output from command python setup.py egg_info:
    ERROR: Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-req-build-1x2ukcp_/setup.py", line 17, in <module>
        raise ValueError("Only meant for install on OS X >= 10.9")
    ValueError: Only meant for install on OS X >= 10.9
    ----------------------------------------
ERROR: Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-req-build-1x2ukcp_/

Hello @AbdealiJK,
Thank you for raising the issue! Cross platform ability has been discussed in several issues. Here is also a good note in PR https://github.com/jazzband/pip-tools/pull/651 (not merged though).
As a workaround, you can pin the appnope with a specific platform platform in a requirements.in separately, for example:
hostname$ cat << EOF > requirements.in
ipython
appnope; sys_platform == "darwin"
EOF

hostname$ pip-compile
#
# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile
#
appnope==0.1.0 ; sys_platform == "darwin"
backcall==0.1.0           # via ipython
decorator==4.4.0          # via ipython, traitlets
ipython-genutils==0.2.0   # via traitlets
ipython==7.4.0
jedi==0.13.3              # via ipython
parso==0.4.0              # via jedi
pexpect==4.7.0            # via ipython
pickleshare==0.7.5        # via ipython
prompt-toolkit==2.0.9     # via ipython
ptyprocess==0.6.0         # via pexpect
pygments==2.3.1           # via ipython
six==1.12.0               # via prompt-toolkit, traitlets
traitlets==4.3.2          # via ipython
wcwidth==0.1.7            # via prompt-toolkit

Now you can ran pip-sync on every OS without an error.

My bad for not searching. closing as duplicate.


Scale/offset with raster:bands.{scale|offset}

The raster extension provides scale and offset information. These scales and offsets should be applied to loaded data, if available. Right now, we're having to work around it like this:
data = odc.stac.load(
    items,
    crs="EPSG:3857",
    bands="500m_16_days_NDVI",
    resolution=500,
    bbox=bbox,
)
raster = RasterExtension.ext(items[0].assets["500m_16_days_NDVI"])
data = data["500m_16_days_NDVI"] * raster.bands[0].scale

Full notebook example that includes the workaround in Cell 4 here.

There are some important implications to supporting this use case.

It impacts dtype derivation for the band, I assume that implies that expected load type is float32 in this case
Native pixel type reads should still be possible in my opinion

This requires some kind of configuration mechanism
Default should probably be: apply scaling, but some mechanism to disable scaling should also be available, ideally per band but at least disable scaling for this load.
Scaling info should be propagated into returned xarray attributes table

Requires adjusting model to propagate scaling information from STAC document

Related to that is scaling information that is supplied in the raster file itself (depending on a format these things can have various levels of being "standard"). For example netcdf reads with GDAL ignore scaling info and return raw pixel values, while reads from the same file with netcdf library return scaled pixels. I'm not sure if TIFF has any "standard" tags like that.

Native pixel type reads should still be possible in my opinion

Agreed.

Related to that is scaling information that is supplied in the raster file itself

Does odc.stac.load apply in-file scale+offsets currently? IMO it would be an error state for the STAC scale+offset information to disagree with the actual file's scale+offset information, so maybe just throw an error if your use_raster_extension config argument is True and the data and metadata disagree?

Does odc.stac.load apply in-file scale+offsets currently?

no, unless rasterio/gdal do it, which I'm pretty sure they don't for COG/netcdf, but who knows what other gdal drivers do or don't do

IMO it would be an error state for the STAC scale+offset information to disagree with the actual file's scale+offset information, so maybe just throw an error if your use_raster_extension config argument is True and the data and metadata disagree?

there is "disagree", but then there is also "stac does not include it but data does".

there is "disagree", but then there is also "stac does not include it but data does".

Yeah, I'd say if rasterio+GDAL isn't applying scale+offset for the "common" data formats, we can't expect to protect against some other GDAL reader applying it under the hood. So I think the answer is "use raster:bands if its there, otherwise don't apply any scale+offset"?

issue is that we can't tell if STAC data is "just a description of a storage scheme" or "description and instruction to convert at load time". For formats like COG there is no "automatic" scaling at read-time done by GDAL, but some tiledb or what not might perform that scaling as part of the read, but it might also be useful to record that metadata in STAC. I guess having "read without further scaling" is enough to deal with those cases for now, later on if it becomes a problem we can change default based on format of the source.

With the new Element84 Sentinel-2 collection, it was decided that

The offset will no longer be applied so the data will be unaltered other than the conversion to a COG. Users should always apply gains and offset when using data.

Is this the time to implement the scale/offset application? Or perhaps at least mention @gadomski's approach here?
Alternatively, should this be pushed further down the stack (pun intended) to e.g. pystac-client?

@idantene my understanding is that right now this collection is in a bit of flux (this is from what I hear from other users, I have not been working with this data recently): some items have pixel scaling applied to data and some do not, and this makes data loading particularly tricky.

Alternatively, should this be pushed further down the stack (pun intended) to e.g. pystac-client?

Not sure what you mean by that, as pystac-client only deals in metadata, not pixel values.
My preference here is to either:

keep the current state: return "raw" pixels, with caveat that "raw" depends on format being used, see discussions above about gdal data loading drivers
implement most flexible solution

Most flexible solution would have to:

support raw mode output

default to applying scaling
allow users to opt-out of that with load time parameter that can be applied per band

apply scale/offset per item (do not assume that all items share the same scale/offset)
allow user supplied overrides per band
possibly allow user hook to decide per-item what scaling should be used

Metadata is broken way too often, or non-standard, one always needs an escape chute

Right now work is underway to refactor loading parts of odc-stac to support non-gdal data loading drivers (zarr with kerchunk for example). There is already an abstraction in place to "bring your own loader", but it will change somewhat as we iron things out. I feel like completing this work will make adding support for inline pixel modification much simpler, with scale and offset being just one of the standard transforms odc-stac should support natively. The same machinery can be used to bring arbitrary user supplied transforms that apply to pixel values in the native projection of the data before reprojection and merging of rasters that share the same pixel plane (data acquired at the same time/orbit/day).

Pinging @robbibt as it relates to "unifying odc-stac/datacube-core", and @woodcockr because of "virtual product light".

 In part because the use data provider metadata is required and is also processing version dependent (the absence of a "scale and offset applied flag" may require knowing what processing version you are dealing with (its implicit).
Ultimately, ODC can only reliably provide "raw" data and allow the client call to hook in anything specific for a particular source.
which is where we are heading with the ODC hyperspectral native loader support currently prototyped in odc-stac but to be added to datacube-code once we get the kinks out.

Thanks (once again) for the very detailed reply @Kirill888!
All of that sounds great, and I guess I'll just wait for future updates (/subscribe 😉).

Not sure what you mean by that, as pystac-client only deals in metadata, not pixel values.

Sorry, I was being a bit laconic there. I meant that maybe pystac-client could handle any mismatch/issues in metadata (such as inconsistent/missing scale/offset), so that odc-stac would simply have to apply it.

this collection is in a bit of flux

That's correct — Element 84 is building a new Sentinel 2 L2A collection, sentinel-2-c1-l2a. All items in that collection will not have the offset applied, which differs from the items in the old sentinel-2-l2a collection. This discussion has links to the mailing list signup and archive for anyone who wants to dig in more.

I meant that maybe pystac-client could handle any mismatch/issues in metadata (such as inconsistent/missing scale/offset)

@idantene can you provide more detail on the desired behavior here? E.g. an example? Thanks!

Sure @gadomski - we currently apply similar transformations internally - but consider:

The user expects the scale and offset for each item. As such, they consider any Item without scale/offset metadata as invalid, and would prefer to ignore it.
The user expects the same scale/offset for each item. They may want to only consider the most common scale/offset, and reject the non-standard ones.
The user expects the same scale/offset for each item. They want to be alerted (or have the code crash) if this isn't the case.

Our current approach is e.g.
def fetch_sentinel2_timeseries(bbox, start_time, end_time, epsg, bands, resolution = 10, fail_on_errors = True, item_filter:  = None):
    # ...
    query = stac_client.search(...)
    try:
        items = query.item_collection()
    except Exception as e:  # noqa, capture any fetching exceptions and raise them as runtime errors
        raise RuntimeError from e
    if item_filter is not None:
        items = [item for item in items if item_filter(item)]
    # ...

For the time being, the only item_filter we're using is to filter away items with zenith larger 11 (calculated from the granule_metadata or metadata xml file).

To me, pystac-client is meant to be a relatively general tool to fetch data from a STAC API. What you're describing (to me) feels more use-case specific, and is already supported more-or-less by the workflow you describe. Happy to continue chatting about desired behaviors, but we should probably move the discussion over to an issue on https://github.com/stac-utils/pystac-client to avoid the noise here on odc-stac.
As an aside, I would recommend using items instead of item_collection so that you can do your filtering on-the-fly rather than loading all items first, e.g.:
item_search = Client.open(...).search(...)
items = [item for item in item_search.items() if item_filter(item)]


Margin line numbers color

Hello,
I use your theme, and like it.
However, is it possible to set the color of the line numbers in the editor margin a little more lighter to increase readibility of them ?
Thank's for your answer.

For which colour theme? Or for all of them?

Hello,
My proposition is for the dark themes (I don't use any light theme)


Can't italicize substring.

When I try to italicize a substring like this:
_this_ should be ita_li_c

the output is:
this should be ita_li_c

Shouldn't it be:
this should be italic

I should mention bold works as expected:
__This__ t__ex__t should be bold

This text should be bold

codepen

This is indeed a difference with GitHub flavoured Markdown (GFM) which is enabled by default.

Where Markdown transforms underscores (_) into italics, GFM ignores underscores in words
To disable this behaviour, one has to set both pedantic: true and gfm: false; I can't say whether this behaviour is also an intentional part of non-pedantic Markdown.

However, you can also use * (asterisks) to italize word portions: Ita*li*ze: Italize

sdfsdf


Added a reference to vue2-dragula

I wouldn't mind to change its position in the list, but since vue-dragula and vue2-dragula are somehow related (a fork), I am thinking that it made sense to have them grouped together in the list.
But if you insist, I can change the position.

@kapuzon I think we can accept this in this case, his argument sounds reasonable.

I wouldn't mind to change its position in the list, but since vue-dragula and vue2-dragula are somehow related (a fork), I am thinking that it made sense to have them grouped together in the list.

All right, it makes sense.


Support for Rush

Turns out my repo DOES have an .npmrc file, but it is under common/config/rush/.npmrc
Ideally we can have the tool discover this when using rush.
This can be accomplished by checking the existence of a rush.json file, and then checking the default location:
common/config/rush/.npmrc

This can be achieved since https://github.com/microsoft/ado-npm-auth/pull/31
npm exec ado-npm-auth -- -c common/config/rush/.npmrc


Changing replicas config on a helm deployed app will end up displaying "services "app_name" already exists"

Internal reference: SURE-3018
Reported in 2.5.8 in Vue.
Issue description:
Changing replicas config on a helm deployed app with Cluster Explorer UI form will end up displaying "services "app_name" already exists"
Business impact:
Troubleshooting steps:
Repro steps:

Provision a Rancher v2.5.8 instance
Deploy an application via a Helm chart, or from Apps & Marketplace (e.g Memcached, HAproxy)
Navigate to the Cluster Explorer UI, and click Edit Config
Make a change to the workload configuration, i.e. scale the number of replicas or update the image and Save the changes

Actual behavior:
an error is displayed: services "haproxy" already exists

@gaktive Neill and I sat down and could not reproduce this in 2.6.3. The steps above don't make sense - step 3 'Navigate to the Cluster Explorer UI, and click Edit Config' does not make sense.
We need the steps clarifying - what we did:
From Cluster Explorer:

Go to Apps and Marketplace, chose the 'HA Proxy' chart and install it
Wait for app to install
Go to 'Deployments'
Find the deployment for the HAProxy application - choose 'Edit Config' from the action menu
Chance the replica count to 3
Click Save
User is taken back to Deployment list without any error message being shown.

Asked original reporter for clarification on steps.

on 2.6.3 and 2.6.4-rc8
From Cluster Explorer:

Go to Apps and Marketplace, chose the 'HA Proxy' chart and install it
Wait for app to install
Go to 'Deployments'
Find the deployment for the HAProxy application - choose 'Edit Config' from the action menu
Chance the replica count to 3
Click Save
User is taken back to Deployment list without any error message being shown.

Was not able to reproduce any errors


Numbers for entire USA not included.

This should be useful to as a baseline to compare against.

now included


Project name creation - Project name cannot contain spaces or special characters

Description:
When using the extension to generate a project I am prompted with an error that I cannot generate a project name with either "-" (hyphen) or "_" (underscore) due to it being a special character.
I understand that these are special characters, but it is quite standard to generate project names with either a hyphen or underscore. This is also relevant to artifact and groupId's
Describe your problem(s)
I am not able generate a project name that contains either "-" (hyphen) or "_" (underscore) as it is not allowed because it is considered a special character.
Describe your solution(s)
Thus, my recommendation is to allow these special characters "-" (hyphen) or "_" (underscore) when creating a project name. This is also applicable to artifact and groupId's.

same for Group Id and Artifact id, they should support hyphens and underscore as specials chars.

Duplicate Issue: https://github.com/wso2/mi-vscode/issues/115

The latest pre-release v1.1.0 has resolved the issue. Please reopen if the problem persists.


Update icons to FontAwesome v5

Deprecate <icon system and spritesheet
Remember to update icons that are embedded in the stylesheets
Figure out a way to use FontAwesome 5 free with upgrade to Pro easily done locally (don't commit the Pro stuff!)

I believe this is done.


Please invite me to the GitHub Community Organization

Name
Naor Tedgi
Discord Username (if applicable)
ntedgi
Additional Context
I want to join JD studio because I am an open-source enthusiast and I have also been a part of many open source communities

@ntedgi

Check your email or organisation page
Thank you for contribution 🙂
Please contribute in Unique-Github-Profiles

@ntedgi

You are now a member of org
Please contribute in Unique-Github-Profiles

Invitation sent for the GitHub Organisation. Welcome to the community 🎉#
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see, you can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/jaidevstudio/people
Like this

Tips for practising:
Remember contributing to open source is not just about code, its about collaboration, communication and adding value
I hope that helps

Please do this firstly 🥰🎉🎉🎉


⬆<EMAIL_ADDRESS>

What do these changes do?
This PR upgrade our TensorFlow dependency to 2.10
How Has This Been Tested?
CI
Benchmark Results
TODO

Looks like on ARM32 we are still running into https://github.com/tensorflow/tensorflow/issues/57364. Locally I ran into another build issue when trying to run the end2end tests, but maybe that's not a problem on CI.

It looks like we might not even need to restrict the supported version of TensorFlow as long as flatbuffers==2.0 is installed.
E.g. TF 2.3 and older didn't even rely on the flatbuffers pip package so we might be OK just requiring flatbuffers==2.0 as a dependency. For me locally the end2end tests pass with tensorflow==2.9 and flatbuffers==2.0.

We could also print a runtime warning if version(tensorflow) <= 2.10 without aborting completely.


fixing noverlap arg to pwelch (noverlap is an integer = number of sam…

…ples, not a ratio)

Ha, great thanks for catching this.


Various actions fail: [Failed to open TCP connection to login.microsoftonline.com:443 (getaddrinfo: nodename nor servname provided, or not known)]

Hi!
Might just be me doing something silly given the hour, but keep running into this on kitchen converge:
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Failed to complete #create action: [Failed to open TCP connection to management.azure.com:443 (getaddrinfo: nodename nor servname provided, or not known)] on default-windows-2012r2
>>>>>> ----------------------

Everything appears to have been created.
Interestingly, I get the same error when destroying, and at least in the three times I've run this, it succeeds after a second run:
[wframe@mbp ~/sc/kitchen-shell-example (master *)]$ bundle exec kitchen destroy
-----> Starting Kitchen (v1.14.0)
-----> Destroying <default-windows-2012r2>...
       Destroying Resource Group: kitchen-default-windows-2012r2-20161204T043202
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Failed to complete #destroy action: [Failed to open TCP connection to login.microsoftonline.com:443 (getaddrinfo: nodename nor servname provided, or not known)] on default-windows-2012r2
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

[wframe@mbp ~/sc/kitchen-shell-example (master *)]$ bundle exec kitchen destroy
-----> Starting Kitchen (v1.14.0)
-----> Destroying <default-windows-2012r2>...
       Destroying Resource Group: kitchen-default-windows-2012r2-20161204T043202
       Destroy operation accepted and will continue in the background.
       Finished destroying <default-windows-2012r2> (0m2.06s).
-----> Kitchen is finished. (0m2.59s)

Any tips?  Will dive into the source tomorrow, but I'm a bit perplexed!
Cheers!

Quite strange.  No issues today.  Chalking this up to something between my client and AzureRM last night... Cheers!


French translation

Hi,
Thank you for you module. I've just made a french translation of it. How can I send it to you ?
Best regards

Hey there, that's awesome! If you are familiar with the Pull Request feature, you can use that, otherwise just attach your new JSON file to this issue and I'll add it to the next release!
Thank you for pitching in 😊

I don't know the pull feature. So, I prefer attaching my translation here ;)
fr.zip

Added via https://github.com/zeel01/MonsterBlocks/commit/66110cbcb4f3716a0ca2295d59627c140bb192bc


Response code 404 (Not Found)

This library worked correctly yesterday, but stopped working earlier today. The translate function returns a Response code 404 (Not Found) error.
Perhaps the translate endpoint has changed url?

Hi, can you provide more information? The auto test shows that it still works well.

Hey @plainheart I tested this morning and it seems to be working again now so I will close this issue.
Maybe the API was having some issues.


Update Data Operations in Docs

Data Operations

Saving Data
Deleting Data
Updating Data
Querying Data
Exporting Data
Importing Data

#28 Done ✔


Update sbt-compatibility to 0.0.5

Updates io.github.alexarchambault.sbt:sbt-compatibility from 0.0.4 to 0.0.5.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.github.alexarchambault.sbt", artifactId = "sbt-compatibility" } ]

labels: sbt-plugin-update, semver-patch

Superseded by https://github.com/alexarchambault/argonaut-shapeless/pull/192.


Show report in LHN if user is expense report manager without access to parent policyChat

cc @marcochavezf
Details

Background in the issue :D
In this PR, we're making sure the expense report shows in a user's LHN when:

User is the current manager of the report & the report is waiting to be approved by that approver & the manager doesn't have access to the parent (policy chat).

We need to show this b/c normally the user has access to the workspace chat, but not if they got removed from the submitter's workspace chat. In this case, the only way to access the report is by knowing the exact report ID & typing it in the URL (bad experience) or by viewing the report in the LHN (or by searching for it). It normally won't show in the LHN b/c its notificationPreferences are set to hidden for all participants, so this PR adds a new "hidden override"

Fixed Issues
$ https://github.com/Expensify/Expensify/issues/422963
Tests

Create a Control policy in OldDot, make sure it has policy expense chats enabled, make sure it has "Advanced Approvals" enabled in members tab
In OldDot, invite 3 people as users (non-admins): A submitter and 2 approvers
In members tab in OldDot, make sure the submitter's submitsTo is set to Approver 1. Approver 1 and Approver 2 should NOT have a forwardsTo set.
As the submitter, log in to NewDot & go to the workspace chat that was just created for you

Submit an expense and submit the report to Approver 1
Keep this tab open! Keep track of the reportID so you have it for later.

In a new tab / device, as the policy owner, go to OldDot, to the workspace settings page, to the members settings

Change the submitter's submitsTo to Approver 2

Verify Approver 1 no longer has access to the workspace chat
As Approver 1, Open the previously created report
Verify Approver 1 sees GBR to that report in the LHN & that Approver 1 sees the Approve button in the report header
Click Approver, make sure it works w/out errors

Note: You may not be able to pay yet, that's fine

[ ] Verify that no errors appear in the JS console

Offline tests
Can't be tested offline b/c this relies on policy Owner activity triggering live updates to Approver 1
QA Steps
Same as above

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari
https://github.com/user-attachments/assets/57b21bf0-a152-4dec-b60f-031670fb89d7

MacOS: Desktop

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/marcochavezf in version: 9.0.28-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

Hi @Beamanator We need to run this in console to enable policy expense chats, right ? Or it should be created and displayed automatically in NewDot, after creating Controll policy in OldDot? Thank you
p = Policy.getCurrent(); p.policy.isPolicyExpenseChatEnabled = "true"; p.save();

Hey @izarutskaya - yes correct, thanks for mentioning that, i'll put it in the test steps 🙏

@Beamanator @marcochavezf I checked this off without Applause explicitly marking it as a pass. Please perform your own QA and make sure it's working as expected

🚀 Deployed to production by https://github.com/roryabraham in version: 9.0.28-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Update log messages to use structured logs

These logs messages were recently merged and weren't using structured logs, they should be

/lgtm

/approve

/retest-required

/retest-required

/retest-required

/retest-required

/retest-required

/override ci/prow/e2e-aws-upgrade
The ovn and serial jobs both passed, and this is a logging change. I can see the CPMS running in the upgrade test history so I'm content that this PR isn't causing an issue


fix Montserrat font #166 + update CLI docs + update index + update deps

I've added the Montserrat font and also reduced the download size by removing font-weight 700 for Open Sans - see index.html.
I made small changes to header styles (see main.css changes).
h1

h2 and h3

h4, h5

h5, h6

The rest are dependency updates + CLI docs pulled + index rebuilt.

Looks good :+1: @emirotin


Add command which changes status of the newcomer

For example: /trust @b0g3r

Interesting idea, I'll see what I can do

Added /trust, but in order to use it you have to reply to any message sent by person you want to trust :) it will remove them from the newcomers list as well as it will lift all the restrictions


Prevent caching GetTaxonomy Action

That action is called by LocalizedTaxonomyField editor view and need to not serve cached data

@sebastienros
to clarify this:
If the results results from that action are cached, the backoffice UI for taxonomyfields in localizable contentItems may result inconsistent after an update where the selected terms have been changed.


Give an example when componentWillMount can be called multiple times

I've found such phrase on this page https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html about componentWillMount callback:

The above code is problematic for both server rendering (where the external data won’t be used) and the upcoming async rendering mode (where the request might be initiated multiple times).

The same problem is described for componentWillUpdate and componentWillReceiveProps.
If I'm not mistaken it means that this function can be executed multiple times for one component if I use async rendering. I've found such question on StackOverflow: https://stackoverflow.com/questions/54533907/react-componentwillupdate-getting-called-twice about the same problem. I think I understand theoretical possibility of case when componentWillMount will be called twice: it can happen when mouning and initial rendering of some component was interrupted with higher priority task, so mounting restarts and calls componentWillMount again. Unfortunately neither documentation nor StackOverflow has any practical example of code which cause multiple calls of componentWillMount.
I've tried to make such an example myself using experimental React.JS version but has no luck.
I think it's better to have such an example to allow people who is not an expert in React.JS source code to under problem of such lifetime callbacks usage. I understand that it's an experimental feature and it can be changed in future but it's easier to understand the conception of async rendering when you have practical examples of possible problems.

It's possible to use example from my article https://0e39bf7b.github.io/posts/react-journey-componentwillmount-in-concurrent-mode/
let lastCounter = 0; // Global variable for multiple mounts detection

class Counter extends React.Component {
  componentWillMount() {
    if (lastCounter === this.props.value) {
      console.log(`mount counter with value = ${this.props.value} multiple times`);
    }
    lastCounter = this.props.value;

    // Syncronously wait for 100ms to emulate long work
    const start = Date.now();
    while (Date.now() - start < 100);
  }

  render() {
    return
{this.props.value}
;
  }
}

class App extends React.Component {
  state = { counter: 0, showGreetings: true };

  componentDidMount() {
    this.interval = setInterval(() => {
      this.setState({ counter: this.state.counter + 1 });
    }, 500);
  }

  componentWillUnmount() {
    clearInterval(this.interval);
  }

  toggleGreetings = () => {
    this.setState({ showGreetings: !this.state.showGreetings });
  };

  render() {
    // Use key attribute to force React.JS to remount Counter component
    return (
      <>
        <button onClick={this.toggleGreetings}>Toggle greetings</button>
        {this.state.showGreetings &&
Hello world!
}
        <Counter value={this.state.counter} key={`counter-${this.state.counter}`} />

{this.state.counter2}

      </>
    );

  }
}

// Instead of regular initialization
// ReactDOM.render(<App />, document.getElementById('root'));
// use Concurrent Rendering for this component
ReactDOM.createRoot(document.getElementById('root')).render(<App />);

Should we add it into documentation?


Many special functions do not appear in the big list

The reference docs at http://docs.scipy.org/doc/scipy/reference/special.html are missing many (obscure) ufuncs from scipy.special.

There are still a few more; a few tweaks to refguide_check and it should be easy to make a giant PR documenting everything that's missing.

This has been fixed I believe.


PR for reusing workflows for CI build and for NuGet package publishing

PR for reusing workflows for CI build and for NuGet package publishing
Contributing to Twilio

All third-party contributors acknowledge that any contributions they provide will be made under the same open-source license that the open-source project is provided under.

[x] I acknowledge that all my contributions will be made under the project's license.

I need to pull in the PR to actually test the release workflow.


cleanup: update github/make supporting releases to latest versions

Changes

🧹 cleanup: update github/make supporting releases to latest versions

/kind cleanup

Fixes #

Release Note

NONE

Docs

/retest

Nice job with the changes :D! Approved


Public clients should be validated when revoking tokens

According to RC7009 Section 2.1, a client should include authentication credentials when revoking its tokens. As discussed in #339, this is not make sense for public clients. However, in that case, the public client should still be checked that is infact a public client (authenticate_client_id).
I also fixed a what appears to be a bad merge (test_revoke_token_without_client_authentication was defined twice), which is why the diff is a little messy.

Bump! Any chance someone can review this or merge it! Thanks!

Sorry. I missed this PR.


Can't deploy contracts reason: 'ExistCoin'

Overview
I Can't deploy contracts reason: 'ExistCoin'
Steps to Reproduce
Steps to reproduce the behavior:

Use config devnet/docker/icon-bsc/scripts/config/icon-ice-arctic-config.sh
/bin/bash /icon-bridge/devnet/docker/icon-bsc/scripts/deploysc.sh
See error

BSC_RPC_URI: https://arctic-rpc.icenetwork.io:9933
Using network 'bsc'.
ProviderError: VM Exception while processing transaction: revert ExistCoin -- Reason given: ExistCoin.
at module.exports (/Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/scripts/bts.js:12:32)
at processTicksAndRejections (node:internal/process/task_queues:95:5) {
code: -32603,
data: '0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000094578697374436f696e0000000000000000000000000000000000000000000000',
reason: 'ExistCoin',
hijackedStack: 'ProviderError: VM Exception while processing transaction: revert ExistCoin -- Reason given: ExistCoin.\n' +
'    at /Users/anymac/.nvm/versions/node/v18.5.0/lib/node_modules/truffle/build/webpack:/packages/provider/wrapper.js:80:1\n' +
'    at /Users/anymac/.nvm/versions/node/v18.5.0/lib/node_modules/truffle/build/webpack:/packages/provider/wrapper.js:118:1\n' +
'    at /Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/build/contracts/solidity/bts/node_modules/web3-provider-engine/index.js:232:9\n' +
'    at /Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/build/contracts/solidity/bts/node_modules/async/internal/once.js:12:16\n' +
'    at replenish (/Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/build/contracts/solidity/bts/node_modules/async/internal/eachOfLimit.js:61:25)\n' +
'    at /Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/build/contracts/solidity/bts/node_modules/async/internal/eachOfLimit.js:71:9\n' +
'    at eachLimit (/Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/build/contracts/solidity/bts/node_modules/async/eachLimit.js:43:36)\n' +
'    at /Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/build/contracts/solidity/bts/node_modules/async/internal/doLimit.js:9:16\n' +
'    at end (/Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/build/contracts/solidity/bts/node_modules/web3-provider-engine/index.js:211:5)\n' +
'    at Request._callback (/Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/build/contracts/solidity/bts/node_modules/web3-provider-engine/subproviders/rpc.js:70:28)\n' +
'    at Request.self.callback (/Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/build/contracts/solidity/bts/node_modules/request/request.js:185:22)\n' +
'    at Request.emit (node:events:537:28)\n' +
'    at Request. (/Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/build/contracts/solidity/bts/node_modules/request/request.js:1154:10)\n' +
'    at Request.emit (node:events:537:28)\n' +
'    at IncomingMessage. (/Users/anymac/projects/web3j/icon-bridge/devnet/docker/icon-bsc/build/contracts/solidity/bts/node_modules/request/request.js:1076:12)\n' +
'    at Object.onceWrapper (node:events:651:28)\n' +
'    at IncomingMessage.emit (node:events:549:35)\n' +
'    at endReadableNT (node:internal/streams/readable:1359:12)\n' +
'    at processTicksAndRejections (node:internal/process/task_queues:82:21)'
}


Use class names instead of instance names

Hello there. Just like the title says, I believe it would be better to use the actual class names instead of instance names and instead replace the type property with the instance property.
Currently, it is difficult to navigate around because everything is Container or Sprite, and I can only check the name of the class by clicking on it. Instead, it would be nice to keep the icons for instances (so all containers share the same icons, all sprites, etc), but use the class names for the main navigator instead (so instead of Container; Container, it would use whatever class name, so Header, Footer, assuming that both the class Header and the class Footer extend Container) and under the type property, just specify what type of PIXI instance it extends (in our case, it would be Container). This would make it so much easier to navigate.

Hey @chky-nmnsoftware thanks for the suggestion, I think this is a good idea and i will implement ASAP

this has been added in 2.0.0 which will land in a couple of days after it passing the review


Failing on node 0.12

node_modules/trace/trace.js:3
const chain = require('stack-chain');
^^^^^
SyntaxError: Use of const in strict mode.

Can you flag an older version in npm, that does not require ES2015, to be installed on node <= 0.12.x?

I think version 1.1.0 may work on node 0.12.x, but I'm not sure.
This module uses a node.js feature called async_wrap, unfortunately this is only half supported in 0.12.x, versions before that don't have it at all. It is possible to use those parts and give some results, be it will suffer from the same memory issues that 4.x.x also have now. So it not about the ES2015 features (I would just refrain from using them then), it is about async_wrap.
I know 4.x.x will get its async_wrap implementation updated to correspond to the much better version there is in 5.x.x, but I don't know if they will update 0.12.x too. I've opened an issue requesting it to be updated: https://github.com/nodejs/node/issues/4592

Yeah, I tried manually grabbing the latest 1.x release (1.2.0) and it seemed to work (didn't crash, seemed to give me slightly better call stacks, though I didn't look too closely as I tracked down the issue I was looking into through other means).

The Node LTS WG has agreed that node v0.12 will not get the async_wrap feature updated. See: https://github.com/nodejs/node/issues/4592


add unitests for rest module

Signed-off-by: 662962756<EMAIL_ADDRESS>

 increase test coverage in driver-pkg/rest


Support for Checkout API v68

Is your feature request related to a problem? Please describe.
Checkout API v68 added the /sessions endpoint needed for the new v5.0.0 Drop In to simplify the payment request flow.
Describe the solution you'd like
sessions endpoint should be supported by this go-api-library
Describe alternatives you've considered
For now we use the pre v5.0.0 payment request flow
Additional context

Are there any updates on this issue?


Support for uninstall packages using Chocolatey

Add support for uninstalling packages using chocolatey. Currently there is no support for this. The case is to install tools using chocolatey during the build and uninstall when the build finishes to keep the build environment as clean as possible.

@gep13 I can take this one if that works for you.

@phillipsj sure thing, happy for you to take this.

Fixed by #1390


Mosquitto connection problem

In my situation mqtt-panel cannot connect to Mosquitto.
The connection is secured with username/password.
First I tried the Docker image, after login an error message is shown.
This is the log:

today at 21:35:082022-01-14 21:35:08,923 INFO [mqtt] Open (mqtt-panel)
today at 21:35:082022-01-14 21:35:08,925 INFO [mqtt] Using basic auth
today at 21:35:082022-01-14 21:35:08,926 INFO [mqtt] Connecting to <IP_ADDRESS>:1883
today at 21:35:082022-01-14 21:35:08,934 INFO [mqtt] Open (mqtt-panel)
today at 21:35:082022-01-14 21:35:08,937 INFO [mqtt] Using basic auth
today at 21:35:082022-01-14 21:35:08,938 INFO [mqtt] Connecting to <IP_ADDRESS>:1883
today at 21:35:082022-01-14 21:35:08,945 INFO [mqtt] On Connect
today at 21:35:082022-01-14 21:35:08,949 INFO [mqtt] On Disconnect
today at 21:35:082022-01-14 21:35:08,950 INFO [mqtt] Close
today at 21:35:082022-01-14 21:35:08,951 INFO [mqtt] Open (mqtt-panel)
today at 21:35:082022-01-14 21:35:08,953 INFO [mqtt] Using basic auth
today at 21:35:082022-01-14 21:35:08,954 INFO [mqtt] Connecting to <IP_ADDRESS>:1883

My next step was to run the Python program on my own computer.
But I am not a Python developer so it is difficult for me to trace down the problem.
It seems to be a problem with the paho.mqtt.client.
I tried several options with the paho.mqtt.client.Client like this:

    self._client = paho.mqtt.client.Client(client_id=self._c['client-id'], userdata=None, protocol=paho.mqtt.client.MQTTv5, transport="tcp")

    self._client = paho.mqtt.client.Client(client_id=self._c['client-id'], userdata=None, protocol=paho.mqtt.client.MQTTv311, transport="tcp")

but that did not solve the problem.
This is the message in the Mosquitto log:

Socket error on client , disconnecting.

It seems to be a known problem with the Python Paho MQTT Client but I am not sure about that.
Is it possible to show debug log messages for the Paho MQTT Client?
Do you have other suggestions?

Thank you for your feedback. I'll take a look and see what I can find.

It works perfectly now, thank you very much!


Simplify code, fix issues

I've simplified some lines of code, got rid of a couple of warnings, and added a print of the plot_order tables as I think it could help people understand what's happening in the code.
The only real change to the code behaviour is removing the call to value_counts() in the last cell: I was getting an error when the call was present as this was changing columns in a way that did not agree with the following code, please check if this version works for you as well

Thanks @barbuz, I had no idea there was a case parameter in contains 🤯 I have merged your branch now


HexDummy 1.20.1 Yarn mappings should use hexcasting fabric jar in Common subproject

When generating a project for 1.20.1 with Yarn mappings, the Common subproject has modApi(libs.hexcasting.common) listed in the dependencies section of build.gradle.kts. Since the Common jar isn't remapped by loom, this dependency should be changed to modApi(libs.hexcasting.fabric) (which includes the Common code).

Thanks!


flirpi: make it cross-compilable

Thanks for the updates! This changes look fine to me. Any issues from other watchers?

LGTM.  I always end up changing the hardcoded spidev0.0 to spidev1.0 or some other, but I think that's out of scope here.

hum... seems like everything I commit on my clone's branch end up here as pull request... at the moment, only the first 2 commits were intended to be merged as is and serve as a test to see if this respository is still active ;-)
Of course if last third commits are OK for you, you can also take them. They are tested and working well here on Armadeus embedded SOMs (cross-compiled with Buildroot).

Since it was not really the intent, I'll merge just the first two commits and if anyone comes across this PR and wants the other ones, leave a note and we'll revisit


Add Tragicbeautiful.com

Listed as 'hard'. Had to email support and there was no confirmation email. Had to log into the site to verify that it was closed.

Thanks for your contribution!


bug

Codecov Report

Merging #1 (5237e66) into master (655beb0) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #1   +/-   ##
=========================================
  Coverage     22.21%   22.21%
  Complexity       57       57
=========================================
  Files           163      163
  Lines          4150     4150
  Branches        595      595
=========================================
  Hits            922      922
  Misses         3206     3206
  Partials         22       22

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 31e98b8...5237e66. Read the comment docs.


[🐞] Latest qwik-react version (0.5.2) shipped without TypeScript types

Which component is affected?
Qwik React
Describe the bug
After updating qwik-react from 0.5.1 to 0.5.2 I got following error:
Could not find a declaration file for module<EMAIL_ADDRESS>
This error affects both qwik-react and qwik-react/vite
If you open @builder.io/qwik-react code in npm you will see that the package lacks lib/types directory: https://www.npmjs.com/package/@builder.io/qwik-react?activeTab=code
But the previous version have those: https://www.npmjs.com/package/@builder.io/qwik-react/v/0.5.1?activeTab=code
Reproduction
https://stackblitz.com/edit/qwik-starter-zsfa6w?file=vite.config.ts
Steps to reproduce

Open vite.config.ts and you will see the error at the line 5.
Then open src/integrations/react/mui.tsx and you'll see TS complaining about missing types on the line 3.

System Info
System:
    OS: macOS 14.2.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 58.19 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 21.3.0 - ~/Library/Caches/fnm_multishells/96117_1704896998443/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 10.2.4 - ~/Library/Caches/fnm_multishells/96117_1704896998443/bin/npm
    pnpm: 8.14.3 - /opt/homebrew/bin/pnpm
    bun: 1.0.25 - /opt/homebrew/bin/bun
  Browsers:
    Chrome: 121.0.6167.139
    Safari: 17.2.1
  npmPackages:
    @builder.io/qwik: 1.4.3 => 1.4.3
    @builder.io/qwik-auth: 0.1.3 => 0.1.3
    @builder.io/qwik-city: 1.4.3 => 1.4.3
    @builder.io/qwik-react: 0.5.2 => 0.5.2
    undici: ^6.6.0 => 6.6.0
    vite: 5.0.12 => 5.0.12

Additional Information
The current solution is to stay on 0.5.1.

Argh

published 0.5.3, containing types this time.


pg_query.proto: Add Token ASCII_36; Add scan test

Postgres's scanner will scan $ into a single token. For example:
    SELECT $identifier;

The parser will later reject this. However, since the scanner returns this value, we should define a Token for it in the protobuf.
test/scan.c:

Add a check so the test does not crash if token_kind is NULL, which it was before I defined the token. The test now prints an error:

    INVALID result for "...": scan_result token 1 token_kind == NULL

Make tests constant to prevent accidental modification. Unnecessary but could be helpful.
Define testsCount automatically so it no longer needs to be changed.
Add an assert to help ensure tests are defined correctly.

As far as I know so far: this $ token is always a parse error. According to my reading of the documentation, Postgres does not permit $ as an operator, but it does permit it:

In parameter placeholders: SELECT $5;
After the first character of an identifier: CREATE TABLE valid$identifier ();
As dollar quote:  SELECT $$string with $ lots of stuff$$;
As a "named" dollar quote: SELECT $name$my string$name$;

I found this because I wrote a fuzz test for a tool that is rewriting Postgres queries using https://github.com/pganalyze/pg_query_go , and it happened to generate this. The "unsupported" token caused my fuzz test to be unhappy.
So: This isn't "needed", except for completeness for supporting any Postgres tool.


flatpak-builder: v6 tag doesn't point to latest v6 release

The typical convention for GitHub actions is for the v6 tag to point to the latest v6.x.x version. Currently, v6 points to the release from a couple of weeks ago with the issue overwriting the Flatpak branch.
This means that automated PRs to bump dependencies in workflow files, like dependabot are proposing bumping to the broken v6 tag, as they typically only bump major versions. See this PR against an elementary repo: https://github.com/elementary/appcenter-reviews/pull/448/files
See the GitHub Actions docs for further info on the conventions: https://github.com/elementary/appcenter-reviews/pull/448/files

I have no idea how to make v6 tag point to a v6.1.... maybe i should ditch all those v6x tags and switch to a v6 branch

You just push a new v6 tag pointing to the same commit that v6.1 points to.

Should be fixed now


ESPHome DSMR fatal error

Describe the bug
When using a ESPHome grid meter of type slimmelezer (https://docs.evcc.io/en/docs/devices/meters#esphome-dsmr), EVCC crashes during startup.
Steps to reproduce
Set the configuration as shown below and restart EVCC. It will throw the fatal error as shown below.
Configuration details
The relevant part of the configuration is below:
meters:
  - name: grid
    type: template
    template: slimmelezer
    usage: grid
    host: a.b.c.d

Log details
(...)

[main  ] FATAL 2023/09/16 15:08:51 cannot create meter 'grid': cannot create meter 'custom': 1 error(s) decoding:

* 'Power' expected a map, got 'slice'

(...)

What type of operating system are you running?
Docker container
Version
0.120.0

A PR to fix this issue is here: https://github.com/evcc-io/evcc/pull/9908

Configfehler.


First pass at style and flow for AC-8 login conformity

This PR addresses the issue raised in RAC-A: Login messaging for AC-8 here: https://github.com/18F/cg-uaa/issues/15
Notably, it does not include final copy for the complete notice. This needs to come later.

OK! Fixed those merge conflicts!

Another important note: This PR includes data in login.yml that must be reset to its original contents before merge. This current contents of this file allow us to spoof agency signin only for testing.


Fix for #15296 bug

Fix for #15296 - the canvas opacity change changes the opacity for all WebGL rendered layers instead only the current one. Removing the 4 lines that do that doesn't seem to break anything and it fixes the issue.

This also fixes a previously unnoticed bug.  With just one layer the opacity was applied twice, so when specified opacity was 0.5 the result was 0.25.  Additional rendering tests based on https://github.com/openlayers/openlayers/tree/main/test/rendering/cases/webgl-vector would be useful.

Ok, I've updated the test to use the VectorLayer. One thing to note here: I don't see a dedicated WebGL VectorLayer (there's WebGLPoints and WebGLTile, but no WebGLVector) . The only way to get WebGL rendered VectorLayer I know of, is to extend the VectorLayer and override createRenderer to create and return WebGLVectorLayerRenderer instance (or a class extending it) - is in webgl-vector test for example.

#16394 recently added WebGLVectorLayer, so the test can be updated if you rebase.

Ah, ok. I didn't see it then. That explains it.

Looks like the lint step is failing, could you please try and fix it? thanks


Show how to generate Java data models that overwrite toString method

What to solve
Depending on what you want to use the data models for, you might stumble upon a scenario where you want the models to overwrite toString method.
This can be done by including the preset JAVA_COMMON_PRESET and providing the option classToString. By default, if no options are present, all support functions are included.
Use the following code in the example:
generator = new JavaGenerator({
  presets: [
    {
      preset: JAVA_COMMON_PRESET,
      options: {
        equal: false,
        hashCode: false,
        classToString: true
      }
    }
  ]
});

Duplicate the folder https://github.com/asyncapi/modelina/tree/master/examples/TEMPLATE and rename it to java-generate-tostring. Update any relevant documentation.

Some folks want more specific tasks to complete, or use this if you get stuck - CLICK ME

This issue is specially designed for first-time contributors, that want to contribute their very first code. If you are accustomed to how to solve issues in AsyncAPI, you can skip some of the steps.
What to know before getting started
Before actually getting started with solving the issue, there are a few things that need to be set up:

Make sure you familiarize yourself with our code-of-conduct and contributor guidelines
We work on forks of repositories and branches in forks, if you are unsure how to set this up you can follow the guide on our git-workflow setup.

Feel free to reach out either here in the issue, or on slack under #tooling if you have any questions or are stuck, we will gladly help.
Getting started
This is a task list, that you copy into your PR description to ensure everything is included, this list walks you through each step as to how to solve this issue. It assumes that you have already set up your fork and branch and are ready to commit code.

[ ] Duplicate the folder https://github.com/asyncapi/modelina/tree/master/examples/TEMPLATE and rename it to java-generate-tostring. This will give you a good base to start out with.
[ ] Adapt the documentation about the feature and ensure the example are linked correctly.

The docs that need to change are the following: docs/languages/Java.md#include-tostring-function-for-the-class
The documentation must reference an actual example that is tested and contain no code itself. It is because the docs will inevitably become desynchronized and display incorrect code.

[ ] Adapt the examples overview to include your new example.
[ ] Now it is time to adapt the test code (in examples/java-generate-tostring/index.spec.ts) and the implementation (in examples/java-generate-tostring/index.ts).
[ ] Make sure that the test succeeds, by standing in the new example folder and execute npm run test.
[ ] Make sure that there are no linting errors, by standing in the root folder and execute npm run lint.
[ ] Create your PR, by selecting your branch that should be merged with the master branch - https://github.com/asyncapi/modelina/compare
[ ] It is good practice to double-check your PR before requesting a review from someone else, the same way you read an assignment before handing it in.

Do you have any examples I can check for reference?
We have currently 4 example documentations that you can look for guidance on how to achieve the desired output:

How to add logging to the library
Generate models from AsyncAPI documents
Generate models from JSON Schema draft 7 documents
Generate an interface instead of class

Happy Hacktoberfest, everyone! ✨✨ Feel free to reach out to me for any questions you may have about adding documentation on these open issues. 🙂
Tag me in your AsyncAPI Doc PRs 📄, my GitHub handle is /alequetzalli 🐙.


APIs and CRDs for backup object

What type of PR is this?
This PR is a new feature for Kahu backup. It contains the Backup API and CRD and generated client
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #31
Test Report Added?:

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:
/kind TESTED
/kind NOT-TESTED

Test Report:

Special notes for your reviewer:
How to generate API-Client code and CRDs:

code-generator/generate-groups.sh all github.com/soda-cdm/kahu/controllers/generated/client github.com/soda-cdm/kahu/apis kahu:v1beta1 --go-header-file ../kahu1/vendor/k8s.io/code-generator/hack/boilerplate.go.txt

controller-gen paths=github.com/soda-cdm/kahu/apis/kahu/v1beta1 crd:crdVersions=v1 output:crd:artifacts:config=config

@sushanthakumar @joseph-v @AmitRoushan plz review

@PravinRanjan10 Please create an issue from the PR

@PravinRanjan10 Please add doc/script to generate CRDs yaml, clientset and configuration

@PravinRanjan10 IMO, informer, lister and client set generated files require SODA Authors in header instead of Kubernetes.

@PravinRanjan10 IMO, informer, lister and client set generated files require SODA Authors in header instead of Kubernetes.

Done


SDK 3.9.4: Goroutine leak in reportToRun

In helm.sh/helm/v3 v3.9.4 the method reportToRun is implemented as follow:
func (i *Install) reportToRun(c chan<- resultMessage, rel *release.Release, err error) {
	i.Lock.Lock()
	if err != nil {
		rel, err = i.failRelease(rel, err)
	}
	c <- resultMessage{r: rel, e: err}
	i.Lock.Unlock()
}

I have confirmed that after performing an install action (using RunWithContext) leads to goroutine leak.

The above screenshot shows that goroutines are stuck in reportToRun. Here a sample stack trace of one of those routines:
goroutine 15463 [chan send, 32 minutes]:
helm.sh/helm/v3/pkg/action.(*Install).reportToRun(0xc0026086e0, 0xc0026804c0?, 0x3?, {0x22dd9c0?, 0xc006a7bf20?})
	/go/pkg/mod/helm.sh/helm/v3@v3.9.4/pkg/action/install.go:435 +0xd6
helm.sh/helm/v3/pkg/action.(*Install).performInstall(0xc0026086e0, 0xc005269f60?, 0xc005216310, {0x0?, 0x0?, 0x0?}, {0xc0026804c0, 0x3, 0x4})
	/go/pkg/mod/helm.sh/helm/v3@v3.9.4/pkg/action/install.go:389 +0x2ea
created by helm.sh/helm/v3/pkg/action.(*Install).RunWithContext
	/go/pkg/mod/helm.sh/helm/v3@v3.9.4/pkg/action/install.go:349 +0x128a

The block seems to be in the chan send call.
On another note, I believe if we fall into the error path, the  i.Lock will stay locked forever.

According to this code:

// Run executes the installation with Context
func (i *Install) RunWithContext(ctx context.Context, chrt *chart.Chart, vals map[string]interface{}) (*release.Release, error) {
        ...
        rChan := make(chan resultMessage)
	doneChan := make(chan struct{})
	defer close(doneChan)
	go i.performInstall(rChan, rel, toBeAdopted, resources)
	go i.handleContext(ctx, rChan, doneChan, rel)
	result := <-rChan
	//start preformInstall go routine
	return result.r, result.e
}

We read from rChan only once. But both performInstall and handleContext do call reportToRun (more then once) which tries to send to rChan.
So basically rChan is getting consumed only once why we send to it more then once.

Have you checked to see if that's still in main?

Yes, it's the same code in main

I have seen the same problem in my program.
My program build helm client and call (*Upgrade)RunWithContext to perform upgrade/install.
After the program runs for a period, it ends up with OOM.
so i used pprof to parse the memory allocation and goroutine, i noticed memory leak and goroutine leak.
memory allocation flame graph as follow:

goroutine flame graph as follow :

When we run helm client command to call (*Upgrade)RunWithContext, it is fine, because the main func exits after upgrade/install finished. but if we develop program by call (*Upgrade)RunWithContext, the main func will not exit(until we want it exit), and the goroutine leak happens, will caused memory leak which is a bigger problem.

@joejulian is there any plan to work on this issue soon?

this problem had been solved according to the code in tag: v3.9.4
	rChan := make(chan resultMessage) 	ctxChan := make(chan resultMessage) 	doneChan := make(chan interface{}) 	defer close(doneChan) 	go u.releasingUpgrade(rChan, upgradedRelease, current, target, originalRelease) 	go u.handleContext(ctx, doneChan, ctxChan, upgradedRelease) 	select { 	case result := <-rChan: 		return result.r, result.e 	case result := <-ctxChan: 		return result.r, result.e 	}
could close the issue now.

No that in the update release path not install release parh

@Segflow sorry, i didnot notice that you are mentioning install release path rather than upgrade release path.
after reading the install code carefully, i realized that it should not lead to goroutine leak in normal cases.
// Run executes the installation with Context
func (i *Install) RunWithContext(ctx context.Context, chrt *chart.Chart, vals map[string]interface{}) (*release.Release, error) {
        ...
        rChan := make(chan resultMessage)
	doneChan := make(chan struct{})
	defer close(doneChan)
	go i.performInstall(rChan, rel, toBeAdopted, resources)
	go i.handleContext(ctx, rChan, doneChan, rel)
	result := <-rChan
	//start preformInstall go routine
	return result.r, result.e
}

according to the above code, in normal cases, performInstall should finish with result sent to rChan,  and result := <-rChan is unblocked, then close doneChan before return.
the close(doneChan) will lead handleContext goroutine return. this is what we expected.
@Segflow how do you think about this?

The issue is performInstall also calls reportToRun, this leads to have both
	go i.performInstall(rChan, rel, toBeAdopted, resources)
	go i.handleContext(ctx, rChan, doneChan, rel)

Send to the channel. We have this issue in our production

i guess the case <-ctx.Done() is triggered in your case, this could lead to goroutine leak due to performInstall and handleContext both are send to rChan.
but goroutine leak donot happen in other cases.
Please correct me if i am wrong.

indeed

Any update on this please?

There's a PR to address this at https://github.com/helm/helm/pull/11978


chore: Add analytics event for merge branch status

Description
Add analytics data points for the merge status flow
PR fixes following issue(s)
Fixes #24803

/build-deploy-preview


FR: Non-autofixable lint rules

Problem
I'd like to write a rule that lets me raises an error when I have a nested wikilink [[Like/So]] because I find duplicate note names is confusing and messy. Since this has the potential to be a destructive change, I'd like the linter to tell me where it occurred, rather than to make the change for me.
Before implementing this rule, I'd need to be able to implement rules that are not autofixed.
Solution
An obvious solution would be to introduce a panel that lists the errors encountered in the previous pass.
For now, I'm just throwing an error in the dev tools console to warn me.

I am working on a warning mode #272 which should allow for rules that are not fixable to be added. I just have not had a whole lot of time recently with being out sick and now trying to get back into the swing of things. I hope to have a warning mode in place in the next couple of weeks. That should satisfy adding support for rules like this.

Yeah that totally answers it. Sorry for the duplication.


chore(main): release 3.1.0

:robot: I have created a release beep boop
3.1.0 (2024-01-29)
Features

events en 4/5 ready (355b5dd)
events en 4/5 ready (#86) (a5587f8)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/Hessuew/flamethefreeze/releases/tag/v3.1.0 :sunflower:


Expand List API

Get item by id, get item by property, etc

Look ups

differentiate library <--> list
check in/out, publish


Re-running generators and dry-run mode - Proposal

Extracting from https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/issues/104.
A Generator in the PDSC specification is essentially a black box from the tooling point of view. It will take some inputs, and then produce some output. This output is then included in the project.
The input is today not specifiable in the PDSC format.
The output is today described in the .GPDSC file that the generator creates.
The use of generated components in a project raises a few questions that we need to clarify on the tool level:
1. When do we need to run the generator
Today a generator is only run manually, and only required when the .gpdsc is missing.
From the end-user point it is expected that generated components are kept up-to-date with changes to the project. This means that if some input changes, then the generator may require re-running to provide the latest contents to the generated component.
This means that a generator should require (re-)running if either:

The .gpdsc is missing (i.e. the first time)
If any of the input is changed
input change detection can be implemented based on file-stat modification date, compared against the .gpdsc file. So if any input file is newer than the .gpdsc file, then the generator requires re-running.

2. What will the generator take as input
A generator today can take a $G parameter as input, this will point to a .cbuild.yml file describing the project state.
However, this is not the only thing a generator may require from the project.
These additional files that the generator depend on is called additionalInputs.
The complete set of input files can then be defined as the combined set of:

The $G input file
The additionalInputs defined for the generator

To define the additionalInputs, it should be possible to define this in the .PDSC using file patterns:
  <generator>
    <additionalInputs>
      <filePattern>$P/.*/settings.json</filePattern> <!-- cproject level -->
      <filePattern>$S/.*/settings.json</filePattern> <!-- csolution level -->

These file patterns can then be evaluated and collected to create the additionalInputs set.
Typically these additionalInputs would be used by the PDSC definition to declare files from the Projects that the generator will depend on.
To be refined: The expanded list of additionalInputs files should be provided to the generator. Preferably in the cbuild.yml
3. What does the generator create if it is run
In 1 and 2, it is now possible to determine if the input requires the generator to be re-run, but it is still not certain that this is the right time to create files, at this point the tools may only want to evaluate dependencies of the would-be-generated-component.
To allow this this proposal introduces the dry-run concept. This allows running generators in a special mode that will not allow creating any files on the file-system. The only output from the generator in this mode is the .GPDSC.
Dry-run mode can be added to the .pdsc specification by introducing a new attribute mode on the /package/generators/generator/.../argument element.

A generator is dry-run capable if it provides an <argument mode="dry-run">--custom-generator-flag-for-dry-run</argument> element in the PDSC definition.
If no mode="dry-run" attribute is provided for any argument, then the generator does not support dry-run mode.

In the dry-run mode it is expected by the generator that it outputs the .GPDSC on stdout of the process and ONLY the .gpdsc. Meaning, in the dry-run-mode, error logs, info messages etc, needs to be printed to stderr or to files directly to avoid mixing with the .GPDSC on stdout information.
Tools can then run generators in dry-run mode, parse the GPDSC from stdout, and then analyze dependencies ahead-of-time. This allows tools to determine fully if the generated components are usable immediately, in a "harmless" way, and only when the user commits to using this component can the tools proceed to create the actual files.

PRs for the "mode" attribute for generator arguments are now available: implementation, spec.


LiveSync plugin settings: the skip pattern to default and select Cross-platform: workspace-mobile.json

Self-hosted LiveSync plugin Version 0.17.30
Windows, Linux, Android, iPad.

Hi, I'm looking forward to using your LiveSync plugin. I always feel comfortable using the LiveSync plugin. Thank you very much.
I read a post about syncing the workspace.json and workspace-mobile.json files with the Obsidian Git plugin, "workspace.json always shows up in source control : ObsidianMD (reddit.com)" made me think.
In the LiveSync plugin settings, go to
Sync Settings -> Skip patterns -> Restore the skip pattern to default and select Cross-platform:
\/node_modules\/, \/\.git\/, \/obsidian-livesync\/,\/workspace$ ,\/workspace.json$
is set.
With this regex, wouldn't workspace.json for desktop be skipped on sync, but workspace-mobile.json for mobile not be skipped on sync, but synced every time?
Is this behavior what you are aiming for?
If I am wrong, I apologize.
Thank you in advance for your time. I am not in a hurry for a response. I would appreciate it if you could respond when you are available.

I found the following skip pattern worked best for me:
\/node_modules\/, \/\.git\/, \/obsidian-livesync\/,\/workspace$ ,\/workspace.json$,\/workspace-mobile.json
I thought I submitted a PR for this but it seems not.

Thank you for opening the issue!
The default value had not been updated for a long time. I hope to fix it and I very much agree with @hilsonp.
Since we are here, I will accept it if you can give me a PR, and I do not mind at all if you leave it to me.

@vrtmrz and @hilsonp, sorry for the delayed response.
Thanks to your help, I've been monitoring for a few days after adding \/workspace-mobile.json$ to Sync Settings->Skip patterns in the LiveSync plugin.
As a result, the workspace-mobile.json conflict that used to occur when syncing between mobile devices has been resolved and I now have much less merging to do when syncing.
Thank you very much.
I would be happy to give you a PR if you want, and I will leave it  to you.
Thanks for your time.