Adding Typography plugin to windi config breaks intellisense

Currently running windicss with the cli. Can't get it to work unless I use a .cjs` config file, otherwise I get the following error:
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /blog/windi.config.js
[1] require() of ES modules is not supported.

Using the following windi.config.cjs works fine, until I add the plugins section, and then intellisense stops working in vscode... If I comment out the plugins section, intellisense works again.  Super weird! Also, the plugin gets loaded, and works correctly, so it just seems to affect intellisense, not actual plugin functionality.
module.exports = {
  theme: {
    extend: {
      colors: {
        dark: '#264653',
        h_dark: '#545863',
        h_blue: '#454ADE',
        h_yellow: '#EDF42A',
        h_orange: '#F96E46'
      },
      textColor: {
        h_iris: '#454ADE',
        h_mand: '#F4753E',
        h_yellow: '#EDF42A',
        h_orange: '#F96E46',
        h_blue: '#454ADE',
        h_black: '#545863',
        primary: '#3490dc',
        secondary: '#ffed4a',
        danger: '#e3342f'
      }
    }
  },
  plugins: [require('windicss/plugin/typography')]   <-- can comment this out and intellisense works again
}

Might be somewhat related to #149.

please check if you have updated everything to the latest version. The bug with the typography plugin was fixed by the latest version I guess

https://github.com/windicss/windicss-intellisense/issues/144

Yes, I had 0.17.2 installed, which looks like it's the latest version.  It even happens on a completely blank project.  Steps to reproduce:

Brand new vscode project with two files: blank index.html and blank windi.config.cjs.
Add <div class="bg-light-100" />. Intellisense works great.
Change blank windi.config.cjs to have just:

module.exports = {
   plugins: [require('windicss/plugin/typography')]
 }

Go back to index.html and try to add another class, intellisense won't load.

/stale


PowerShell coerces pipeline object to string to bind parameter, instead of choosing property that matches type and alias name

Steps to reproduce
class Foo {}
class Bar {
  [Foo]$Foo
  [string]$FooStr
}
$bar = [Bar]::new()
$bar.Foo = [Foo]::new()
$bar.FooStr = 'abc'

function Fn {
  [CmdletBinding()]
  param(
    [Parameter(ValueFromPipelineByPropertyName, Mandatory)]
    [Alias('FooStr')]
    [string] $Foo
  )
  return $Foo
}

$bar | Fn

Expected behavior
Output abc
Actual behavior
Output: Foo
Having an arbitrary class instance be coerced to a string of the class name is unexpected. I'd expect a type error if no other alias matches, and in the case where there is an alias defined that actually matches a property with the correct type, it should prefer that.
Concrete real world case: PowerGit Get-GitBranch returns a LibGit2Sharp.Branch object, which has a Repository property of type  LibGit2Sharp.Repository, and a PowerShell ScriptProperty RepositoryName of type string which is parsed out of the remote URL.
PSGitHub cmdlets like Get-GitHubPullRequest have a mandatory -Repository parameter of type string, which is annotated with ValueFromPipelineByPropertyName and aliased to RepositoryName. I would expect to be able to pipe the branch object to this cmdlet and PowerShell to bind the RepositoryName property, instead it coerces the Repository property to the class name "LibGit2Sharp.Repository" and passes that, which obviously does not make sense. PSGitHub then fails because it cannot find a GitHub repository with that name.
Environment data

Name                           Value
----                           -----
PSVersion                      6.2.1
PSEdition                      Core
GitCommitId                    6.2.1
OS                             Darwin 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Trace-Command ParameterBinding logs:
> Trace-Command -Name ParameterBinding -Expression { $bar | Fn } -PSHost
DEBUG: ParameterBinding Information: 0 : BIND NAMED cmd line args [Fn]
DEBUG: ParameterBinding Information: 0 : BIND POSITIONAL cmd line args [Fn]
DEBUG: ParameterBinding Information: 0 : MANDATORY PARAMETER CHECK on cmdlet [Fn]
DEBUG: ParameterBinding Information: 0 :     BIND arg [] to parameter [foo]
DEBUG: ParameterBinding Information: 0 :         Executing DATA GENERATION metadata: [System.Management.Automation.ArgumentTypeConverterAttribute]
DEBUG: ParameterBinding Information: 0 :             result returned from DATA GENERATION:
DEBUG: ParameterBinding Information: 0 :         COERCE arg to [System.String]
DEBUG: ParameterBinding Information: 0 :             Parameter and arg types the same, no coercion is needed.
DEBUG: ParameterBinding Information: 0 :         BIND arg [] to param [foo] SUCCESSFUL
DEBUG: ParameterBinding Information: 0 : CALLING BeginProcessing
DEBUG: ParameterBinding Information: 0 : BIND PIPELINE object to parameters: [Fn]
DEBUG: ParameterBinding Information: 0 :     PIPELINE object TYPE = [Bar]
DEBUG: ParameterBinding Information: 0 :     RESTORING pipeline parameter's original values
DEBUG: ParameterBinding Information: 0 :     Parameter [foo] PIPELINE INPUT ValueFromPipelineByPropertyName NO COERCION
DEBUG: ParameterBinding Information: 0 :     BIND arg [Foo] to parameter [foo]
DEBUG: ParameterBinding Information: 0 :         Executing DATA GENERATION metadata: [System.Management.Automation.ArgumentTypeConverterAttribute]
DEBUG: ParameterBinding Information: 0 :             result returned from DATA GENERATION: Foo
DEBUG: ParameterBinding Information: 0 :         BIND arg [Foo] to param [foo] SKIPPED
DEBUG: ParameterBinding Information: 0 :     Parameter [foo] PIPELINE INPUT ValueFromPipelineByPropertyName WITH COERCION
DEBUG: ParameterBinding Information: 0 :     BIND arg [Foo] to parameter [foo]
DEBUG: ParameterBinding Information: 0 :         Executing DATA GENERATION metadata: [System.Management.Automation.ArgumentTypeConverterAttribute]
DEBUG: ParameterBinding Information: 0 :             result returned from DATA GENERATION: Foo
DEBUG: ParameterBinding Information: 0 :         COERCE arg to [System.String]
DEBUG: ParameterBinding Information: 0 :             Parameter and arg types the same, no coercion is needed.
DEBUG: ParameterBinding Information: 0 :         BIND arg [Foo] to param [foo] SUCCESSFUL
DEBUG: ParameterBinding Information: 0 : MANDATORY PARAMETER CHECK on cmdlet [Fn]
DEBUG: ParameterBinding Information: 0 : CALLING EndProcessing
Foo

I'd almost call this expected behaviour. The default .ToString() behaviour is to return the class name, which is what will happen here in this binding...
I do agree that if there's a better type match under an alias name that it should still be selected though. 👍
Not sure if it qualifies as a bug, but the handling here could absolutely be improved. 😄

I'd say it's not expected, because what's the point of a [string] type annotation if anything goes (because everything can be ToString()ed).
Even if you say that it should be coerced, you can't even force the string to not get chosen through ValidatePattern() - the parameter will still be bound and then fail validation with an error, instead of picking the other property that would pass.

Yeah, that's fair. The logic probably wasn't coded with the expectation that there would be multiple properties that could possibly match with different types.

Something similar has hit me, and I think it's more likely than at first indicated by the OP.  Consider:
function ProcessString {[cmdletbinding()]Param([Parameter(ValueFromPipeline, ValueFromPipelineByPropertyName)] [string]$p) process { write-host "p value <$p>, type $($p.gettype())"}}
function ProcessInt    {[cmdletbinding()]Param([Parameter(ValueFromPipeline, ValueFromPipelineByPropertyName)] [int]$p)    process { write-host "p value <$p>, type $($p.gettype())"}}
function ProcessObject {[cmdletbinding()]Param([Parameter(ValueFromPipeline, ValueFromPipelineByPropertyName)] $p)         process { write-host "p value <$p>, type $($p.gettype())"}}

Then we'll feed those by pipeline value and propertyname:
> '123', 123, [pscustomobject]@{p=123}, [pscustomobject]@{p='123'} | ProcessObject
p value <123>, type string
p value <123>, type int
p value <@{p=123}>, type System.Management.Automation.PSCustomObject
p value <@{p=123}>, type System.Management.Automation.PSCustomObject

That's expected, but a small gotcha to remember that the whole custom object can be coerced to string and value bound. There's a way out of course by typing the argument:
> '123', 123, [pscustomobject]@{p=123}, [pscustomobject]@{p='123'} | ProcessInt
p value <123>, type int
p value <123>, type int
p value <123>, type int
p value <123>, type int

That's expected by type coercion and selection of the propertyname
> '123', 123, [pscustomobject]@{p=123}, [pscustomobject]@{p='123'} | ProcessString
p value <123>, type string
p value <123>, type string
p value <@{p=123}>, type string
p value <123>, type string

That's surprising. The difference between the by value binding and the by property name binding seems wrong. There's been an "accidental" string coercion of the whole pscustomobject before the parameter binder spotted the potential property binding.
In the end I had to write a ArgumentTransformationAttribute to beat the awkward coercion. That cast the [object] via [string][int] which allowed:
function ProcessId {[cmdletbinding()]Param([Parameter(ValueFromPipeline, ValueFromPipelineByPropertyName)] [Id()]  $p) process { write-host "p value <$p>, type $($p.gettype())"}}

> '123', 123, [pscustomobject]@{p=123}, [pscustomobject]@{p='123'} | ProcessId
p value <123>, type string
p value <123>, type string
p value <123>, type string
p value <123>, type string

(This did have a side-advantage that I could extract any int-like value from an incoming string-like object, so all was not lost)


plot_histogram should plot error bars

What is the expected enhancement?
plot_histogram should plot the error bars associated with distributions.

see my comment on your other issue this should go into a new function for this type of visualizations.

Closing in favor of a different route


BigQuery - 404 Not found

