x:Bind Functions - usage of BindBack is unclear

The description of two way function binding doesn't seem to clarify how the functions should work, and there's no example for the implementation of a BindBack function.
Since x:Bind Functions are used for converting data, I'd expect that a BindBack function would require a return statement of the source type and set it to the source property. However, it seems like this is not the intended functionality, as the set of a property is never called on a two-way x:Bind with BindBack.
According to this unofficial sample it seems as if the BindBack function should directly set the source property, so rather than working as a performant substitute for a classic converter, it works like a "ValueChanged" callback, which is counter-intuitive to the way that bindings work.
Is this how BindBack functions are supposed to work? If so, what's the difference between them and "ValueChanged" callbacks?
I'd like to get some clarification on this topic, since there doesn't seem to be much info about it around the internet.
Also, it would be nice if the documentation page contained an example for an implemented BindBack function.
Thanks

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9fdf7014-70bd-f562-046a-432f5f5caf11
Version Independent ID: f45e3d08-66e0-1b74-2c0d-595345e7f3b1
Content: Functions in x:Bind - UWP applications
Content Source: windows-apps-src/data-binding/function-bindings.md
Product: uwp
Technology: data-and-files
GitHub Login: @lastnameholiu
Microsoft Alias: alholiu

AI Generated answer attached. Jim, would this be accurate?
The x:Bind with BindBack in UWP (Universal Windows Platform) is indeed a topic that can be a bit confusing without clear documentation and examples. Your understanding and the observations from the unofficial sample lead to a correct interpretation of how BindBack functions are intended to work, which might differ from initial expectations based on traditional data binding concepts.
Understanding BindBack
The primary purpose of x:Bind is to provide a more performant and type-safe way of binding data in UWP compared to the older {Binding} syntax. When you use x:Bind in Two-Way binding mode, you typically specify a Mode=TwoWay parameter to enable updates to flow from the target back to the source.
The BindBack function is used in scenarios where the data conversion needs to happen not just from source to target (which is handled by the converter parameter in x:Bind) but also from target back to source when the target changes. However, the intuitive expectation that BindBack functions like a traditional converter that simply returns a value to be automatically assigned to the source property is not accurate.
Instead, BindBack acts more like a "ValueChanged" callback where you manually handle the update to the source property based on the target's new value. This means that within the BindBack function, you should directly set the source property to its new value, reflecting the change from the target.
Why Use BindBack Over "ValueChanged" Callbacks?
While BindBack and "ValueChanged" callbacks might seem to serve similar purposes, there are nuances:
Declarative Binding: BindBack keeps the logic related to updating the source property in the context of the binding declaration, making it clearer that this logic is specifically for handling changes from the target back to the source.
Consistency and Maintainability: Using BindBack maintains consistency in your data binding strategy, keeping both the forward and backward conversions within the x:Bind syntax. This can make the code more maintainable and easier to understand at a glance, especially for others reviewing your code or for you when coming back to it after some time.
Separation of Concerns: "ValueChanged" callbacks might be used for a variety of reasons unrelated to updating a source property based on a change in the target. Using BindBack specifically for the reverse data flow in two-way bindings helps maintain a clear separation of concerns.
Example of BindBack Implementation
While official examples in the documentation would be ideal, here's a basic conceptual example to illustrate how BindBack could be implemented:
xml
Copy code

In your ViewModel:
csharp
Copy code
public void IntToStringBindBack(string value)
{
if (int.TryParse(value, out int result))
{
this.SomeProperty = result;
}
// Optionally handle the case where conversion fails
}
In this example, IntToStringBindBack directly sets SomeProperty in the ViewModel based on the value from the TextBox. This approach ensures that you're manually handling the conversion and assignment back to the source property, which is the intended functionality of BindBack.
Conclusion
BindBack functions are indeed meant to directly set the source property, acting more like a manual "ValueChanged" handler within the context of two-way x:Bind bindings. The distinction between BindBack and general "ValueChanged" callbacks lies in their specific use cases and the structured approach BindBack provides for handling reverse data flow in bindings. Your feedback about the lack of clear examples and detailed explanations in the official documentation is valid, and it would be beneficial for the documentation to include explicit BindBack examples for developers.


Fixing various typos in documentation files and source code comments

This PR fixes various typos, both in the documentation files and in source code files (mainly comments).

Appreciate the corrections! Did you use a tool to find all of these? I can't imagine you actually read all the code comments.


pip-compile fails to resolve dependency versions, even though solution exists

For some reason pip-compile decides to pin a direct dependency's (google-api-python-client) dependency (google-auth-httplib2) to a higher-than-necessary version (0.1.0 instead of 0.0.4), which causes a clash between another direct dependency (httplib2==0.11.3 ) and the resolved version (google-auth-httplib2==0.1.0 requires httplib2>=0.15.0).
Directly running pip install google-api-python-client==1.7.8 httplib2==0.11.3  results in:
Successfully installed cachetools-4.2.1 google-api-python-client-1.7.8 google-auth-1.28.0 google-auth-httplib2-0.0.4 httplib2-0.11.3 pyasn1-0.4.8 pyasn1-modules-0.2.8 rsa-4.7.2 six-1.15.0 uritemplate-3.0.1

Environment Versions

Ubuntu 18.04.5 LTS (through Docker version 20.10.5, build 55c4c88 on Mac OS Catalina 10.15.7)
Python version: 3.6.9
pip version: 21.0.1
pip-tools version: 6.0.1

Steps to replicate
cat >> requirements.in <<EOF
httplib2==0.11.3
google-api-python-client==1.7.8
EOF

pip-compile requirements.in --output-file requirements.txt

Expected result
# requirements.txt
cachetools==4.2.1
google-api-python-client==1.7.8
google-auth==1.28.0
google-auth-httplib2==0.0.4
httplib2==0.11.3
pyasn1==0.4.8
pyasn1-modules==0.2.8
rsa==4.7.2
six==1.15.0
uritemplate==3.0.1

Actual result
Could not find a version that matches httplib2<1dev,==0.11.3,>=0.15.0,>=0.9.2 (from -r requirements/test.in (line 1))
Tried: 0.7.3, 0.7.3, 0.7.4, 0.7.4, 0.7.5, 0.7.5, 0.7.6, 0.7.6, 0.7.7, 0.7.7, 0.8, 0.8, 0.9, 0.9, 0.9.1, 0.9.1, 0.9.2, 0.9.2, 0.10.3, 0.11.0, 0.11.1, 0.11.3, 0.12.0, 0.12.1, 0.12.3, 0.12.3, 0.13.0, 0.13.0, 0.13.1, 0.13.1, 0.14.0, 0.14.0, 0.15.0, 0.15.0, 0.16.0, 0.16.0, 0.17.0, 0.17.0, 0.17.1, 0.17.1, 0.17.2, 0.17.2, 0.17.3, 0.17.3, 0.17.4, 0.17.4, 0.18.0, 0.18.0, 0.18.1, 0.18.1, 0.19.0, 0.19.0, 0.19.1, 0.19.1
There are incompatible versions in the resolved dependencies:
  httplib2==0.11.3 (from -r requirements/test.in (line 1))
  httplib2<1dev,>=0.9.2 (from google-api-python-client==1.7.8->-r requirements/test.in (line 2))
  httplib2>=0.15.0 (from google-auth-httplib2==0.1.0->google-api-python-client==1.7.8->-r requirements/test.in (line 2))

Hello @tmarice,
Thanks for the report. That's because pip-tools doesn't yet have a proper dependency resolver. See #693 and the other related issues for details.

@atugushev was it a design choice (not having a proper resolver) since it's fast and fails only in few cases, or you'd accept/consider a PR for example using resolvelib or another proper resolver?

@dieggoluis I think nobody here opposes having resolvelib integrated. I suggested it in some threads too. But it'd take some effort to get it done. I have experience integrating resolvelib but I've never gotten to explore what it'd take to get it pulled into pip-tools.
If you're willing to start working on a PR, I'll try to find some time to review it. Not sure if there's anybody else here who's actually worked with resolvelib directly in the past but if there is, it'd be useful to track them down and ask for reviews too.

I have a prototype https://github.com/atugushev/pip-tools/pull/10. Implemented the new resolver using pip itself (not resolvelib though). It almost works (98% tests passed) but it's pretty raw.

I'd still prefer resolvelib tho

@webknjaz May I ask you why you'd prefer resolvelib instead of using pip's resolver?
At Data Theorem, we are experimenting pip-tools in one of our projects in replacement of pipenv and we like it so far.
We think that it would make more sense that pip-tools uses pip's resolver. It would make it a thin wrapper around pip and we think that's what pip-tools should become (a set of tools based on pip which adds features that pip is currently missing).
It would also make sense to us to have pip-compile and pip-sync use the same resolver to ensure their behavior is more consistent.
If we can provide any help for the implementation or the review, we would be happy to contribute.
Thanks!

@FlorentJeannot pip actually uses resolvelib as a vendored library. The advantage of using resolvelib might be that it is easier to get the most updated version. The drawback is adding a new dependency.
@atugushev I'd start working on it this weekend in my spare time, but if you are almost done with it I'll leave you to finish the job :)  I'd be happy to help reviewing it

I have a prototype atugushev#10. Implemented the new resolver using pip itself (not resolvelib though). It almost works (98% tests passed) but it's pretty raw.

@atugushev Sorry to bother, I'd like to know if there's any news about this PR and if we could expect an improved resolver for this year?
Thanks!

I'd like to know if there's any news about this PR and if we could expect an improved resolver for this year?

@FlorentJeannot thanks for pinging 🙏🏻  It's at the top of my TODO list.

@FlorentJeannot try #1539 which adds support for pip's 2020 dependency resolver

Works with new resolver #1539:

Details
❯ pip-compile --resolver backtracking
#
# This file is autogenerated by pip-compile with python 3.8
# To update, run:
#
#    pip-compile --resolver=backtracking
#
aiobotocore[boto3]==1.3.0
    # via
    #   dvc
    #   s3fs
aiohttp==3.8.1
    # via aiobotocore
aioitertools==0.9.0
    # via aiobotocore
aiosignal==1.2.0
    # via aiohttp
appdirs==1.4.4
    # via dvc
async-timeout==4.0.2
    # via aiohttp
atpublic==3.0.1
    # via flufl-lock
attrs==21.4.0
    # via aiohttp
boto3==1.17.49
    # via
    #   -r requirements.in
    #   aiobotocore
botocore==1.20.49
    # via
    #   aiobotocore
    #   boto3
    #   s3transfer
cachetools==5.0.0
    # via google-auth
certifi==2021.10.8
    # via
    #   dulwich
    #   requests
cffi==1.15.0
    # via pygit2
charset-normalizer==2.0.12
    # via
    #   aiohttp
    #   requests
colorama==0.4.4
    # via
    #   dvc
    #   rich
commonmark==0.9.1
    # via rich
configobj==5.0.6
    # via dvc
decorator==5.1.1
    # via jsonpath-ng
dictdiffer==0.9.0
    # via dvc
diskcache==5.4.0
    # via dvc
distro==1.7.0
    # via dvc
dpath==2.0.6
    # via dvc
dulwich==0.20.32
    # via dvc
dvc[s3]==2.3.0
    # via -r requirements.in
flatten-dict==0.4.2
    # via dvc
flufl-lock==3.2
    # via dvc
frozenlist==1.3.0
    # via
    #   aiohttp
    #   aiosignal
fsspec==2021.5.0
    # via
    #   dvc
    #   s3fs
