Need sample for scope validation for Jersey-based applications

Hi @nenaraab ,
In continuation with issue https://github.com/SAP/cloud-security-xsuaa-integration/issues/409, The scope validation provided in the sample code is specific to HttpServlet class and it did not work for Java applications (JAX-RS) based on Jersey. Spring-xsuaa as well did not work for non-spring boot apps.
Could you please provide an example for Jersey-based apps. https://github.wdf.sap.corp/iot/configuration/blob/master/src/generated/java/com/sap/appcore/configuration/resource/ConfigurationResource.java#L16
Best regards,
Augustine

Hi @Augustine-Joshua,
thanks for your question!
Yes, spring-xsuaa was NEVER suggested for NON-Spring (boot) applications.
Yes, the sample shows how to integrate to Tomcat Servlet container by implementing javax.servlet.Filter class as described here:
https://github.com/SAP/cloud-security-xsuaa-integration/blob/master/samples/java-security-usage/src/main/java/com/sap/cloud/security/samples/XsuaaSecurityFilter.java
This performs the token validation and fills the SecurityContext in case the user could be authenticated (token is valid).
The same implementation has to be provided as part of a JAX-RS javax.ws.rs.container.ContainerRequestFilter to support the same functionality for Jersey Servlet Container.
This webpage seems to provide a good explanation on how to implement such a ContainerRequestFilter:
https://howtodoinjava.com/spring-boot/role-based-security-jaxrs-annotations/
The SecurityContext then can be used within the same thread, request context. Or, you implement the isUserAllowed as explained in the references page.
Best regards,
Nena
Further References

https://github.com/SAP/cloud-security-xsuaa-integration/tree/master/java-security


refactor: use composition api in player

build(deps): Bump deps

bug: change language to english/french not working
reason: unknown. next branch code works fine. but pr branch will cause this problem.


WebWorker support

+1
For reference, here's the hacky solution that I came up with:
https://gist.github.com/matthewoates/7dead5c35249fd6d8062


IT-1797 remove references to IT-1383 from Puppetfile

Change Puppetfile mod branch reference for baseline_cfg in a separate commit, as suggested in #42

@jhoblitt Added you as reviewer for FYI, but I'm going to go ahead and merge this change as it was previously part of #42 and pulled out into a separate commit at your request. I realize now that you meant just a separate commit as opposed to a whole separate branch and merge, ... but I guess some of just learn the hard way. :)


fetchLinks support for specified document types

There are some instances where digging deeper into a document that is linked to another document would be very useful up-front so that the linkResolver could build URLs based off of a more complex document relationship.
For instance: If I have an Article document type, and it links to a Category, building a URL based off of a data field in a Category instance that's linked from this Article involves handing Prismic an additional fetchLinks key that hints at what kind of data should be available.
The result should be that when in the linkResolver function, when handling the right doc type, we should be able to access the doc's data property and drill down into the content relationship / link to pull out whatever was specific in fetchLinks.

@angeloashmore Yup, that sounds about right. That is interesting about being able to use the existing data to add that information in post-fetch, but besides the caveat you mentioned, I'm not sure if it would gum up everything trying to match the right data with the right doc type and/or slow something down shrug
I've only ever used fetchLinks while querying for a single document, so I'm not sure, but I think you would add it in as an option here:
https://github.com/angeloashmore/gatsby-source-prismic/blob/cdd08bf916ba9c6c5d7cd41ffa8b10035b954a8e/src/fetch.js#L35-L39
I can do some more research to see how it does/doesn't work when querying everything versus just the one record.

I'm wondering what the best way to construct the value of fetchLinks. A couple of options:

Let the user provide it in gatsby-config.js and pass it to client.query directly
Query all documents, get a list of the fields for all types, and query all the documents again with all fields listed in fetchLinks
Let the user provide a list of custom types and perform the above, but only for those types (less network delays, and off by default)

I think option 1 is our best bet. It's the simplest and is probably what most people would expect. Options 2 and 3 could be a little too magical and with too much complexity.


Need API to query existing chaincode names

We need API to query chaincode ID/name which was deployed. Like following:
GET host:port/chaincodes
{
"jsonrpc": "2.0",
"chaincodes": [
"52b0d803fc395b5e34d8d4a7cd69fb6aa00099b8fabed83504ac1c5d61a425aca5b3ad3bf96643ea4fdaac132c417c37b00f88fa800de7ece387d008a76d3586"
]
}

@genggjh :  In addition to query for the system generated hash, we also need to allow user-given names.  In general naming and lifecycle aspects of chaincode need work.  Please watch out for activity in this area near future.

@muralisrini thanks for your response. I think we also need support to stop/delete chaincode in the future, right?

@genggjh : right.... and upgrade.

@muralisrini will glad to see it.

@muralisrini @srderson does this really need to remain open or have we captured this somewhere else? Generally, I prefer that we not have a bunch of nice-to-have issues remain open when we already have plans for enhancements that incorporate the desired capability.

@christo4ferris @muralisrini @srderson
I am wondering if this needs to be transferred to Jira? Or closed? Thanks.


Mention Azure Functions blob trigger supports Storage V2 accounts with hierarchal namespaces

This issue is specific to Azure Functions support for triggers on general purpose storage accounts.  With the introduction of Azure Data Lake Gen2 and hierarchal namespaces on Storage V2 accounts, customers can create Azure Storage V2 accounts and
optionally enable hierarchal namespaces so they can use the account with Azure Data Lake Gen2.  Until "multi-protocol access" support was added, access to these accounts would not work with the Storage Blob APIs and this meant that Azure Function triggers against these accounts would not work.  It might be useful to users if we clarify in our documentation that Azure Functions works with hierarchal namespace enabled storage accounts since it did not work in the past.  proposing the following change to this text on the page:
Original text:
"The Azure Blob storage trigger require a general-purpose storage account."
Proposed text:
"The Azure Blob storage trigger requires a general-purpose storage account.  Storage V2 accounts with hierarchal namespaces are also supported."
Thanks for considering this change.

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

ID: 5ecb1e79-f603-03fd-2ef9-c6cf08ffaacd
Version Independent ID: 35c99e36-f224-350b-a258-2e0cfb8ab154
Content: Azure Blob storage trigger for Azure Functions
Content Source: articles/azure-functions/functions-bindings-storage-blob-trigger.md
Service: azure-functions
GitHub Login: @craigshoemaker
Microsoft Alias: cshoe

Hi @sidkri Thanks for your feedback. We will review and update as appropriate.

Hm, I've been grepping https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-storage-blob-trigger?tabs=python-v2%2Cisolated-process%2Cnodejs-v4&pivots=programming-language-python and I can't find any mentions of "hierarchical", "datalake", "adls", etc. Where did the text get changed? Is it supported in Python?


Unable  to create command with Bob Compile

I have a simple command cmpf.cmdsrc in local folder qcmdsrc.
    CMD     PROMPT('Compare file with SQL')
    PARM    KWD(FILE) TYPE(*CHAR) LEN(10) MIN(1) +
                PGM(*YES) PROMPT('File...')
    PARM    KWD(OLDLIB) TYPE(*CHAR) LEN(10) MIN(1) +
                PGM(*YES) PROMPT('Old Library...')
    PARM    KWD(NEWLIB) TYPE(*CHAR) LEN(10) MIN(1) +
                PGM(*YES) PROMPT('New Library...')

My Rules.mk in the qcmdsrc folder is
CMPF.CMD: TEXT = Compare file with SQL
CMPF.CMD: CMPF.CMDSRC
CMPF.CMD: private PGM = PG5000C

When I try to create the command with Bob Compile my output is
Current library: DCUTILS
Library list: DTCSRC QTEMP DTCOBJ DTCDTA QGPL RROGERSON
Commands:
		err=*EVENTF /QOpenSys/pkgs/bin/makei compile -f cmpf.cmdsrc -e lib1=DCUTILS

Set variable <lib1> to 'DCUTILS'
targets: CMPF.CMD
> /QOpenSys/pkgs/bin/make -k BUILDVARSMKPATH="/tmp/tmpyb8nvos5" -k BOB="/QOpenSys/pkgs/lib/bob" -f "/QOpenSys/pkgs/lib/bob/src/mk/Makefile" CMPF.CMD
make: *** No rule to make target 'CMPF.CMD'.
Objects:             0 failed 0 succeed 0 total
Build Completed!

Fetching errors from DCUTILS/cmpf.
Downloaded files as part of Action: .logs/, .evfevent/

Is there an issue with creating command that I am missing?

I'm unable to reproduce this error. Is this still a problem with v2.4.16?

Hello @irfanshar , I do seem to be getting closer.  I upgraded Bob as suggested.  Now I get a new error.  It does not seem to populate my  when creating the command.  Here is from output.log

executing command: CRTCMD CMD(/CMPF) srcstmf('/home/rrogerson/dcutils/QCMDSRC/CMPF.CMDSRC') PGM(PG5000C) VLDCKR(*NONE) PMTFILE(*NONE) HLPPNLGRP(CMPF) HLPID(CMPF) AUT() ALLOW() TEXT('Compare file with SQL')
liblist: QSYS QSYS2 QHLPSYS QUSRSYS QSHELL DCUTILS DCUTILS QTEMP DTCSRC DTCOBJ DTCDTA QGPL RROGERSON
executing time: 2023-08-03-<IP_ADDRESS>893000

CPD0104: Expression not allowed for parameter CMD.
CPF0006: Errors occurred in command.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Any ideas why this is not being set?
Thanks

what is your iproj.json contents?

@edmundreinhardt and @irfanshar, my apologies for not responding sooner but the company I'm working at just did a migration to SAP and I've been extremely busy.
Last night I upgraded bob to 2.4.19-1 and successfully rebuilt all objects for bob-recursive-example.

I then switched to my CMPF utility and attempted a compile but received basically the same error.

I then attempted a build all

For some reason it is not populating the object library.
Here is my iproj.json.  It is copied from the successful bob-recursive-example with only the description, includePath and repository lines changed.
{
"version": "0.0.1",
"description": "Compare two files row by row for regression testing",
"objlib": "&lib1",
"curlib": "&lib1",
"includePath": [],
"preUsrlibl": ["&lib1"],
"postUsrlibl": [],
"setIBMiEnvCmd": [],
"repository": "https://github.com/rogersonra/cmpf.git"
}