Hi,
We are experiencing that the on-run-end hook is trying to send a query to BigQuery, inserting data to a table that does not yet exist.
We can see that it sends a query to BigQuery, but this fails as the table does not already exist. I assume we're not supposed to create the table and schema beforehand (no information about this is given in the quickstart).
The error returned to dbt, directly from BigQuery:
404 Not found: Table "<our_project:our_dataset>".model_executions was not found in location EU
Worth mentioning - The profile used has sufficient rights to create new tables within this dataset.
Query that BigQuery tries to run (which looks ok in my opinion) :
    /* {"app": "dbt", "dbt_version": "1.3.0", "profile_name": "xxx", "target_name": "xxx", "connection_name": "master"} */

    insert into our_project.our_dataset.model_executions
    VALUES

    (
        'c6e11536-4c12-497b-8e84-89b1b65bd3e8',
        'model.xxx.xxx',
        '2022-10-26 13:06:30.837610+00:00',
        False,
        'Thread-1',
        'success',

                    '2022-10-26 13:06:35.238630',

                    '2022-10-26 13:06:40.023520',

        4.786630868911743,
        safe_cast('76637' as int64),
        safe_cast('16114509' as int64),
        'table',
        'xxx',
        'xxx'
        )`

This is  compiled state of stg_dbt__seed_executions.sql and giving syntax issue in bigquery @lanchett have you seen something like that?

    select *
    from `dlake`.`dbt_artifacts_source`.`seed_executions`

),

enhanced as (

    select

    to_base64(md5(CAST(coalesce(cast(command_invocation_id as STRING), '') || '-' || coalesce(cast(node_id as STRING), '') as STRING))) as coalesce(cast(command_invocation_id as STRING), '') || '-' || coalesce(cast(node_id as STRING), '')_hash
 as seed_execution_id,
        command_invocation_id,
        node_id,
        run_started_at,
        was_full_refresh,

    split(
        thread_id,
        '-'
        )[safe_offset(1)]

 as thread_id,
        status,
        compile_started_at,
        query_completed_at,
        total_node_runtime,
        rows_affected,
        materialization,
        schema, -- noqa
        name,
        alias
    from base

)

select * from enhanced```

Note: This is not the only one but I am writing this one as a sample

Hi @lanchett .
It looks like the issue you were having has been kindly resolved by @charles-astrafy , so I am going to close this issue. However, please feel free to reopen it and let me know if not.
Fwiw, I have added additional instructions in PR #297 which will hopefully address the lack of documentation around how to build the tables prior to using the post-run hook too - thank you for your feedback on this.
@calkan-cue it looks like your question may be related to something slightly different. Please could you raise a separate issue with details of what error messages you are seeing, so that I am able to help you to debug it? Thanks!


kubectl exec not working as expected on EKS AMIs with GPU support

What happened:
On EKS nodes running AMIs with GPU support, kubectl cannot pipe STDIN to running containers using kubectl exec. Consequently, some other things don't work either, such as kubectl cp or attaching VSCode to a container running on such a node.
How to reproduce it (as minimally and precisely as possible):
The following command yields an empty file in the pod running on a GPU-enabled node while the file is non-empty on other nodes without GPU support:
cat nonempty_file.txt | kubectl exec -i pod -- tee /home/jovyan/empty_file.txt
This has been tested using the exact same image/container on both nodes.
Anything else we need to know?:
There's been a bit of discussion of this issue on Stack Overflow and in the nvidia-docker repository on GitHub.
While it could be an issue with nvidia-docker, Azure doesn't suffer from this problem. So at the very least, there must be a workaround.
Environment:

AWS Region: ap-southeast-2
Instance Type(s): p3.2xlarge
EKS Platform version: eks.8
Kubernetes version: 1.14
AMI Version: ami-038df8ee88d869e42

@itssimon does AKS use nvidia-docker? I am 99% sure GKE doesn't, since they also have their own GPU plugin daemonset.

Not sure actually. I don’t have access to an AKS cluster anymore.
There appears to be a fix for EKS that simply involves updating docker-ce and nvidia-docker in the AMI:
https://github.com/emypar/aws/tree/master/eks/gpu-node-stdin-patch
This was pointed out in https://github.com/NVIDIA/nvidia-docker/issues/1091#issuecomment-622926550.

For anyone not following the other issue, as I just mentioned there, I found a simpler fix that requires just a couple of megabytes over  avoids the risks of changing Docker versions:
yum swap -- remove docker-runtime-nvidia \
         -- install nvidia-docker2-2.2.2-1 nvidia-container-runtime-3.1.4-1
systemctl try-restart docker

It would be great if anyone could confirm that it works for them, too.

And... I think the bug is actually in the obscure oci-add-hooks, which is a custom AWS tool. See   https://github.com/awslabs/oci-add-hooks/issues/5

We will release a new AMI with fix pretty soon. It will come with docker 19 with latest nvidia-docker.

More details:
docker-runtime-nvidia adds a nvidia runtime under /etc/docker-runtimes.d/
#!/bin/sh
exec /usr/bin/oci-add-hooks --hook-config-path /usr/share/docker-runtime-nvidia/hook-config.json --runtime-path /usr/bin/docker-runc "$@"

/usr/share/docker-runtime-nvidia/hook-config.json:
{
  "hooks": {
    "prestart": [
      {
        "path": "/usr/bin/nvidia-container-runtime-hook",
        "args": ["/usr/bin/nvidia-container-runtime-hook", "prestart"]
      }
    ]
  }
}

If we remove docker-runtime-nvidia,  following dropin.conf will fail to start because it can not find nvidia runtime. anymore.  We should remove --default-runtime=nvidia  to unblock docker start. Since Nvidia has been added as devices in docker 19.03. We don't need runtime anymore.  docker will use right runc to start container if nvidia gpus are requested.
We should keep oci-hook for other devices.
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock $OPTIONS $DOCKER_STORAGE_OPTIONS $DOCKER_ADD_RUNTIMES \
	--default-runtime=nvidia

For nvidia-docker2 users, it will let docker use nvidia-container-runtime for runtime nvidia. This is configured in /etc/docker/daemon.json.  Underneath, it will call nvidia-container-runtime-hook to check if container uses GPU or not, then use libnvidia-container to expose the GPU.
{
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}

To mitigate the issue, add back nvidia-docker2 helps and we will release latest version with nvidia-docker and docker 19.03 soon.  (nvidia-docker2 has been deprecated)

@Jeffwan Do you have an estimate on the release date of the fixed AMI?

This seems fixed with latest v20200609 release

@ArchiFleKs correct, this has been resolved with latest release. Closing the issue.


Electron ID requirement not working 100%

For every good Electron, a lot of the requirements are correct, e.g. PdgId
ak.sum((abs(electronPdgId[:, 0:1]) == 11)) Out[12]: 10198
However, ElectronTightId is still of by a small margin
ak.sum(events.ElectronTightId[:, 0:1]) Out[13]: 9863

This is fixed by redefining the veto leptons in the commit 53eb20d. Now every lepton we consider in this analysis is at least a veto lepton to.


[ci] fix CircleCI builds by adding back ruby_version parameter to the workflows

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[ ] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[ ] I see several green ci/circleci builds in the "All checks have passed" section of my PR (connect CircleCI to GitHub if not)

Motivation and Context
CircleCI hasn't been running in PRs or master, or it's intermittent at its best. E.g.:

This regressed when we merged this PR of mine: https://github.com/fastlane/fastlane/pull/21735
Description
What is weird is that it was sometimes running and sometimes not running anymore, in master, see 4/4 (CircleCI didn't run) vs 5/5 (CircleCI ran):

Moving forward we really need to add CircleCI to the list of required checks in this repo.
I also took the opportunity to change the super vague name of the workflow from build to Run Tests & Checks:

Testing Steps
Pass CI and check that CircleCI ran in this PR.

With the CI fixed, now it finds 4 lint violations—which were likely introduced by other PRs, back when the CI was not always running the linter, letting those go thru the cracks. We should probably use the occasion of this PR to fix those violations.

@AliSoftware I actually had opened a separate PR for those 😅 do you mind? https://github.com/fastlane/fastlane/pull/21747

I think we should merge that one first, then rebase this one and see if everything passes 👀

Yep, especially since the PR where you fixed those violations only ran the 4 checks, not 5:

So merging this PR first then rebasing https://github.com/fastlane/fastlane/pull/21747 on top should hopefully fix it.

All good @AliSoftware 💪


Peer-Reviewed Academic Journal Article and Dissemination - Digital Inheritance in Web3: A Case Study of Soulbound Tokens and Social Recovery Pallets within the Polkadot and Kusama Ecosystems

Project Abstract

This proposal is to create a peer-reviewed academic case study for applying soulbound tokens within the Polkadot and Kusama ecosystems by leveraging the Social Recovery pallet and soulbound token use cases developed by the Phala Network and RMRK for digital inheritance. This will be a qualitative case study where we will conduct a literature review of soulbound tokens and interview team members and developers of the Phala Network, as well as team members from RMRK. In addition to the research on soulbound tokens, we will also interview Parity Technologies members who are familiar with the development of the Social Recovery pallet to investigate how it can be applied to digital inheritance.

Grant level

[ ] Level 1:  Up to $10,000, 2 approvals
[x] Level 2:  Up to $30,000, 3 approvals
[ ] Level 3:  Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

[x] The application template has been copied and aptly renamed (project_name.md).
[ ] I have read the application guidelines.
[ ] A BTC, Ethereum (USDT/USDC/DAI) or Polkadot/Kusama (aUSD) address for the payment of the milestones is provided inside the application.
[ ] The software delivered for this grant will be released under an open-source license specified in the application.
[ ] The initial PR contains only one commit (squash and force-push if needed).
[ ] The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
[ ] I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

Thank you for submitting the grant proposal. I have some doubts about the research and its context.
The authors work for universities and SydTek. In name of which entity the authors will be publishing the study, and for which reason? There are any conflicts of interest between any entities involved?
As with any grant-funded research, if approved, an acknowledgment statement about the grant is expected to be declared in the body of the paper. How the authors would handle possible bias and threats to the validity of the study if it is funded by w3f?
The authors expect to perform any comparison between w3f/parity solutions with others like Vault12 and Safe Haven?
How the sessions to share the findings of the study will be held? Will be some specific events? What is the profile and number of people expected? Did you consider submitting the paper for a conference instead of a journal to share the findings of the study?

@dsm-w3f, thank you for sending over this feedback. Please see my responses below to each question.
@jgophd thank you for submitting the grant proposal. I have some doubts about the research and its context.
** The authors work for universities and SydTek. In name of which entity the authors will be publishing the study, and for which reason?**
Justin Goldston from Penn State University will be the Principal Investigator (PI), and graduate students from other universities will contribute to the research. There are no conflicts of interest in this research.
There are any conflicts of interest between any entities involved?
There are no conflicts of interest in this research. The following statement will be added to the study:
"The authors declared that there are no conflicts of interest in the authorship and publication of this contribution."
** As with any grant-funded research, if approved, an acknowledgment statement about the grant is expected to be declared in the body of the paper.**
The following statement will be added to the study to declare the acknowledgment of the grant.
"This research study was funded by the Web 3 Foundation, a non-profit entity that looks to create a decentralized and fair internet where users control their own data and identity."
How would the authors handle possible bias and threats to the validity of the study if it is funded by w3f?
A section will be included in the study for the scope and delimitations that will outline the steps taken to reduce researcher bias. Additionally, in the limitations section, we will disclose that the researchers had preconceptions before the study was conducted (Hasson et al., 2000). We will go on to note that this purposive sampling approach could be viewed as a strength of the study as we evaluated both the Vault12 and Safe Haven projects (Elledge & McAleer, 2015). Finally, to address the concerns of validity in the study, we will validate our approach by referencing studies from researchers such as Ampatzoglou et al., (2019) and Cruzes and ben Othmane (2017) to address that concern.
References
Ampatzoglou, A., Bibi, S., Avgeriou, P., Verbeek, M., & Chatzigeorgiou, A. (2019). Identifying, categorizing and mitigating threats to validity in software engineering secondary studies. Information and Software Technology, 106, 201-230.
Cruzes, D. S., & ben Othmane, L. (2017). Threats to validity in empirical software security research. In Empirical Research for Software Security (pp. 275-300). CRC Press.
Elledge, R. O., & McAleer, S. (2015). Planning the content of a brief educational course in maxillofacial emergencies for staff in accident and emergency departments: A modified Delphi study. British Journal of Oral and Maxillofacial Surgery, 53(2),
109-113.
Hasson, F., & Keeney, S. (2011). Enhancing rigour in the Delphi technique research. Technological Forecasting and Social Change, 78(9), 1695-1704.
The authors expect to perform any comparison between w3f/parity solutions with others like Vault12 and Safe Haven?
Initially, we weren’t going to view it as a comparison. We were going to discuss the current capabilities of Vault12 and SafeHaven and discuss the current state of these projects from a digital inheritance perspective in the literature review. Also, in the literature review, as Vitalik Buterin and the Ethereum Foundation have discussed social recovery mechanisms and wallets, they are primarily focused on the use case for lost keys. In the Zilliqa ecosystem, Tyron SSI created a social recovery wallet based on the research conducted by Vitalik and the Ethereum Foundation. Additional research on our end will have to be done to see if the Tyron SSI wallet could perform digital inheritance types of capabilities.
Please see a few references below:
https://ethresear.ch/t/sovereign-social-recovery-mechanism/12709
https://vitalik.ca/general/2021/01/11/recovery.html
https://cryptoslate.com/social-recovery-now-available-on-zilliqa-at-a-fraction-of-the-cost-of-ethereum/?amp=1
https://vault12.com/amp/vitalik-buterin-social-recovery-2652780545
How the sessions to share the findings of the study will be held? Will be some specific events?
The research will be disseminated at Georgetown University, McGill University, and virtually to students of the blockchain club at Kings College in the UK.
What is the profile and number of people expected?
If you all agree with disseminating research at universities and blockchain clubs, clubs will range from 30 to over 100 students. We also have connections with Faculty Directors at a number of graduate programs. For example, we are doing an event at Georgetown University on October 20th, and graduate students from the Technology Management, Strategic Digital Transformation, Cybersecurity Risk Management, Supply Chain, traditional MBA, and Law programs have shown interest in this session. Outside of Computer Science students, introducing non-technical students and conventional researchers to Web3 with this approach, we can potentially uncover additional use cases for a variety of different pallets, bringing in new researchers, developers, users, and industries within the Web3/Parity/Polkadot/Kusama ecosystems.
Did you consider submitting the paper for a conference instead of a journal to share the findings of the study?
When you say conference, are you referring to academic conferences, professional technology conferences such as IEEE, Web 3/Parity/Polkadot conferences, or general blockchain conferences? We did consider submitting this as a conference paper, but some of those conferences are not recorded, and we were looking for reach and immediate application with this study. If we disseminate this research at universities and blockchain clubs such as those previously mentioned, we can share these findings with developers and users that could respond to our calls to action, build the Web3 community, as well as potentially accelerate the development of this digital inheritance tool using the Social Recovery pallet. Additionally, we will be live streaming these sessions, and we have connections with students and blockchain clubs globally that normally watch the events we post on YouTube at a later date.

@jgophd thank you for the reply.

In my opinion, comparing w3f/parity based solution with other in a grant-funded research by w3f could lead to doubts about bias in the comparison. In this way, if any comparison would be performed is important to be based on facts and not opinions. This could reduce the bias and mitigate this threat to the validity of the study.

When you say conference, are you referring to academic conferences, professional technology conferences such as IEEE, Web 3/Parity/Polkadot conferences, or general blockchain conferences?

I was thinking in peer-reviewed academic conferences since the proposal is for peer-reviewed academic paper. As you proposed a dissemination of the study, this could be a way of doing it. There are some good specific conferences on blockchain, see the print bellow from google scholar. This was just an idea, feel free to select the proper venue for your research.

Thank you again for your proposal, no more questions from my side.

@dsm-w3f, thank you for your quick response. I just wanted to circle back and respond to your comments.
> In my opinion, comparing w3f/parity based solution with other in a grant-funded research by w3f could lead to doubts about bias in the comparison. In this way, if any comparison would be performed is important to be based on facts and not opinions. This could reduce the bias and mitigate this threat to the validity of the study.

The research will be based on facts by citing the referenced project's whitepapers, along with peer-reviewed articles on the topic of digital inheritance, such as the article below:
Singh, R. G., Shrivastava, A., & Ruj, S. (2022). A digital asset inheritance model to convey online persona posthumously. International Journal of Information Security, 1-21.
> I was thinking in peer-reviewed academic conferences since the proposal is for peer-reviewed academic paper. As you proposed a dissemination of the study, this could be a way of doing it. There are some good specific conferences on blockchain, see the print bellow from google scholar. This was just an idea, feel free to select the proper venue for your research.
Thank you for sharing this. I initially thought about submitting this study to Frontiers in Blockchain as they reached out to me last year to be a contributor to that journal. I will look into the dates for these conferences as Jordi and/or myself would be open to presenting at these conferences in addition to the defined universities.

@semuelle, per your last message, please see the changes from 'developed materials' to 'raw data'.

Thanks for this application. I have renamed some of your deliverables to make them more expressive and left two questions. Other than that, I am happy to support this.

@semuelle, I have now responded to these questions. Thanks again for your review and assistance on this.

Thanks for the quick reply, @jgophd, but my questions were how you would make them accessible, and if it would be also the raw data. It would be nice if you could phrase the specification accordingly.

Thanks for the quick reply, @jgophd, but my questions were how you would make them accessible, and if it would be also the raw data. It would be nice if you could phrase the specification accordingly.

@semuelle Thank you for this. I updated each section with the following comment. "All developed materials and raw data will be publicly accessible and public domain via a GitHub repository."

@jgophd thanks a lot for your application. This looks great and we're generally interested in supporting more research projects. However, please note that as a rule of thumb we only fund the development/research work itself, not any related costs such as infrastructure or, in your case, in-person presentations and travel costs. See our FAQ in this regard. The treasury is a much better-suited source of funds for such activities. I suggest you remove deliverable 1a. from milestone 3 and apply for Treasury funding to promote the article when you're ready.
Feel free to redistribute the costs among all milestones, since I think deliverable 1 currently also accounts for the actual writing of the article but only covers the submission costs.

@jgophd thanks a lot for your application. This looks great and we're generally interested in supporting more research projects. However, please note that as a rule of thumb we only fund the development/research work itself, not any related costs such as infrastructure or, in your case, in-person presentations and travel costs. See our FAQ in this regard. The treasury is a much better-suited source of funds for such activities. I suggest you remove deliverable 1a. from milestone 3 and apply for Treasury funding to promote the article when you're ready.
Feel free to redistribute the costs among all milestones, since I think deliverable 1 currently also accounts for the actual writing of the article but only covers the submission costs.

@alxs Thank you for your feedback. I have redistributed the costs for more researchers, which will provide a more well-rounded study. Please let me know if this is what you are looking for.

Thanks for the quick reply, @jgophd, but my questions were how you would make them accessible, and if it would be also the raw data. It would be nice if you could phrase the specification accordingly.

@semuelle Thank you for this. I updated each section with the following comment. "All developed materials and raw data will be publicly accessible and public domain via a GitHub repository."

@semuelle, are the revisions what you were looking for?

Thanks @jgophd. Could you please fill in your first comment, which I've replaced with our comment template?

Thanks @jgophd. Could you please fill in your first comment, which I've replaced with our PR comment template?

@alxs, thank you for your quick response. I have populated the first comment per your request.

Congratulations! Your application has been accepted, but the bot didn’t post the welcome message here, because it was merged into the wrong folder. I updated it. And here is the official text:
Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.
Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at<EMAIL_ADDRESS>and we'll be happy to collaborate on an announcement about the work you’re doing.
Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! :rocket:

Hi @jgophd just checking in to see how milestone 3 is coming along?

Hi @jgophd just checking in to see how milestone 3 is coming along?

@keeganquigley, I hope all is well. The team is waiting to hear back from IEEE, and the submission is under manuscript ID Access-2023-06036. Per direction in Milestone 2, the pre-print of article was uploaded to arXiv - arXiv preprint arXiv:2301.11074 - and can be found at Google Scholar - https://bit.ly/3oDJLxt - and at university libraries just as Penn State University - https://bit.ly/3LofgEZ.
After discussing this research with projects from other ecosystems, the team has been working with Safe Haven in the VeChain ecosystem to integrate some of the findings from this study into their base product. The overall goal is to hopefully introduce a solution on Kusama in the future. Please see more about that collaboration here - https://bit.ly/3N53Erv.
Finally, for the dissemination of the research, I will be discussing this study at Coin Bureau Live on June 10th https://live.coinbureau.com/. The Coin Bureau has 2.25 million subscribers on YouTube - https://www.youtube.com/@CoinBureau - many of which will be reviewing the livestream of the event, as well as in-person. This is the first of many engagements where I will be discussing the research as well at academic conferences in the Fall of 2023.
I will keep you updated on IEEE as I assumed you all wanted a report once the study was published in IEEE instead of arXiv.

Hi @jgophd just circling back on this to see if you ever heard back from the IEEE. Also, I think I found the correct video stream of the Coin Bureau conference but it is 8 hours long. Are you able to point to where your panel/presentation was? Just curious to watch it.
Regarding milestone 3, after talking internally with the grants team, I think you can probably go ahead and submit the delivery as is, since the arXiv version is published. That way we can finish up the grant, as waiting for IEEE could still take a long time. Let me know your thoughts. Thanks!

Hi @jgophd just circling back on this to see if you ever heard back from the IEEE. Also, I think I found the correct video stream of the Coin Bureau conference but it is 8 hours long. Are you able to point to where your panel/presentation was? Just curious to watch it.
Regarding milestone 3, after talking internally with the grants team, I think you can probably go ahead and submit the delivery as is, since the arXiv version is published. That way we can finish up the grant, as waiting for IEEE could still take a long time. Let me know your thoughts. Thanks!

@keeganquigley, sorry for the delayed response. The Coin Bureau video above is on the main stage. I discussed the digital inheritance session in another session. Also, I make revisions to the IEEE article and am waiting to hear back after those revisions. I will submit the final milestone now.


Font references stored across frames

It looks like font references are stored across frames. This will crash the Rack VST.
src/plugin.hpp
163-
164-    FlatDisplay() {
165-            std::string fontPath = asset::plugin(pluginInstance, "res/fonts/MonoBold.ttf");
166:            font = APP->window->loadFont(fontPath);
167-    }
168-
169-    void step() override {

See migration manual for more information on how to fix this.

Fixed


Resources have not been migrated to 2.0.0 logging

Do you want to request a feature, improve documentation, or ask a question?
Are you reporting a bug?
What is the current behavior?
Some resources are still depending on being supplied the logger from node-fhir-server-core.
What is the expected behavior?
All resources should include the logger on their own.
What are the steps to reproduce?
Choose a resource like Immunization and create a resource, then update it.

To anyone watching... Going to try to. have a fix for this today


Encountering issue with scanning larger datasets - TypeError in dbstore.py

With larger file counts (50M, e.g.) encountering an issue with TypeError. This is not seen with small counts (14M, e.g.). Is there a a workaround for this?
This is running with 32 processes "fprof $DIR" and seeing:
Traceback (most recent call last):
  File "/home/loewe/packages/pcircle-py3.9/bin/fprof", line 8, in <module>
    sys.exit(main())
  File "/home/loewe/treewalk-py3/local/miniconda3/envs/pcircle-py3.9/lib/python3.9/site-packages/pcircle/fprof.py", line 768, in main
    circle.begin(treewalk)
  File "/home/loewe/treewalk-py3/local/miniconda3/envs/pcircle-py3.9/lib/python3.9/site-packages/pcircle/circle.py", line 224, in begin
    self.loop()
  File "/home/loewe/treewalk-py3/local/miniconda3/envs/pcircle-py3.9/lib/python3.9/site-packages/pcircle/circle.py", line 257, in loop
    self.task.process()
  File "/home/loewe/treewalk-py3/local/miniconda3/envs/pcircle-py3.9/lib/python3.9/site-packages/pcircle/fprof.py", line 397, in process
    self.handle_file_or_dir(spath, st)
  File "/home/loewe/treewalk-py3/local/miniconda3/envs/pcircle-py3.9/lib/python3.9/site-packages/pcircle/fprof.py", line 487, in handle_file_or_dir
    self.process_dir(spath, st)
  File "/home/loewe/treewalk-py3/local/miniconda3/envs/pcircle-py3.9/lib/python3.9/site-packages/pcircle/fprof.py", line 328, in process_dir
    self.circle.enq(entry.path)
  File "/home/loewe/treewalk-py3/local/miniconda3/envs/pcircle-py3.9/lib/python3.9/site-packages/pcircle/circle.py", line 275, in enq
    self.workq_init(self.dbname, G.resume)
  File "/home/loewe/treewalk-py3/local/miniconda3/envs/pcircle-py3.9/lib/python3.9/site-packages/pcircle/circle.py", line 194, in workq_init
    self.workq_db = DbStore(self.dbname, resume=G.resume)
  File "/home/loewe/treewalk-py3/local/miniconda3/envs/pcircle-py3.9/lib/python3.9/site-packages/pcircle/dbstore.py", line 85, in __init__
    (sqlite3.Binary(str(0)),))
TypeError: memoryview: a bytes-like object is required, not 'str'

I tried changing the line to use the encode() method rather than str(), and this seems to have helped:
$ diff pcircle.orig/pcircle/dbstore.py pcircle/pcircle/dbstore.py
85c85
<                               (sqlite3.Binary(str(0)),))
---
>                               (sqlite3.Binary('0'.encode()),))