ftfy==6.1.1
    # via python-benedict
funcy==1.17
    # via dvc
future==0.18.2
    # via grandalf
gitdb==4.0.9
    # via gitpython
gitpython==3.1.27
    # via dvc
google-api-python-client==1.7.8
    # via -r requirements.in
google-auth==2.6.0
    # via
    #   google-api-python-client
    #   google-auth-httplib2
google-auth-httplib2==0.0.4
    # via google-api-python-client
grandalf==0.6
    # via dvc
httplib2==0.11.3
    # via
    #   -r requirements.in
    #   google-api-python-client
    #   google-auth-httplib2
idna==3.3
    # via
    #   requests
    #   yarl
jmespath==0.10.0
    # via
    #   boto3
    #   botocore
jsonpath-ng==1.5.3
    # via dvc
mailchecker==4.1.12
    # via python-benedict
multidict==6.0.2
    # via
    #   aiohttp
    #   yarl
nanotime==0.5.2
    # via dvc
networkx==2.6.3
    # via dvc
packaging==21.3
    # via dvc
pathspec==0.9.0
    # via dvc
phonenumbers==8.12.43
    # via python-benedict
ply==3.11
    # via
    #   dvc
    #   jsonpath-ng
psutil==5.9.0
    # via dvc
pyasn1==0.4.8
    # via
    #   dvc
    #   pyasn1-modules
    #   rsa
pyasn1-modules==0.2.8
    # via google-auth
pycparser==2.21
    # via cffi
pydot==1.4.2
    # via dvc
pygit2==1.9.0
    # via dvc
pygments==2.11.2
    # via rich
pygtrie==2.3.2
    # via dvc
pyparsing==2.4.7
    # via
    #   dvc
    #   grandalf
    #   packaging
    #   pydot
python-benedict==0.25.0
    # via dvc
python-dateutil==2.8.2
    # via
    #   botocore
    #   python-benedict
python-fsutil==0.6.0
    # via python-benedict
python-slugify==6.1.0
    # via python-benedict
pyyaml==6.0
    # via python-benedict
requests==2.27.1
    # via
    #   dvc
    #   python-benedict
rich==11.2.0
    # via dvc
rsa==4.8
    # via google-auth
ruamel-yaml==0.17.21
    # via dvc
ruamel-yaml-clib==0.2.6
    # via ruamel-yaml
s3fs==2021.5.0
    # via dvc
s3transfer==0.3.7
    # via boto3
shortuuid==1.0.8
    # via dvc
shtab==1.5.3
    # via dvc
six==1.16.0
    # via
    #   configobj
    #   flatten-dict
    #   google-api-python-client
    #   google-auth
    #   google-auth-httplib2
    #   jsonpath-ng
    #   python-dateutil
smmap==5.0.0
    # via gitdb
tabulate==0.8.9
    # via dvc
text-unidecode==1.3
    # via python-slugify
toml==0.10.2
    # via
    #   dvc
    #   python-benedict
tqdm==4.62.3
    # via dvc
typing-extensions==4.1.1
    # via
    #   aioitertools
    #   dvc
uritemplate==3.0.1
    # via google-api-python-client
urllib3==1.26.8
    # via
    #   botocore
    #   dulwich
    #   requests
voluptuous==0.12.2
    # via dvc
wcwidth==0.2.5
    # via ftfy
wrapt==1.13.3
    # via aiobotocore
xmltodict==0.12.0
    # via python-benedict
yarl==1.7.2
    # via aiohttp
zc-lockfile==2.0
    # via dvc

# The following packages are considered to be unsafe in a requirements file:
# setuptools

This has been fixed in #1539 with the backtracking resolver, try pip-compile --resolver backtracking. The resolver is released as part of pip-tools v6.8.0. Please let us know if it doesn't resolve your issue. Thanks!


WIP Feature/issue 740 static icon names

Fixes #740
This PR is not ready for review.
Risk
This PR makes minor API changes.
Testing Plan

add unit tests for enums

Summary

Implement Static Icon Names as defined by the proposal

Tasks Remaining:

[ ] Unit Tests

CLA

[X] I have signed the CLA

Codecov Report

Merging #831 into develop will decrease coverage by 0.5%.
The diff coverage is 0%.

@@              Coverage Diff              @@
##             develop     #831      +/-   ##
=============================================
- Coverage      43.47%   42.97%   -0.51%
  Complexity      3029     3029
=============================================
  Files            382      383       +1
  Lines          17454    17640     +186
  Branches        1734     1736       +2
=============================================
- Hits            7588     7580       -8
- Misses          9547     9743     +196
+ Partials         319      317       -2

Impacted Files
Coverage Δ
Complexity Δ

...martdevicelink/proxy/rpc/enums/StaticIconName.java
0% <0%> (ø)
0 <0> (?)

...smartdevicelink/encoder/VirtualDisplayEncoder.java
24.71% <0%> (-4.6%)
8% <0%> (ø)

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 7ec84be...458680f. Read the comment docs.


fix(release): fix the Dockerfile

This commit fixes the broken Dockerfile that is used in release CI. It adds wasmedge installation step in the build, uses xx-cargo instead of cargo, and copies the sed command from Docker's build script that allows xx-cargo to be used with pkg-config in build scripts.
Reference

Docker's build script
xx issue

FYI @cpuguy83 @jprendes

Looks like just one comment from @jprendes but otherwise LGTM.
Thanks all.

nit: line 56 replace all the xx-info ... with a single xx-cargo --print-target-triple to compute the output directory:

Done.
Thank you @jprendes


⚠ Jenkins Plugins Artifactory has degraded performance

In a5d425a, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1224 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 566d8cc after 38 minutes.


SDK path error

Installed new Simplicity IDE (SV<IP_ADDRESS>) and updated per instructions on WIKI
https://github.com/OpenAcousticDevices/AudioMoth-Project/wiki/AudioMoth
Studio Packages installed are:
GNU ARM Toolchain (v4.9.2015.q3)
GNU ARM Toolchain (v7.2.2017.q4)
32 bit MCU SDK - <IP_ADDRESS>
32 bit MCU SDK - <IP_ADDRESS>
Trying to import AudioMoth-Project I get error:
"SDK of the build configuration cannot be resolved."
Specifically it doesn't like the line in .cproject:
value="${StudioSdkPathFromID:com.silabs.sdk.stack.super:1.1.0._1914564505}"/>

Currently responding to issue here: https://www.openacousticdevices.info/support/device-support/sdk-path-error-compiling-audiomoth-project
Will copy over solution to this issue page when found.

Solution - install 32 bit MCU SDK - <IP_ADDRESS>


txt2al shouldn't handle LineStart differences in delta files #4460 didnt fix the problem

in issue #4460 the problem isn`t fixed.
the txt2al still goes berserk is on linestart diffs
tested in build BC14CU0 (14.0.29530) and tested in latest build (14.0.31388)

just adding one function ddd in table36 result is:
//Unsupported feature: Property Modification (Attributes) on "InitInsert(PROCEDURE 61)".

//Unsupported feature: Property Modification (Attributes) on "InitRecord(PROCEDURE 10)".

//Unsupported feature: Property Modification (Attributes) on "AssistEdit(PROCEDURE 1)".

//Unsupported feature: Property Modification (Attributes) on "TestNoSeries(PROCEDURE 6)".

//Unsupported feature: Property Modification (Attributes) on "GetNoSeriesCode(PROCEDURE 9)".

//Unsupported feature: Property Modification (Attributes) on "ConfirmDeletion(PROCEDURE 11)".

//Unsupported feature: Property Modification (Attributes) on "SalesLinesExist(PROCEDURE 3)".

//Unsupported feature: Property Modification (Attributes) on "MessageIfSalesLinesExist(PROCEDURE 5)".

//Unsupported feature: Property Modification (Attributes) on "PriceMessageIfSalesLinesExist(PROCEDURE 7)".

//Unsupported feature: Property Modification (Attributes) on "UpdateCurrencyFactor(PROCEDURE 12)".

//Unsupported feature: Property Modification (Attributes) on "SetHideValidationDialog(PROCEDURE 14)".

//Unsupported feature: Property Modification (Attributes) on "GetHideValidationDialog(PROCEDURE 123)".

//Unsupported feature: Property Modification (Attributes) on "UpdateSalesLines(PROCEDURE 15)".

//Unsupported feature: Property Modification (Attributes) on "UpdateSalesLinesByFieldNo(PROCEDURE 154)".

//Unsupported feature: Property Modification (Attributes) on "CreateDim(PROCEDURE 16)".

//Unsupported feature: Property Modification (Attributes) on "ValidateShortcutDimCode(PROCEDURE 19)".

//Unsupported feature: Property Modification (Attributes) on "CheckCustomerCreated(PROCEDURE 18)".

//Unsupported feature: Property Modification (Attributes) on "CheckCreditMaxBeforeInsert(PROCEDURE 28)".

//Unsupported feature: Property Modification (Attributes) on "CreateInvtPutAwayPick(PROCEDURE 29)".

//Unsupported feature: Property Modification (Attributes) on "CreateTask(PROCEDURE 30)".

//Unsupported feature: Property Modification (Attributes) on "UpdateShipToAddress(PROCEDURE 31)".

//Unsupported feature: Property Modification (Attributes) on "ShowDocDim(PROCEDURE 32)".

//Unsupported feature: Property Modification (Attributes) on "UpdateAllLineDim(PROCEDURE 34)".

//Unsupported feature: Property Modification (Attributes) on "LookupAdjmtValueEntries(PROCEDURE 37)".

//Unsupported feature: Property Modification (Attributes) on "GetCustomerVATRegistrationNumber(PROCEDURE 63)".

//Unsupported feature: Property Modification (Attributes) on "GetCustomerVATRegistrationNumberLbl(PROCEDURE 62)".

//Unsupported feature: Property Modification (Attributes) on "GetCustomerGlobalLocationNumber(PROCEDURE 164)".

//Unsupported feature: Property Modification (Attributes) on "GetCustomerGlobalLocationNumberLbl(PROCEDURE 161)".

//Unsupported feature: Property Modification (Attributes) on "GetPstdDocLinesToRevere(PROCEDURE 39)".

//Unsupported feature: Property Modification (Attributes) on "CalcInvDiscForHeader(PROCEDURE 45)".

//Unsupported feature: Property Modification (Attributes) on "SetSecurityFilterOnRespCenter(PROCEDURE 43)".

//Unsupported feature: Property Modification (Attributes) on "InventoryPickConflict(PROCEDURE 46)".

//Unsupported feature: Property Modification (Attributes) on "WhseShpmntConflict(PROCEDURE 52)".

//Unsupported feature: Property Modification (Attributes) on "CheckItemAvailabilityInLines(PROCEDURE 142)".

//Unsupported feature: Property Modification (Attributes) on "QtyToShipIsZero(PROCEDURE 49)".

//Unsupported feature: Property Modification (Attributes) on "IsApprovedForPosting(PROCEDURE 53)".

//Unsupported feature: Property Modification (Attributes) on "IsApprovedForPostingBatch(PROCEDURE 54)".

//Unsupported feature: Property Modification (Attributes) on "GetLegalStatement(PROCEDURE 60)".

//Unsupported feature: Property Modification (Attributes) on "SendToPosting(PROCEDURE 57)".

//Unsupported feature: Property Modification (Attributes) on "CancelBackgroundPosting(PROCEDURE 48)".

//Unsupported feature: Property Modification (Attributes) on "EmailRecords(PROCEDURE 135)".