Hello Robert I would love to help
I think you mistakenly pasted the same screen cap of bob-recursive working without showing us the error you are seeing
I tried to clone your repo from the iproj.json to reproduce it myself, but I got
@.*** git %
git clone https://github.com/rogersonra/cmpf.git
Cloning into 'cmpf'...
remote: Repository not found.
fatal: repository 'https://github.com/rogersonra/cmpf.git/' not found
Ping me back with a time and we can set up a meeting to resolve this quickly
From: Robert Rogerson @.>
Date: Saturday, September 23, 2023 at 10:48 AM
To: IBM/ibmi-bob @.>
Cc: Edmund Reinhardt @.>, Mention @.>
Subject: [EXTERNAL] Re: [IBM/ibmi-bob] Unable to create command with Bob Compile (Issue #245)
@edmundreinhardt and @irfanshar, my apologies for not responding sooner but the company I'm working at just did a migration to SAP and I've been extremely busy. Last night I upgraded bob to 2. 4. 19-1 and successfully rebuilt all objects for
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
Report Suspicious  https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!2g-u7PHcoZPREQYRk2sGZfEFEPMaJjwQiqwOVdnefxLVWRz4VBkhgWSj7welfXp9iji0QDxFUL_FXb96T3o5z4ZXgHVAMKhDrgju$
ZjQcmQRYFpfptBannerEnd
@edmundreinhardthttps://github.com/edmundreinhardt and @irfansharhttps://github.com/irfanshar, my apologies for not responding sooner but the company I'm working at just did a migration to SAP and I've been extremely busy.
Last night I upgraded bob to 2.4.19-1 and successfully rebuilt all objects for bob-recursive-example.
[image]https://user-images.githubusercontent.com/32421796/270114277-655778b4-7feb-49c3-a2cc-c9e38d3968ea.png
I then switched to my CMPF utility and attempted a compile but received basically the same error.
[image]https://user-images.githubusercontent.com/32421796/270114454-39c2bc14-fe33-444d-beda-1f03bed3e0cf.png
I then attempted a build all
[image]https://user-images.githubusercontent.com/32421796/270114689-afb88845-42bd-4a0d-ae7f-216c3646eadf.png
For some reason it is not populating the object library.
Here is my iproj.json. It is copied from the successful bob-recursive-example with only the description, includePath and repository lines changed.
{
"version": "0.0.1",
"description": "Compare two files row by row for regression testing",
"objlib": "&lib1",
"curlib": "&lib1",
"includePath": [],
"preUsrlibl": ["&lib1"],
"postUsrlibl": [],
"setIBMiEnvCmd": [],
"repository": "https://github.com/rogersonra/cmpf.githttps://github.com/rogersonra/cmpf.git"
}
—
Reply to this email directly, view it on GitHubhttps://github.com/IBM/ibmi-bob/issues/245#issuecomment-1732334339, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACVKTQ3V5D3NIHPB4JTTSRLX33ZCVANCNFSM6AAAAAA2G3UCZQ.
You are receiving this because you were mentioned.Message ID: @.***>


Invisible underscore in integrated terminal

VSCode Version: 1.18.1
OS Version: Fedora 26 (4.13.13-200.fc26.x86_64)

Steps to Reproduce:

Go to integrated terminal.
Type something, which contains an underscore, for example MY_VARIABLE="test"

Underscore is invisible.

Reproduces without extensions: Yes

Duplicate https://github.com/Microsoft/vscode/issues/35901


Sozo auth checks

Related to DOJ-216, https://github.com/dojoengine/dojo/issues/1628
Before granting write access to models with the sozo auth grant writer command, this PR verifies if the model name exists and if the provided address is the good one.
Note that:

the issue also mentions the sozo auth revoke command but it is not implemented yet.
I've added a new dependency to the colored package to add some colors in warning traces. This is done in a separate commit so easy to remove if not needed.

For the coloration, it looks definitely better. I'm wondering in which measure we should attempt to introduce a UI (as scarb is doing) to have a more consistent way of printing stuff. :)
(definitely not in the scope of this PR though)

I would abstain from adding any coloring or specific formatting for now.. to keep the cli messages consistent across sozo

I would abstain from adding any coloring or specific formatting for now.. to keep the cli messages consistent across sozo

In fact, there is already a difference between the sozo migrate UI and other commands. But yes, maybe I should leave this PR without any coloring and create another issue/PR to add some colors for warnings and errors in all the sozo commands.

In fact, there is already a difference between the sozo migrate UI and other commands.

Yup very much aware of that that's why we definitely don't want to introduce more inconsistencies. That should be a whole other issue to solve and something that we should properly think about to avoid creating half-baked solution.


feat(app): add heater-shaker attached confirmation modal

Overview
Add heater-shaker attached confirmation modal
design
https://www.figma.com/file/AoTLAYuWawlaWItB1umOjr/Release%3A-Opentrons-Flex-Touchscreen?type=design&node-id=14613-321529&t=OMze5UKIoktj87Qo-0
close RAUT-489

Test Plan

Changelog

Review requests

Risk assessment
low

This feat will be added by a following PR


Services: first build: abs added

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_798o71jb7s/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:22: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
clone/recipe/meta.yaml:17: avoid_noarch: noarch: python packages should be avoided

===== ERRORS =====

clone/recipe/meta.yaml:48: missing_dev_url: The recipe is missing a dev_url
clone/recipe/meta.yaml:23: missing_wheel: For pypi packages, wheel should be present in the host section
clone/recipe/meta.yaml:17: pip_install_args: pip install should be run with --no-deps and --no-build-isolation.
clone/recipe/meta.yaml:48: missing_documentation: The recipe is missing a doc_url or doc_source_url
===== Final Report: =====
4 Errors and 2 Warnings were found


fix dead link in factor_graph.pdf (#200)

I'm thinking we could keep the source (.tex?) for the file together if that's not too much work.

@netj Added source

Coverage remained the same at 78.53% when pulling 91ceea70f08167838c64ad76510386066ac43ca9 on doc into 9b1425b37daf9edcb9ef60a45860072dc466791d on develop.

Looks great, merging.

Coverage remained the same at 78.53% when pulling 91ceea70f08167838c64ad76510386066ac43ca9 on doc into 9b1425b37daf9edcb9ef60a45860072dc466791d on develop.


Code cleanups from PVS/Studio

The team that makes PVS/Studio makes free licenses available for open-source projects (which is an awesome service to the community).
I ran it across the RDKit and have started fixing things that it flags up. This PR is the first wave of those fixes. I haven't made it through the report completely yet, but I will do another round at some point in the hopefully not-too-distant future.
Most of this is at the level of theoretical problems or removing warnings, but there are a couple of actual obvious bugs in there that either haven't come up yet or no one has noticed. I'll add comments for those.

@greglandrum I made a PR to your repo based on the FilterCatalog warnings, we could do this separately though.

@greglandrum I made a PR to your repo based on the FilterCatalog warnings, we could do this separately though.

Thanks for pointing that out. I knew I had seen a notification about a PR from you about this, but then I couldn't find the PR. :-)


bidirectional

I know there have been quite intensive discussions about applying bidirectional recurrent layer. So, I guess this code is a potential solution to the masking issue.
https://github.com/farizrahman4u/seq2seq/blob/master/seq2seq/layers/bidirectional.py
I tried the following:
model  = Sequential()
model.add(Embedding(30, 10, mask_zero=True, input_length=10))
model.add(Bidirectional(LSTM(10, return_sequences=True)))
But an error occurred. Its message is as follows:
'LSTM' object has no attribute 'batch_input_shape'
Any thoughts?

@meain Can you reproduce this issue? my laptop is broken.

I'm also wondering it this line is correct: https://github.com/farizrahman4u/seq2seq/blob/master/seq2seq/layers/bidirectional.py#L88
I guess the reversed result should be 0,0,0,10,9,7,4, not 10,10,10,10,9,7,4.

It will get masked.

I don't want to bother you, but can you elaborate on that? I don't see any point where it will get masked. It was already masked in line 87, and the remaining next step is simply concatenating/summing/averaging/multiplying Y and Y_rev. So I guess the final hidden states would be
[[0    0    0 1 3 6 10]
[10 10 10 10 9 7 4]]
, where the expected result of concatenating is
[[0 0 0 1 3 6 10]
[0 0 0 10 9 7 4]]
If I miss something, please let me know.

If I miss something, please let me know.

You are missing ** THE MASK**

If I miss something, please let me know.

You are missing :


Performance metrics listAccountHistory

Hi @fuxingloh  I have a question regarding the performance behavior of the listAccountHistory  command.
Node version: 1.7.10
Yellyfish version: 0.12.0
I´m using jellyfish to get my transactions und experimented with chopping up the requests in multiple batches (like pagination). I got some unexpected performance results and would like your opinion on it.
I executed the listaccounthistory with different  parameters.
Results:
The smaller the batch size and the more requests the longer it takes.

listaccounthistory with  mine depth = blockCount, and limit = MAX_SAFE_INTEGER

listAccountHistory from 915977 with depth 915977: 14022.044921875 ms

listaccounthistory with  mine depth = 100000, and limit = MAX_SAFE_INTEGER

listAccountHistory from 915934 with depth 100000: 13730.339111328125 ms
listAccountHistory from 815934 with depth 100000: 4062.484130859375 ms
listAccountHistory from 715934 with depth 100000: 4947.461181640625 ms
listAccountHistory from 615934 with depth 100000: 6408.5869140625 ms
listAccountHistory from 515934 with depth 100000: 7882.18994140625 ms
listAccountHistory from 415934 with depth 100000: 7924.23388671875 ms
listAccountHistory from 315934 with depth 100000: 8189.227294921875 ms
listAccountHistory from 215934 with depth 100000: 8182.885009765625 ms
listAccountHistory from 115934 with depth 100000: 7863.46484375 ms
listAccountHistory from 15934 with depth 100000: 8583.657958984375 ms

listaccounthistory with  mine depth = 10000, and limit = MAX_SAFE_INTEGER

listAccountHistory from 915945 with depth 10000: 2666.263916015625 ms
listAccountHistory from 905945 with depth 10000: 1992.656005859375 ms
listAccountHistory from 895945 with depth 10000: 2247.8408203125 ms
listAccountHistory from 885945 with depth 10000: 2371.30224609375 ms
listAccountHistory from 875945 with depth 10000: 2363.537109375 ms
listAccountHistory from 865945 with depth 10000: 4181.380126953125 ms
listAccountHistory from 855945 with depth 10000: 4110.50390625 ms
listAccountHistory from 845945 with depth 10000: 2984.93505859375 ms
listAccountHistory from 835945 with depth 10000: 3420.834228515625 ms
listAccountHistory from 825945 with depth 10000: 3645.53515625 ms
listAccountHistory from 815945 with depth 10000: 3359.8271484375 ms
listAccountHistory from 805945 with depth 10000: 3729.358154296875 ms
listAccountHistory from 795945 with depth 10000: 3862.964111328125 ms
listAccountHistory from 785945 with depth 10000: 4225.881103515625 ms
listAccountHistory from 775945 with depth 10000: 4061.76708984375 ms
listAccountHistory from 765945 with depth 10000: 5611.7939453125 ms
listAccountHistory from 755945 with depth 10000: 4824.673095703125 ms
listAccountHistory from 745945 with depth 10000: 4753.401123046875 ms
listAccountHistory from 735945 with depth 10000: 4553.934814453125 ms
listAccountHistory from 725945 with depth 10000: 4675.406982421875 ms
listAccountHistory from 715945 with depth 10000: 4825.72900390625 ms
listAccountHistory from 705945 with depth 10000: 5101.509765625 ms
listAccountHistory from 695945 with depth 10000: 5811.173095703125 ms
listAccountHistory from 685945 with depth 10000: 5372.3779296875 ms
listAccountHistory from 675945 with depth 10000: 5552.522216796875 ms
listAccountHistory from 665945 with depth 10000: 5545.52001953125 ms
listAccountHistory from 655945 with depth 10000: 5697.468017578125 ms
listAccountHistory from 645945 with depth 10000: 6289.509033203125 ms
listAccountHistory from 635945 with depth 10000: 6338.385986328125 ms
listAccountHistory from 625945 with depth 10000: 6167.596923828125 ms
listAccountHistory from 615945 with depth 10000: 6429.10888671875 ms
listAccountHistory from 605945 with depth 10000: 6491.8701171875 ms
listAccountHistory from 595945 with depth 10000: 7152.47900390625 ms
listAccountHistory from 585945 with depth 10000: 7183.89599609375 ms
listAccountHistory from 575945 with depth 10000: 6958.467041015625 ms
listAccountHistory from 565945 with depth 10000: 7039.7099609375 ms
listAccountHistory from 555945 with depth 10000: 7483.881103515625 ms
listAccountHistory from 545945 with depth 10000: 7580.385986328125 ms
listAccountHistory from 535945 with depth 10000: 7420.279052734375 ms
listAccountHistory from 525945 with depth 10000: 7609.2041015625 ms
listAccountHistory from 515945 with depth 10000: 8134.376953125 ms
listAccountHistory from 505945 with depth 10000: 8331.550048828125 ms
listAccountHistory from 495945 with depth 10000: 7985.054931640625 ms
listAccountHistory from 485945 with depth 10000: 8049.72802734375 ms
listAccountHistory from 475945 with depth 10000: 8192.090087890625 ms
listAccountHistory from 465945 with depth 10000: 8170.890869140625 ms
listAccountHistory from 455945 with depth 10000: 7948.885986328125 ms
listAccountHistory from 445945 with depth 10000: 7848.35009765625 ms
listAccountHistory from 435945 with depth 10000: 8146.239990234375 ms
listAccountHistory from 425945 with depth 10000: 8286.370849609375 ms
listAccountHistory from 415945 with depth 10000: 8125.609130859375 ms
listAccountHistory from 405945 with depth 10000: 8661.31103515625 ms
listAccountHistory from 395945 with depth 10000: 7890.9638671875 ms
listAccountHistory from 385945 with depth 10000: 8092.35302734375 ms
listAccountHistory from 375945 with depth 10000: 8639.26318359375 ms
listAccountHistory from 365945 with depth 10000: 8697.256103515625 ms
listAccountHistory from 355945 with depth 10000: 8252.044921875 ms
listAccountHistory from 345945 with depth 10000: 8064.43408203125 ms
listAccountHistory from 335945 with depth 10000: 8177.599853515625 ms
listAccountHistory from 325945 with depth 10000: 8151.36181640625 ms
listAccountHistory from 315945 with depth 10000: 8223.304931640625 ms
listAccountHistory from 305945 with depth 10000: 8187.89697265625 ms
listAccountHistory from 295945 with depth 10000: 8760.250244140625 ms
listAccountHistory from 285945 with depth 10000: 8960.788818359375 ms
listAccountHistory from 275945 with depth 10000: 8326.14697265625 ms
listAccountHistory from 265945 with depth 10000: 8114.1259765625 ms
listAccountHistory from 255945 with depth 10000: 8644.2890625 ms
listAccountHistory from 245945 with depth 10000: 8433.56689453125 ms
listAccountHistory from 235945 with depth 10000: 8042.621826171875 ms
listAccountHistory from 225945 with depth 10000: 8914.689697265625 ms
listAccountHistory from 215945 with depth 10000: 8413.66015625 ms
listAccountHistory from 205945 with depth 10000: 9076.339111328125 ms
listAccountHistory from 195945 with depth 10000: 8382.399169921875 ms
listAccountHistory from 185945 with depth 10000: 8451.809814453125 ms
listAccountHistory from 175945 with depth 10000: 9118.77783203125 ms
listAccountHistory from 165945 with depth 10000: 8758.65625 ms
listAccountHistory from 155945 with depth 10000: 9449.3720703125 ms
listAccountHistory from 145945 with depth 10000: 8990.319091796875 ms
listAccountHistory from 135945 with depth 10000: 8670.402099609375 ms
listAccountHistory from 125945 with depth 10000: 8720.38818359375 ms
listAccountHistory from 115945 with depth 10000: 8837.97412109375 ms
listAccountHistory from 105945 with depth 10000: 8860.684814453125 ms
listAccountHistory from 95945 with depth 10000: 8587.530029296875 ms
listAccountHistory from 85945 with depth 10000: 10138.6572265625 ms
listAccountHistory from 75945 with depth 10000: 8891.4580078125 ms
listAccountHistory from 65945 with depth 10000: 8956.875732421875 ms
listAccountHistory from 55945 with depth 10000: 9357.477783203125 ms
listAccountHistory from 45945 with depth 10000: 9548.032958984375 ms
listAccountHistory from 35945 with depth 10000: 8830.254150390625 ms
listAccountHistory from 25945 with depth 10000: 8745.31298828125 ms
listAccountHistory from 15945 with depth 10000: 8665.583251953125 ms
listAccountHistory from 5945 with depth 10000: 8244.087158203125 ms

Hey @gamsterx 👋
In an effort to move fast in the early days we included product-facing indexes within the blockchain. These indexes were created to allow you to query your history ('mine') but in reality, the blockchain consensus logic doesn't need it and it's a waste of storage and complexity. The blockchain consensus has no concept of mine but rather script.
In order not to break compatibility, we remove those indexes but kept feature compatibility by iterating through a large dataset. Ultimately slated for deprecation as we don't need it moving forward.
If you want performance for that RPC, you have to index it yourself (cache it or create that index). Eventually, that will also be implemented in our new product-facing index. The project is called https://github.com/DeFiCh/whale in short it's the super index for DeFi Blockchain to simplify DeFi light implementation.
For your particular use case it's not yet implemented as we are have only implemented what we need for the light wallet development (probably sick of me saying this by now 😅). High-performance indexes that are currently are present here https://github.com/DeFiCh/whale/tree/main/packages/whale-api-client/src/api you can also fork the project and change the indexes to what you need, it's database agnostic. These endpoints will be also deployed as part of the https://github.com/DeFiCh/ocean project undertaking.
In summary, this is the project overview. I included other projects that are part of our new ecosystem undertaking that might interest you.

DeFiCh/ain → Indexes data for consensus only, not good for product features.
DeFiCh/jellyfish → RPC interfacing, wallet system, transaction crafting, transaction building, low-level blockchain, crypto logic, and other ecosystem tools.
DeFiCh/whale → The super index for DeFi Blockchain to simplify DeFi light implementation. (product facing indexes)
DeFiCh/ocean → Globally distributed and decentralized DeFiChain node infrastructure.
DeFiCh/playground → DeFi playground for DeFi Blockchain engineers to build DeFi applications without running your own node.

Hey @fuxingloh
thank you for your detailed answer. I will take a look at the provided links and maybe come back with additional questions 😉
I will close the issue.


code from issac work, take 1

Work from Issac. Camera is working. Preview is not. Code is running!

Seedsigner works on luckfox pico!


README.md specifies uploading non-existent dist folder

Instructions state:

Download to your project's source dir
Upload folder dist from repository
Add dist/bundle.js file to your page.

However, there is no dist folder, and no packages or releases available.

you get this folder by installing the node package.. very croocked but works for me


Add context propagation to the Storage interface

What would you like to have changed?
The Storage interfaces do not support context propagation. Only the Lock method does.  This would require changing the method signature for the Storage interface:
// Implementations of Storage must be safe for concurrent use.
type Storage interface {
	// Locker provides atomic synchronization
	// operations, making Storage safe to share.
	Locker

	// Store puts value at key.
	Store(ctx context.Context, key string, value []byte) error

	// Load retrieves the value at key.
	Load(ctx context.Context, key string) ([]byte, error)

	// Delete deletes key. An error should be
	// returned only if the key still exists
	// when the method returns.
	Delete(ctx context.Context, key string) error

	// Exists returns true if the key exists
	// and there was no error checking.
	Exists(ctx context.Context, key string) bool

	// List returns all keys that match prefix.
	// If recursive is true, non-terminal keys
	// will be enumerated (i.e. "directories"
	// should be walked); otherwise, only keys
	// prefixed exactly by prefix will be listed.
	List(ctx context.Context, prefix string, recursive bool) ([]string, error)

	// Stat returns information about key.
	Stat(ctx context.Context, key string) (KeyInfo, error)
}

Why is this feature a useful, necessary, and/or important addition to this project?
Propagating the context would be useful when using a remote storage (mainly for context cancellation). For example with the s3 storage:
https://github.com/ss098/certmagic-s3/blob/efad3a48d4edfbe2fee64e9c4d04195603822b07/s3.go#L144

Are you finding that those calls are taking a long time? (S3 is not a suitable storage backend, because it does not provide atomic operations, by the way, you will run into problems.)
Lock can definitely block for some time, but other calls shouldn't in practice.

@mholt FYI Georges is my teammate and I encouraged him to file this 😉

Are you finding that those calls are taking a long time?

In the general case it's useful to be able to cancel any I/O, especially with remote back-ends, regardless of how much time they may take. There are cases where an operation may simply block indefinitely, and so we need to be able to timeout/cancel/trigger a retry within a reasonable amount of time.
In our case we're working on a GCS backend (which does provide acceptable consistency), and similar to the linked S3 backend we're finding ourselves unable to propagate the context in a satisfactory way.
I suggested this get filed as certmagic is still pre-1.0 and so this is IMO the right opportunity to change the interface to allow for propagation.

Ok. I did think about doing this, but doing so will break all the storage implementations.
I suppose we can do this, but we'll need to file issues -- maybe even PRs that fill in a context.TODO() if there isn't one in their code already -- with all known storage implementations.

but doing so will break all the storage implementations.

This is 0.x still, so there's no promise of compatibility, right? 😉
I think opening issues/PRs is fair. Is sticking with the list at https://github.com/caddyserver/certmagic/wiki/Storage-Implementations enough?
I'm willing to help open issues/PRs with these implementations to help smooth things through, and I might be able to convince @chaudyg to lend a hand as well.
Given you're amenable to this, I'll issue a PR to make the change.

This is 0.x still, so there's no promise of compatibility, right? wink

Sure, but everyone who builds Caddy with any of the storage plugins would have breaking builds unless the version of certmagic in Caddy and the one the storage plugin uses match. It's a wrench.

Yeah, that should be fine, CertMagic is still pre 1.0 for these reasons.


Explosion of Bolt :)

Describe the bug
Hello,
While using this (great) app I got that error :
Application Error
Error: Minified React error #310; visit https://reactjs.org/docs/error-decoder.html?invariant=310 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
at Le (https://bolt.new/assets/components-B64jh5hJ.js:22:17522)
at Object.ec [as useCallback] (https://bolt.new/assets/components-B64jh5hJ.js:22:21045)
at O.useCallback (https://bolt.new/assets/index-fw5NnR3n.js:9:5633)
at I (https://bolt.new/assets/stripIndent-YObSZ0C4.js:1:206)
at OP (https://bolt.new/assets/_index-BDOX5lQw.js:66:4112)
at https://bolt.new/assets/_index-BDOX5lQw.js:66:4053
at Array.flatMap ()
at https://bolt.new/assets/_index-BDOX5lQw.js:66:4007
at Vo (https://bolt.new/assets/components-B64jh5hJ.js:22:16948)
at Ji (https://bolt.new/assets/components-B64jh5hJ.js:24:3134)
Link to the Bolt URL that caused the error
https://bolt.new/~/sb1-7k5rnz
Steps to reproduce
It happens during a prompt, I have no clue why, but the all interface exploded !
Expected behavior
Not to explode ? :)
Screen Recording / Screenshot
No response
Platform
Browser name = Chrome
Full version = <IP_ADDRESS>
Major version = 130
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
performance.memory = {
  "totalJSHeapSize": 114854736,
  "usedJSHeapSize": 90593068,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}
Username = Niko
Chat ID = bc3411b9d013

Additional context
No response

Appreciate the feedback! We are tracking this issue here: #2348.


Hollow out package to just be aliases/shims to the new home

This draft PR is a preview of what this repo will look like after the module has been moved to a new home at connectrpc.com/grpcreflect. For code that continues to refer to the prior module name, all exported vars, consts, and types are just aliases to the new module, and all exported functions are shims that call the new module.

Go does not allow creating an alias for a generic type. That means we can't do this same thing for the connect-go repo. And since this repo depends on that, we can't really do it here either.


New version seems to break Vite 2

I got the No "exports" main defined in /opt/build/repo/node_modules/vite-aliases/package.json error.

You have to add type: "module" to your package.json, as this package moved over to ESM. Also vite 2 support is not guaranteed anymore with newer versions of this package, as vite 3 and the upcoming vite 4 have major breaking changes to the plugin structure, it is also not advised to keep using it! ;)


Add failing test for default export IIFE

This plugin does not transform all IIFEs properly (see https://github.com/rollup/rollup-plugin-commonjs/issues/123) This PR adds a failing test which demos a case where parsing fails.  The leading open parenthesis on the IIFE does not show up in the transformed output which causes a parsing error since the closing paren is not matched by a leading one...
The issue is caused by the line: https://github.com/ntilwalli/rollup-plugin-commonjs/blob/v5.0.4/src/transform.js#L270
The leading paren is preserved if the above line is changed to:
magicString.overwrite( node.start, right.start - 1, `var ${moduleName} = ` );

However doing so causes some other tests to fail on formatting issues.  I'm posting this PR for comment on the best way to approach.

Hi, thanks for the PR – afraid I don't quite understand what the issue is here? The test passes without any modifications to the source code. (It could be due to upstream fixes.) If it still is an issue are you able to share a repro? Thanks

That's good news! If I remember correctly, I created this PR to demo the issue in #123.  Only one form of IIFE was being parsed properly when both should be.  The key is to have test coverage ensuring both IIFE formats are parsed properly.  If that's already the case, this can be closed, otherwise merging this PR would add that coverage.

Gotcha. Merging, thanks!


[Feature] tooltip.appendToBody with no scroll

What problem does this feature solve?
I'm using tooltip.appendToBody = true in order to be able to see all the tooltips properly. Everything works perfectly until I hover over a chart that's nearly outside of the screen.

As you can see it overflows the body and therefore creates s scrollbar in the html element. In this screen the charts are inside a container with inner scroll, so it kind of messes up the scroll because the user can scroll outside the view:

Maybe it would be good to create the tooltip div inside of a relative layout that doesn't exceed the body size:

.....

the tooltip as it is now

What does the proposed API look like?
Add an option:
{
   tooltip: {
       appendToBodyConfine: boolean
    }
}

which will add the overflow: hidden property to the tooltips parent container

This is still relevant :)


V2 Monitoring Fails to upgrade when crd is in a failed state

Rancher Server Setup

Rancher version: v2.6-head(46eb9d4)
Installation option (Docker install/Helm Chart):Docker
Proxy/Cert Details: self-signed

Information about the Cluster

Kubernetes version:v1.21.6-rancher1-1
Cluster Type (Local/Downstream):Downstream aws/ec2
4 worker nodes, 1 etcd nodes, 1 control plane node

Each worker node should have a taint added to it during the configuration steps. For example: qa=test:noschedule

Describe the bug
After installing v2 Monitoring (100.1.0+up19.0.3) onto a cluster with taints on every single node, it is required of us to add tolerations (for the taints on the nodes) to the "rancher-monitoring-crd" by editing the yaml file while the pod is in a failed state.
To Reproduce

Go to the apps and marketplace, install monitoring and the previously mentioned version
While waiting for install to process you can check whether the pods are being deployed or whether the app "rancher-monitoring-crd" is working in the "installed apps" page.
Once you see it's failed, use the kebab menu of the CRD to "edit/upgrade"
On the yaml page add tolerations equivalent to the previously created taints. For example:

tolerations:
- key: "qa"
  operator: "Equal"
  value: "test"
  effect: "NoSchedule"

Click save and return to the installed apps page.
View the yaml of the crd from the kebab menu and notice the previously added tolerations are not listed.

Result
The rancher-monitoring-crd remains in a failed state. The workaround would be to install the application using a helm install.
Following error when attempting to upgrade the already installed monitoring.
Fri, Dec 3 2021 4:32:50 pm | helm upgrade --install=true --namespace=cattle-monitoring-system --timeout=10m0s --values=/home/shell/helm/values-rancher-monitoring-crd-100.1.0-up19.0.3.yaml --version=100.1.0+up19.0.3 --wait=true rancher-monitoring-crd /home/shell/helm/rancher-monitoring-crd-100.1.0-up19.0.3.tgz
Fri, Dec 3 2021 4:32:50 pm | Error: UPGRADE FAILED: "rancher-monitoring-crd" has no deployed releases

Expected Result
The application should be upgraded and the tolerations should be installed just fine.
Additional context
This is a blocker of this issue: https://github.com/rancher/rancher/issues/34439

In my test, I could not reproduce the error mentioned in the issue. The error "rancher-monitoring-crd" has no deployed releases indicates the installation process did not start properly, we can use the helm list -A command to check if there is a release. Here is the output from my setup, which shows the app rancher-monitoring-crd is in a failed state.
> helm list -A
NAME                  	NAMESPACE               	REVISION	UPDATED                                	STATUS  	CHART                                                                                APP VERSION
fleet-agent-c-xp2px   	cattle-fleet-system     	2       	2021-12-06 16:54:29.056504086 +0000 UTC	deployed	fleet-agent-c-xp2px-v0.0.0+s-ab7adbbc8a2a4ffc2b8734b929cbae38d95ef9ce7e271dca92b4334d7c458
rancher-monitoring-crd	cattle-monitoring-system	3       	2021-12-06 20:15:15.286786805 +0000 UTC	failed  	rancher-monitoring-crd-100.1.0+up19.0.3

Now if I edit the app in rancher UI to set the toleration, an upgrade will be triggered and installed the app successfully.

However, I realized another two issue that blocks us from installing the monitoring chart from the UI:

Even we add the toleration to the crd chart and get it installed, the rancher-monitoring app will not be installed. in other words, the installation process stops at the 1st failure on the crd chart.
Every time we edit the rancher-monitoring app in the UI, it will trigger an upgrade on the crd chart, but since the UI does not provide the toleration in the values it passes to Helm, the upgrade always fail and we have to edit the app manually which brings us back to the issue 1.

Because of the above 2 issues, although we have added the support for toleration in the crd chat, since the missing UI component, the rancher-monitoring will still not be usable on a cluster where customized taints are applied to nodes.
As always, we have a workaround for this issue: instead of using Rancher UI, use Helm to install the rancher-monitoring chart into the cluster directly.

We need to add the following to the release note:
In order to set nodeSelector or tolerations to the rancher-monitoring-crd chart, you need to install the rancher-monitoring-crd and rancher-monitoring chart by using the Helm command via command line. Rancher UI will add the support soon.

@jiaqiluo let me know if rancher/dashboard#4737 covers the UI need correctly or if the description needs updating

Rancher Setup Reproduction

Rancher version: v2.6-head(46eb9d4)
Installation option (Docker install/Helm Chart):Docker
Proxy/Cert Details: self-signed

Information about the Cluster

Kubernetes version:v1.21.6-rancher1-1
Cluster Type (Local/Downstream):Downstream aws/ec2
4 worker nodes, 1 etcd nodes, 1 control plane node

Each worker node should have a taint added to it during the configuration steps. For example: qa=test:noschedule

To Reproduce

Go to the apps and marketplace, install monitoring and the previously mentioned version
While waiting for install to process you can check whether the pods are being deployed or whether the app "rancher-monitoring-crd" is working in the "installed apps" page.
Once you see it's failed, use the kebab menu of the CRD to "edit/upgrade"
On the yaml page add tolerations equivalent to the previously created taints. For example:

tolerations:
- key: "qa"
  operator: "Equal"
  value: "test"
  effect: "NoSchedule"

Click save and return to the installed apps page.
View the yaml of the crd from the kebab menu and notice the previously added tolerations are not listed.

Setup For Validation

Rancher version: v2.6-head(0d14421)
Installation option (Docker install/Helm Chart):Docker
Proxy/Cert Details: self-signed

Information about the Cluster

Kubernetes version:v1.22.4
Cluster Type (Local/Downstream):Downstream aws/ec2
4 worker nodes, 1 etcd nodes, 1 control plane node

Each worker node should have a taint added to it during the configuration steps. For example: qa=test:noschedule

Steps For Validation
Test case 1:

In the downstream cluster with the aforementioned configuration try install monitoring v100.1.0+up19.0.3
Let rancher-monitoring-crd get to a failed state by waiting approximately 10 minutes.
Once the app is in a failed state edit the yaml to have the appropriate tolerations and that should allow for the app to be installed.

Test case 2:

Download the kubeconfig files for the local cluster and the aforementioned downstream cluster.
Download the charts-dev-v2.6 repository from the rancher repository
From either your file explorer go to charts-dev-v2.6-->charts-->rancher-monitoring-crd-->100.1.0+up19.0.3
within this directory you will edit the following yaml --> "values.yaml" _example below: _

tolerations:
- key: "qa"
  operator: "Equal"
  value: "test"
  effect: "NoSchedule"

now take the kubeconfig for your downstream cluster and copy it to the last mentioned path: charts-dev-v2.6-->charts-->rancher-monitoring-crd-->100.1.0+up19.0.3/<downstreamcluster.yaml>
now run the command:

export KUBECONFIG=<localcluster.yaml>
7. The previous command lets you run the following to install rancher-monitoring-crd via a helm install _example below:  _
helm install rancher-monitoring-crd . -n cattle-monitoring-system --create-namespace --kubeconfig <downstreamcluster.yaml>
Results
The rancher-monitoring-crd is successfully installed following either steps.

Confirmed that in Rancher UI v2.6.3 removing the old version (100.1.0+up19.0.3) and installing the latest (v100.1.2+up19.0.3) from the UI succeeded.


can't set attribute

Hello,I try to repeat this experiment.But an error occured in nem_model.py. It's the 42 line: self.input_shape = input_shape. The error is can't set attribute.I tried the solution:self.input_shape = self.input_shape._replace(input_shape ),but it sill can't work. It throw another exception:NEMCell has no attribute name "_inbound_nodes". Preciate for any answer!

Emm…thank you, maybe my tensorflow's version  is too high…


Update notification a bit too agressive.

I know that you want to notify the users about the new updates, but it hits a bit too frequently, to the point of being kinda annoying.
Even if you update to the latest version, it still pops up.

It doesn't show anything when you update to last version though

It does. I have the latest version and it still pops up.

What message do you get? Are you sure you're on 3.1.4?

Hmm, i updated the file manually, but it seems that Firefox still thinks its on 3.0.2. I know i replaced the file with the 3.1.4 update... Im guessing it needs to be reinstalled for it to take effect, cus it does work fine except the constant message.

Try pressing "Reload" button on extension

I dont have a reload button on it, only a on/off toggle. anyway, ill reinstall it.


Recover funds

Hello, was wondering how can I recover funds I sent to the contract ?

Hello, was wondering how can I recover funds I sent to the contract ?

Did you make a profit bud? Can this run as is on BSC?

Look in closed issues, this has been addressed

Hello, was wondering how can I recover funds I sent to the contract ?

Did you make a profit bud? Can this run as is on BSC?

Unfortunately no, I keep getting Nonce too low and I can't figure out why.
As for BSC you should be able to but I don't think its worth.


Add Issuer instead ClusterIssuer

The ClusterIssuer will be unable to locate the selfsigned-ca-tls secret, particularly when Cert Manager v1.14.x is running in a different namespace than Firefly.
Updated the Kubernetes resource definitions to use Issuer instead of ClusterIssuer for the self-signed issuer, ensuring it operates within the namespace scope.

Hey @mario-bam thanks again. So there was some intention behind ClusterIssuer in case you wanted to use it across multiple different namespaces, for a FF installation in each.
Rather than change the issuers, I'd suggest we ensure the Certificate's namespace is configurable, or matches where the docs install cert-manager, to avoid your issue.
Please note - anything in manifests/ folder is not supported for production use as its outside of the scope of the chart and is there for a reference and CI tests.

@EnriqueL8  @hfuss , the namespace has been added, and the ClusterIssuer has been returned as well. There is a workaround when cert-manager is in a different namespace than Firefly and it can't find the selfsigned-ca-tls certificate. This can be resolved by adding an additional argument in the cert-manager deployment: '--cluster-resource-namespace=firefly'.


debug mode should add a "reset state" button

It would be the equivalent of ?reset but no editing of the URL required.

Completed as part of the Advanced Dropdown


Fixes deprecation Spree::RoleConfiguration.configure with solidus v2.5.0

After the release of solidus v2.5.0, the Spree::RoleConfiguration.configure is working in a different way. The Solidus commit is the following:
https://github.com/solidusio/solidus/commit/43ffb90c25ecacd080d046d073656b3c7c23a58c
This branch fixes the deprecation message and it works now with the new Spree::Config.roles approach.

This branch fixes the deprecation message and it works now with the new Spree::Config.roles approach.
...and makes impossible to use this gem with Solidus v2.4.2

Hello @VitaliyAdamkov
As you know, changes between solidus 2.4.x and 2.5 were quiet significant. Many things are not working with the latest gem versions. If you cannot migrate to solidus 2.5 yet, I recommend to set your solidus_user_role gem to get a particular commit/version in your Gemfile, so it will use the version compatible with 2.4.x. (maybe this https://github.com/boomerdigital/solidus_user_roles/commit/94a289aeb1b0061dd65f6491d51069ff15079417 or this https://github.com/boomerdigital/solidus_user_roles/commit/b6181e815ea2753850667d646380b78495368bc0) ?
Let me know what you think.
Regards

Hi @memotoro , thanx for your response.
Issue was successfully solved, referencing to 94a289a commit, as you suggested.
Though it's pity enough to lose all later commits to this pretty useful gem, keeping in mind not so stable Solidus v.2.5


*.txt, *.tpl, *.htm, *.html, *.md should always use eol=lf

1. What does this change do, exactly?
Make sure on Windows, checkout these files in EOL = LF in order to pass unit tests
and when git config core.autocrlf is set to true
Update .gitattributes file only
4. Checklist

[X] I have written tests and verified that they fail without my change
[x] I am willing to help maintain this change if there are issues with it later

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Linquize seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Thank you for the PR, we will get this reviewed.   Can you see any potential issues with doing this?

No potential issues. Windows user can still edit these files with notepad++ that can handle eol=lf

once you sign the license Contributor Agreement we can get this merged.

email added

Thank you for the PR, we will get this reviewed. Can you see any potential issues with doing this?

this has potential for breaking vendored packages.
https://github.com/kubernetes/kubernetes/issues/71177
line ending settings should be only on the user side.

cc @tobya

Opened an issue for this: https://github.com/mholt/caddy/issues/2348

@neolit123 @cblecker We'd happily accept a quick PR to fix it.


Implemented non zero block testnet list in WalletsActivity when use…

Added horizontal list of blockchains in WalletsActivity to show case the non zero blocks when testnet is active.

hi @keval-finimble , pls check the lint errors and Unit test job which is failed.

hi @keval-finimble , pls check the lint errors and Unit test job which failed.

hi @keval-finimble , pls check the lint errors and Unit test job which failed.

re-open, accidentally closed

@keval-finimble can you check the source commit I just made and all the //TODO - JB comments. You can make the code quite a bit more simple by checking those.
Also you may want to simplify that error handler with the nested if statements, you can could check if you can chuck custom errors and handle those in their own methods.


updating schema to support new options

updating schema to reflect additional options that can be passed in to CoreOS now.
After this goes in "rootPassword" will always need to be passed in the body of a POST workflow until this bug is resolved https://github.com/RackHD/RackHD/issues/493
@srinia6 @dalebremner @keedya @tannoa2 @geoff-reid @uppalk1

depends on https://github.com/RackHD/on-http/pull/529

BUILD on-tasks #1743 : FAILURE

** BUILD build-config-setup  #158638: SUCCESS

** BUILD unit-tests  #10058: UNSTABLE

** BUILD on-taskgraph #1706: FAILURE

BUILD unit-tests  #10058  Error Logs  ▼Test Name: install-coreos-spec.js "before all" hook: Validate canonical data
Error Details: data should have required property 'rootPassword'
Stack Trace: Error: data should have required property 'rootPassword'
    at validateData (spec/lib/task-data/schemas/schema-ut-helper.js:100:20)
    at SchemaUnitTestHelper._validate (spec/lib/task-data/schemas/schema-ut-helper.js:170:17)
    at Context.<anonymous> (spec/lib/task-data/schemas/schema-ut-helper.js:153:18)

BUILD on-tasks #1744 : FAILURE

** BUILD build-config-setup  #158705: SUCCESS

** BUILD unit-tests  #10059: UNSTABLE

** BUILD on-taskgraph #1707: FAILURE

BUILD unit-tests  #10059  Error Logs  ▼Test Name: install-coreos-spec.js "before all" hook: Validate canonical data
Error Details: data should have required property 'rootPassword'
Stack Trace: Error: data should have required property 'rootPassword'
    at validateData (spec/lib/task-data/schemas/schema-ut-helper.js:100:20)
    at SchemaUnitTestHelper._validate (spec/lib/task-data/schemas/schema-ut-helper.js:170:17)
    at Context.<anonymous> (spec/lib/task-data/schemas/schema-ut-helper.js:153:18)

test this please

BUILD on-tasks #1746 : FAILURE

** BUILD build-config-setup  #158765: SUCCESS

** BUILD unit-tests  #10065: SUCCESS

** BUILD on-taskgraph #1710: FAILURE

** BUILD build-config-setup  #158767: SUCCESS
** BUILD unit-tests  #10066: FAILURE

BUILD on-tasks #1745 : UNSTABLE

** BUILD build-config-setup  #158731: SUCCESS

** BUILD unit-tests  #10061: UNSTABLE

** BUILD smoke-test  #3772: SUCCESS

** BUILD on-taskgraph #1709: SUCCESS

** BUILD build-config-setup  #158732: SUCCESS
** BUILD unit-tests  #10062: SUCCESS

** BUILD on-http #2826: SUCCESS

** BUILD build-config-setup  #158734: SUCCESS
** BUILD unit-tests  #10063: SUCCESS

BUILD unit-tests  #10061  Error Logs  ▼Test Name: install-coreos-spec.js "before all" hook: Validate canonical data
Error Details: data should have required property 'rootPassword'
Stack Trace: Error: data should have required property 'rootPassword'
    at validateData (spec/lib/task-data/schemas/schema-ut-helper.js:100:20)
    at SchemaUnitTestHelper._validate (spec/lib/task-data/schemas/schema-ut-helper.js:170:17)
    at Context.<anonymous> (spec/lib/task-data/schemas/schema-ut-helper.js:153:18)

test this please

:+1:


fix unintended side effects from PR-#9.

remove class “sv-visibility-hidden” regardless of whether a move is executed or not, as this class gets added on click and not on move.
this results in the element disappearing (being hidden by sv-visibility-hidden) if its not moved (it source and destination are the same upon drop)
you can see this on the demo page with helpers.

fix addresses the same issue as PR #61


Implement endpoint to get all events since a block height

Similarly to /txs/since/:height, but returning events instead of transactions. Could be called /events/since/:height.
This would make it easier to catch-up with missed events, without having to implement separate code to extract relevant updates out of transactions.
Internally, bwt should create the events based on the transaction data, rather than keeping the events themselves around. This ensures that no events will be missed even if bwt is down while they happen.

Implemented in 9d619f76a973edde12dc2355a307ff0a89f3a4ff.


lock dotenv gem to < 3

Fixes #712
This is a 🐞 bug fix.

[X] The test suite passes (run bundle exec rspec to verify this)

Summary
dotenv 3.0 introduces breaking changes which break Jets::Dotenv.load! in a way which causes the lamda function's environment to be corrupted on jets deploy
The test suite shows this failure so the necessary tests are already present.

Closed in favor of #718  Thanks for the PR though!


Typing activities blow up in live bot

                        await turn.SendActivities(new[]{
                            MessageFactory.Text(@"Stopping server..."),
                            Activity.CreateTypingActivity()});

Works great in emulator, blows up in Azure with a nullref exception down in Botbuilder core.
also tried
                        var typing = turn.Activity.CreateReply();
                        typing.Type = ActivityTypes.Typing;
                        await turn.SendActivity(typing);

w/ the same result.

Would you be so kind as to edit and include the full stack trace?

That's not good. Working on a Repro now. Can you include the stack trace? That would make this much quicker to turn-around.

@brandonh-msft  what channel are you using out of curiosity?

As a quick workaround, here's Jason's comment on this in the v3 SDK earlier today.
It's probably the same problem, with the same fix.

@JasonSowers  has confirmed this is working properly.
"the second code snippet is working in emulator, webchat, and facebook.  However in webchat it is not actually displaying the typing indicator"

@brandonh-msft using the code below I was able to send a typing activity in the emulator, facebook, and webchat.  It did not blow up at all the only thing that was an issue for me was that in webchat the typing indicator was not actually displayed, but the code ran just fine.  Can you please provide more detail and context?
using System.Threading.Tasks;
using Microsoft.Bot;
using Microsoft.Bot.Builder;
using Microsoft.Bot.Builder.Core.Extensions;
using Microsoft.Bot.Schema;

namespace AspNetCore_EchoBot_With_State
{
    public class EchoBot : IBot
    {
        /// <summary>
        /// Every Conversation turn for our EchoBot will call this method. In here
        /// the bot checks the Activty type to verify it's a message, bumps the
        /// turn conversation 'Turn' count, and then echoes the users typing
        /// back to them.
        /// </summary>
        /// <param name="context">Turn scoped context containing all the data needed
        /// for processing this conversation turn. </param>
        public async Task OnTurn(ITurnContext context)
        {
            // This bot is only handling Messages
            if (context.Activity.Type == ActivityTypes.Message)
            {
                // Get the conversation state from the turn context
                //var state = context.GetConversationState<EchoState>();

                var typing = context.Activity.CreateReply();
                typing.Type = ActivityTypes.Typing;
                await context.SendActivity(typing);
                // Bump the turn count.
                //state.TurnCount++;

                // Echo back to the user whatever they typed.
                //await context.SendActivity($"Turn {state.TurnCount}: You sent '{context.Activity.Text}'");
            }
        }
    }
}

I think Steve is correct.  It blew up in Teams stack trace below:
   at Microsoft.Bot.Builder.TurnContext.<>c__DisplayClass22_0.<<SendActivities>g__ActuallySendStuff|1>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Bot.Builder.TurnContext.<SendActivitiesInternal>d__26.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Bot.Builder.TurnContext.<SendActivities>d__22.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Bot.Builder.TurnContext.<SendActivity>d__21.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at AspNetCore_EchoBot_With_State.EchoBot.<OnTurn>d__0.MoveNext() in C:\source\gitHub\botbuilder-dotnet\AspNetCore-EchoBot-With-State\EchoBot.cs:line 32

Yup @Stevenic  is right the following code worked:
                    var typing = context.Activity.CreateReply();
                    typing.Type = ActivityTypes.Typing;
                    typing.ReplyToId = context.Activity.Recipient.Id;
                    await context.SendActivity(typing);

@JasonSowers will update CreateReply tomorrow to make sure this is always filled out. Note that it only fails with Teams.
Note: I think this thread highlights that Bug Reports really need to be more detailed. I'll talk with the team tomorrow, and make sure we have a Bug Template.

That code is no longer working after about 5 successfully sent typing activities, it blows up everytime now.

My example occurred in Skype.

Fixed in #480


Build: Make main aware 0.8.0

Summary
Update main branch to aware the latest release 0.8.0
Checklist
Delete items not relevant to your PR:

[ ] Unit and integration tests covering the common scenarios were added
[ ] A human-readable description of the changes was provided to include in CHANGELOG
[ ] For significant changes, documentation in https://github.com/ClickHouse/clickhouse-docs was updated with further explanations or tutorials

ping @mzitnik

@pan3793 Thanks


biber-for-tectonic, tectonic-with-biber: wrap tectonic with biber-2.17, fix #88067

Description of changes
The version of biber is strongly coupled to the TeX-like system it works with. For example, the biber version required by tectonic is not found in nixpkgs, since the texlive bundle used by tectonic lags behind the one in nixpkgs. This has been a known issue. Previously, a user had to manually download (or pin nixpkgs to) a particular version of biber to use with the appropriate TeX system, in this case, tectonic.
In this PR we introduce a biberVersions package set to hold alternative versions of biber required by other TeX systems in nixpkgs. Currently there is only one variant, biberVersions.biber_2_17, which works with the current tectonic. At the same time, we provide a wrapper tectonic-with-biber, which bundles tectonic with the appropriate version of biber. This fixes #88067.
The PR is organized as follows:

maintainers: add myself
biber: refactor to expose biberSource for ease of override; this is a trivial refactor and does not rebuild biber
biberVersions.biber_2_17: provide biber v2.17 to be used by tectonic, commit myself as a maintainer
tectonic-with-biber: wrap tectonic with biber v2.17 for it to function properly, commit myself as a maintainer

Note that this PR does not affect pre-existing packages such as biber and tectonic themselves. We only extend on top of these packages with biberVersions.biber_2_17 and tectonic-with-biber, for maximal backward compatibility.
Some nixpkgs code  by @collares and @doronbehar is recycled for use in this PR. I will wait for the latest staging-next to be cached, and then do a nixpkgs-review.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[x] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Hi Doron! Thank you very much for the comment!

I'm not sure I like this approach... It is a bit too overwhelming IMO. Why not simply create a biber2_17 attribute, that will overrideAttrs of biber, and we'll comment near it that tectonic is it's purpose?

Yeah, that's perfectly fine! In fact, that's the first thing that I tried, but I later settled on the biberVersions abstraction because by doing this, when it comes to updating biber, everything can be done by updating biber/versions.nix, without touching any other file. We don't need to touch all-packages.nix or biber at all.

The downside of wrapping Tectonic though, is that Tectonic may break again in the future when the Tectonic's TeX bundle will be updated but no new Tectonic version will be released, because we will find out about it too late, and then again we'd have to force Tectonic to use the newer Biber.

Yes, I agree and I share all your concerns. The reason I chose to do this now is that the tectonic development is slowing down. This is bad news for tectonic but good news for downstream, since it would not be too difficult to keep up. Also since I am a keen user of both biber and tectonic, I have committed myself to be the maintainer (of the wrappers).

I was thinking, perhaps we can force Tectonic to use a web bundle that we know for sure is compatible with a certain Biber package? Then at least we know we will overcome the downside presented above.

That's brilliant, but I am not sure whether there is an API for that in tectonic...

I have simply the structure of biberVersions in biber/version.nix. Now there is no change of biber/default.nix.
However, we need to do biber.override { version = ...; } first and then .overrideAttrs, otherwise the meta.name attribute would be wrong. It seems that this is due to the wrapping of mkDerivation by buildPerlModule.

but I later settled on the biberVersions abstraction because by doing this, when it comes to updating biber, everything can be done by updating biber/versions.nix, without touching any other file. We don't need to touch all-packages.nix or biber at all.

I agree that touching all-packages.nix is a headache :) Still you can create that derivation in a separate file, (use pkgs/by-name/bi/biber-for-tectonic to further ease yourself).

I was thinking, perhaps we can force Tectonic to use a web bundle that we know for sure is compatible with a certain Biber package? Then at least we know we will overcome the downside presented above.

That's brilliant, but I am not sure whether there is an API for that in tectonic...

See the main comment of the last review about the --web-bundle Tectonic option.

Yes, I agree and I share all your concerns. The reason I chose to do this now is that the tectonic development is slowing down. This is bad news for tectonic but good news for downstream, since it would not be too difficult to keep up. Also since I am a keen user of both biber and tectonic, I have committed myself to be the maintainer (of the wrappers).

Thanks for the link! I think it should be mentioned in the comments at the biber-for-tectonic/package.nix file that this thread strengthens our motivation to maintain tectonic as we do and that biber-for-tectonic package this way. In fact, if the --web-bundle option proves to work, perhaps we can even feel confident enough to force this wrapping for main tectonic as well, and not introduce a new tectonic-with-biber attribute.
There's also the middle-way betweeen your approach and the above, which would be to provide an unwrapped tectonic.unwrapped and keep the main tectonic derivation the wrapped one.

maybe the --web-bundle option could allow us to stick to a specific bundle version which includes a biblatex version that supports our biber version we force here. Using this option needs testing though, and perhaps even documentation in the meta.longDescription.

In fact, if the --web-bundle option proves to work, perhaps we can even feel confident enough to force this wrapping for main tectonic as well, and not introduce a new tectonic-with-biber attribute.

There's also the middle-way betweeen your approach and the above, which would be to provide an unwrapped tectonic.unwrapped and keep the main tectonic derivation the wrapped one.

This is interesting, but I need some time to take a look and see how to implement that!

I agree that touching all-packages.nix is a headache :) Still you can create that derivation in a separate file, (use pkgs/by-name/bi/biber-for-tectonic to further ease yourself).

This is cool! I didn't know this! But after some thought, I think this scheme places the biber override far away from tectonic and biber, which is somewhat cumbersome.
In the end, I decided to collapse biberVersions and move the biber-for-tectonic definition to tectonic/biber.nix. Please see whether it is okay this way!

There is currently this upstream issue which prevents us to consistently override web-bundle for all cli interface. Currently, the default web bundle is hardcoded.
I am experimenting with patching tectonic to pin the hardcoded bundle; maybe that's too much? In any case, I haven't finished, but I will report back what I find.

Hey @bryango sorry for the long waiting. Well done on https://github.com/tectonic-typesetting/tectonic/pull/1131 ! I really like the general idea, though I left a comment there as you probably noticed..
I think the best way to ensure reproducibility in Nixpkgs most cleanly would be to implement the following design:

tectonic-unwrapped is a derivation that includes some version of your upstream patch https://github.com/tectonic-typesetting/tectonic/pull/1131 .
tectonic is nothing but a wrapping derivation for tectonic-unwrapped that includes both:

${biber-for-tectonic}/bin in it's $PATH

The $TECTONIC_WEB_BUNDLE environment variable ensures the above biber is compatible with the bundle.

tectonic.passthru.unwrapped could be another way to access tectonic-unwrapped.
tectonic.passthru.biber could be another way to access biber-for-tectonic.

This way, users could use the attribute tectonic-unwrapped to play around with different bundles if they wish so, and be able to also play with the feature of your patch.

Hey @doronbehar thank you for the comment! The structure you proposed looks good to me. I will wait a bit for upstream response and see what we should do. If there is no response, I will start to implement it based on our discussions!

I'm afraid your work would be forgotten while we wait for upstream, and the issue will persist and most users won't get a proper fix as proposed here. We agree upon many of the changes and they aren't too entangled to the upstream PR IMO. Let's commit to Nixpkgs in the meantime the following commits:

maintainers: add bryango
tectonic: add bryango as maintainer
biber-for-tectonic: init at 2.17 # With you & I as maintainers
tectonic: redefine it as a wrapper derivation, using biber-for-tectonic

In the last commit, add a comment that mentions your upstream PR, and that ideally the web bundle of the wrapped tectonic should use a pinned texlive bundle, to ensure reproducibility... I think you had a good phrased comment in the current PR that you can start with.

I have implemented the suggested changes!
Result of nixpkgs-review pr 273740 run on x86_64-linux (details)

4 packages built:

biber-for-tectonic
biber-for-tectonic.devdoc
tectonic
tectonic-unwrapped

I really prefer tectonic-unwrapped to be a clean Tectonic without patches. I also dislike the fact that you have to recompile tectonic just to change the URL of the bundle - I dislike it being a build time option and not a runtime option, since it takes a lot of resources to compile it...

I totally understand the desire to be perfect, but I am afraid I am running out of energy to continue... And I am getting more and more occupied in my day job :crying_cat_face: I will try to implement the remaining suggestions; the VM test is particularly interesting (I didn't know about that). For now, I will mark this PR as draft, but if you or anyone would like to build on the work here, feel free to do so!

It's OK @bryango , you have done very good job anyway. I will checkout out this PR locally and do prepare to merge the things that we agree upon. I'll leave the upstream patches aside for now.

It's OK @bryango , you have done very good job anyway. I will checkout out this PR locally and do prepare to merge the things that we agree upon. I'll leave the upstream patches aside for now.

Thank you very much! I learned quite a lot along the way. If there is anything confusing in the code that you would like me to clarify, feel free to ping me! I might code less, but I can explain.

Will merge when CI is green.

Fixed Darwin issue discovered by ofborg. Will wait for CI again..

@ofborg build tectonic

Wow awesome! Thank you very much for finishing this!


Improvement - make tone 1750Hz with timer 2-3s

Improvement - make tone 1750Hz with timer 2-3s
At the moment it is necessary to press side button twice to stop the tone.
It will be much easier to trigger 2-3s long tone by one button pressing

Better than a timer would be to send the tone WHILE the button is pressed. Then stop the tone when release.

quite good idea


costura

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

Describe the solution you'd like:

Describe alternatives you've considered:

Additional context:

### Tasks
- [ ] https://github.com/microsoft/vscode-edge-devtools/issues/2438
- [ ] https://github.com/microsoft/vscode-edge-devtools/issues/2437
- [ ] https://github.com/microsoft/vscode-edge-devtools/issues/2148
- [ ] https://github.com/microsoft/vscode-edge-devtools/issues/2422

gracias porsus

das

Hi,
Please add more information and feel free to reopen.


[5.9] Add the drop_deinit instruction

The drop_deinit instruction is a marker for a following destroy instruction to suppress the call of the move-only type's deinitializer.
SILGen needs to insert drop_deinit in move-only deinitializers to avoid that - due to other optimizations, like inlining - the deinitializer call is inserted multiple times.
rdar://105798769
This is a cherry-pick of https://github.com/apple/swift/pull/65060

@swift-ci test

@swift-ci test


Persistent volumes: probably a bug when restart the marathon app (click the restart button)

When restart the marathon app(click the restart button via web interface), there is one more instance id in the app instance list with status WAITING, as well as the app volumes list also show the same case. Is this a bug? Or Is this a feature?

This is a bug that got fixed in 1.1.0-RC1.
Please use this version.


Latest version is broken,

forked your stakblitz demo updated to the latest version of your pacakage and it's doesnt load the inputs.
types are also giving an error
 There are types at 'c:/dev/Projects/node/tresjs/node_modules/v-tweakpane/dist/index.d.ts', but this result could not be resolved when respecting package.json "exports". The 'v-tweakpane' library may need to update its package.json or typings.

https://stackblitz.com/edit/v-tweakpane-alp9fg?file=src%2FApp.vue,package.json

https://stackblitz.com/edit/v-tweakpane?file=src/App.vue
Updated with latest version!


elm-spa.dev website is down and theres no other place for documentation apparently

You can run it locally. It's also good example how elm-spa looks like. But this is a hotfix not permanent solution.

Hey @NikosEfthias - elm-spa is still in alpha, and hasn't been officially launched yet!
When the docs website is live, I'll make an announcement and encourage folks to try it out!
Hoping to share the official site soon :)


Ansi colors not working in devops agent, does not always respect "NO_COLOR", only works with "__SuppressAnsiEscapeSequences"

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
Running powershell scripts in Azure DevOps agent, by turning on the "Use PowerShell Core" option. Even though Azure DevOps is unable to display ansi colors, pwsh still prints them into the logs. If environment variable NO_COLOR is assigned, it reduces the amount of ansi colors printed.
This is probably the exact same issue as mentioned here closed few weeks ago: https://github.com/PowerShell/PowerShell/issues/19188
Expected behavior
Expected to see clear output without ANSI colors messing up the whole thing generally in Azure DevOps because it is unable to render them. If that's not possible to do by default, at least when NO_COLOR is specified.

Actual behavior
Dir by default:

2023-07-13T06:42:19.8478852Z     Directory: D:\DevOpsAgent\_work\r5\a\BuildTools
2023-07-13T06:42:19.8478970Z
2023-07-13T06:42:19.8480977Z Mode                 LastWriteTime         Length Name
2023-07-13T06:42:19.8481434Z ----                 -------------         ------ ----

Dir fixed when NO_COLOR defined:
2023-07-13T06:54:04.2713978Z     Directory: D:\DevOpsAgent\_work\r5\a\BuildTools
2023-07-13T06:54:04.2714057Z
2023-07-13T06:54:04.2852758Z Mode                 LastWriteTime         Length Name
2023-07-13T06:54:04.2854940Z ----                 -------------         ------ ----

Looks ok so far, but then if an error happens:
2023-07-13T08:03:54.6876706Z Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
2023-07-13T08:03:54.6877395Z At D:\DevOpsAgent\_work\_temp\5505d246-fe88-4efd-b7fb-ccb93a66f2cb.ps1:9 char:3

When environment variable __SuppressAnsiEscapeSequences defined, then this is fixed too:
2023-07-13T08:08:11.1173976Z Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
2023-07-13T08:08:11.1175015Z At D:\DevOpsAgent\_work\_temp\f49db8aa-a65b-4b52-bccc-839d8d14f63f.ps1:9 char:3

### Error details

_No response_

### Environment data

```powershell
Name                           Value
----                           -----
PSVersion                      7.3.5
PSEdition                      Core
GitCommitId                    7.3.5
OS                             Microsoft Windows 10.0.20348
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Visuals
No response

I also experience this, using pwsh as a custom build step running pwsh.exe -file $path/script.ps1:
$ErrorActionPreference = 'Stop'
$PSStyle.OutputRendering = "plaintext"
# horrible hacky hackity hack - https://github.com/PowerShell/PowerShell/issues/19188
# this also suppresses the output for me, where nothing else has yet...
# $env:__SuppressAnsiEscapeSequences = 1

Write-Host "PSVersionTable", $PSVersionTable
$log = Get-Item 'C:\...\x64\Release\reverse-.7b77e999.tlog'
Select-String -path $log -pattern '^\^.+\RTTI[.]CPP' -context 0,1

WITHOUT $env:__SuppressAnsiEscapeSequences I get:
1>  Performing Custom Build Step
1>  PSVersionTable [PSVersion, 7.3.6] [PSEdition, Core] [GitCommitId, 7.3.6] [OS, Microsoft Windows 10.0.22621] [Platform, Win32NT] [PSCompatibleVersions, System.Version[]] [PSRemotingProtocolVersion, 2.3] [SerializationVersion, <IP_ADDRESS>] [WSManStackVersion, 3.0]
1>  Select-String: C:\...\class-layout.ps1:14
1>  Line |
1>    14 |  Select-String -path $log -pattern '^\^.+\RTTI[.]CPP' -context 0,1
1>       |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1>       | The string ^\^.+\RTTI[.]CPP is not a valid regular expression: Invalid pattern '^\^.+\RTTI[.]CPP' at
1>       | offset 7. Unrecognized escape sequence \\R.
1>  C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(294,5): error MSB3073: The command "pwsh.exe -file "C:\...\class-layout.ps1"
1>  C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(294,5): error MSB3073: :VCEnd" exited with code 1.

Any updates on this?

Thanks __SuppressAnsiEscapeSequences is working for me in Azure Automation

Thanks for mentioning the __SuppressAnsiEscapeSequences environment-variable workaround, but it's not a real solution, given the comment made by a team member in https://github.com/PowerShell/PowerShell/issues/19188#issuecomment-1601562724:

we're a little concerned about your use of __SuppressAnsiEscapeSequences as it is a __* variable which are generally (and traditionally) internal variables. (which is one of the reasons it's not documented)

As hinted at in the initial post, the problem surfaces when the PowerShell CLI process' stderr output is redirected, as the following simple repro demonstrates:
$psi =  [System.Diagnostics.ProcessStartInfo] @{
    FileName  = 'pwsh'
    # Pass a command that succeeds and normally produces colored output, and one that produces error output.
    Arguments = '-NoProfile -Command Get-Item .; Get-Content \nosuch123'
    # Redirect (capture) both stdout and stderr.
    RedirectStandardOutput = $true
    RedirectStandardError = $true
  }
$psi.Environment.Add('NO_COLOR', 1)
($ps = [System.Diagnostics.Process]::Start($psi)).WaitForExit()
# OK: Captured stdout output is not colored, as requested.
$ps.StandardOutput.ReadToEnd()
# !! BROKEN: Captured stderr output shouldn't be colored either, but currently is.
$ps.StandardError.ReadToEnd()

You'll get output such as the following:

That is, NO_COLOR was honored only for the redirected stdout output, not also for the redirected stderr output.
Note that not redirecting stderr does not surface the problem (without such a redirection, the PowerShell CLI actually sends it error output to stdout(!) - see #7989).


board: m5stack-core2 module support

This Pull-Request features support for the M5Stack Core2 hardware. The module features a LCD display, touchscreen, battery, USB-Port, 8MB RAM and 18GB Flash.
Basic features are working. See board documentation for details.
Signed-off-by: Martin Kiepfer<EMAIL_ADDRESS>

Very cool!
It doesn't have to be through this PR but it would be nice to have a binding for the MBUS header, as this will make it easier to start adding M5 shields that "just work" :)

MBUS

Can you describe this idea on more detail? Are you referring to the Module BUS M5 is offering (https://docs.m5stack.com/en/module/bus)?
There are generally a lot of other functionalities missing yet (gauge, audio, ...). But I want to add additional functionality in future.

I mean describing the pin headers similar to how it's done for say Arduino R3 headers, grove connectors, or Raspberry Pi 40-pin headers. You should be able to find examples easily by searching the code base. Thanks to this, shield definitions for M5Stack modules would conveniently be able to reference pins from the header, with Devicetree then automagically "routing" them to the corresponding pins of the ESP32. Plus you could also define aliases like m5stack_i2c or m5stack_spi.
Here's the description of the pin mappings for the M5Stack Core2: https://static-cdn.m5stack.com/resource/docs/products/core/core2/core2_mbus_01.webp
Hope this helps clarify!

I mean describing the pin headers similar to how it's done for say Arduino R3 headers, grove connectors, or Raspberry Pi 40-pin headers. You should be able to find examples easily by searching the code base. Thanks to this, shield definitions for M5Stack modules would conveniently be able to reference pins from the header, with Devicetree then automagically "routing" them to the corresponding pins of the ESP32. Plus you could also define aliases like m5stack_i2c or m5stack_spi.
Here's the description of the pin mappings for the M5Stack Core2: https://static-cdn.m5stack.com/resource/docs/products/core/core2/core2_mbus_01.webp
Hope this helps clarify!

Thank you. I've understood and like the idea. I will add this functionality in a separate PR.

Typo in commit message has been corrected.

Any further comments, change requests?

@MrMarteng Is the M5stack and M5stack core2 that different? IIUC major differences are missing PSRAM and a few sensors on the older M5stack board. But otherwise, it seems to be very similar boards.

@MrMarteng Is the M5stack and M5stack core2 that different? IIUC major differences are missing PSRAM and a few sensors on the older M5stack board. But otherwise, it seems to be very similar boards.

I am not an expert on the basic/core module, but to my assessment there are quite a view differences to core2 version. The basic has 3 only buttons, the core2 has 3 touch-buttons and a touch-screen. Core2 comes with a more advanced power-management, which was most of the work I needed to invest to get the core2 module running (#59768, #58809).
Depending if the basic module is still available on market, it might make sense to add support for this module as well. This PR only focuses on core2 module.

Depending if the basic module is still available on market, it might make sense to add support for this module as well. This PR only focuses on core2 module.

@MrMarteng The M5stack core is still available and is based on the same CPU as the new Core2. So I think your work is solid ground for supporting the older module if someone chooses to.

I mean describing the pin headers similar to how it's done for say Arduino R3 headers, grove connectors, or Raspberry Pi 40-pin headers. You should be able to find examples easily by searching the code base. Thanks to this, shield definitions for M5Stack modules would conveniently be able to reference pins from the header, with Devicetree then automagically "routing" them to the corresponding pins of the ESP32. Plus you could also define aliases like m5stack_i2c or m5stack_spi.
Here's the description of the pin mappings for the M5Stack Core2: https://static-cdn.m5stack.com/resource/docs/products/core/core2/core2_mbus_01.webp
Hope this helps clarify!

Thank you. I've understood and like the idea. I will add this functionality in a separate PR.

While the "M5bus" thing can definitely come in a follow up PR, could you please add the mapping for the grove connector, since this one should be pretty trivial. See ex. https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/wio_terminal/grove_connectors.dtsi - I believe this is GPIO21 and GPIO22 that are exposed through the Grove connector.
Thank you! FWIW I am ordering a Core2 as I am typing this, and I am looking forward to putting together a video demo for my Zephyr Weekly Update as soon as this gets merged ;-)

[...] I believe this is GPIO21 and GPIO22 that are exposed through the Grove connector.

mmm actually no, that's 32 and 33.

Rebased to latest main.
Added additional fix for latest gpio get_direction unit test.

This is good to go from my perspective! Thanks @MrMarteng!
Thanks.

Can't wait to get I2S support on ESP32 ;-)
Yes indeed ;-). And I would also love to see SMP working again to speed up graphical performance.

@MrMarteng please address the dtsi include and fix the incorrect m5stack-core2_defconfig as requested by the review.

@MrMarteng please address the dtsi include and fix the incorrect m5stack-core2_defconfig as requested by the review.

@marekmatej Did you see my comment on the dtsi include? The m5stack does not feature the wrover module. The design is just aligned on the wrover board.

@MrMarteng please address the dtsi include and fix the incorrect m5stack-core2_defconfig as requested by the review.

@marekmatej Did you see my comment on the dtsi include? The m5stack does not feature the wrover module. The design is just aligned on the wrover board.

@MrMarteng sure, I did read it, but you probably missed my replies ;)
With the increasing number of comments, it is getting harder to read the conversation, so I asked for specific changes in the code. Please take a look at it.

@marekmatej FWIW pending means that you forgot to actually submit your review :)

@marekmatej FWIW "pending" means that you forgot to actually submit your review so only you can see this :)

ok I see, my bad folks! but there was a few comments that were submitted and visible, but not replied :)

@marekmatej, @kartben Thank you both for the effort you put into this PR!


T02.03-Exercise-DisplayUrl: Why use e.printStackTrace ?

Just a small nitpick. Why are you using e.printStacktrace here:
https://github.com/udacity/ud851-Exercises/compare/T02.03-Exercise-DisplayUrl...T02.03-Solution-DisplayUrl#diff-6c3a9934179a9ce7753ae20d129e383fR61
The lesson sequence just explained using the Log apis to log error messages right before that exercise, so why isn't that being used here to log the error properly?

@kdvolder issues are not the right place for asking questions. You should use the forum instead https://discussions.udacity.com/c/standalone-courses/developing-android-apps

This is not a question, but a suggestion for improving the code in the tutorial.

BTW: If you don't think this is important enough to fix, then I understand. Feel free to close this issue, I will not be offended. Just trying to help in whatever small way, to make the tutorial content a little better. Like I said, its only a 'small nitpick' and not really something important.

Oh okay, my fault then, I just misunderstood you and thought it was a question.
I think the best way to do it would be Log.e(String tag, String msg, Throwable tr)
Sorry for the bad formatting but I am using the mobile version.
Just in case you haven't done it yet, you can open a pull request with this improvement so they can merge it to their repo.

Sorry, but reporting the issue is as far as I'm personally going with this. If whoever is maintaining these repo's doesn't think its worth fixing then just go ahead and close the issue.

omg what a retard lol


Release for Scala 3.0.0 M3

Dear Monocle Devs,
from what I have read in the doc monocle is released for scala 3.0.0 M3. However, I cannot find monocle dependency for scala 3.0.0-M3 in maven central: https://repo1.maven.org/maven2/com/github/julien-truffaut/
Is it a the place right place to look for it?
Best regards,
Romain

Hi Romain, sorry for the confusion. I updated the website too early, there is no version release for Scala 3.0.0-M3 yet.
The latest version currently available is https://github.com/optics-dev/Monocle/releases/tag/v2.1.0
We intend to release the first milestone of Monocle 3.0.0 by Wednesday this week. It will be available for Scala 3.0.0-M3 and Scala 2.13.

Dear Julien,
thanks for your answer. I'm eager to try this new version !
FYI just a bit of context: we implement large simulation model (million of agents and million of cells) and Monocle is a very elegant way to compress the model data while keeping the code logic readable. An example of that can be found here: https://github.com/eighties-cities/h24/blob/master/src/main/scala/eighties/h24/social.scala. In this model we animate 8 millions human agents with sociological attributes and we make it fit in less than 2GB of RAM. The model I am starting now is about dengue epidemic at the scale of an entire city.
Romain

That sounds awesome. I will update this ticket as soon as the new version is released.
FYI, I am going to present Monocle 3 on Thursday: https://www.meetup.com/Scala-Berlin-Brandenburg/events/275841617/

Great ! Thank for the link.

@romainreuillon It is available. Here is the release note:
https://github.com/optics-dev/Monocle/releases/tag/v3.0.0-M1

:+1: :champagne:


Feature Request: support gradle 3.x

There are tests failures with gradle 3.3.
Failures:

  1) Gradle Dependencies show both file-based jars and downloaded dependencies
     Failure/Error: expect(java_developer).to be_seeing_line 'data.json-0.2.3.jar, unknown, unknown'
       expected `#<LicenseFinder::TestingDSL::User:0x007fc928971320 @output="\nFAILURE: Build failed with an exception...ad'\n\tfrom /Users/pivotal/.rbenv/versions/2.3.1/bin/license_finder:23:in `<main>'\n", @exit_code=1>.seeing_line?("data.json-0.2.3.jar, unknown, unknown")` to return true, got nil
     # ./features/features/package_managers/gradle_spec.rb:25:in `block (2 levels) in <top (required)>'

Finished in 2 minutes 22.6 seconds (files took 0.28884 seconds to load)
60 examples, 1 failure, 1 pending

Failed examples:

rspec ./features/features/package_managers/gradle_spec.rb:22 # Gradle Dependencies show both file-based jars and downloaded dependencies

/Users/pivotal/.rbenv/versions/2.3.1/bin/ruby -I/Users/pivotal/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rspec-support-3.5.0/lib:/Users/pivotal/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.4/lib /Users/pivotal/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.4/exe/rspec --pattern ./features/\*\*/\*_spec.rb --color --format d failed

This was an issue with the fixture for the test.  As of Gradle 3.3, it appears fileTree only accepts an array; whereas, previously it accepted a string or an array.
I committed the the fix.


PicklingError when trying to pickle a VSC randobj

Is it possible to pickle a class that has the @vsc.randobj decorator? I get a PicklingError when trying to do something like this code below. Using the dill module instead of pickle results in the same error.
import vsc
import pickle

@vsc.randobj
class Sample():
    pass

obj = Sample()
string = pickle.dumps(obj)

Running that results in this error:
Traceback (most recent call last):
  File "test_vsc.py", line 10, in <module>
    string = pickle.dumps(obj)
_pickle.PicklingError: Can't pickle <class 'vsc.rand_obj.Sample'>: attribute lookup Sample on vsc.rand_obj failed

Good question, @smccans. Can you share a bit more about your intended usecase? My understanding is that Pickling is used to capture some 'persistent' view of an object that can be stored and/or transported, then 'restored' to its original state. I'll have to give thought to what state, exactly, would need to be stored in order to reconstruct the object.
I will try to read up a bit on Pickling. I suspect there are some hooks that can be used to properly handle corner cases like 'vsc.rand_obj'.
-Matthew

I'm trying to create a vsc.rand_obj and do some randomization on one system and then send that object over the network to one or more other systems. I could just send the seed and do the randomization again on the other systems, but I thought I might get a little better performance by just doing the randomization once.
As a workaround for now, I'm using jsonpickle to encode the vsc.rand_obj as a json string. Then I replace "vsc.rand_obj" in that json string with the correct module path ("main" in my original example). This seems to be working so far.


[Feature Request]: i want to add solution of "Minimum indexed character" Problem

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
it will show solution of "Minimum indexed character" Problem.
Use Case
user can easily see solution if they did not got solution after very try.
Benefits
user can easily see solution if they did not got solution after very try.
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

hey @Ajay-Dhangar , please assign me this issue as GSSOC'24 contributor.
after 2 3 solution added i have mastery in it now.