As well, there was a problem encountered subsequently in dbstore.py with:
    obj = pickle.loads(row[0].encode())
AttributeError: 'bytes' object has no attribute 'encode'

Changing to the following seems to have corrected this, too:
$ diff pcircle.orig/pcircle/dbstore.py pcircle/pcircle/dbstore.py
191c191
<                 obj = pickle.loads(str(row[0]))
---
>                 obj = pickle.loads(row[0])


Allow deploy to a custom location

Solve issue #96
Basically, this work. But no code for auto-test yet! Reading the code, I am unable to figure out how to run test locally!
How can I run tests locally? Especially, with a custom deploy-path?

As far as the standalone tests go you need to do something like this to run them locally:
cargo build
export REPOSITORY_ROOT=/path/where/you/have/cloned/cargo-web
export CARGO_WEB=$REPOSITORY_ROOT/target/debug/cargo-web
cd integration-tests
cargo run

Running ci/run_tests.sh should also work, but that will take significantly longer as it will run everything.

Oh no, +36,709 lines!!!
I added custom_deploy_path_here/* to .gitignore, but apparently not effect! I will try to read the document then try it again.

Thanks for your review!
Why do I use loop instead of for

As far as I see self is only borrowed once inside, so you should be able to turn it into a normal for loop.

    let mut iter = backends.iter();
    let error = loop {
        if let Some(backend) = iter.next(){
            let per_target = self.per_target.entry( *backend ).or_insert( Default::default() );
            if per_target.$field_ident.is_none() {
                per_target.$field_ident = Some( string_value.clone() );
            }else{
                break true;
            }
        }else{
            break false;
        }
    };
    if error {
        Err( format!( "{}: you can't have multiple '{}' defined for a single target", self.source(), stringify!($field_ident)).into())
    }else{
        Ok(())
    }

If I remember correctly. When I return this directly inside the for loop:
Err( format!( "{}: you can't have multiple '{}' defined for a single target", self.source(), stringify!($field_ident)).into())

The compiler complains about mutable of self at
let per_target = self.per_target.entry...

and immutable borrow at
self.source() // in Err(...)

(because the Err(...) is now inside the loop). Therefore, I must transform the for into what it is now.
Can we move this into Project::build from build.rs?
(hacking emscripten output)
I will try (but I am not sure if I can understand it enough to do it or not).

My original effort was to look through the emscripten manual to file some flags, but failed to find any. I end up doing the hack like that.

wasm-path/serve-path
What you want is:

By default put both .js and .wasm under serve-path.
If the user wants to put the .wasm file somewhere else then they can set wasm-path.
The path to the .wasm file in the .js file will be always consistent with what cargo web start is serving and cargo web deploy is outputting.

The first case is that the user want only serve-path. Nothing special in this case.
The second case: .js in serve-path, .wasm in wasm-path, then:

index.html have its .js src point to  /serve-path/<name>.js
.js loads .wasm from /wasm-path/<name>.wasm

in this case, serve-path is not actually/fully a served/serving path any more. (Does this cause any confusion?). And I think users that want their .wasm file (only one file) in a separate folder is very rare?
You say that you like to have a separate PR for the case where users want that their request-path (the path to load .wasm from browsers) different to the path they deploy it. I think that such a PR will modify the path where .wasm is loaded from - it is exactly what we are doing now in this PR. Why not just do it now?
To make things simpler, I propose this:
# Default value: `target/deploy`
deploy-path = "path/to/put/deploy/files"

# `wasm-serve-path` is the path under which the `.wasm` file will be served.
# This means `https://example.com/wasm-serve-path/<name>.wasm`
# Default value: `/`
wasm-serve-path = "path/to/load/.wasm/file/from/browser"

With this proposal:

We will force .js, .wasm and all files in crate-root/static/ to be placed at the root of deploy-path.
Both deploy-path, wasm-serve-path will only accept /, any \ will cause error.
deploy-path is always relative! (My intention is also allow absolute path for the case where a absolute path is simpler than a relative path. How about this case? But it is not a big thing, we can ignore this)

Why do I use loop instead of for

You can just simply run self.source() and assign it to a variable before the loop. (:

in this case, serve-path is not actually/fully a served/serving path any more. (Does this cause any confusion?). And I think users that want their .wasm file (only one file) in a separate folder is very rare?

Well, the idea is that serve-path means "the path under which the generated artifacts are served", which includes the .js and (depending on the --target) the .wasm file. That's pretty simple conceptually. And then for those who want to put the .wasm file somewhere else they can do it.
I agree that it's probably rare that someone wants to keep the .js file and the .wasm file separately. I'm fine with having that; I'm also fine with removing it for now and only keeping serve-path and deploy-path.

You say that you like to have a separate PR for the case where users want that their request-path (the path to load .wasm from browsers) different to the path they deploy it. I think that such a PR will modify the path where .wasm is loaded from - it is exactly what we are doing now in this PR. Why not just do it now?

Mostly because this PR is already very big, and in most cases it probably won't be necessary. (:
Having a different path for deployment does bring some additional complexity (e.g. we'll need to add forced rebuilding to be able to patch the filename again if someone first does cargo build and then cargo deploy, or perhaps a better idea would be to backup the original data before patching it, and then we wouldn't have to force a rebuild).

To make things simpler, I propose this: [...]

So basically - disentangle the paths to .js and .wasm, have them be set to / by default, and have them separately overridable? Hmm... I guess that is somewhat less confusing than having a shared serve-path. Okay, sounds fine to me.
However, I'd still like to keep the invariant that cargo deploy generates exactly what cargo start serves. The idea is that you can use cargo start to develop your application, and then you can cargo deploy it somewhere and run it as-is with a static HTTP server of your choice with no modification. If we'll always deploy the .wasm file to / regardless of the path set in Web.toml then we'll break that.

My intention is also allow absolute path for the case where a absolute path is simpler than a relative path. How about this case? But it is not a big thing, we can ignore this)

There are two main problems with absolute paths: 1) they're OS specific (e.g. Windows uses drive letters, Linux doesn't), and 2) they effectively make the crate unusable if you, for example, copy your project to a different directory or a different drive. So I don't think it'd be really worth supporting them? (And I don't think encouraging (2) is a good idea.)

After some long thought about this, I think we should make things simpler by

always output to the root of deploy-path
and by breaking this PR into different steps

First step: close this PR :grin:

Because you do not like big PR.
There are some conflict between this PR and the master branch now! If I make more changes on old code, maybe more conflict appears???

Second: A new PR only for deploy-path
Most users just only use deploy-path (for simple sites, or sites with few static-files)
# Default value: `target/deploy`
deploy-path = "where/to/put/deploy/files"

.js/.wasm and crate-root/static/* are always copied to the root of deploy-path.
.js/.wasm are always served at the root. It means: example.com/<name>.js and example.com/<name>.wasm.

This case, cargo web start will be no different between before and after this PR. The output (content of js files) of cargo web deploy and cargo web start are exactly the same. The only benefit provides by this PR is that cargo web deploy will put everything in the right folder (rather than target/deploy that requires further manual actions to be actually useful).
Some users may not happy because they are unable to put .js/.wasm in other folder. But they just have few files in their static folder, therefore, it is not a big problem.
Third: A new PR for serve-path
For some users who have a big site and want to serve .js/wasm under another path rather than /, for example:
http://example.com
    /               # this will serve index.html
    /users          # contents...
    /pages          # ...from...
    /posts          # ...database!
    /and
    /many
    /more
    /routes
    /here!
    /static         # all static files will be served under this route
        /other-files/*
        /<name>.js
        /<name>.wasm

In this case, because of the complexity of the project, users will want to serve all static files under a special route such as /static/. Therefore, .js/.wasm files will be served at /static/ or even deeper!
To support this, we add two more parameters:
# `serve-path` is the path under which the `.js`/`.wasm` files will be served.
# Default value: `/`
serve-path = "path/to/load/.js/and/.wasm/file/from/browser"

# `index-path` is where to put `index.html`
# Default value: Same as `deploy-path`
index-path = "where/to/put/index/html"

.js/.wasm and crate-root/static/* are still always copied to the root of deploy-path.
Of course, if there is index-path, index.html will be copied to that instead of deploy-path.
cargo web start always serves index.html at /, but all other files will be served under serve-path.
(When users serve these by their own server, I think they should know what to do).
Users must make sure that every request (from browser) for static files are prefixed by serve-path.
If users provide their own index.html, they must make sure it load .js under serve-path.
If there is no index.html, then cargo web start/deploy generates it with <script src="/server-path/<name>.js"></script>.
cargo web start will strip prefix serve-path from request-url, then just serve requested files as it does without serve-path.
The content of .js file (with serve-path inserted) will be exactly the same in both cargo web deploy and cargo web start.

There is a place in the test code (that I have written to test this current PR) that I have to hack the .js file again to pass the test successfully. It is only happen to wasm32-unknown-emscripten because I insert serve-path into the .js content in the deployment process. The content that is received from cargo web start is the modified content (cargo web start served it from memory). The .js file on disk (in folder target/wasm32-unknown-emscripten) is the original one (it is loaded and modified by deployment but not saved back to disk). When comparing these (content served by cargo web start, and content loaded from disk), I must hack it again like that.
Maybe you have concern about differences between cargo web deploy and cargo web start from that portion of code? But now, you have a demand that serve-path must be insert in the build process. The problem will just simply vanish! Because the content of .js file on disk will be the modified one!
Relative/absolute path for deploy-path?
An absolute path is better in these cases:

Users move their source code to other location/partition, but they still want to deploy to the current absolute deploy-path in Web.toml
Or even on a local network, users may move their source code from machine to machine, but always deploy to a single network location (on a server, which is rarely changed)

I still think it is better to support both relative and absolute path for deploy-path!

Sounds mostly good to me, except a few points:

Of course, if there is index-path, index.html will be copied to that instead of deploy-path.

index-path should be relative to deploy-path and be equal to /index.html by default. (That is - it should be a virtual path instead of being a physical path like deploy-path.)

Users must make sure that every request (from browser) for static files are prefixed by serve-path.

Am I misunderstanding what you just said, or are you suggesting that we should serve everything under the serve-path? I don't think that's necessary.
The static files from the $crate/static folder are currently always served from /, and there is no point in making this configurable. If the user wants those files to be served from /foobar they can always move them to $crate/static/foobar.

cargo web start will strip prefix serve-path from request-url, then just serve requested files as it does without serve-path.

Unless you're talking purely conceptually here, internally there is no need to do any fiddly stripping; the files should just be mounted under serve-path, e.g. here:
let (is_js, key) = match path.extension() {
    Some( ext ) if ext == "js" => (true, js_name.clone()),
    Some( ext ) if ext == "wasm" => (false, path.file_name().unwrap().to_string_lossy().into_owned()),
    _ => continue
}

just prepend the serve-path:
let key = format!( "{}/{}", serve_path, key );

This will automatically make the file appear in the same place with both start and deploy.

I still think it is better to support both relative and absolute path for deploy-path!

Well, I'm fine with supporting it as long as someone actually needs this feature.

This will go into detail, I just want to make sure that we are talking and thinking about exactly the same thing!
Pretend we a going to build a site name rusters, to be run at rusters.com
The rust source code that will be deployed by cargo web:
rusters/
    |--- src/
    |--- static/
            |--- images/
                    |--- background1.png
            |--- index.html

In Web.toml
deploy-path = "/path/to/rusters-static"

Then after cargo web deploy, we expect /path/to/rusters-static looks like this:
rusters-static/
    |--- other-static-files/*       # from other sources
    |--- images/
            |--- background1.png
    |--- index.html
    |--- rusters.js
    |--- rusters.wasm

Because of the complexity of the project, we want our server serves things like this:
rusters.com
    /               # serve index.html
    /users
    /posts
    /....
    /s-files        # serve all content of `rusters-static` under `s-files`

Our server code similar to:
let server = Server::new()
    .index(serve_index_html)
    .route("users", handle_users)
    .route("posts", handle_posts)
    ....
    .route("s-files", StaticFiles::new("/path/to/rusters-static"));      // under `s-files`

This way, what we expect are: (all of them have s-files)
rusters.com/s-files/images/background1.png
rusters.com/s-files/rusters.js
rusters.com/s-files/rusters.wasm

Although we deploy everything to the root of deploy-path, but they are all served under a common route s-files. Therefore, we need to tell rusters.js that the path for rusters.wasm is /s-files/rusters.wasm. And similarly, /s-files/images/*. This is why we have to use serve-path in Web.toml:
serve-path = "s-files"

If we prepend serve-path to the key of deployment::Route like:
let key = format!( "{}/{}", serve_path, key );

Then, cargo web start runs ok.
But, cargo web deploy cause a problem because it also use Route.key to create file's path. Therefore, cargo web deploy will give results like:
rusters-static/
    |--- other-static-files/*       # from other sources
    |--- s-files  # <================ this new folder
            |--- images/
                    |--- background1.png
            |--- index.html
            |--- rusters.js
            |--- rusters.wasm

With rusters-static content like this, and the server code above, all urls for static files change to: (all of them have /s-files/s-files)
rusters.com/s-files/s-files/images/background1.png
rusters.com/s-files/s-files/rusters.js
rusters.com/s-files/s-files/rusters.wasm

Maybe we could say we are running into a recursive problem??
I can only figure out two solutions for this problem:

Do not prepend serve-path to key, then we must strip serve-path from request path when runing cargo web start
Or, change deployment::Route to

struct Route {
    serve_key: String,      // use for `cargo web start`
    deploy_key: String,     // use for `cargo web deploy`
}

After we set serve-path:
serve-path = "s-files"

the deployment (both start and deploy) should look like this:
rusters-static/
    |--- other-static-files/*       # from other sources
    |--- images/
            |--- background1.png
    |--- index.html
    |--- s-files
            |--- rusters.js
            |--- rusters.wasm

If the user wants to have the index.html under s-files they should set index-path, and if the user wants to move the images directory they should move it from $crate/static/images to $crate/static/s-files/images.
Or to reiterate:

$crate/src/static/* always gets copied to $deploy_path/* and served under http://.../*
.js and .wasm are copied to $deploy_path/$serve_path/{.js, .wasm} and served under http://.../$serve_path/{.js, .wasm} (I'm also fine with splitting serve-path into separate js-path and wasm-path so that it's perhaps less confusing that it's not affecting everything that's served?)
index.html is copied to $deploy_path/$index_path and served under http://.../$index_path
$deploy_path is always at the root of what's being served at the root

If we prepend serve-path to the key of deployment::Route [...] But, cargo web deploy cause a problem

Sorry, I don't fully understand what's the problem here. (: We prepend the serve-path to the keys for .js and .wasm in Deployment, and automatically those files will be deployed to $deploy_path/$serve_path and served under http://localhost:8000/$serve_path. Then if you manually go into the $deploy_path directory and manually start your own server those files will still be served under http://localhost.$port/$serve_path. Nowhere do we get double $serve_paths. Am I missing something here?

Maybe you missed this
In this comment, maybe you missed the following line?

.js/.wasm and crate-root/static/* are still always copied to the root of deploy-path.

If you missed that line, I think I should say it more clearly that:

Both .js and.wasm and all content of crate-root/static/* are still always copied to the root of deploy-path.
Therefore, serve-path is only purely using as a serving-path, not using to make a sub folder for .js/.wasm any more.

There are only just two files (.js and .wasm), I think it is not a big problem if we force them into the root of deploy path. (Except for index.html, users can put everything else into static/sub-folders)
We are still talking about different things:

$deploy_path is always at the root of what's being served at the root

Yes, if we serve things that way, it's ok with the very first version of serve-path that we disccussed before I start this PR.
I said about a different case, where users want to put them under a route. I said it two times, and somehow you missed both. The first time in this comment, that:
http://example.com
    /               # this will serve index.html
    /users          # contents...
    /pages          # ...from...
    /posts          # ...database!
    /and
    /many
    /more
    /routes
    /here!
    /static         # all static files will be served under this route
        /other-files/*
        /<name>.js
        /<name>.wasm

The second time in this comment, that:
rusters.com
    /               # serve index.html
    /users
    /posts
    /....
    /s-files        # serve all content of `rusters-static` under `s-files`

@limira Apologies for the late reply.

I said about a different case, where users want to put them under a route. I said it two times, and somehow you missed both.

Sorry, I was a little confused, but I think I get it now... (:
Just to double check, by this:

Both .js and.wasm and all content of crate-root/static/* are still always copied to the root of deploy-path. Therefore, serve-path is only purely using as a serving-path, not using to make a sub folder for .js/.wasm any more.

... do you mean you want the serve paths to affect only two things:

the URL under which cargo web start will serve everything except index.html (.js, .wasm, and everything from the $crate/static)
and the path to the .wasm in the .js file,

but when running cargo web deploy it's going to dump everything in the root of deploy-path just as it's doing now?
Hmmm.... this is starting to get messy.
Okay, so, can we for now have a PR with only the deploy-path? That is relatively simple and uncontroversial. And I'll try to think a little more about how we should proceed with doing the rest.

At @koute's invitation I'd like to register a related feature request.  I need to, ideally using Web.toml, specify a host and path for the generated .js to use when fetching the .wasm file.
I also need to have the option to customize the specified host and path depending on the environment I'll deploy the build to and serve it from. (eg., development, production) STDWEB_ENVIRONMENT=production cargo web build or cargo web build -e production.
Example using the current behavior in development and serving from a CDN in production:
// Web.toml
[environment.production]
serve-url = "htts://cdn.example.com/v1/app.wasm"

./cargo web build -e production

I just come to say that I am currently unable to continue the work on this PR. I don't know if I may come back again to finish this or not. Thank you for all your time spending to review my work!


Error on "Enable Lore Store Options"

Hello,
I am trying to new 1.2.0 Save Editor and the Lore Points editor does not seem to work any longer. Adjusted the value, saved, reloaded and still the same value of Lore Points.
Additionally I get an error when attempting to click on "Enable Lore Store Options".

Game Version: v<IP_ADDRESS>69 epic ( Dont have the Lost Civilization Adventure Pack )
PC: Windows 10 Pro - Build 19042.804

This issue is caused by the stats not existing in the database, you do not own the DLC and start up the game to create statistics.

Yeah I should have seen that coming, I'll fix that asap so the tool still works for people without the DLC. Additionally the reason why the lore store points are not updating is probably because the Epic version has multiple profiles in the save game folder, and online and offline one an my tool is editing the wrong version for you.
Could you zip your savegame folder and upload it here so I can take a look?
I should probably give you a selection box incase there are multiple versions of the savegame files.
The savegame folder is located here: C:\Users[UserName]\AppData\LocalLow\IronOak Games\FTK\save\

I just release version 1.2.1 which might fix the issue for you it allows selection of the lore file incase there are multiple, try it out to see if that works for you!


transak

Preview https://lw-transak.oasis-wallet.pages.dev/account/oasis1qrzj88c9jzufzl0fmr9nkdsqad4xu89a4ysvpt6p/fiat-onramp

Preview

Buy flow, with random data:

step
screenshot

Open account

Open Fiat on-ramp

Transak: choose amount, Oasis Network is preselected

Transak: billing

Transak: choose payment

Transak: wallet address is prefilled

Transak pay

Transak done

Redirected back to wallet

Unlocked wallet, auto-refreshing, and waiting for transaction to arrive

Mobile navigation

Ready for review, while waiting for design

not sure what's a a plan here. shouldn't we hide this feature for now (like paratimes)?

Yeah, let's do that, so this PR doesn't drag on


Implement "all namespaces" mode

Implement "all namespaces" mode
Referenced issue:
https://github.com/redhat-appstudio/pvc-cleaner/issues/2

Pr updated.

@Michkov I handled feedback, pr updated one more time.


[DOCS]

Issue Description
Can improve styling of navbar-menus to make it more attractive from the UI prospective.
Additional Context
No response
Screenshots or Examples (if applicable)

Proposed Solution (optional)
No response
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)

@aditya-bhaumik Please assign me for this issue.

yeah i can do it! please assign under it to me.

@RAMIREDDYGAYATHRI02 stop spamming in other peoples issues
this is your first and last warning
i will block you from contributing if i see this again

this issue has been solved, so we are closing this issue.


Support PURL Data Source for Single Package Scanning

Package URL is a standard for representing a package using an URL notation. Example:
pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c
pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?repository_url=repo.spring.io%2Frelease
<EMAIL_ADDRESS><EMAIL_ADDRESS>
Having the ability to scan package URL is useful for vetting single packages. Example:
vet scan --purl<EMAIL_ADDRESS>--purl<EMAIL_ADDRESS>
We need to support a list of PURL as input and scanning them as a single virtual manifest.
This should be implemented as a reader implemented in #53

This is implemented


Second test issue for Happyfox flow

Bug description
A clear and concise description of what the bug is.
Expected behavior
A clear and concise description of what you expected to happen.
Portainer Logs
Provide the logs of your Portainer container or Service.
You can see how here
Steps to reproduce the issue:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Technical details:

Portainer version:
Docker version (managed by Portainer):
Kubernetes version (managed by Portainer):
Platform (windows/linux):
Command used to start Portainer (docker run -p 9000:9000 portainer/portainer):
Browser:

Additional context
Add any other context about the problem here.

Ticket update by Anthony McMahon<EMAIL_ADDRESS>Tell me a little bit about what is going on.

Ticket update by Anthony McMahon<EMAIL_ADDRESS>Tell me a little bit about what is going on.


[X11] Use Xft.dpi and QT_*** environment variable to get screen scaling

This should match Qt6 behavior, so Avalonia should pick up system settings out of the box

You can test this PR using the following package version. 11.0.999-cibuild0039450-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]


How to run background jobs which require Principal Propagation to SAP Backend?

I have a use case where the background job needs to access the backend system via destinations in a multi tenant app. How can i achieve this? Basically i want to run a background job with a technical user

Hi @codeyogi911,
cds.spawn should help you with your use case as described here.
cds.spawn ({ tenant:'t0', every: 1000 /* ms */ }, async (tx) => {
  const mails = await SELECT.from('Outbox')
  await MailServer.send(mails)
  await DELETE.from('Outbox').where (`ID in ${mails.map(m => m.ID)}`)
})