//Unsupported feature: Property Modification (Attributes) on "GetDocTypeTxt(PROCEDURE 140)".

//Unsupported feature: Property Modification (Attributes) on "LinkSalesDocWithOpportunity(PROCEDURE 79)".

//Unsupported feature: Property Modification (Attributes) on "SynchronizeAsmHeader(PROCEDURE 56)".

//Unsupported feature: Property Modification (Attributes) on "CheckShippingAdvice(PROCEDURE 55)".

//Unsupported feature: Property Modification (Attributes) on "TryGetFilterCustNoRange(PROCEDURE 128)".

//Unsupported feature: Property Modification (Attributes) on "InvoicedLineExists(PROCEDURE 156)".

//Unsupported feature: Property Modification (Attributes) on "CreateDimSetForPrepmtAccDefaultDim(PROCEDURE 73)".

//Unsupported feature: Property Modification (Attributes) on "OpenSalesOrderStatistics(PROCEDURE 70)".

//Unsupported feature: Property Modification (Attributes) on "GetCardpageID(PROCEDURE 58)".

//Unsupported feature: Property Modification (Attributes) on "CheckAvailableCreditLimit(PROCEDURE 67)".

//Unsupported feature: Property Modification (Attributes) on "SetStatus(PROCEDURE 99)".

//Unsupported feature: Property Modification (Attributes) on "OnCheckSalesPostRestrictions(PROCEDURE 115)".

//Unsupported feature: Property Modification (Attributes) on "OnCustomerCreditLimitExceeded(PROCEDURE 74)".

//Unsupported feature: Property Modification (Attributes) on "OnCustomerCreditLimitNotExceeded(PROCEDURE 76)".

//Unsupported feature: Property Modification (Attributes) on "OnCheckSalesReleaseRestrictions(PROCEDURE 81)".

//Unsupported feature: Property Modification (Attributes) on "CheckSalesReleaseRestrictions(PROCEDURE 162)".

//Unsupported feature: Property Modification (Attributes) on "DeferralHeadersExist(PROCEDURE 82)".

//Unsupported feature: Property Modification (Attributes) on "SetSellToCustomerFromFilter(PROCEDURE 186)".

//Unsupported feature: Property Modification (Attributes) on "CopySellToCustomerFilter(PROCEDURE 44)".

//Unsupported feature: Property Modification (Attributes) on "BatchConfirmUpdateDeferralDate(PROCEDURE 130)".

//Unsupported feature: Property Modification (Attributes) on "GetSelectedPaymentServicesText(PROCEDURE 84)".

//Unsupported feature: Property Modification (Attributes) on "SetDefaultPaymentServices(PROCEDURE 86)".

//Unsupported feature: Property Modification (Attributes) on "ChangePaymentServiceSetting(PROCEDURE 87)".

//Unsupported feature: Property Modification (Attributes) on "IsCreditDocType(PROCEDURE 110)".

//Unsupported feature: Property Modification (Attributes) on "HasSellToAddress(PROCEDURE 94)".

//Unsupported feature: Property Modification (Attributes) on "HasShipToAddress(PROCEDURE 103)".

//Unsupported feature: Property Modification (Attributes) on "HasBillToAddress(PROCEDURE 95)".

//Unsupported feature: Property Modification (Attributes) on "SetShipToAddress(PROCEDURE 117)".

//Unsupported feature: Property Modification (Attributes) on "ShipToAddressEqualsSellToAddress(PROCEDURE 111)".

//Unsupported feature: Property Modification (Attributes) on "CopySellToAddressToShipToAddress(PROCEDURE 112)".

//Unsupported feature: Property Modification (Attributes) on "CopySellToAddressToBillToAddress(PROCEDURE 92)".

//Unsupported feature: Property Modification (Attributes) on "ConfirmCloseUnposted(PROCEDURE 104)".

//Unsupported feature: Property Modification (Attributes) on "InitFromSalesHeader(PROCEDURE 109)".

//Unsupported feature: Property Modification (Attributes) on "SetWorkDescription(PROCEDURE 120)".

//Unsupported feature: Property Modification (Attributes) on "GetWorkDescription(PROCEDURE 114)".

//Unsupported feature: Property Modification (Attributes) on "GetWorkDescriptionWorkDescriptionCalculated(PROCEDURE 160)".

//Unsupported feature: Property Modification (Attributes) on "SetAllowSelectNoSeries(PROCEDURE 100)".

//Unsupported feature: Property Modification (Attributes) on "SelltoCustomerNoOnAfterValidate(PROCEDURE 125)".

//Unsupported feature: Property Modification (Attributes) on "SelectSalesHeaderCustomerTemplate(PROCEDURE 127)".

//Unsupported feature: Property Modification (Attributes) on "RecallModifyAddressNotification(PROCEDURE 148)".

//Unsupported feature: Property Modification (Attributes) on "GetModifyCustomerAddressNotificationId(PROCEDURE 193)".

//Unsupported feature: Property Modification (Attributes) on "GetModifyBillToCustomerAddressNotificationId(PROCEDURE 191)".

//Unsupported feature: Property Modification (Attributes) on "SetModifyCustomerAddressNotificationDefaultState(PROCEDURE 89)".

//Unsupported feature: Property Modification (Attributes) on "SetModifyBillToCustomerAddressNotificationDefaultState(PROCEDURE 91)".

//Unsupported feature: Property Modification (Attributes) on "DontNotifyCurrentUserAgain(PROCEDURE 141)".

//Unsupported feature: Property Modification (Attributes) on "HasDifferentSellToAddress(PROCEDURE 195)".

//Unsupported feature: Property Modification (Attributes) on "HasDifferentBillToAddress(PROCEDURE 192)".

//Unsupported feature: Property Modification (Attributes) on "HasDifferentShipToAddress(PROCEDURE 1059)".

//Unsupported feature: Property Modification (Attributes) on "ShowInteractionLogEntries(PROCEDURE 131)".

//Unsupported feature: Property Modification (Attributes) on "GetBillToNo(PROCEDURE 132)".

//Unsupported feature: Property Modification (Attributes) on "GetCurrencySymbol(PROCEDURE 146)".

//Unsupported feature: Property Modification (Attributes) on "ValidateSalesPersonOnSalesHeader(PROCEDURE 218)".

//Unsupported feature: Property Modification (Attributes) on "TestQuantityShippedField(PROCEDURE 190)".

//Unsupported feature: Property Modification (Attributes) on "TestStatusOpen(PROCEDURE 134)".

//Unsupported feature: Property Modification (Attributes) on "SuspendStatusCheck(PROCEDURE 133)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterInitRecord(PROCEDURE 21)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterInitNoSeries(PROCEDURE 35)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterCheckCreditLimitCondition(PROCEDURE 290)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterConfirmSalesPrice(PROCEDURE 183)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterRecreateSalesLine(PROCEDURE 152)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterDeleteAllTempSalesLines(PROCEDURE 155)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterInsertTempSalesLine(PROCEDURE 158)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterGetNoSeriesCode(PROCEDURE 166)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterGetPostingNoSeriesCode(PROCEDURE 175)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterGetPrepaymentPostingNoSeriesCode(PROCEDURE 178)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterTestNoSeries(PROCEDURE 136)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterUpdateShipToAddress(PROCEDURE 137)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterUpdateCurrencyFactor(PROCEDURE 180)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterAppliesToDocNoOnLookup(PROCEDURE 163)".

//Unsupported feature: Property Modification (Attributes) on "OnUpdateSalesLineByChangedFieldName(PROCEDURE 139)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterCreateDimTableIDs(PROCEDURE 138)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterValidateShortcutDimCode(PROCEDURE 176)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterCreateSalesLine(PROCEDURE 147)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterSalesQuoteAccepted(PROCEDURE 143)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterChangePricesIncludingVAT(PROCEDURE 187)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterSendSalesHeader(PROCEDURE 144)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterSetFieldsBilltoCustomer(PROCEDURE 151)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterTransferExtendedTextForSalesLineRecreation(PROCEDURE 145)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterCopyFromSellToCustTemplate(PROCEDURE 184)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterCopySellToAddressToShipToAddress(PROCEDURE 198)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterCopySellToAddressToBillToAddress(PROCEDURE 200)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterCopySellToCustomerAddressFieldsFromCustomer(PROCEDURE 177)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterCopyShipToCustomerAddressFieldsFromCustomer(PROCEDURE 173)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterCopyShipToCustomerAddressFieldsFromShipToAddr(PROCEDURE 174)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeCheckCreditLimit(PROCEDURE 196)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeGetNoSeriesCode(PROCEDURE 309)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeGetPostingNoSeriesCode(PROCEDURE 212)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeInitInsert(PROCEDURE 208)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeInitRecord(PROCEDURE 210)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeUpdateCurrencyFactor(PROCEDURE 153)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeRecreateSalesLines(PROCEDURE 197)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeSalesLineByChangedFieldNo(PROCEDURE 168)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeSalesLineInsert(PROCEDURE 169)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeTestNoSeries(PROCEDURE 213)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeSetSecurityFilterOnRespCenter(PROCEDURE 207)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeUpdateSalesLinesByFieldNo(PROCEDURE 303)".

//Unsupported feature: Property Modification (Attributes) on "OnCopySelltoCustomerAddressFieldsFromCustomerOnAfterAssignRespCenter(PROCEDURE 182)".

//Unsupported feature: Property Modification (Attributes) on "OnCreateSalesLineOnAfterAssignType(PROCEDURE 185)".

//Unsupported feature: Property Modification (Attributes) on "OnInitInsertOnBeforeInitRecord(PROCEDURE 179)".

//Unsupported feature: Property Modification (Attributes) on "OnUpdateBillToCustOnAfterSalesQuote(PROCEDURE 188)".

//Unsupported feature: Property Modification (Attributes) on "OnValidateBilltoCustomerTemplateCodeBeforeRecreateSalesLines(PROCEDURE 171)".

//Unsupported feature: Property Modification (Attributes) on "OnValidateSellToCustomerNoAfterInit(PROCEDURE 206)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterTestQuantityShippedField(PROCEDURE 189)".

//Unsupported feature: Property Modification (Attributes) on "OnBeforeTestStatusOpen(PROCEDURE 202)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterTestStatusOpen(PROCEDURE 201)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterUpdateBillToCont(PROCEDURE 199)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterUpdateSellToCont(PROCEDURE 203)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterUpdateSellToCust(PROCEDURE 204)".

//Unsupported feature: Property Modification (Attributes) on "OnAfterUpdateSalesLines(PROCEDURE 205)".

//Unsupported feature: Property Modification (Attributes) on "OnRecreateSalesLinesOnBeforeConfirm(PROCEDURE 211)".

//Unsupported feature: Property Modification (Attributes) on "OnValidatePricesIncludingVATOnBeforeSalesLineModify(PROCEDURE 214)".

//Unsupported feature: Property Modification (Attributes) on "OnValidateShippingAgentCodeOnBeforeUpdateLines(PROCEDURE 215)".

local procedure dddd()
begin
end;

Hi @Pieterheinevdm, did you also re-generated the delta files using the command Compare-NAVApplicationObject? The fix was made there in order to ignore the attribute LineStart.

I use this as a workaround:
`$Regex = "(    .LineStart.([0-9]+)..)"
$Location = "C:\pathtoyourfiles"
$Files = Get-ChildItem $Location
foreach($file in $Files)
{
$Content = Get-Content $file.FullName
$Content = $Content -replace $Regex,''
$Content | Out-File $file.FullName -Force
}
`