@alperdedeoglu I am aware about how to use cds.spawn, what I want to find out is how to run with a jwt in the background?

What kind of SAP Backend are we talking about? Can you explain the exact use case you have?

I have an SAP Onprem system connected to our multi-tenant app. We are running in the background a Auto Sales Order job. When connecting to the backend API it fails because there is no jwt. Is there a way to configure and use technical user for each tenant?
What i did currently is get the jwt using password_grant (which is not correct) and created a cds.user using this token and @sap/xssec. I am then using this user in the cds.spawn.
I feel like its a work around and there should be a way to configure and use background users.

Where exactly do you get your JWT from? By Backend API do you mean CAP API or S/4 API?

Right now as a workaround i get the jwt from the bound XSUAA using a password_grant. Backend API means S4 API using Destinations and Cloud Connector.

Right now as a workaround i get the jwt from the bound XSUAA using a password_grant. Backend API means S4 API using Destinations and Cloud Connector.

And are you using Cloud SDK or something to connect to the backend? Or have you defined a destination? How do you call the on-premise backend? Which library do you use?

I have my function to create sales order defined like:
async function createSalesOrder(orderData) {
  LOGGER.info("Creating sales order: ", cds.context.user)
  const salesSrv = await cds.connect.to("API_SALES_ORDER_SRV", {
    destinationOptions: {
      jwt: cds.context.user.tokenInfo.getTokenValue(),
    }
  })
  const result = await salesSrv.create("A_SalesOrder").entries(orderData)
  LOGGER.info("Sales order created", result.SalesOrder)
  return result
}

earlier i had it defined like:
async function createSalesOrder(orderData) {
  let salesSrv
  if (cds.context.isPrivilegedSpawn) {
    const subDomain = await getTenantSubdomain(cds.context.tenant)
    LOGGER.info("Subdomain for tenant", subDomain)
    LOGGER.info("Creating sales order for tenant using basic authentication", cds.context.tenant)
    salesSrv = await cds.connect.to("API_SALES_ORDER_SRV", {
      credentials: {
        destination: "onpremise-basic",
        path: "/sap/opu/odata/sap/API_SALES_ORDER_SRV",
      },
      destinationOptions: {
        selectionStrategy: "alwaysSubscriber",
        iss: `https://${subDomain}.authentication.eu10.hana.ondemand.com/oauth/token`,
        useCache: true,
      },
    })
  } else {
    salesSrv = await cds.connect.to("API_SALES_ORDER_SRV")
  }
  const result = await salesSrv.create("A_SalesOrder").entries(orderData)
  LOGGER.info("Sales order created", result.SalesOrder)
  return result
}

so this stopped working after the upgrading to CDS8, it somehow now gives me 401 when using onpremise-basic and even if i try in the foreground then also it gives me 401, even though it should use the onpremise in foreground.
Somehow the destination is not getting cached even after setting
"API_SALES_ORDER_SRV": {
        "kind": "odata-v2",
        "model": "srv/external/API_SALES_ORDER_SRV",
        "csrf": true,
        "csrfInBatch": true,
        "[production]": {
          "credentials": {
            "destination": "onpremise",
            "path": "/sap/opu/odata/sap/API_SALES_ORDER_SRV"
          },
          "destinationOptions": {
            "selectionStrategy": "alwaysSubscriber",
            "useCache": false
          }
        }
      },

Ok got it, can you just give the jwt with retrieving a token via client_credentials and let me know how it goes?

Hi @codeyogi911, did that work for you?


Allow multiple origin domains for CORS

This PR references 1774 contributed by @danielvijge and has been rebased on top of next.
Summary
When several domains consume an API, the CORS header Access-Control-Allow-Origin is not as useful, because it only allows one domain, or all domains (with "*"). The specs do not allow for a list of domains. This change works around this by comparing the Origin header to a list of configured domain in the array 'origin_domains'. It tests if the end of the domain matches either ".{domain}" or "//{domain}". Thus, if origins_domain="example.com, example.net", a request from Origin="http://www.example.com" would be allowed, as does a request from Origin="http://example.com". But Origin="http://my-example.com" is not allowed. In this case, no Access-Control-Allow-Origin header is set.
If both origin and origin_domains are configured, origin_domains take precedence over origin.
Full changelog

Changes to CORS plugin schema to have extra configuration for origin_domains[]
Changes to CORS plugin handler to test for multiple domain and set correct header
Changes to test script to test if the correct header is set when the origin domain matches
Changes to test script to test if the header remains empty when the origin domain does not match

Issues resolved
Fix #1043

I have added some comments on the original #1774