Hi @Pieterheinevdm, did you also re-generated the delta files using the command Compare-NAVApplicationObject? The fix was made there in order to ignore the attribute LineStart.

Yes I am using the Compare-NAVApplicationObject  (build14.0.29530)
$result = Compare-NAVApplicationObject -OriginalPath ($originalFolder.FullName + '*.txt') -ModifiedPath ($modifiedFolder.FullName + '*.txt') -DeltaPath $AppFilesFolder -NoCodeCompression -Force -ExportToNewSyntax

Regex
Thank you ik3ras,
this workaround script is working, I have changed your script a little bit to support special chars:
$Content | Out-File $file.FullName -Force -Encoding default

@Pieterheinevdm are you still able to reproduce this issue using the latest developer previews from the 14.x branch?

?this issue is 6 months old, our company could wait that long so we implemented a workaround. The steps to reproduce are simple, could you run a test your self?

This issue has been closed because it needs more information and has not had recent activity. Please open a new issue if you believe this has not been resolved and reference the current issue.


perf: don't manipulate empty entries

This PR prevents manipulation of empty entries (arrays, strings, etc) which have no point except increasing execution time.

Oops, I totally forgot about this 😅
There were a couple more things I wanted to add to this, am I able to make another PR for this?

Of course.


The SSFSL results of ICI may be modified

Hi there,
I am the first author of ICI. Very thanks to add our results in your list. The reported accuracy of SSFSL in your repo uses 80 unlabeled data for each class, which is more than the standard setting and resulting in better performance. This may be unfair for other methods. I recommend to use the results of 30/50 unlabeled data, which is most widely setting used in other SSFSL methods. Please see our paper for more details.
Besides, now we have an improved version of ICI with better performance. You may add it in your list. Please note that it is now only a arxiv preprint.

Thanks for reporting the results.
I've updated the results in our repository.
You may also directly create a pull request to update the scores.


"Runtime.ImportModuleError: Error: Cannot find module '@libsql/linux-x64-gnu" when bundling with esbuild for aws lambda

I was switching my database from planetscale to turso but I'm getting the following error
 {
  "errorType": "Runtime.ImportModuleError",
  "errorMessage": "Error: Cannot find module '@libsql/linux-x64-gnu'\nRequire stack:\n- /var/task/index.js\n- /var/runtime/index.mjs",
  "trace": [
    "Runtime.ImportModuleError: Error: Cannot find module '@libsql/linux-x64-gnu'",
    "Require stack:",
    "- /var/task/index.js",
    "- /var/runtime/index.mjs",
    "    at _loadUserApp (file:///var/runtime/index.mjs:1061:17)",
    "    at async UserFunction.js.module.exports.load (file:///var/runtime/index.mjs:1093:21)",
    "    at async start (file:///var/runtime/index.mjs:1256:23)",
    "    at async file:///var/runtime/index.mjs:1262:1"
  ]
}

I use the aws cdk to build and deploy my aws lambda function internally it uses esbuild here is a simple reproduction step
the aws lambda function code
/nodejs/index.ts
import { drizzle } from 'drizzle-orm/libsql';
import { createClient } from '@libsql/client';
const client = createClient({ url: 'DATABASE_URL', authToken: 'DATABASE_AUTH_TOKEN' });

const db = drizzle(client);

export const handler = async (event) => {
  console.log('event', event);
}

the aws cdk code to deploy the function:
import {Construct} from 'constructs';
import {NodejsFunction} from 'aws-cdk-lib/aws-lambda-nodejs';
import {Architecture, Runtime} from 'aws-cdk-lib/aws-lambda';

export class SendUserToDynamo extends Construct {
  function: NodejsFunction;
  constructor(scope: Construct, id: string) {
    super(scope, id);

    // lambda function that triggers on aws lambda user created event
    this.function = new NodejsFunction(this, 'sendUserToDynamo', {
      entry: __dirname + '/nodejs/index.ts',
      handler: 'handler',
      architecture: Architecture.X86_64,
      runtime: Runtime.NODEJS_18_X,
    });
  }
}

Everything works when I'm using the PlanetScale driver, so the error must come from libsql and not the CDK build step. I tried using a Dockerfile without TypeScript and ESBuild, and it did work

Similar error happens when deploying to vercel. Any advice?

same here
and confirmed downgrading to 0.3.2 fixed it

0.3.3 also works

bump

Confirming I'm seeing this too, also switching from Planetscale to Turso.
Interestingly the error doesn't happen in local env, only when deployed to Netlify. Running node 16.
Pulling @libsql/client down to 0.3.2 from 0.5.3 fixed things for me.

Ran into this too and got it working with 0.3.3.

Having the same issue, but I'm on Windows 11 and getting:
Cannot find module '@libsql/win32-x64-msvc'

Works with 0.3.3 for now, though.

I'm experiencing this on an arm lambda: https://github.com/tursodatabase/libsql-js/issues/70

Downgrading to 0.3.3 just results in "Cannot find module '@libsql/linux-arm64-gnu'"" too, no change

I ended up using the web/HTTP client to be able to run the latest version:
import { createClient } from '@libsql/client/web';

it does say in the docs that you should use it for vercel functions and the like. the docs could be a bit clearer here. nothing mentions what to use for lambda

Just wanted to chime in that I also ran into this exact same issue deploying to AWS Lambda using Architect and on version 0.6.0 of @libsql/client.  Including that it all worked fine locally.  (using the Architect's sandbox mode for local dev)
The suggestion to use web worked for me.  👍

The same problem here using versions 0.5.x and 0.6.x with Deno Deploy with NPM comparability layer. I tried to use it with esm.sh but I didn't have any success.

If you want to use the native client that uses the libsql binary under the hood in Lambda, you'll have to build the function in a similar arch/environment or use a Lambda layer, also built under the same conditions (i.e. Docker).
A bundler like esbuild won't be able to include the correct version (i.e. @libsql-linux-arm64-gnu) unless it's itself running on that same hardware.
This worked for me:
import { Stack, type StackProps, CfnOutput } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import { Architecture, Code, LayerVersion, Runtime } from 'aws-cdk-lib/aws-lambda';
import { NodejsFunction, OutputFormat } from 'aws-cdk-lib/aws-lambda-nodejs';

export class LibsqlStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const libsqlLayer = new LayerVersion(this, 'LibsqlLayer', {
      compatibleArchitectures: [Architecture.ARM_64],
      compatibleRuntimes: [Runtime.NODEJS_20_X],
      code: Code.fromAsset('./layers/libsql/nodejs', {
        bundling: {
          image: Runtime.NODEJS_20_X.bundlingImage,
          environment: {
            npm_config_cache: "/tmp/npm_cache",
            npm_config_update_notifier: "false",
          },
          command: [
            'bash',
            '-xc',
            [
              'cd $(mktemp -d)',
              'cp /asset-input/package* .',
              'npm ci',
              'cp -r node_modules /asset-output/'
            ].join(' && '),
          ]
        }
      }),
    });

    const fn = new NodejsFunction(this, 'MyFunction', {
      runtime: Runtime.NODEJS_20_X,
      architecture: Architecture.ARM_64,
      entry: './src/index.ts',
      handler: 'handler',
      bundling: {
        minify: true,
        mainFields: ['module', 'main'],
        sourceMap: true,
        format: OutputFormat.ESM,
        externalModules: ['@libsql/client'],
      },
      layers: [libsqlLayer],
    });

    new CfnOutput(this, 'FunctionArn', {
      value: fn.functionArn,
    });
  }
}

then in my function I use @libsql/client as normal:
import { Logger } from "@aws-lambda-powertools/logger";
import { createClient } from "@libsql/client";

const logger = new Logger();
const db = createClient({
  url: "file:/tmp/sqlite.db",
});

export const handler = async () => {

  await db.execute("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)");

  await db.execute({ sql: "INSERT INTO users (name) VALUES (?)", args:  ["Alice"]});

  const rows = await db.execute("SELECT * FROM users");

  logger.info("Rows: ", {rows});

  return {
    statusCode: 200,
    body: JSON.stringify("Hello, World!"),
  };
};

which when invoked prints this:
{
    "level": "INFO",
    "message": "Rows: ",
    "sampling_rate": 0,
    "service": "service_undefined",
    "timestamp": "2024-06-27T18:14:43.388Z",
    "xray_trace_id": "1-667dac12-2624c2867735f80f34586f58",
    "rows": {
        "columns": [
            "id",
            "name"
        ],
        "columnTypes": [
            "INTEGER",
            "TEXT"
        ],
        "rows": [
            [
                1,
                "Alice"
            ]
        ],
        "rowsAffected": 0,
        "lastInsertRowid": null
    }
}

The advantage of using a Lambda layer like that is that you can still continue using esbuild for the function(s) - the only caveat there is to make sure to specify externalModules: ['@libsql/client'], so that the dependency is not included in the bundle - this is because it comes from the Layer.

If you want to use the native client that uses the libsql binary under the hood in Lambda, you'll have to build the function in a similar arch/environment or use a Lambda layer, also built under the same conditions (i.e. Docker).
A bundler like esbuild won't be able to include the correct version (i.e. @libsql-linux-arm64-gnu) unless it's itself running on that same hardware.
This worked for me:
import { Stack, type StackProps, CfnOutput } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import { Architecture, Code, LayerVersion, Runtime } from 'aws-cdk-lib/aws-lambda';
import { NodejsFunction, OutputFormat } from 'aws-cdk-lib/aws-lambda-nodejs';

export class LibsqlStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const libsqlLayer = new LayerVersion(this, 'LibsqlLayer', {
      compatibleArchitectures: [Architecture.ARM_64],
      compatibleRuntimes: [Runtime.NODEJS_20_X],
      code: Code.fromAsset('./layers/libsql/nodejs', {
        bundling: {
          image: Runtime.NODEJS_20_X.bundlingImage,
          environment: {
            npm_config_cache: "/tmp/npm_cache",
            npm_config_update_notifier: "false",
          },
          command: [
            'bash',
            '-xc',
            [
              'cd $(mktemp -d)',
              'cp /asset-input/package* .',
              'npm --prefix . i @libsql/client',
              'cp -r node_modules /asset-output/'
            ].join(' && '),
          ]
        }
      }),
    });

    const fn = new NodejsFunction(this, 'MyFunction', {
      runtime: Runtime.NODEJS_20_X,
      architecture: Architecture.ARM_64,
      entry: './src/index.ts',
      handler: 'handler',
      bundling: {
        minify: true,
        mainFields: ['module', 'main'],
        sourceMap: true,
        format: OutputFormat.ESM,
        externalModules: ['@libsql/client'],
      },
      layers: [libsqlLayer],
    });

    new CfnOutput(this, 'FunctionArn', {
      value: fn.functionArn,
    });
  }
}

then in my function I use @libsql/client as normal:
import { Logger } from "@aws-lambda-powertools/logger";
import { createClient } from "@libsql/client";

const logger = new Logger();
const db = createClient({
  url: "file:/tmp/sqlite.db",
});

export const handler = async () => {

  await db.execute("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)");

  await db.execute({ sql: "INSERT INTO users (name) VALUES (?)", args:  ["Alice"]});

  const rows = await db.execute("SELECT * FROM users");

  logger.info("Rows: ", {rows});

  return {
    statusCode: 200,
    body: JSON.stringify("Hello, World!"),
  };
};