Replaced by #2203 with a new commit on top of yours which fixes the missing requirements. Thanks again!


Wait on gRPC readiness

Is your feature request related to a problem? Please describe.
At the moment, we're restricted to a fairly basic HTTP based wait. If would be good if we could wait on a gRPC service to become available.

Can I get assigned this task please?


docs: README Revamp

README Revamp

[x] I reviewed linter warnings + errors, resolved formatting, types and other issues related to my work
[x] The PR title follows the convention we established conventional-commit
[x] I performed a functional test on my final commit

Added some information throughout that was missing, reformatted some of the layouts that were a bit wonky, and streamlined the language for clarity and readability.

Screenshots

💯

Will let @TheoBr review this since he wrote most of the readme.

Overall good but a few small things I'd like changed:

I think it's important to have a "how to use command" as high up as possible. Down to add just the npx create-t3-app example near the top? (Maybe with a footnote linking to the "getting started" w/ the other options)
I really hate combining multiple "commands" into one code block, because you can't use the "copy" button and get what you need. Would prefer to break up the npm, yarn and pnpm options, even if it's a bit bigger :(
The two pictures near the top feels weird, might be worth moving the T3 logo OVER create-t3-app title to split them apart a bit

Other things I had thoughts on:

Not sure how I feel about the use of bullet points for visual emphasis on the first section
Also felt weird having bullet points broken out in only part 2 of the T3 Axioms 🤔

Cool, I can make those changes. And with the bullet points it was mostly just trying to get something that visually looked a little cleaner without having much control over actual GitHub markdown styling, so I'll flatten those out.

Edits are all done, I'd @ you but that's literally rule number 1.

Looks like we also have merge conflicts, please resolve them.

@nexxeln Done

Looks great! Might swap out the sub-sub-title with the npx create-t3-app to use a codeblock instead so it's insta-copy-able (doesn't need to block this tho)


[1250] expose if accrediting_provider to provider endpoint

Context
Expose accredited_body? on provider endpoint
Changes proposed in this pull request

Add accredited_body? to provider endpoint
Expand provider serializer spec

Guidance to review
/api/v2/providers

@benilovj almost pairing ;-)

 Add New Training Courses Button


🔧 IOTSTOOL-1822 Implement retry in JavaScript SDK

ConnectApi.StartNotifications() keeps retrying MAXIMUM_NUMBER_OF_RETRIES for server errors (5xx) and network errors.

Codecov Report

Merging #253 into master will increase coverage by 0.02%.
The diff coverage is 84.21%.

@@            Coverage Diff            @@
##           master    #253      +/-   ##
=========================================
+ Coverage   80.08%   80.1%   +0.02%
=========================================
  Files          78      78
  Lines        2184    2202      +18
  Branches      388     392       +4
=========================================
+ Hits         1749    1764      +15
- Misses        434     437       +3
  Partials        1       1

Impacted Files
Coverage Δ

src/connect/connectApi.ts
80.66% <84.21%> (+0.15%)
:arrow_up:

Continue to review full report at Codecov.

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


Workflow definitions

Changes introduced with this PR
This PR adds actual workflow handling.

By contributing to this repository, I agree to the contribution guidelines.

If the yaml files in this PR are going to be included in the main engine branch, they should probably be modified and renamed as example files.


mudata 0.3.0 requires python>=3.10

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