which when invoked prints this:
{
    "level": "INFO",
    "message": "Rows: ",
    "sampling_rate": 0,
    "service": "service_undefined",
    "timestamp": "2024-06-27T18:14:43.388Z",
    "xray_trace_id": "1-667dac12-2624c2867735f80f34586f58",
    "rows": {
        "columns": [
            "id",
            "name"
        ],
        "columnTypes": [
            "INTEGER",
            "TEXT"
        ],
        "rows": [
            [
                1,
                "Alice"
            ]
        ],
        "rowsAffected": 0,
        "lastInsertRowid": null
    }
}

The advantage of using a Lambda layer like that is that you can still continue using esbuild for the function(s) - the only caveat there is to make sure to specify externalModules: ['@libsql/client'], so that the dependency is not included in the bundle - this is because it comes from the Layer.

Hey @dreamorosi , thanks for this.
I am currently trying to get this to work with SST Ion that uses Pulumi under the hood, and it seems it won't bundle this automatically as CDK does.
How would I go about bundling this manually? Here you can see what Pulumi offers from an AWS lambda layer standpoint: https://www.pulumi.com/registry/packages/aws/api-docs/lambda/layerversion/#constructor-example
As you can see, there is no option to set the command or the bundling configuration. Same with the Lambda itself, as seen here: https://www.pulumi.com/registry/packages/aws/api-docs/lambda/function/#constructor-example

I was able to solve this by adding the @libsql/client as a nodejs dependency which allows SST to do an NPM install of them in the function bundle:
import { usersTable } from "./database";
import { TursoAuthToken, TursoDatabaseUrl } from "./database";

export const api = new sst.aws.Function("Api", {
  url: true,
  link: [usersTable, TursoAuthToken, TursoDatabaseUrl],
  handler: "./packages/functions/api/index.handler",
  architecture: "arm64",
  nodejs: {
    install: ["@libsql/client"]
  }
});

I ended up using the web/HTTP client to be able to run the latest version:
import { createClient } from '@libsql/client/web';

this works

I ended up using the web/HTTP client to be able to run the latest version:
import { createClient } from '@libsql/client/web';

this works

This worked for me too! Thanks!

fyi this is still an active issue. @libsql/client/web is also not a feasible workaround as it doesn't support embedded replicas.


chore(main): release 1.3.8

:robot: I have created a release beep boop
1.3.8 (2024-07-07)
Bug Fixes

update npm yml 7 (3f6638a)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.3.8
:sunflower:


Create Notification for New Resale Listing

Currently we do not notify the user when a resale listing is created.  We want to notify when it is created and deleted for awareness to the user.

Done


Add chat to rn storybook

@keybase/react-hackers
Just the conversation list into rn story book. Really useful for debugging the chat list perf on android.
After doing this exercise I think it's also useful to have more of these for bigger screens. It makes it much easier to:

Test the state -> ui mapping is what you expect
When changes to the store happen you have screens that prove the state -> ui mapping still works
Test the perf of just the ui.
Be able to work and optimize the ui without internet! (and w/o even using the go code on android)

In a future PR I think I'll change the apk uploader pr thing to use storybook instead so it will be much more useful.

We really should change the store /props that come in. Really not dumb enough

Yeah that's another point for why we should have these holistic screens in story book. Let's us see exactly the kind of data we need to build a screen.


PR #1799 is missing

Hello there,
I previously submitted PR #1799 (added in milestone v3.6) but it seems that it got lost.
The PR was merged into old-dev and I think that it is missing in #2262.
I would create a new one if you want me to. :)

Thank you @hatsuo! It would be really helpful if you're able to open up a new PR- as you probably better remember everything about it that I do. Thanks again


⚠ Community has degraded performance

In a3b1ee7, Community (https://community.wrk.com/health) experienced degraded performance:

HTTP code: 200
Response time: 201 ms

Resolved: Community performance has improved in a895690.


[Application] add validation process of yolo example on pytorch

Add validation process of yolo example using validation dataset on
pytorch.
Signed-off-by: Seungbaek Hong<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #2160. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

We generate a report if there are dangerous coding constructs in your code. Please read http://ci.nnstreamer.ai/nntrainer/ci/repo-workers/pr-checker/2160-202303301526290.93005704879761-1855e0098817139b8b5d4742a74455b2f2edec0a/report/pylint_result.txt.


Db update

Cool. couple of issues before merging:

This is to master -- should be to dev.
For some reason this pr contains the entire commit history. i'm not sure how this happened or what the effect will be on the history if i merge it. can you remake it with just the new commits?


sudo make install doesn't work on ubuntu with GPU enabled

sudo on ubuntu resets the $PATH, so even if you have cuda installed and /usr/local/cuda/bin in your PATH, the makefile can't find nvcc.

Hi rongou,
I don't think it's safe to assume that nvcc will always be in the location /usr/local/cuda/bin/nvcc. You can try to use sudo -E  to preserve the environment variables, or just explicitly include the path in your sudo call.

At least on my system, sudo -E doesn't work. The only way to make it work is do sudo env PATH=$PATH make install. Maybe just need to document this.

Hi @rongou this is actually already documented in our FAQ: http://neon.nervanasys.com/docs/latest/faq.html#installation  (see the last bullet point under installation)


Add diagramming feature via Mermaid (see Hugo Learn Theme for reference)

The Hugo Learn Theme has Mermaid-based diagramming by default. This would be a valuable addition to Cupper and should be relatively easy to port from that theme.
(Also, see the Typora editor app – which also uses Mermaid internally – for a possible front-end for authoring and rapidly prototyping documentation with diagrams in Markdown for Cupper.)
Reference: https://learn.netlify.com/en/
Source: https://github.com/matcornic/hugo-theme-learn

The problem is that the Mermaid diagrams are not very accessible with a screen reader. The alt text does not give nearly enough information to be useful. It would be better if the code was the alt text, as it's more understandable.
The diagrams need some work before they could be considered inclusive for screen reader users.


Wellbeing Template: Use correct font weight for Source Serif Pro

Feature Description
In #1616 it was noted that the Wellbeing template cannot currently use the lighter 300 font weight of the Source Serif Pro font because it's not yet available on Google Fonts.
According to https://github.com/google/fonts/issues/23#issuecomment-658175392 this has just changed now!
That means we can now adapt the template to use the correct 300 font weight for Source Serif Pro.
Alternatives Considered

Additional Context

Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance Criteria

Source Serif Pro uses font weight 300 where applicable.

Implementation Brief

FYI @mariano-formidable @pbakaus

nice!

Verified in QA


Don't restore Persistent Volume status from Backup

This PR modifies the restoration logic on the longhorn-manager such that it sets the KubernetesStatus fields PVName and PVStatus to empty string, preventing longhorn-manager from having a Volume that is stuck with a reference to a nonexistent PersistentVolume as described in longhorn/longhorn#638.
The other mitigation described in that issue has been dropped due to the possible fixes requiring either conflicting with the existing logic in the KubernetesController or requiring that the VolumeController also modify the KubernetesStatus and potentially cause conflicts.

LGTM. Wait for the integration test update.


Ideas on improving Crate Validator

Overview
We propose incremental changes to the already existing tools Crate Validator  and cargo risczero test, as well as a revamp on the report UI; This changes seek to remove overlaping functionalities among the tools, and to provide a more user-friendly experience to developers seeking to use the zkVM.
Motivation
Our current Crate Validator tool allow users to check if crates listed in crates.io are compatible with our zkVM, giving them the flexibility to query individual or a list of crates. However, the current tool is not user-friendly and provides no support for selectively enabling/disabling features for the requested crate, nor to run the test against a pre-specified crate version (always checking the latest one).
Also, with the incoming cargo risczero test command, we will have two tools with overlaping functionalities around the building process of specified crates.
Another issue that we would seek to address is an improvement on the current report UI, allowing users to easily identify issues found during crate compilation steps, and to provide more detail around current and previous status for each crate.
In the same topic of report UI, we'd like to provide a more stable version of the report, avoiding situations where the report is not available due to a failure on the build process of a crate. Such an issue occured recently with the parity-scale-codec-derive crate, which was failing to build due to a missing dependency (cargo risczero install) during CI setup, and was causing the report to show all crates as failing to build.
Proposed changes
Taking into account the issues mentioned above, we propose the following changes:
Crate Validator
In order to remove overlaping functionalities between Crate Validator and cargo risczero test, we propose to use Crate Validator as an orchestration tool, which will have the following responsibilities:

Perform selection of crates to check based on user input
Existing build logic present in Crate Validator will be removed, and replaced by a call to cargo risczero test with the appropriate flags.
Data from build and test steps will be exported enabling posterior usage by the report service that will consume it in order to present up-do-date information in a user-friendly way.

One change that we propose to the current Crate Validator is to allow users to specify a Cargo.toml file instead of a custom JSON. By doing this, users can specify their dependencies in the way they're already used to do in normal rust project, giving them the flexibility to specify crate version, patches, features, etc.
cargo risczero test
The cargo risczero test command will be responsible for building and testing the specified crate, will be pretty much unchanged from the current implementation, only needing to be added to a wrapping call inside the Crate Validator.
Report service
One possibility is that we implement a simple REST API that will be responsible for receiving compilation and test results from the Crate Validator and presenting it in a user-friendly way, as demonstrated in the image below.
Maybe we could also provide a way for users to request a report given a specific Cargo.toml definition? This would allow users to offload the compilation and testing process to the report service, and to receive a report with the results.
Proposed initial service UI:

Observations
It's important to note that some of the features here already exists both in the Crates Validator and report; We would do incremental changes to the existing tools, and would not need to start from scratch.
Notable features missing are the usage of Cargo.toml file instead of a custom JSON in the Crate Validator, and the cargo risczero test command, which is still in development and might change before being merged.
With regards to the report service, all the REST API and respective UI would need to be implemented from scratch, but we could reuse the existing report UI as a starting point.

Curious if some of you would have inputs on this matter.
cc/ @mothran  @carterbrett @nategraf @jjtny1

I think thinking about the crate validator as an orchestration tool, and one specifically designed to generate the compatibility reports is the right direction. Having it use cargo risczero build and cargo risczero test internally seems correct to me as well. 👍
I like the idea of generating a standardized output from the core tool e.g. in CSV or JSON format and parsing that in the UI that displays the page. Note that we can make this as simple as uploading the reports to an S3 bucket and serving a static HTML / TS webpage that parses the CSV or JSON report and produces the visuals. With this there is essentially no continually running service overhead, just a batch pipeline and some static resources.
I don't think we should be making an effort to make user-requested reports. Instead, when a user wants to know if a a crate will build for the RISC Zero target, they should simply build it using cargo risczero build. This is much simpler and more direct method for developers, and does not require us to run a service that takes user requests.
Instead I think the tool should focus on periodic reporting, running builds and tests for a list of crates and versions nightly. Users can request new crates, for example crates they wrote, be added to the report and we could accommodate that via pull request or via a Google form. Users can also report crates that don't build with an issue to risc0 and we should provide an issue template for that.
I also don't think using Cargo.toml to configure the crate validator tool is the right approach. The crate validator tool is an orchestration tool, and wraps the cargo build system. It's configuration goes well beyond what cargo is designed to support. For example, we may want to test a matrix of a crate's versions and features and for that we would likely want our own configuration schema. Build profiles are another example of this where we want to encode additional steps required to get a crate to build. Additionally, when we start running unit tests with cargo risczero test we will likely want to add test filters, which is another configuration not present in Cargo.toml
Instead I think we should have a YAML or TOML configuration for the crate validator. Over time we will add more crates and configurations to it to test, and it provides a location for library developers to make their pull requests.
One feature that would be nice to support in the future is to have our build system check the dependency graph for crates with known issues, and especially known workarounds for these issues. This should definitely be included in the crates validator report, and if it is posted to a well known location the build system could fetch it and use the data included. This would greatly increase discoverability of this tool and allow developers to use the known workarounds quicker instead of getting stuck.
Thanks for working on this tool! It's going to be super valuable for developers as people implement more and more complicated applications on top of the zkVM.

Thanks for the feedback, Victor!
I agree with you on all points, but I have some questions:

When you mention the addition of filters for tests, you mean running only specific tests, or tests that match a specific pattern, right?

On the dependency graph check, how are you envisioning it to work? I'd imagine that we'd scan the dependency graph and see if there is any crate that we know won't compile or the ones that need a workaround, but how exactly should we proceed? For the ones that do have a workaround, should we, during compilation apply the workaround automatically (if so, how)? Or should we just warn the user that there is a workaround for that crate and let them decide if they want to apply it or not (also giving instructions on how they should proceed in applying it)?

When you mention the addition of filters for tests, you mean running only specific tests, or tests that match a specific pattern, right?

That's right. By default we should try running all the tests, but I imagine there will be a lot of cases where many of tests either don't work (e.g. they require filesystem access) or are too time consuming (e.g. fuzzing tests with high iteration counts).


Version 0.5.0 breaks numpy

Multiple errors incl
module 'numpy' has no attribute '__version__'

and
ImportError: Something is wrong with the numpy installation. While importing we detected an older version of numpy in ['/.../miniconda2/envs/sunbeam/lib/python3.6/site-packages/numpy']. One method of fixing this is to repeatedly uninstall numpy until none is found, then reinstall this version.

I suspect this is due to duplicated requirements/dependencies between setup.py (pip) and other packages grabbing numpy in their environment.yml (conda) although I'm not sure what the correct workaround is for this...

A workaround (at least for Sunbeam) is to pin to v0.3.4....which already appears to be the case. I guess my local version was behind. Keeping this open for additional testing

I just now made an empty environment and did conda install -c louiejtaylor -c bioconda grabseqs and grabseqs and numpy combo I ended up with (versions 0.5.0 and 1.16.2) seem happy, for what that's worth.

Thanks for looking at this, Jesse! I thought the issue was related to installing numpy via pip and conda, but it worked fine (conda install -c louiejtaylor -c bioconda grabseqs installed the same versions you saw and import numpy threw no errors).
The numpy version installed with Sunbeam is different (1.12.1)--so that might be the source of the problem. I can troubleshoot it later; this is a low-priority problem that will likely only affect me so don't worry about spending more of your valuable time tracking it down!


Add ContributingGuidelines.md

The Contributing Guideline documentation will contain set of guidelines that will help contributors during the contribution process.
File type markdown.

@purnima143 Could you please assign this issue to me under GSSOC ' 23.
I would like to work on it.
Thank you!

What exctly do you want to the contribution guideline that's not present in the one we have currently?


MM-26749 Fix race condition when open from PN

Summary
Currently there is a race condition when loading the channel from the push notification finishes before loading the channel screen and so because the EphemeralStore flag for startFromNotification  is set to false before it reaches the  loadChannels methods we are switching back to the "last" channel you were in.
This was happening for both Android and iOS and reproducing is not consistent hence the race condition.
Happened on:

Opening the app from cold start
With the app in the background and receiving a notification on different team than the current one visible in the app.

In this PR we set the flag after the channel screen has been loaded instead of doing that at the action level.
Ticket Link
https://mattermost.atlassian.net/browse/MM-26749

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/8057
https://circleci.com/gh/mattermost/mattermost-mobile/8056

Artifact links:
https://8057-70265724-gh.circle-artifacts.com/0/~/mattermost-mobile/Mattermost_Beta.ipa
https://8056-70265724-gh.circle-artifacts.com/0/~/mattermost-mobile/Mattermost_Beta.apk

@josephbaylon give it another try...

Additional info: At least on my device, the issue happens more frequently when

User B opens a DM of User C (not public/private channel) then close app
User A sends User B message
User B taps on notification

Observed: User B lands on User C DM instead of User A DM.

@josephbaylon I can't reproduce tried the following about 10 times

Additional info: At least on my device, the issue happens more frequently when

User B opens a DM of User C (not public/private channel) then close app
User A sends User B message (either directly or from a public/private channel)
User B taps on notification

Going to build the Android app manually for you to try

Actually, let me try it on a slower device first

Ok tried on 3 different Android devices and I'm not seeing it

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/8119
https://circleci.com/gh/mattermost/mattermost-mobile/8117

Artifact links:
https://8119-70265724-gh.circle-artifacts.com/0/~/mattermost-mobile/Mattermost_Beta.ipa
https://8117-70265724-gh.circle-artifacts.com/0/~/mattermost-mobile/Mattermost_Beta.apk


UPM: Upgrading shaders for Universal Render Pipeline does not persist

Describe the bug
When MRTK is installed via UPM upgrading the MRTK Standard shader for Universal RP will only update materials for the current sessoin. Once Unity is restarted the shader/materials are back to the legacy mode.
To reproduce

Import MRTK via UPM
Upgrade shaders/materials
Restart Unity
Materials are not working with URP again

Expected behavior
The upgrade persists.
Your setup (please complete the following information)

Unity 2019.4 LTS
MRTK 2.5
Import via UPM

Got it too!

Ahh @Cameron-Micka, does this step edit the shader file directly?
@davidkline-ms might be another asset we'll need to import into the Assets folder.

@keveleigh yes it does! It changes two lines in the shader: https://github.com/microsoft/MixedRealityToolkit-Unity/blob/06a06778e38da622b37cc299a93f16e143b7bdeb/Assets/MRTK/Core/Inspectors/MixedRealityStandardShaderGUI.cs#L781

@keveleigh @Cameron-Micka thanks for the info.
I would love to not require importing unless the customer needs to update to URP. Any thoughts on how to do that given the constraints of UPM?

fixed with #8804


fix large images

i managed to compress readme images and saved them locally in the repo . #4

Hi @sakethpathike  Could you please review the changes ?

@MostafaMohamed2002, thank you! The issue you were referring to was related to the old README file. I forgot to close it, lol.


fix: ignore tonic to resolve advisories

Problem
check-rust-style fails because tonic version too old, this does not seem to be an easy fix, so ignore it from the deny list.
Summary of changes
Checklist before requesting a review

[x] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.
[ ] Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
[ ] If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

[ ] Do not forget to reformat commit message to not include the above checklist

follow up: https://github.com/neondatabase/neon/issues/9231


traefik v2 "standalone" + docker provider = can't communicate

Do you want to request a feature or report a bug?

Bug

What did you do?

I've installed traefik v2.2 as a standalone application (macOS, with brew).
I've configured 2 providers : docker (to be used as dynamic) and file (just to give access to dashboard).
I have a running docker service (via docker-compose) with the appropriate labels (an official swagger-editor image).
What did you expect to see?
I expect to access to dashboard.
I expect to access to my docker service.
I expect traefik to communicate with docker without be in a docker container.
I don't expect to have to run traefik as a docker container to be able to communicate with docker containers.
What did you see instead?
TL;DR: traefik works well in a full docker environment, but it didn't if is living outside it.
I got access to dashboard
I can't access to my docker service: got a Bad Gateway
In dashboard: #/http/services/traefik-swagger-editor@docker

the Server URL is almost correct: the IP of the container is OK, but the exposed port (there is only one) is not correctly detected (80 wherease it's a 8080 for this image)

So I forced it myself with the label traefik.http.services.<myservice>.loadbalancer.server.port=<correct_port>
Unfortunately it still doesn't work.
Then I disabled the standalone traefik, and use it as a container in my docker.
It works.
Below all the informations needed.
Thanks,
Regards.
Output of traefik version: (What version of Traefik are you using?)

Version:      2.2.0
Codename:     cheddar
Go version:   go1.14
Built:        I don't remember exactly
OS/Arch:      darwin/amd64

brew info traefik
traefik: stable 2.2.0 (bottled), HEAD
Modern reverse proxy
https://traefik.io/
/usr/local/Cellar/traefik/2.2.0 (7 files, 74.4MB) *
  Poured from bottle on 2020-04-04 at 19:49:12
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/traefik.rb
==> Dependencies
Build: go ✘, go-bindata ✘
==> Options
--HEAD
	Install HEAD version
==> Caveats
To have launchd start traefik now and restart at login:
  brew services start traefik
Or, if you don't want/need a background service you can just run:
  traefik
==> Analytics
install: 290 (30 days), 916 (90 days), 3,503 (365 days)
install-on-request: 287 (30 days), 910 (90 days), 3,491 (365 days)
build-error: 0 (30 days)

What is your environment & configuration (arguments, toml, provider, platform, ...)?
macOS Catalina 10.15.4
Docker Desktop <IP_ADDRESS>
Docker 19.03.8
/usr/local/etc/traefik/traefik.toml
# https://github.com/containous/traefik/blob/v2.2/traefik.sample.toml
[global]
  checkNewVersion = true
  sendAnonymousUsage = true
[entryPoints]
  [entryPoints.web]
    address = ":80"

  [entryPoints.websecure]
    address = ":443"
[log]
  level = "DEBUG"
[accessLog]
  filePath = "/usr/local/var/log/traefik.log"

[api]
  insecure = true
  dashboard = true

[ping]

[providers.docker]
  defaultRule = "Host(`{{ normalize .Name }}.localhost`)"
  exposedByDefault = true

[providers.file]
  directory = "/Users/florianlevis/.config/traefik.d/"

/Users/florianlevis/.config/traefik.d/dashboard.toml content below:
[http.routers.dashboard]
   rule = "Host(`traefik.localhost`)"
   service = "api@internal"

docker-compose.yml
version: '3'
services:
    swagger:
        image: swaggerapi/swagger-editor
        labels:
          - traefik.http.routers.swagger.rule=Host(`swagger-editor.localhost`)
          - traefik.http.routers.swagger.entrypoints=web
          - traefik.http.services.swagger.loadbalancer.server.port=8080

If applicable, please paste the log output in DEBUG level (--log.level=DEBUG switch)
Logs before adding label to force the port:
time="2020-04-05T00:26:12+02:00" level=info msg="Configuration loaded from file: /usr/local/etc/traefik/traefik.toml"
time="2020-04-05T00:26:12+02:00" level=info msg="Traefik version 2.2.0 built on I don't remember exactly"
time="2020-04-05T00:26:12+02:00" level=debug msg="Static configuration loaded {\"global\":{\"checkNewVersion\":true,\"sendAnonymousUsage\":true},\"serversTransport\":{\"maxIdleConnsPerHost\":200},\"entryPoints\":{\"traefik\":{\"address\":\":8080\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":10000000000},\"respondingTimeouts\":{\"idleTimeout\":180000000000}},\"forwardedHeaders\":{},\"http\":{}},\"web\":{\"address\":\":80\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":10000000000},\"respondingTimeouts\":{\"idleTimeout\":180000000000}},\"forwardedHeaders\":{},\"http\":{}},\"websecure\":{\"address\":\":443\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":10000000000},\"respondingTimeouts\":{\"idleTimeout\":180000000000}},\"forwardedHeaders\":{},\"http\":{}}},\"providers\":{\"providersThrottleDuration\":2000000000,\"docker\":{\"watch\":true,\"endpoint\":\"unix:///var/run/docker.sock\",\"defaultRule\":\"Host(`{{ normalize .Name }}.localhost`)\",\"exposedByDefault\":true,\"swarmModeRefreshSeconds\":15000000000},\"file\":{\"directory\":\"/Users/florianlevis/.config/traefik.d/\",\"watch\":true}},\"api\":{\"insecure\":true,\"dashboard\":true},\"ping\":{\"entryPoint\":\"traefik\"},\"log\":{\"level\":\"DEBUG\",\"format\":\"common\"},\"accessLog\":{\"filePath\":\"/usr/local/var/log/traefik.log\",\"format\":\"common\",\"filters\":{},\"fields\":{\"defaultMode\":\"keep\",\"headers\":{\"defaultMode\":\"drop\"}}}}"
time="2020-04-05T00:26:12+02:00" level=info msg="Stats collection is enabled."
time="2020-04-05T00:26:12+02:00" level=info msg="Many thanks for contributing to Traefik's improvement by allowing us to receive anonymous information from your configuration."
time="2020-04-05T00:26:12+02:00" level=info msg="Help us improve Traefik by leaving this feature on :)"
time="2020-04-05T00:26:12+02:00" level=info msg="More details on: https://docs.traefik.io/contributing/data-collection/"
time="2020-04-05T00:26:12+02:00" level=debug msg="Start TCP Server" entryPointName=traefik
time="2020-04-05T00:26:12+02:00" level=info msg="Starting provider aggregator.ProviderAggregator {}"
time="2020-04-05T00:26:12+02:00" level=debug msg="Start TCP Server" entryPointName=web
time="2020-04-05T00:26:12+02:00" level=debug msg="Start TCP Server" entryPointName=websecure
time="2020-04-05T00:26:12+02:00" level=info msg="Starting provider *file.Provider {\"directory\":\"/Users/florianlevis/.config/traefik.d/\",\"watch\":true}"
time="2020-04-05T00:26:12+02:00" level=info msg="Starting provider *docker.Provider {\"watch\":true,\"endpoint\":\"unix:///var/run/docker.sock\",\"defaultRule\":\"Host(`{{ normalize .Name }}.localhost`)\",\"exposedByDefault\":true,\"swarmModeRefreshSeconds\":15000000000}"
time="2020-04-05T00:26:12+02:00" level=info msg="Starting provider *traefik.Provider {}"
time="2020-04-05T00:26:12+02:00" level=debug msg="Configuration received from provider file: {\"http\":{\"routers\":{\"dashboard\":{\"service\":\"api@internal\",\"rule\":\"Host(`traefik.localhost`)\"}}},\"tcp\":{},\"udp\":{},\"tls\":{}}" providerName=file
time="2020-04-05T00:26:12+02:00" level=debug msg="No entryPoint defined for this router, using the default one(s) instead: [web websecure]" routerName=dashboard
time="2020-04-05T00:26:12+02:00" level=debug msg="Configuration received from provider internal: {\"http\":{\"routers\":{\"api\":{\"entryPoints\":[\"traefik\"],\"service\":\"api@internal\",\"rule\":\"PathPrefix(`/api`)\",\"priority\":2147483646},\"dashboard\":{\"entryPoints\":[\"traefik\"],\"middlewares\":[\"dashboard_redirect@internal\",\"dashboard_stripprefix@internal\"],\"service\":\"dashboard@internal\",\"rule\":\"PathPrefix(`/`)\",\"priority\":2147483645},\"ping\":{\"entryPoints\":[\"traefik\"],\"service\":\"ping@internal\",\"rule\":\"PathPrefix(`/ping`)\",\"priority\":2147483647}},\"services\":{\"api\":{},\"dashboard\":{},\"noop\":{},\"ping\":{}},\"middlewares\":{\"dashboard_redirect\":{\"redirectRegex\":{\"regex\":\"^(http:\\\\/\\\\/[^:\\\\/]+(:\\\\d+)?)\\\\/$\",\"replacement\":\"${1}/dashboard/\",\"permanent\":true}},\"dashboard_stripprefix\":{\"stripPrefix\":{\"prefixes\":[\"/dashboard/\",\"/dashboard\"]}}}},\"tcp\":{},\"tls\":{}}" providerName=internal
time="2020-04-05T00:26:12+02:00" level=debug msg="Added outgoing tracing middleware api@internal" middlewareType=TracingForwarder entryPointName=web routerName=dashboard@file middlewareName=tracing
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" middlewareName=traefik-internal-recovery middlewareType=Recovery entryPointName=web
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" middlewareName=traefik-internal-recovery middlewareType=Recovery entryPointName=websecure
time="2020-04-05T00:26:12+02:00" level=debug msg="No default certificate, generating one"
time="2020-04-05T00:26:12+02:00" level=debug msg="Provider connection established with docker 19.03.8 (API 1.40)" providerName=docker
time="2020-04-05T00:26:12+02:00" level=debug msg="Configuration received from provider docker: {\"http\":{},\"tcp\":{},\"udp\":{}}" providerName=docker
time="2020-04-05T00:26:12+02:00" level=debug msg="Added outgoing tracing middleware api@internal" routerName=dashboard@file middlewareName=tracing middlewareType=TracingForwarder entryPointName=web
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" entryPointName=web middlewareName=traefik-internal-recovery middlewareType=Recovery
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" middlewareName=traefik-internal-recovery entryPointName=websecure middlewareType=Recovery
time="2020-04-05T00:26:12+02:00" level=debug msg="Added outgoing tracing middleware api@internal" entryPointName=traefik routerName=api@internal middlewareName=tracing middlewareType=TracingForwarder
time="2020-04-05T00:26:12+02:00" level=debug msg="Added outgoing tracing middleware dashboard@internal" routerName=dashboard@internal middlewareName=tracing middlewareType=TracingForwarder entryPointName=traefik
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_stripprefix@internal middlewareType=StripPrefix
time="2020-04-05T00:26:12+02:00" level=debug msg="Adding tracing to middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_stripprefix@internal
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" middlewareType=RedirectRegex entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_redirect@internal
time="2020-04-05T00:26:12+02:00" level=debug msg="Setting up redirection from ^(http:\\/\\/[^:\\/]+(:\\d+)?)\\/$ to ${1}/dashboard/" middlewareName=dashboard_redirect@internal middlewareType=RedirectRegex entryPointName=traefik routerName=dashboard@internal
time="2020-04-05T00:26:12+02:00" level=debug msg="Adding tracing to middleware" routerName=dashboard@internal entryPointName=traefik middlewareName=dashboard_redirect@internal
time="2020-04-05T00:26:12+02:00" level=debug msg="Added outgoing tracing middleware ping@internal" entryPointName=traefik routerName=ping@internal middlewareName=tracing middlewareType=TracingForwarder
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" middlewareName=traefik-internal-recovery middlewareType=Recovery entryPointName=traefik
time="2020-04-05T00:26:12+02:00" level=debug msg="No default certificate, generating one"
time="2020-04-05T00:26:12+02:00" level=debug msg="Added outgoing tracing middleware api@internal" entryPointName=traefik routerName=api@internal middlewareName=tracing middlewareType=TracingForwarder
time="2020-04-05T00:26:12+02:00" level=debug msg="Added outgoing tracing middleware dashboard@internal" entryPointName=traefik routerName=dashboard@internal middlewareName=tracing middlewareType=TracingForwarder
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" entryPointName=traefik routerName=dashboard@internal middlewareType=StripPrefix middlewareName=dashboard_stripprefix@internal
time="2020-04-05T00:26:12+02:00" level=debug msg="Adding tracing to middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_stripprefix@internal
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" middlewareType=RedirectRegex entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_redirect@internal
time="2020-04-05T00:26:12+02:00" level=debug msg="Setting up redirection from ^(http:\\/\\/[^:\\/]+(:\\d+)?)\\/$ to ${1}/dashboard/" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_redirect@internal middlewareType=RedirectRegex
time="2020-04-05T00:26:12+02:00" level=debug msg="Adding tracing to middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_redirect@internal
time="2020-04-05T00:26:12+02:00" level=debug msg="Added outgoing tracing middleware ping@internal" entryPointName=traefik routerName=ping@internal middlewareName=tracing middlewareType=TracingForwarder
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" entryPointName=traefik middlewareName=traefik-internal-recovery middlewareType=Recovery
time="2020-04-05T00:26:12+02:00" level=debug msg="Added outgoing tracing middleware api@internal" entryPointName=web routerName=dashboard@file middlewareName=tracing middlewareType=TracingForwarder
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" entryPointName=web middlewareName=traefik-internal-recovery middlewareType=Recovery
time="2020-04-05T00:26:12+02:00" level=debug msg="Creating middleware" entryPointName=websecure middlewareName=traefik-internal-recovery middlewareType=Recovery
time="2020-04-05T00:26:12+02:00" level=debug msg="No default certificate, generating one"
time="2020-04-05T00:26:31+02:00" level=debug msg="Provider event received {Status:start ID:b4b7b9a5d36fc3773bd64f937ed1c0ad4ca5139edb83517d9590b55804f149bb From:swaggerapi/swagger-editor Type:container Action:start Actor:{ID:b4b7b9a5d36fc3773bd64f937ed1c0ad4ca5139edb83517d9590b55804f149bb Attributes:map[com.docker.compose.config-hash:6415fd0769191070aca928df0940611936f4556081aabea6dcdc0051b8be67b0 com.docker.compose.container-number:1 com.docker.compose.oneoff:False com.docker.compose.project:swagger-editor com.docker.compose.project.config_files:docker-compose.yml com.docker.compose.project.working_dir:/Users/florianlevis/Serveur/0tools/swagger-editor com.docker.compose.service:swagger com.docker.compose.version:1.25.4 image:swaggerapi/swagger-editor maintainer:NGINX Docker Maintainers<EMAIL_ADDRESS>name:swagger-editor_swagger_1 traefik.http.routers.swagger.entrypoints:web traefik.http.routers.swagger.rule:Host(`swagger-editor.localhost`)]} Scope:local Time:1586039191 TimeNano:1586039191177567872}" providerName=docker
time="2020-04-05T00:26:31+02:00" level=debug msg="Configuration received from provider docker: {\"http\":{\"routers\":{\"swagger\":{\"entryPoints\":[\"web\"],\"service\":\"swagger-swagger-editor\",\"rule\":\"Host(`swagger-editor.localhost`)\"}},\"services\":{\"swagger-swagger-editor\":{\"loadBalancer\":{\"servers\":[{\"url\":\"http://<IP_ADDRESS>:80\"}],\"passHostHeader\":true}}}},\"tcp\":{},\"udp\":{}}" providerName=docker
time="2020-04-05T00:26:31+02:00" level=debug msg="Added outgoing tracing middleware api@internal" middlewareType=TracingForwarder entryPointName=web routerName=dashboard@file middlewareName=tracing
time="2020-04-05T00:26:31+02:00" level=debug msg="Creating middleware" middlewareName=pipelining middlewareType=Pipelining entryPointName=web routerName=swagger@docker serviceName=swagger-swagger-editor
time="2020-04-05T00:26:31+02:00" level=debug msg="Creating load-balancer" serviceName=swagger-swagger-editor entryPointName=web routerName=swagger@docker
time="2020-04-05T00:26:31+02:00" level=debug msg="Creating server 0 http://<IP_ADDRESS>:80" routerName=swagger@docker serviceName=swagger-swagger-editor entryPointName=web serverName=0
time="2020-04-05T00:26:31+02:00" level=debug msg="Added outgoing tracing middleware swagger-swagger-editor" entryPointName=web routerName=swagger@docker middlewareName=tracing middlewareType=TracingForwarder
time="2020-04-05T00:26:31+02:00" level=debug msg="Creating middleware" middlewareName=traefik-internal-recovery middlewareType=Recovery entryPointName=web
time="2020-04-05T00:26:31+02:00" level=debug msg="Creating middleware" middlewareName=traefik-internal-recovery middlewareType=Recovery entryPointName=websecure
time="2020-04-05T00:26:31+02:00" level=debug msg="Added outgoing tracing middleware api@internal" entryPointName=traefik routerName=api@internal middlewareName=tracing middlewareType=TracingForwarder
time="2020-04-05T00:26:31+02:00" level=debug msg="Added outgoing tracing middleware dashboard@internal" entryPointName=traefik routerName=dashboard@internal middlewareName=tracing middlewareType=TracingForwarder
time="2020-04-05T00:26:31+02:00" level=debug msg="Creating middleware" entryPointName=traefik routerName=dashboard@internal middlewareType=StripPrefix middlewareName=dashboard_stripprefix@internal
time="2020-04-05T00:26:31+02:00" level=debug msg="Adding tracing to middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_stripprefix@internal
time="2020-04-05T00:26:31+02:00" level=debug msg="Creating middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_redirect@internal middlewareType=RedirectRegex
time="2020-04-05T00:26:31+02:00" level=debug msg="Setting up redirection from ^(http:\\/\\/[^:\\/]+(:\\d+)?)\\/$ to ${1}/dashboard/" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_redirect@internal middlewareType=RedirectRegex
time="2020-04-05T00:26:31+02:00" level=debug msg="Adding tracing to middleware" routerName=dashboard@internal middlewareName=dashboard_redirect@internal entryPointName=traefik
time="2020-04-05T00:26:31+02:00" level=debug msg="Added outgoing tracing middleware ping@internal" middlewareType=TracingForwarder entryPointName=traefik routerName=ping@internal middlewareName=tracing
time="2020-04-05T00:26:31+02:00" level=debug msg="Creating middleware" middlewareName=traefik-internal-recovery middlewareType=Recovery entryPointName=traefik
time="2020-04-05T00:26:31+02:00" level=debug msg="No default certificate, generating one"
time="2020-04-05T00:26:37+02:00" level=debug msg="vulcand/oxy/roundrobin/rr: begin ServeHttp on request" Request="{\"Method\":\"GET\",\"URL\":{\"Scheme\":\"\",\"Opaque\":\"\",\"User\":null,\"Host\":\"\",\"Path\":\"/\",\"RawPath\":\"\",\"ForceQuery\":false,\"RawQuery\":\"\",\"Fragment\":\"\"},\"Proto\":\"HTTP/1.1\",\"ProtoMajor\":1,\"ProtoMinor\":1,\"Header\":{\"Accept\":[\"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\"],\"Accept-Encoding\":[\"gzip, deflate\"],\"Accept-Language\":[\"fr-FR,fr;q=0.5\"],\"Cache-Control\":[\"max-age=0\"],\"Connection\":[\"keep-alive\"],\"Dnt\":[\"1\"],\"Upgrade-Insecure-Requests\":[\"1\"],\"User-Agent\":[\"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0\"],\"X-Forwarded-Host\":[\"swagger-editor.localhost\"],\"X-Forwarded-Port\":[\"80\"],\"X-Forwarded-Proto\":[\"http\"],\"X-Forwarded-Server\":[\"zaphod.local\"],\"X-Real-Ip\":[\"::1\"]},\"ContentLength\":0,\"TransferEncoding\":null,\"Host\":\"swagger-editor.localhost\",\"Form\":null,\"PostForm\":null,\"MultipartForm\":null,\"Trailer\":null,\"RemoteAddr\":\"[::1]:58775\",\"RequestURI\":\"/\",\"TLS\":null}"
time="2020-04-05T00:26:37+02:00" level=debug msg="vulcand/oxy/roundrobin/rr: Forwarding this request to URL" Request="{\"Method\":\"GET\",\"URL\":{\"Scheme\":\"\",\"Opaque\":\"\",\"User\":null,\"Host\":\"\",\"Path\":\"/\",\"RawPath\":\"\",\"ForceQuery\":false,\"RawQuery\":\"\",\"Fragment\":\"\"},\"Proto\":\"HTTP/1.1\",\"ProtoMajor\":1,\"ProtoMinor\":1,\"Header\":{\"Accept\":[\"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\"],\"Accept-Encoding\":[\"gzip, deflate\"],\"Accept-Language\":[\"fr-FR,fr;q=0.5\"],\"Cache-Control\":[\"max-age=0\"],\"Connection\":[\"keep-alive\"],\"Dnt\":[\"1\"],\"Upgrade-Insecure-Requests\":[\"1\"],\"User-Agent\":[\"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0\"],\"X-Forwarded-Host\":[\"swagger-editor.localhost\"],\"X-Forwarded-Port\":[\"80\"],\"X-Forwarded-Proto\":[\"http\"],\"X-Forwarded-Server\":[\"zaphod.local\"],\"X-Real-Ip\":[\"::1\"]},\"ContentLength\":0,\"TransferEncoding\":null,\"Host\":\"swagger-editor.localhost\",\"Form\":null,\"PostForm\":null,\"MultipartForm\":null,\"Trailer\":null,\"RemoteAddr\":\"[::1]:58775\",\"RequestURI\":\"/\",\"TLS\":null}" ForwardURL="http://<IP_ADDRESS>:80"
time="2020-04-05T00:26:44+02:00" level=debug msg="'502 Bad Gateway' caused by: dial tcp <IP_ADDRESS>:80: connect: network is unreachable"
time="2020-04-05T00:26:44+02:00" level=debug msg="vulcand/oxy/roundrobin/rr: completed ServeHttp on request" Request="{\"Method\":\"GET\",\"URL\":{\"Scheme\":\"\",\"Opaque\":\"\",\"User\":null,\"Host\":\"\",\"Path\":\"/\",\"RawPath\":\"\",\"ForceQuery\":false,\"RawQuery\":\"\",\"Fragment\":\"\"},\"Proto\":\"HTTP/1.1\",\"ProtoMajor\":1,\"ProtoMinor\":1,\"Header\":{\"Accept\":[\"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\"],\"Accept-Encoding\":[\"gzip, deflate\"],\"Accept-Language\":[\"fr-FR,fr;q=0.5\"],\"Cache-Control\":[\"max-age=0\"],\"Connection\":[\"keep-alive\"],\"Dnt\":[\"1\"],\"Upgrade-Insecure-Requests\":[\"1\"],\"User-Agent\":[\"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0\"],\"X-Forwarded-Host\":[\"swagger-editor.localhost\"],\"X-Forwarded-Port\":[\"80\"],\"X-Forwarded-Proto\":[\"http\"],\"X-Forwarded-Server\":[\"zaphod.local\"],\"X-Real-Ip\":[\"::1\"]},\"ContentLength\":0,\"TransferEncoding\":null,\"Host\":\"swagger-editor.localhost\",\"Form\":null,\"PostForm\":null,\"MultipartForm\":null,\"Trailer\":null,\"RemoteAddr\":\"[::1]:58775\",\"RequestURI\":\"/\",\"TLS\":null}"
::1 - - [04/Apr/2020:22:26:37 +0000] "GET / HTTP/1.1" 502 11 "-" "-" 3 "swagger@docker" "http://<IP_ADDRESS>:80" 7023ms