mudata 0.3.0 requires python>=3.10 (https://github.com/scverse/mudata/commit/ce28ac42c941103f1d8521a5d805777d1af3651e), but the recent update PR (#12) didn't bump the minimum required python version. This results in mudata 0.3.0 being installed in python 3.9 conda envs. This PR fixes the minimum required python version. I'll also send a repodata patch to fix the existing 0.3.0 conda binary.

@grst thanks for the review and merge!
Unfortunately no new conda binary was uploaded because the CI on the merge commit failed (https://github.com/conda-forge/mudata-feedstock/commit/a0bbfa3329676b187ae61a4375276956e2a8f73e, build). Not sure what happened since the CI passed on the PR. Could you please restart the failed build?
Here is the error message from the failed import test:
import: 'mudata'
Traceback (most recent call last):
  File "/home/conda/feedstock_root/build_artifacts/mudata_1724912300974/test_tmp/run_test.py", line 2, in <module>
    import mudata
  File "/home/conda/feedstock_root/build_artifacts/mudata_1724912300974/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.12/site-packages/mudata/__init__.py", line 17, in <module>
    from ._core.io import (
  File "/home/conda/feedstock_root/build_artifacts/mudata_1724912300974/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.12/site-packages/mudata/_core/io.py", line 23, in <module>
    from .mudata import ModDict, MuData
  File "/home/conda/feedstock_root/build_artifacts/mudata_1724912300974/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.12/site-packages/mudata/_core/mudata.py", line 18, in <module>
    from anndata._core.aligned_mapping import (
ImportError: cannot import name 'AlignedViewMixin' from 'anndata._core.aligned_mapping' (/home/conda/feedstock_root/build_artifacts/mudata_1724912300974/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.12/site-packages/anndata/_core/aligned_mapping.py). Did you mean: 'AlignedView'?
WARNING: Tests failed for mudata-0.3.0-pyhd8ed1ab_1.conda - moving package to /home/conda/feedstock_root/build_artifacts/broken

Actually I figured it out. The PR CI installed anndata 0.10.8, but the merge commit CI installed the recently built anndata 0.10.9 (https://github.com/conda-forge/anndata-feedstock/pull/41). So it looks like mudata needs the pin anndata >=0.10.8,<0.10.9. That means another patch is required...


Mishandling of the parentheses in :deep

Here is the matching test:
#[test]
fn test_56() {
    let style = style_test! {
        .fullData :deep(dl.alarm:has(dd.true) dt) {
            color: var(--bs-danger);
        }
    };
    assert_eq!(
        style,
        r#".fullData.test dl.alarm:has(dd.true) dt{color: var(--bs-danger);}"#
    );
}

@svieujot  I will try to debug an fix this issue(but it may take some time). If you are interested you can also try it.

I think most probably the bug will be parse_selector.

Either we have to fix this issue directly by changing some logics in this function or we can try to figure out more consistent solution for parsing the selector.


[Feat][Netan] Added product endpoints

Added:
GetEmployeeById
Changes:
FOR VIEW EMPLOYEES:

view -> findAll
view -> getAll
Employee.findAll returns all values of the Employee instead of just defined values, if there are no employees returns an empty array
Filtered the password for Employee.findAll in the controller

FOR TOGGLE STATUS:

Used constants for toggling don't hardcode values
Used named parameters for the query

FOR EDIT AND CREATE:

Removed image source

FOR CREATE

renamed create -> save for models

FOR EDIT:

Added error message to the not found
renamed some variables
renamed edit -> update

FOR RESET:

renamed reset -> changePassword
renamed reset in model -> savePassword
removed return value for savePassword
extracted password generation to a helper function
removed error and status of response
changed route from /:id -> /:id/password

FOR ERROR MESSAGES IN Employee:

Since employee not found string is repeating throughout employee.controller.js, I placed it in a variable called EMPLOYEE_404

BUG

There is currently a bug for employee edit, if a user edits and it is still the same email it throws an email is already in use error, when it shouldn't

It is also missing these functions for employee users

Missing role access for employees

Please implement this for products

Also missing role access for employees


plugin not replacing placeholder

Describe the bug
Hi All,
kindly I have helm,argocd and hashicorp vault.
I am implementing "Argo CD Vault Plugin" so it can read the placeholders and change it with the value from the hashicorp vault.
I tried the plugin with command line on mac device to test the plugin in argo and works perfectly for the same helmchart and connection is opened to the vault from local.
command "helm template keycloak-config ./chart-name -f chart-name/dev-values.yaml | argocd-vault-plugin generate -c /tmp/vaultconfig.yaml"
but on argocd the plugin is installed and I can deploy using it although the placeholders doesn't change for example  goes in EKS secrets  wthout changing with the value in the vault
I appreciate your support very much, it has been a week looking into this one
To Reproduce
Steps to reproduce the behavior:
install plugin with init containers and ConfigMap
Expected behavior
if the yaml has
stringData:
password: <POSTGRES_PASSWORD>
in the k8s secrets the password value goes like <POSTGRES_PASSWORD>  without getting changed
Screenshots/Verbose output
If applicable, add screenshots to help explain your problem.
If you've tried running argocd-vault-plugin generate with --verbose-sensitive-output to help debug, please include that output here after redacting any secrets.
Additional context
Add any other context about the problem here.

Can you please provide your application manifest, the full yaml with the placeholders and how you’re setting up AVP?

Hi Jacob,
Kindly I attached the following

the complete manifest "argocd.yaml" of argocd objects.
the yaml with the placeholders "secrets.yaml"

I am setting the AVP using the options "InitContainer and configuration via
argocd-cm ConfigMap" in the documentation
https://argocd-vault-plugin.readthedocs.io/en/stable/installation/
I have read in some blog that this installation not supported since version
2.4.0 although argo official documentation not stating that.
please confirm so I can act upon your reply.
Thanks,
George Halim
On Tue, Mar 21, 2023 at 1:58 PM Jacob Wernette @.***>
wrote:

Can you please provide your application manifest, the full yaml with the
placeholders and how you’re setting up AVP?
—
Reply to this email directly, view it on GitHub
https://github.com/argoproj-labs/argocd-vault-plugin/issues/479#issuecomment-1477711309,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALPFOIDIKPT2O46TBWMN2ILW5GJYFANCNFSM6AAAAAAV6YT4QQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

@gehal6 Looks like the yamls never got uploaded to github. Can you add them in the comments?

Same issue here, the secret value is created exactly as the placeholder. <path:secrets/data/helm#CUSTOM_ENV>
I ran ssh to the repo-server pod and the command argocd-vault-plugin generate worked perfect, the placeholder is changed to the secret value.
But when I sync the application, it does not work.

but if it was env vars problems, the container would not be able to run the command and make connection to vault, right?
sorry, but I didn't get the point.
I mean, the container is actually working the command when I run manually, but the argo executing the plugin is not.

I was able to fix it.
I removed the plugin configuration from the application manifest and it worked!

@kaiquerass can I know which approach did you follow in the vault plugin installation?

for people having this problem:
argo will automatically discover which plugin to use based on the discover section of the plugin, so write a discover command that will fit your application.
then remove the plugin config in application manifest:
source:
  repoURL: ''
  path: charts
  targetRevision: HEAD
  plugin: {}

I'm using as sidecar @GeorgeWasla

@kaiquerass could you please elaborate a bit more on the discover command that you wrote? my AVP works with regular manifests in .yaml format, but I'm passing a custom values.yaml file for my chart and for some reason the placeholder isn't being replaced in the values.yaml file, but regular manifests in .yaml are replacing the placeholder

@epetrovski-endava I fixed the issue, the problem happens when installing argocd using manifest in the documentation to fix that you need to use the helm chart instead

@epetrovski-endava I fixed the issue, the problem happens when installing argocd using manifest in the documentation to fix that you need to use the helm chart instead

@gehal6 Could you please elaborate a bit further? I'm not sure I understand what exactly is needed to fix this. I added the three plugins (avp, avp-kustomize, avp-helm) in my ArgoCD values.yaml, under config.cmp, chart version 5.26.0, and the plugin still does not replace the placeholder when I am adding it in my values.yaml of the application that I use.
Do I need to modify my application.yaml? Thank you

@epetrovski-endava I'm having same issue in my environment, did you succeded to solve yours issue?

for people having this problem: argo will automatically discover which plugin to use based on the discover section of the plugin, so write a discover command that will fit your application. then remove the plugin config in application manifest:
source:
  repoURL: ''
  path: charts
  targetRevision: HEAD
  plugin: {}

@kaiquerass Could you give more detail about this I'm using https://github.com/luafanti/spring-boot-debug-app/tree/main/infra/helm for testing but values set in https://github.com/luafanti/spring-boot-debug-app/blob/main/infra/argocd/argocd-application-with-vault-secrets.yaml this app manifest are not being replaced

Same issue for me as well:
replaceString: missing Vault value for placeholder password in string password:
I tried to let argo automatically discover the plugin: plugin: {},
but same error.


Desktop App freezes

seems electon limits the ulimit soft even if it’s system wide setup in both MacOS and Linux
https://github.com/electron/electron/issues/2584
It’s fixed was pushed already: https://github.com/electron/electron/pull/2642
This is what we need to do in our Electron App
https://github.com/electron/electron/blob/master/docs/api/process.md#processsetfdlimitmaxdescriptors-macos-linux

pushed experimental commit with fix related to this issue:
https://github.com/SuperNETorg/iguana/commit/ffc6882cbdaa00b5081b1605967d5d439001aa18
testing and possible improvements required.

fixed. linux and OSX don't freeze anymore.


Log unauthorized access

At the time of writing the MIW does not log unauthorized access. It would be great of this security information would be part of the INFO logs.

Should it be just an "info" or better a "warning"?

Should it be just an "info" or better a "warning"?

I assume warning would be the appropriate level.


GoogleSpreadsheetWorksheet.loadCells() really slow!

I'm currently working on reading data from a spreadsheet but when I try to load 108 rows, each with 43 columns, it takes alot of time to load the cells into the application.
async readSpreadsheetData() {
  await this.authenticateGoogleSpreadsheet();
  await this.googleSpreadsheet.loadInfo();

  const sheet = this.googleSpreadsheet.sheetsByIndex[MAIN_SPREADSHEET_INDEX];

  console.time('loadCells benchmark');

  // For some reason, loadCells is too SLOW
  await sheet.loadCells({
    startRowIndex: 1,
    startColumnIndex: 0,
    endRowIndex: 108,
    endColumnIndex: 43,
  });

  console.timeEnd('loadCells benchmark'); // Logs 8.5+ seconds on average
}

Time results:

As you can see, I'm just calling loadCells but it is taking a bit of time to load the cells (above 8 seconds on average).
Is there a way to make loadCells faster? Am I doing something wrong, or is this how it is supposed to be?
I really need to load all the cells. I know that the docs says that if speed is crucial, I better go off and use the googleapi but speed isn't crucial here and I think there might be a quick workaround on this simple loadCell use case (hopefully).  Maybe just by checking the amount of rows and doing a batchGet if passed a certain limit?
Anyways, thank you for this beautiful library!

Maybe I can help you. Do you still have the error?
If you do, did you set the environment variables?

I dont think theres much that can be done for this, since the loadCells call is just calling google's API.


Does catalyst support Huobi.pro, the most popular Chinese exchanges ?

Does catalyst support Huobi.pro, the most popular Chinese exchanges ?
Ccxt already supports Huobi.pro API.
The Huobi API doc link is Huobi API

Hi @chairy11 ,
Please visit the following link describing catalyst tested and supported exchanges both in backtest and in live.
We haven't checked nor tested Huobi.pro exchange yet, although catalyst does integrate with the CCXT library.
If you decide to try testing catalyst with Huobi.pro (in paper or live mode) we will be happy if you could report back, otherwise we hope to get to it in the near future.
Thanks,
Lena

I want to change my local code to test HuobiPro exchange.
But my code changes seems not work. Why? Can Catalyst keep watching source files for changes and reloading modules ?
I am novice to Python.

I suggest you to go through the entire catalyst documentation and get yourself more familiar with Python programming.
Regarding your questions:

Currently only Bitfinex, Bittrex and Poloniex are supported in backtest. So there is not point in trying to ingest HuobiPro information, as no historical data for this exchange is saved and can be downloaded.
As mentioned above, because catalyst does integrate with the CCXT library, you can try to test the HuobiPro integration in live and paper modes only. However because it was not yet tested by us, it might not work, so use carefully. To try this, no code change is required, only defining the HuobiPro exchange in your algorithm definition.

I suggest you to familiar yourself with catalyst before trying to test the HuobiPro integration; and again, as this exchange functionality was not yet validated nor tested, please use carefully as issues might come up.

@lenak25
Thank you for your answer.
Now I have a bitfinex account and I can open the url "https://api.bitfinex.com/v1/symbols_details " in my brower.
But when I run the command catalyst ingest-exchange -x bitfinex -i btc_usd, the terminal always raise an error
raise ExchangeRequestError(error=e)
catalyst.exchange.exchange_errors.ExchangeRequestError: Request failed: bitfinex GET https://api.bitfinex.com/v1/symbols_details HTTPSConnectionPool(host='api.bitfinex.com', port=443): Max retries exceeded with url: /v1/symbols_details (Caused by ConnectTimeoutError(<urllib3.connection.VerifiedHTTPSConnection object at 0x114f2a320>, 'Connection to api.bitfinex.com timed out. (connect timeout=10)'))

I can't understand.  The catalyst document say the ingest data is from catalyst server, why it still requests from https://api.bitfinex.com/v1/symbols_details  ?
And I have already set the bitfinex API in file ~/.catalyst/data/exchanges/bitfinex/auth.json.
Did I do anything wrong?

@chairy11 , to avoid confusion, I am closing this issue, as its original subject was answered.
Regarding the error you have encountered, this indeed looks strange but I need more details.
Please open a new issue with the description of your problem and details regrading the catalyst version + python version + a more detailed stack trace.
Thanks,
Lena


add integration test for django documentation build

We seem to break the Django build, so let's use it as a way to detect
breaking changes in our implementation.

@jdufresne does this seem worthwhile?


lib: add request-v3, for GitHub API v3 support

We can use this whenever we need it. Let me know if you think there should a diffrent name for this.

I think we should use a library like https://github.com/octokit/node-github (it supports promises) for API v3 calls.

@targos that would be good idea if this whole repo was on v3 but it based on v4 it just required for one functionality or maybe some in feature.

I think... I tend to agree with @targos here. Using node-github means we don't need to worry about testing some of that stuff and it allows us to easily expand functionality in the future, as opposed to refactoring everything when we suddenly need it at a later time.

I do agree too. For now we need only for one thing, but I think we're doomed to have more uses for it later unless GitHub implements new nodes in the Graph API.
I think adding the node-github package would be a safe bet now.

A few thoughts:

We can just put a v3 method/property on the Request class in lib/request.js.
I tend to agree with @targos , we can instantiate the node-github client in Request and expose it as request.v3


Add aliases for PV and PVC resources

@ahmetb I understand the desire to not balloon the combinations, but I manage PVC on a daily basis and PV/PVC are such integral components of K8s, I hope one day this tool supports them so I can adopt it to my team.

@iczman ok I'll accept this since it came up many times. Feel free to send another PR.


added Heliosschule, Cologne, Germany

@jeschu Thank you for your patience while waiting for a review and processing your request. Pull request merged.


Folding does not work

I don't know if this is a bug or a VSCode's specification, but parentheses with no content cannot be collapsed.

Version: 1.77.3
Commit: 704ed70d4fd1c6bd6342c436f1ede30d1cff4710
Date: 2023-04-12T09:16:52.732Z
Electron: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.2.10-arch1-1
Sandboxed: No

fixed by https://github.com/zigtools/zls/pull/1801


build: bump chrono to 0.4.23 and stop using deprecated from_timestamp

In order to replace: https://github.com/containers/aardvark-dns/pull/255

/lgtm
/approve


TearDown Steps are getting executed only for last scenario.

Expected behavior
TearDown Steps should get executed for all the scenarios.
Actual behavior
It's getting executed only for the last scenario
Steps to reproduce

create A specification with two scenario and teardown.
Ex :-

Specification Heading
=====================

Vowel counts in single word
---------------------------
* The word "gauge" has "3" vowels.

Vowel counts in multiple word
-----------------------------
* The word "gauge" has "3" vowels.

----
* word is  "Word".

Implement steps

import com.thoughtworks.gauge.Step;

import static org.junit.Assert.assertEquals;

public class StepImplementation {

    @Step("word is  <Word>.")
    public void setLanguageVowels(String Word) {

    }

    @Step("The word <word> has <expectedCount> vowels.")
    public void verifyVowelsCountInWord(String word, int expectedCount) {

    }
}

Execute specs in verbose mode.
See the console output

# Specification Heading
  ## Vowel counts in single word
      * The word "gauge" has "3" vowels.	 ...[PASS]
  ## Vowel counts in multiple word
      * The word "gauge" has "3" vowels.	 ...[PASS]
      * word is  "Word".	 ...[PASS]

Specifications:	1 executed	1 passed	0 failed	0 skipped
Scenarios:	3 executed	3 passed	0 failed	0 skipped

Total time taken: 27ms

the teardown step word is  "Word" go executed only for last scenario.

Gauge version
Gauge version: 0.8.2

Plugins
-------
java (0.6.1)

@BugDiver The teardown identifier is 3 or more underscores ___ but I think you have used hyphens. Please verify and close this issue.

@kashishm You are right. Working as expected.