Logs after adding label to force the port:
time="2020-04-05T00:29:14+02:00" level=info msg="Configuration loaded from file: /usr/local/etc/traefik/traefik.toml"
time="2020-04-05T00:29:14+02:00" level=info msg="Traefik version 2.2.0 built on I don't remember exactly"
time="2020-04-05T00:29:14+02:00" level=debug msg="Static configuration loaded {\"global\":{\"checkNewVersion\":true,\"sendAnonymousUsage\":true},\"serversTransport\":{\"maxIdleConnsPerHost\":200},\"entryPoints\":{\"traefik\":{\"address\":\":8080\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":10000000000},\"respondingTimeouts\":{\"idleTimeout\":180000000000}},\"forwardedHeaders\":{},\"http\":{}},\"web\":{\"address\":\":80\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":10000000000},\"respondingTimeouts\":{\"idleTimeout\":180000000000}},\"forwardedHeaders\":{},\"http\":{}},\"websecure\":{\"address\":\":443\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":10000000000},\"respondingTimeouts\":{\"idleTimeout\":180000000000}},\"forwardedHeaders\":{},\"http\":{}}},\"providers\":{\"providersThrottleDuration\":2000000000,\"docker\":{\"watch\":true,\"endpoint\":\"unix:///var/run/docker.sock\",\"defaultRule\":\"Host(`{{ normalize .Name }}.localhost`)\",\"exposedByDefault\":true,\"swarmModeRefreshSeconds\":15000000000},\"file\":{\"directory\":\"/Users/florianlevis/.config/traefik.d/\",\"watch\":true}},\"api\":{\"insecure\":true,\"dashboard\":true},\"ping\":{\"entryPoint\":\"traefik\"},\"log\":{\"level\":\"DEBUG\",\"format\":\"common\"},\"accessLog\":{\"filePath\":\"/usr/local/var/log/traefik.log\",\"format\":\"common\",\"filters\":{},\"fields\":{\"defaultMode\":\"keep\",\"headers\":{\"defaultMode\":\"drop\"}}}}"
time="2020-04-05T00:29:14+02:00" level=info msg="Stats collection is enabled."
time="2020-04-05T00:29:14+02:00" level=info msg="Many thanks for contributing to Traefik's improvement by allowing us to receive anonymous information from your configuration."
 I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Traefik!
We dedicate the issue tracker to bug reports and feature requests only. My advanced AI has spotted that your issue might be a configuration problem or relates to something that doesn't look like a bug.
To confirm this, please join our Community Forum and reach out to us on the Traefik section.
In case I'm wrong (well, that would be embarrassing :sweat_smile:), my developers will re-open the issue and fix me!
In the meantime, you can double check Traefik's documentation.


Return error if isProtectedDataAvailable = false

Addresses issue #72 where SecItemCOpyMatching doesn't return data and
doesn't give an error when the protected files are not yet
available. This will now give an error instead of empty results,
allowing the caller to retry after some delay.

One note on this change: keychain items using kSecAttrAccessibleAfterFirstUnlock - e.g. for apps that run in the background - will fail this check, even though the keychain item is available when the device is locked (isProtectedDataAvailable is false).
It appears that getItem needs to include kSecAttrAccessible anyway, so perhaps this check should be conditional on kSecAttrAccessible actually requiring isProtectedDataAvailable?


Overlay triplets appear not to work

See https://github.com/zig-for/snfm/actions/runs/2646107112
I've set
        "VCPKG_TARGET_TRIPLET": "x64-windows-static-release",
        "VCPKG_OVERLAY_TRIPLES": "${sourceDir}",

in my CMakePresets.json and added the new triplet file to the root of my source directory. When I run this locally, it works just fine, both through visual studio and through the command line. When I run through github actions, it doesn't work. I'm happy to try and debug this, but I've no idea where to go from here.

Never mind, I had local changes to my vcpkg dir.