[FEAT] Inferencers with Hasura dataProvider

Is your feature request related to a problem? Please describe.
When I initialize a new Hasura version of refine, and I use the command "refine create-ressource", the pages are generated with Inferencers (Mantine, ANT etc..) but they dont seem to work with GraphQL, I keep getting the following GraphQL error :
{"errors":[{"extensions":{"code":"validation-failed","path":"$.selectionSet.refine_posts_by_pk.selectionSet"},"message":"missing selection set for 'refine_posts'"}]}
Describe alternatives you've considered
No response
Additional context
No response
Describe the thing to improve
It would be awsome if the Inferencers would work out of the box with GraphQL

Hey @purplefish32 thank you for the issue! 🙏 We have this in our backlog and start implementing this as soon as possible. We have multiple approaches we might follow. Not very clear right now but I think the result will provide a smooth way for inferencer to interact with GraphQL APIs. 🚀

@aliemir do you plan to provide specific inferencing to Hasura or to any Graphql API in general?

Hey @beepsoft sorry for the late response 🙏 Yes, we're definitely planning to include GraphQL support to our Inferencer package. It's probably be like, you providing the gql query to the inferencer for the resources and the inferencer generating views for it. We've looked for the opportunity to use introspection but ended up not liking the result and the way it works 😅
We're hoping to get started on this feature as soon as possible and release the GraphQL support. I'll try to prioritize this as much as I can 🚀

@aliemir thank you so much for the explanation, eager to see and use the result. 😃

I'm also keen to use a generic dataProvider for either GraphQL & Apollo Client. How's the progrss for this ticket so far? @aliemir

Hi team, hitting this roadblock when trying to use Hasura data provider. Hasura makes it easy to wire up a Postgres DB and is an excellent combination with Refine.

Hey @mayurdhurpate ,
Thank you for contacting us. The fact that Inferencer doesn't support GraphQL providers shouldn't be considered as a blocker. Inferencer is a Refine feature that shortens development time. You can already use Hasura with Refine. Please check out our Hasura examples and GraphQL documentation at https://refine.dev/docs/examples/data-provider/hasura/ and https://refine.dev/docs/advanced-tutorials/data-provider/graphql/."

Hey @purplefish32 @mayurdhurpate @beepsoft @Mingyang-Li ,
We have some news today that will make you happy 🎉 Inferencer can now be used with GraphQL data providers.
To try it out, update your refine dependencies (with npm run refine update) and check out our documentation at https://refine.dev/docs/packages/documentation/inferencer/ ! 🎯
Hasura example: https://github.com/refinedev/refine/tree/next/examples/inferencer-graphql-hasura


Add sample jobv2

Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Github Branch
As most of the development works are on Kylin 4, we need to switch it as main branch. Apache Kylin community changes the branch settings on Github since 2021-08-04 :

The original branch kylin-on-parquet-v2 for Kylin 4.X (Parquet Storage) has been renamed to branch main, and configured as the default branch;
The original branch master for Kylin 3.X (HBase Storage) has been renamed to branch kylin3 ;

Please check Intro to Kylin 4 architecture and INFRA-22166 if you are interested.
Types of changes
What types of changes does your code introduce to Kylin?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)

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

[ ] I have create an issue on Kylin's jira, and have described the bug/feature there in detail
[ ] Commit messages in my PR start with the related jira ID, like "KYLIN-0000 Make Kylin project open-source"
[ ] Compiling and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged

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

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@0fa4176). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1858   +/-   ##
=======================================
  Coverage        ?   24.56%
  Complexity      ?     4458
=======================================
  Files           ?     1103
  Lines           ?    62384
  Branches        ?     8926
=======================================
  Hits            ?    15327
  Misses          ?    45442
  Partials        ?     1615

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 0fa4176...11edc39. Read the comment docs.


markup/goldmark: Revert from 1.4.8 to 1.4.7

Fixes #9650
I think this is serious enough to downgrade. PR includes test to make sure this doesn't happen again.
Or we can wait a day to see if it gets fixed upstream.

Thanks, I will do a release with a fix for this one way or the other some time later today.

https://github.com/yuin/goldmark/releases/tag/v1.4.9
10 minutes old.

Closing this, will open another.


Introduce sleep_timeout configuration + documentation

This pull request introduces the sleep_timeout configuration to set a differend timeout while sleep mode is active (https://github.com/jseidl/hass-magic_areas/issues/29).
Fixes also the documentation issue (https://github.com/jseidl/hass-magic_areas/issues/27).

Overseen the dev branch. I will fix this later and push again.

@sti0 thanks for the PR!
I've created a develop branch which contains the features I'm working on for the next release which one of them is moving constants to a separate file thus causing a conflict with your PR.
If you have the time, could you pull the develop branch and apply your changes to it? I'm still to write the CONTRIBUTORS.md with the guidelines. If not I can perform the surgery on this PR during the week.
I'll be using GitFlow naming for the branches (feature/...,hotfix/....) if you wanna follow along ;)

Overseen the dev branch. I will fix this later and push again.

LOL you replied while I was typing. Alright buddy thanks for the contribution!

I'll be using GitFlow naming for the branches (feature/...,hotfix/....) if you wanna follow along ;)

At work we use Bitbucket, so I'm familiar with GitFlow. I will use it next time.
@jseidl what do you think about the naming of the configuration entry? Should it be sleep_timeout or sleep_clear_timeout? In my opinion sleep_timeout is shorter and sounds way better but sleep_clear_timeout is more precise.

Here we go
https://github.com/jseidl/hass-magic_areas/pull/34

I agree with you. sleep_clear_timeout is indeed more precise. Let's churn on that and decide prior to the next feature release.
Thanks for the contribution!


Only show bufferline when more than one buffer is open

When I first installed the plugin, the bufferline wasn't showing up. In the docs, it said to use :set showtabline = 2 to make the bufferline show always, which does work for me.
However, I want it to only show up when there's more than one buffer open (so if I'm only working with one file, it should not be there... if I'm working with more than one, then it should). How can I do that? If I look at :help showtabline, it looks like setting it to 1 should accomplish this, but it's not
https://user-images.githubusercontent.com/53885408/147841649-33dfec85-9a94-4c4d-a63b-2193c4eaed03.mp4
.

The setting showtabline is from vim and has to be set to 2 to enable the bufferline (otherwise it will not be visible at all).
Then you can use the setting min_buffer_count to show the bufferline only when a certain number of buffers are open.
In your case you can set it to 2 to hide the bufferline if only one buffer is open:
let g:lightline#bufferline#min_buffer_count = 2

The setting showtabline is from vim and has to be set to 2 to enable the bufferline (otherwise it will not be visible at all).
Then you can use the setting min_buffer_count to show the bufferline only when a certain number of buffers are open.
In your case you can set it to 2 to hide the bufferline if only one buffer is open:
let g:lightline#bufferline#min_buffer_count = 2

I see... that setting seems to work. Thanks for your help!

I see... that setting seems to work. Thanks for your help!


Added Noor

hey @noormohammadsiddiqui-io, It would be good if you create a new branch in your forked repo and then create a PR into main branch.
Thank you!

Thank you for your valuable contribution!
Make sure to leave a star ⭐ on repo


Failed in generating csr test

Observed Behavior

riscv32-unknown-elf-gcc: error: out/run/riscv_csr_test.30802/test.S: No such file or directory
riscv32-unknown-elf-gcc: fatal error: no input files
Expected Behavior

Steps to reproduce the issue

I entered "make" in dv/uvm/core_ibex, all the test before csr test are generated and traces are compared.
I went to the out/run/riscv_csr_test.30802/ folder and checked the riscv_csr_test.30802.riscv-dv.log, its contents are as follows:
Mon, 16 May 2022 15:33:18 INFO     Creating output directory: /tmp/tmp74o9j11h/@@PLACEHOLDER@@
Mon, 16 May 2022 15:33:18 INFO     Processing regression test list :
/home/oyykyook/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/testlist.yaml, test: riscv_csr_test
Mon, 16 May 2022 15:33:18 INFO     Found matched tests: riscv_csr_test, iterations:1
Mon, 16 May 2022 15:33:18 INFO     Processing simulator setup file : /home/oyykyook/ibex/vendor/google_riscv-dv/yaml/simulator.yaml
Mon, 16 May 2022 15:33:18 INFO     Found matching simulator: vcs
Mon, 16 May 2022 15:33:18 INFO     Running RISC-V instruction generator
Mon, 16 May 2022 15:33:18 INFO     Generating 1 riscv_csr_test
I don't know why it ditn't generate the .S file.
My Environment

EDA tool and version:

Operating system:

Version of the Ibex source code:

Thanks!

Hmm, that's odd! It's definitely supposed to work. Could you zip up and attach the logs in the build directory?

Hmm, that's odd! It's definitely supposed to work. Could you zip up and attach the logs in the build directory?

Sure, I have attached my build folder.
I also found that after running a riscv_arithmetic_basic_test, the spike_cosim.log.csv is empty but it still reports pass. So I also attach the run folder for the arithmetic test.
I have deleted some files in the directory because they are too large, if you need any file please tell me.
Thank you!
logs-in-build-directory.zip
logs_in_riscv_arithmetic_basic_test.zip

Oh, sorry! That's not quite what I meant (I was being lazy and didn't explain myself properly).
If I run the following command:
make -j4 -C dv/uvm/core_ibex ITERATIONS=1 SEED=1 TEST=riscv_csr_test VERBOSE=1

in a clean tree (09d2dd2) then the test runs to completion. (The test is actually failing, but I'm at least getting as far as running everything).
All the files that you care about should appear in out/run/riscv_csr_test.1 (for seed 1). My riscv_csr_test.1.riscv-dv.log contains:
Mon, 16 May 2022 12:39:47 lib.py:249   INFO     Creating output directory: /tmp/tmptd7ddcyu/@@PLACEHOLDER@@
Mon, 16 May 2022 12:39:47 lib.py:186   DEBUG    mkdir -p /tmp/tmptd7ddcyu/@@PLACEHOLDER@@/asm_test
Mon, 16 May 2022 12:39:47 lib.py:214   INFO     Processing regression test list : /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/testlist.yaml, test: riscv_csr_test
Mon, 16 May 2022 12:39:47 lib.py:228   INFO     Found matched tests: riscv_csr_test, iterations:1
Mon, 16 May 2022 12:39:47 run.py:87    INFO     Processing simulator setup file : /src/lr/ibex/vendor/google_riscv-dv/yaml/simulator.yaml
Mon, 16 May 2022 12:39:47 run.py:92    INFO     Found matching simulator: vcs
Mon, 16 May 2022 12:39:47 run.py:269   INFO     Running RISC-V instruction generator
Mon, 16 May 2022 12:39:47 run.py:273   INFO     Generating 1 riscv_csr_test
Mon, 16 May 2022 12:39:47 lib.py:100   DEBUG    python3 /src/lr/ibex/vendor/google_riscv-dv/scripts/gen_csr_test.py --csr_file /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/csr_description.yaml --xlen 32 --iterations 1 --out /tmp/tmptd7ddcyu/@@PLACEHOLDER@@/asm_test --end_signature_addr 0

The @@PLACEHOLDER@@ stuff is because of an ugly hack that we do to force riscv-dv to generate files following the directory layout that we want: see scripts/run-instr-gen.py for details. The riscv_csr_test test is special because riscv-dv generates slightly different files for it.
To figure out what's going on, could you edit that script and add the following lines to the start of the do_file_copies() function?
    print()
    print('\n'.join(os.listdir(src_dir)))
    print()
    assert 0

Re-running make, I see the following:
scripts/run-instr-gen.py          \
  --verbose                            \
  --simulator vcs               \
  --end-signature-addr 8ffffffc \
  --output-dir out/run/riscv_csr_test.1                     \
  --gen-build-dir out/build/instr-gen \
  --ibex-config opentitan           \
  --test-dot-seed riscv_csr_test.1
+ python3 /src/lr/ibex/vendor/google_riscv-dv/run.py --testlist /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/testlist.yaml --gcc_opts=-mno-strict-align --custom_target /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension --csr_yaml /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/csr_description.yaml --mabi=ilp32 --verbose --so --steps=gen --output /tmp/tmpu8_e91q7/@@PLACEHOLDER@@ --simulator vcs --isa rv32imcb --test riscv_csr_test --start_seed 1 --iterations 1 --sim_opts '+uvm_set_inst_override=riscv_asm_program_gen,ibex_asm_program_gen,uvm_test_top.asm_gen +signature_addr=8ffffffc +pmp_num_regions=16 +pmp_granularity=0 +tvec_alignment=8' --debug /tmp/tmpu8_e91q7/cmds.list >out/run/riscv_csr_test.1/riscv_csr_test.1.riscv-dv.log 2>&1
+ python3 /src/lr/ibex/vendor/google_riscv-dv/scripts/gen_csr_test.py --csr_file /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/csr_description.yaml --xlen 32 --iterations 1 --out /tmp/tmpu8_e91q7 --end_signature_addr 0 >/dev/null 2>&1

cmds.list
@@PLACEHOLDER@@
riscv_csr_test_0.S

ERROR:
make: *** [Makefile:238: out/run/riscv_csr_test.1/test.S] Error 1

I'm assuming that you won't have riscv_csr_test_0.S there?

Oh, sorry! That's not quite what I meant (I was being lazy and didn't explain myself properly).
If I run the following command:
make -j4 -C dv/uvm/core_ibex ITERATIONS=1 SEED=1 TEST=riscv_csr_test VERBOSE=1

in a clean tree (09d2dd2) then the test runs to completion. (The test is actually failing, but I'm at least getting as far as running everything).
All the files that you care about should appear in out/run/riscv_csr_test.1 (for seed 1). My riscv_csr_test.1.riscv-dv.log contains:
Mon, 16 May 2022 12:39:47 lib.py:249   INFO     Creating output directory: /tmp/tmptd7ddcyu/@@PLACEHOLDER@@
Mon, 16 May 2022 12:39:47 lib.py:186   DEBUG    mkdir -p /tmp/tmptd7ddcyu/@@PLACEHOLDER@@/asm_test
Mon, 16 May 2022 12:39:47 lib.py:214   INFO     Processing regression test list : /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/testlist.yaml, test: riscv_csr_test
Mon, 16 May 2022 12:39:47 lib.py:228   INFO     Found matched tests: riscv_csr_test, iterations:1
Mon, 16 May 2022 12:39:47 run.py:87    INFO     Processing simulator setup file : /src/lr/ibex/vendor/google_riscv-dv/yaml/simulator.yaml
Mon, 16 May 2022 12:39:47 run.py:92    INFO     Found matching simulator: vcs
Mon, 16 May 2022 12:39:47 run.py:269   INFO     Running RISC-V instruction generator
Mon, 16 May 2022 12:39:47 run.py:273   INFO     Generating 1 riscv_csr_test
Mon, 16 May 2022 12:39:47 lib.py:100   DEBUG    python3 /src/lr/ibex/vendor/google_riscv-dv/scripts/gen_csr_test.py --csr_file /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/csr_description.yaml --xlen 32 --iterations 1 --out /tmp/tmptd7ddcyu/@@PLACEHOLDER@@/asm_test --end_signature_addr 0

The @@PLACEHOLDER@@ stuff is because of an ugly hack that we do to force riscv-dv to generate files following the directory layout that we want: see scripts/run-instr-gen.py for details. The riscv_csr_test test is special because riscv-dv generates slightly different files for it.
To figure out what's going on, could you edit that script and add the following lines to the start of the do_file_copies() function?
    print()
    print('\n'.join(os.listdir(src_dir)))
    print()
    assert 0

Re-running make, I see the following:
rupert@halibut /s/l/i/d/u/core_ibex (work) > make -j4 ITERATIONS=1 SEED=1 TEST=riscv_csr_test VERBOSE=1
scripts/run-instr-gen.py          \
  --verbose                            \
  --simulator vcs               \
  --end-signature-addr 8ffffffc \
  --output-dir out/run/riscv_csr_test.1                     \
  --gen-build-dir out/build/instr-gen \
  --ibex-config opentitan           \
  --test-dot-seed riscv_csr_test.1
+ python3 /src/lr/ibex/vendor/google_riscv-dv/run.py --testlist /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/testlist.yaml --gcc_opts=-mno-strict-align --custom_target /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension --csr_yaml /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/csr_description.yaml --mabi=ilp32 --verbose --so --steps=gen --output /tmp/tmpu8_e91q7/@@PLACEHOLDER@@ --simulator vcs --isa rv32imcb --test riscv_csr_test --start_seed 1 --iterations 1 --sim_opts '+uvm_set_inst_override=riscv_asm_program_gen,ibex_asm_program_gen,uvm_test_top.asm_gen +signature_addr=8ffffffc +pmp_num_regions=16 +pmp_granularity=0 +tvec_alignment=8' --debug /tmp/tmpu8_e91q7/cmds.list >out/run/riscv_csr_test.1/riscv_csr_test.1.riscv-dv.log 2>&1
+ python3 /src/lr/ibex/vendor/google_riscv-dv/scripts/gen_csr_test.py --csr_file /src/lr/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/csr_description.yaml --xlen 32 --iterations 1 --out /tmp/tmpu8_e91q7 --end_signature_addr 0 >/dev/null 2>&1

cmds.list
@@PLACEHOLDER@@
riscv_csr_test_0.S

ERROR:
make: *** [Makefile:238: out/run/riscv_csr_test.1/test.S] Error 1

I'm assuming that you won't have riscv_csr_test_0.S there?

Yes, after adding that lines to the do_file_copies() function and re-running make, I don't see riscv_csr_test_0.S.
My output is as follow:
`(base) [oyykyook@mics-eda ibex]$ make -j4 -C dv/uvm/core_ibex ITERATIONS=1 SEED=1 TEST=riscv_csr_test VERBOSE=1
make: Entering directory '/home/oyykyook/ibex/dv/uvm/core_ibex'
scripts/compile-tb.py
--verbose
--ibex-config opentitan
--output=out/build/tb
--shared-cov-dir=out/run/shared_cov
--simulator=vcs
--en_wave --en_cosim
scripts/run-instr-gen.py
--verbose
--simulator vcs
--end-signature-addr 8ffffffc
--output-dir out/run/riscv_csr_test.1
--gen-build-dir out/build/instr-gen
--ibex-config opentitan
--test-dot-seed riscv_csr_test.1

python3 /home/oyykyook/ibex/vendor/google_riscv-dv/run.py --testlist /home/oyykyook/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/testlist.yaml --gcc_opts=-mno-strict-align --custom_target /home/oyykyook/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension --csr_yaml /home/oyykyook/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/csr_description.yaml --mabi=ilp32 --verbose --so --steps=gen --output /tmp/tmpnzifgitv/@@PLACEHOLDER@@ --simulator vcs --isa rv32imcb --test riscv_csr_test --start_seed 1 --iterations 1 --sim_opts '+uvm_set_inst_override=riscv_asm_program_gen,ibex_asm_program_gen,uvm_test_top.asm_gen +signature_addr=8ffffffc +pmp_num_regions=16 +pmp_granularity=0 +tvec_alignment=8' --debug /tmp/tmpnzifgitv/cmds.list >out/run/riscv_csr_test.1/riscv_csr_test.1.riscv-dv.log 2>&1
sh -c 'vcs -f /home/oyykyook/ibex/dv/uvm/core_ibex/ibex_dv.f  -full64 -l out/build/tb/compile.log -sverilog -ntb_opts uvm-1.2 +define+UVM +define+UVM_REGEX_NO_DPI -timescale=1ns/10ps -licqueue -LDFLAGS '"'"'-Wl,--no-as-needed'"'"' -CFLAGS '"'"'--std=c99 -fno-extended-identifiers'"'"' -Mdir=out/build/tb/vcs_simv.csrc -o out/build/tb/vcs_simv -debug_access+pp -xlrm uniq_prior_final -CFLAGS '"'"'--std=c99 -fno-extended-identifiers'"'"' -lca -kdb -pvalue+core_ibex_tb_top.RV32E=0 +define+IBEX_CFG_RV32M=ibex_pkg::RV32MSingleCycle +define+IBEX_CFG_RV32B=ibex_pkg::RV32BOTEarlGrey +define+IBEX_CFG_RegFile=ibex_pkg::RegFileFF -pvalue+core_ibex_tb_top.BranchTargetALU=1 -pvalue+core_ibex_tb_top.WritebackStage=1 -pvalue+core_ibex_tb_top.ICache=1 -pvalue+core_ibex_tb_top.ICacheECC=1 -pvalue+core_ibex_tb_top.ICacheScramble=1 -pvalue+core_ibex_tb_top.BranchPredictor=0 -pvalue+core_ibex_tb_top.DbgTriggerEn=1 -pvalue+core_ibex_tb_top.SecureIbex=1 -pvalue+core_ibex_tb_top.PMPEnable=1 -pvalue+core_ibex_tb_top.PMPGranularity=0 -pvalue+core_ibex_tb_top.PMPNumRegions=16 -pvalue+core_ibex_tb_top.MHPMCounterNum=10 -pvalue+core_ibex_tb_top.MHPMCounterWidth=32 -debug_access+all -ucli -do vcs.tcl   -f /home/oyykyook/ibex/dv/uvm/core_ibex/ibex_dv_cosim_dpi.f +define+INC_IBEX_COSIM -LDFLAGS '"'"'-Wl,-rpath,/home/oyykyook/ibex_toolchain/lowrisc-toolchain-gcc-rv32imcb-20220210-1/lib'"'"' -CFLAGS '"'"'-I/home/oyykyook/ibex_toolchain/lowrisc-toolchain-gcc-rv32imcb-20220210-1/include -I/home/oyykyook/ibex_toolchain/lowrisc-toolchain-gcc-rv32imcb-20220210-1/include/softfloat'"'"' -CFLAGS '"'"'-I/home/oyykyook/ibex/dv/cosim'"'"' -lriscv -lsoftfloat -ldl -ldisasm -lfdt -lstdc++ ' >/dev/null 2>&1
python3 /home/oyykyook/ibex/vendor/google_riscv-dv/scripts/gen_csr_test.py --csr_file /home/oyykyook/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/csr_description.yaml --xlen 32 --iterations 1 --out /tmp/tmpnzifgitv --end_signature_addr 0 >/dev/null 2>&1

cmds.list
@@PLACEHOLDER@@
ERROR:
make: *** [Makefile:238: out/run/riscv_csr_test.1/test.S] Error 1
make: *** Waiting for unfinished jobs....
make: *** [Makefile:331: out/build/tb/.compile.stamp] Error 2
make: Leaving directory '/home/oyykyook/ibex/dv/uvm/core_ibex'
`
Thank you!

How annoying! Well, this is kind of my fault :-( If you look at line 97 of run-instr-gen.py, you'll find this:
            ret = run_one(args.verbose, cmd, redirect_stdstreams='/dev/null')

Can you change it to this?
            ret = run_one(args.verbose, cmd)

Then you should at least see the error messages on your console.
I'll open a PR in a minute that writes them somewhere a bit more helpful.

For a less hacky approach, see: https://github.com/lowRISC/ibex/pull/1660

Yes I changed the line 97 in the run-inst-gen.py and re-ran make -j4 -C dv/uvm/core_ibex ITERATIONS=1 SEED=1 TEST=riscv_csr_test VERBOSE=1, first it raised an error:
ERROR:root:Please install bitstring package: sudo apt-get install python3-bitstring
Then I used pip to install bitstring and ran the make again, this time the terminal output is as follows:
(base) [oyykyook@mics-eda ibex]$ make -j4 -C dv/uvm/core_ibex ITERATIONS=1 SEED=1 TEST=riscv_csr_test VERBOSE=1
make: Entering directory '/home/oyykyook/ibex/dv/uvm/core_ibex'
scripts/compile-tb.py
--verbose
--ibex-config opentitan
--output=out/build/tb
--shared-cov-dir=out/run/shared_cov
--simulator=vcs
--en_wave --en_cosim
scripts/run-instr-gen.py
--verbose
--simulator vcs
--end-signature-addr 8ffffffc
--output-dir out/run/riscv_csr_test.1
--gen-build-dir out/build/instr-gen
--ibex-config opentitan
--test-dot-seed riscv_csr_test.1

python3 /home/oyykyook/ibex/vendor/google_riscv-dv/run.py --testlist /home/oyykyook/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/testlist.yaml --gcc_opts=-mno-strict-align --custom_target /home/oyykyook/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension --csr_yaml /home/oyykyook/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/csr_description.yaml --mabi=ilp32 --verbose --so --steps=gen --output /tmp/tmpuob8sbng/@@PLACEHOLDER@@ --simulator vcs --isa rv32imcb --test riscv_csr_test --start_seed 1 --iterations 1 --sim_opts '+uvm_set_inst_override=riscv_asm_program_gen,ibex_asm_program_gen,uvm_test_top.asm_gen +signature_addr=8ffffffc +pmp_num_regions=16 +pmp_granularity=0 +tvec_alignment=8' --debug /tmp/tmpuob8sbng/cmds.list >out/run/riscv_csr_test.1/riscv_csr_test.1.riscv-dv.log 2>&1
sh -c 'vcs -f /home/oyykyook/ibex/dv/uvm/core_ibex/ibex_dv.f  -full64 -l out/build/tb/compile.log -sverilog -ntb_opts uvm-1.2 +define+UVM +define+UVM_REGEX_NO_DPI -timescale=1ns/10ps -licqueue -LDFLAGS '"'"'-Wl,--no-as-needed'"'"' -CFLAGS '"'"'--std=c99 -fno-extended-identifiers'"'"' -Mdir=out/build/tb/vcs_simv.csrc -o out/build/tb/vcs_simv -debug_access+pp -xlrm uniq_prior_final -CFLAGS '"'"'--std=c99 -fno-extended-identifiers'"'"' -lca -kdb -pvalue+core_ibex_tb_top.RV32E=0 +define+IBEX_CFG_RV32M=ibex_pkg::RV32MSingleCycle +define+IBEX_CFG_RV32B=ibex_pkg::RV32BOTEarlGrey +define+IBEX_CFG_RegFile=ibex_pkg::RegFileFF -pvalue+core_ibex_tb_top.BranchTargetALU=1 -pvalue+core_ibex_tb_top.WritebackStage=1 -pvalue+core_ibex_tb_top.ICache=1 -pvalue+core_ibex_tb_top.ICacheECC=1 -pvalue+core_ibex_tb_top.ICacheScramble=1 -pvalue+core_ibex_tb_top.BranchPredictor=0 -pvalue+core_ibex_tb_top.DbgTriggerEn=1 -pvalue+core_ibex_tb_top.SecureIbex=1 -pvalue+core_ibex_tb_top.PMPEnable=1 -pvalue+core_ibex_tb_top.PMPGranularity=0 -pvalue+core_ibex_tb_top.PMPNumRegions=16 -pvalue+core_ibex_tb_top.MHPMCounterNum=10 -pvalue+core_ibex_tb_top.MHPMCounterWidth=32 -debug_access+all -ucli -do vcs.tcl   -f /home/oyykyook/ibex/dv/uvm/core_ibex/ibex_dv_cosim_dpi.f +define+INC_IBEX_COSIM -LDFLAGS '"'"'-Wl,-rpath,/home/oyykyook/ibex_toolchain/lowrisc-toolchain-gcc-rv32imcb-20220210-1/lib'"'"' -CFLAGS '"'"'-I/home/oyykyook/ibex_toolchain/lowrisc-toolchain-gcc-rv32imcb-20220210-1/include -I/home/oyykyook/ibex_toolchain/lowrisc-toolchain-gcc-rv32imcb-20220210-1/include/softfloat'"'"' -CFLAGS '"'"'-I/home/oyykyook/ibex/dv/cosim'"'"' -lriscv -lsoftfloat -ldl -ldisasm -lfdt -lstdc++ ' >/dev/null 2>&1
python3 /home/oyykyook/ibex/vendor/google_riscv-dv/scripts/gen_csr_test.py --csr_file /home/oyykyook/ibex/dv/uvm/core_ibex/scripts/../riscv_dv_extension/csr_description.yaml --xlen 32 --iterations 1 --out /tmp/tmpuob8sbng --end_signature_addr 0

cmds.list
@@PLACEHOLDER@@
riscv_csr_test_0.S
ERROR:
make: *** [Makefile:238: out/run/riscv_csr_test.1/test.S] Error 1
make: *** Waiting for unfinished jobs....
make: *** [Makefile:331: out/build/tb/.compile.stamp] Error 2
make: Leaving directory '/home/oyykyook/ibex/dv/uvm/core_ibex'
I can see there is the .S file now, but the compile failed though, so I checked the /build/tb/compile.log and I found following errors:
`/home/oyykyook/ibex/dv/cosim/spike_cosim.cc:301:14: error: 'class processor_t' has
no member named 'set_csr'; did you mean 'get_csr'?
301 |   processor->set_csr(CSR_MSTATUS, mstatus);
|              ^~~~~~~
|              get_csr
/home/oyykyook/ibex/dv/cosim/spike_cosim.cc:303:14: error: 'class processor_t' has
no member named 'set_csr'; did you mean 'get_csr'?
303 |   processor->set_csr(CSR_MEPC, mstack.epc);
|              ^~~~~~~
|              get_csr
/home/oyykyook/ibex/dv/cosim/spike_cosim.cc:304:14: error: 'class processor_t' has
no member named 'set_csr'; did you mean 'get_csr'?
304 |   processor->set_csr(CSR_MCAUSE, mstack.cause);
|              ^~~~~~~
|              get_csr
/home/oyykyook/ibex/dv/cosim/spike_cosim.cc: In member function 'void SpikeCosim::fixup_csr(int,
uint32_t)':
/home/oyykyook/ibex/dv/cosim/spike_cosim.cc:365:18: error: 'class processor_t' has
no member named 'set_csr'; did you mean 'get_csr'?
365 |       processor->set_csr(csr_num, new_val);
|                  ^~~~~~~
|                  get_csr
In file included from /home/oyykyook/centos/riscv-gcc/include/c++/10.2.0/memory:83, \
             from /home/oyykyook/ibex_toolchain/lowrisc-toolchain-gcc-rv32imcb-20220210-1/include/riscv/log_file.h:6, \

             from /home/oyykyook/ibex/dv/cosim/spike_cosim.h:10,
             from /home/oyykyook/ibex/dv/cosim/spike_cosim.cc:5:

/home/oyykyook/centos/riscv-gcc/include/c++/10.2.0/bits/unique_ptr.h: In instantiation
of 'typename std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...) [with
_Tp = processor_t; _Args = {const char*, const char (&)[3], const char (&)[17], SpikeCosim*,
int, bool, _IO_FILE*&, std::basic_ostream<char, std::char_traits >&}; typename
std::_MakeUniq<_Tp>::__single_object = std::unique_ptr<processor_t>]':
/home/oyykyook/ibex/dv/cosim/spike_cosim.cc:29:72:   required from here
/home/oyykyook/centos/riscv-gcc/include/c++/10.2.0/bits/unique_ptr.h:962:30: error:
no matching function for call to 'processor_t::processor_t(const char*, const char
[3], const char [17], SpikeCosim*, int, bool, _IO_FILE*&, std::basic_ostream&)' \
962 |     { return unique_ptr<_Tp>(new _Tp(std::forward<_Args>(__args)...)); } \
  |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In file included from /home/oyykyook/ibex/dv/cosim/spike_cosim.h:11,
from /home/oyykyook/ibex/dv/cosim/spike_cosim.cc:5:
/home/oyykyook/ibex_toolchain/lowrisc-toolchain-gcc-rv32imcb-20220210-1/include/riscv/processor.h:234:3:
note: candidate: 'processor_t::processor_t(const isa_parser_t*, const char*, simif_t*,
uint32_t, bool, FILE*, std::ostream&)'
234 |   processor_t(const isa_parser_t isa, const char varch,
|   ^~~~~~~~~~~
/home/oyykyook/ibex_toolchain/lowrisc-toolchain-gcc-rv32imcb-20220210-1/include/riscv/processor.h:234:3:
note:   candidate expects 7 arguments, 8 provided
make[2]: *** [filelist:19: spike_cosim.o] Error 1
make[1]: *** [Makefile:111: product_clean_order] Error 2
make[1]: Leaving directory '/home/oyykyook/ibex/dv/uvm/core_ibex/out/build/tb/vcs_simv.csrc'
So do I need to changeset_csrtoget_csr`?
Thank you for your help!

Hi I have changed my code according to this PR, but when I run make, I still got some problems:
Traceback (most recent call last):   File "/home/oyykyook/ibex/dv/uvm/core_ibex/scripts/compile-tb.py", line 104, in <module>     sys.exit(main())   File "/home/oyykyook/ibex/dv/uvm/core_ibex/scripts/compile-tb.py", line 95, in main     retcode = run_one(args.verbose, ['sh', '-c', cmd],   File "/home/oyykyook/ibex/dv/uvm/core_ibex/scripts/scripts_lib.py", line 68, in run_one     print('+ ' + cmd_str, file=stdstream_dest) AttributeError: 'int' object has no attribute 'write' make: *** [Makefile:331: out/build/tb/.compile.stamp] Error 1
Thanks for your work!

The C++ build problems look a lot like you're using an unsupported version of Spike. I think we now default to enabling "co-simulation". The easiest approach is to install the lowrisc-cosim-v0.2 version, as described here. I think we forgot to update some documents: oops!
You might also have some success with specifying COSIM=0 on your Make command line, but we're planning to remove that option (and sort out the documentation) in the next few days.

Hi, sorry for the late reply.
I have fixed spike problem and changed my code according to #1660 .
I ran make -j4  ITERATIONS=1 SEED=1 TEST=riscv_csr_test VERBOSE=1, then in /out/run/riscv_csr_test.1/test-result.yml I found:
name:            riscv_csr_test seed:            1 binary:          out/run/riscv_csr_test.1/test.o uvm_log:         out/run/riscv_csr_test.1/rtl.log rtl_trace:       out/run/riscv_csr_test.1/trace_core_00000000.log rtl_trace_csv:   out/run/riscv_csr_test.1/trace_core_00000000.log.csv iss_trace: iss_trace_csv: en_cosim:        True cosim_trace: cosim_trace_csv: comparison_log: passed:          False failure_message: |-   UVM_ERROR /home/oyykyook/ibex/vendor/lowrisc_ip/dv/sv/mem_model/mem_model.sv(35) @ 4378400: reporter [mem] read from uninitialized addr 0x80000b5f   [FAILED]: sim error seen
Then I checked rtl.log, and it reports following info:
`
UVM_INFO @ 0: reporter [RNTST] Running test core_ibex_csr_test...
UVM_INFO /home/oyykyook/ibex/dv/uvm/core_ibex/env/core_ibex_env.sv(37) @ 0: uvm_test_top.env [uvm_test_top.env] Cosim disabled by plusarg +disable_cosim=1
UVM_INFO /home/oyykyook/ibex/dv/uvm/core_ibex/tests/core_ibex_base_test.sv(169) @ 202400: uvm_test_top [uvm_test_top] Running test : out/run/riscv_csr_test.1/test.bin
UVM_INFO /home/oyykyook/ibex/dv/uvm/core_ibex/common/ibex_mem_intf_agent/ibex_mem_intf_response_seq_lib.sv(26) @ 202400: uvm_test_top.env.instr_if_response_agent.sequencer@@instr_intf_seq [uvm_test_top.env.instr_if_response_agent.sequencer.instr_intf_seq] is_dmem_seq: 0x0
UVM_INFO /home/oyykyook/ibex/dv/uvm/core_ibex/common/ibex_mem_intf_agent/ibex_mem_intf_response_seq_lib.sv(26) @ 202400: uvm_test_top.env.data_if_response_agent.sequencer@@data_intf_seq [uvm_test_top.env.data_if_response_agent.sequencer.data_intf_seq] is_dmem_seq: 0x1
core_ibex_tb_top.dut.u_ibex_tracer.printbuffer_dumpline.unnamed$$_0: Writing execution trace to out/run/riscv_csr_test.1/trace_core_00000000.log
UVM_ERROR /home/oyykyook/ibex/vendor/lowrisc_ip/dv/sv/mem_model/mem_model.sv(35) @ 4378400: reporter [mem] read from uninitialized addr 0x80000b5f
--- RISC-V UVM TEST FAILED ---
`
Looks like we have found the cause of the problem, but I don't have much experience using vcs so I still don't know how to fix it.
Thanks for your help!

Ahah! That's excellent: you're now at the same point that we are :-) Sadly, this specific test is currently failing. Fortunately, I think I can see what's going on: the memory model is overly zealous about making sure we don't read from uninitialised addresses. It turns out that the test is executing an instruction near the top of initialised IMEM and we're reading a couple of words ahead. Oops!
I'm going to take a proper look either this evening or tomorrow.

As a follow-up, I've done a bit of debugging and fixed one DV bug (https://github.com/lowRISC/ibex/pull/1662). Unfortunately, this wasn't the root cause of why the test is failing. Hopefully I'll get to that soon.

A tiny bit more debugging (mostly to help me pick things up tomorrow morning): The problem is that we describe the mcause CSR with the following hunk of YAML:
# MCAUSE
- csr: mcause
  description: >
    Indicates trap cause
  address: 0x342
  privilege_mode: M
  rv32:
    - field_name: Interrupt
      description: >
        Indicates if trap caused by interrupt
      type: WARL
      reset_val: 0
      msb: 31
      lsb: 31
    - field_name: Exception Code
      type: WLRL
      reset_val: 0
      msb: 4
      lsb: 0

This might have been right once, but is no longer correct since Greg implemented internal interrupts. I don't think that gen_csr_test.py supports the behaviour that we've got for our MCAUSE field, which boils down to this code in ibex_cs_registers.sv:
      // mcause: exception cause
      CSR_MCAUSE: csr_rdata_int = {mcause_q.irq_ext | mcause_q.irq_int,
                                   mcause_q.irq_int ? {26{1'b1}} : 26'b0,
                                   mcause_q.lower_cause[4:0]};

Here, we ostensibly have a 31-bit exception code field, but the top bits are all constrained to be equal.
@GregAC: What do you think we should do? A lame response might be to just use 6 bits and represent internal interrupts starting at 32, without the bit extension. Or we could split the field and just set the top bit? Or we could do some work to generalise the DV code to understand this sort of thing: for example, we could say that the field is 6 bits but the other 25 bits are some sort of mirror. But that means some DV work and (eek) getting a patch into riscv-dv.

Right, I think we've got to the stage where everything is building for you. And I've fixed the silly bug in the script that meant we weren't exposing error messages (oops). I'm going to close this now and track the failing test in its own issue (linked just above). Thank you very much for the bug report.


@clerk/backend throws: Invalid URL string

Preliminary Checks

[X] I have reviewed the documentation: https://clerk.com/docs
[X] I have searched for existing issues: https://github.com/clerk/javascript/issues
[X] I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)
[X] This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.

Reproduction / Replay Link
n/a
Publishable key
n/a
Description
Steps to reproduce:
Create a clerk client with the latest beta version (1.0.0-beta-v5.18) and get an organization.
import { createClerkClient } from '@clerk/backend'

const clerk = createClerkClient({
  secretKey: env.CLERK_SECRET_KEY,
})

const org = await ctx.clerk.organizations.getOrganization({
  organizationId: 'org_xxxxxxxxxxxxxxxxx',
})

Expected behavior:
Get back org correctly
Actual behavior:
It throws an error with Invalid URL string.

I tried to hunt it down and maybe found the problem:
https://github.com/clerk/javascript/blob/9289aafd0ac5178bef355a3410e3d7e120e51482/packages/backend/src/api/request.ts#L64-L67
joinPaths is responsible to remove double path joiners (when is it ever not a slash?):
https://github.com/clerk/javascript/blob/9289aafd0ac5178bef355a3410e3d7e120e51482/packages/backend/src/util/path.ts#L7-L10
Now the args of joinPaths look something like this: ["https://api.clerk.com", "v1", "/organizations/org_xxxxxxxxxxxxxxxxx"]
Unfortunately, the protocol contains a double slash as well and the result of url is:
https:/api.clerk.com/v1/organizations/org_xxxxxxxxxxxxxxxxx

Notice the https:/. new URL will throw with this input

Also noticed this and reported in the Discord. However i am using "@clerk/backend": "^0.37.3", for what it is worth. Lets me believe i should maybe downgrade my version and see if that works.

@dan-lee Any chance the code is running in an edge-runtime ?

@panteliselef Yeah that's right, the code is running a Cloudflare Worker


Exported C# List of Color objects return wrong values

Godot version:
3.2.3 Stable Mono
OS/device including version:
Windows 10
Issue description:
Exported C# List of Color objects return wrong values while Godot.Collections.Array works
Steps to reproduce:
Setup the list with same value in Inspector
public class Test : Node
{

    [Export] public List<Color> colorsList;
    [Export] public Godot.Collections.Array colorsArray;

    // Called when the node enters the scene tree for the first time.
    public override void _Ready()
    {
        GD.Print(colorsArray[0]);
        GD.Print(colorsList[0]);
    }
}

Minimal reproduction project:
BugColor.zip

Duplicate of https://github.com/godotengine/godot/issues/37652?

Possible duplicate of #37652?

It's too much technical to me to know but there's no error messages as in that other bug report. The Color object is returned but it value is just wrong.

It's also replicable on master. I played with this scenario a bit. I've tested Godot.Collections.Array<Color>, Color[], List<Color>, IEnumerable<Color> and ICollection<Color> and as far as I can tell, this only happens with List<> and it looks like a weird bit packing issue. No matter what colors are set I always get this behaviour:

if the collection's size is even (for example 6), first half will have "garbage" values like -1.971708E-29, 6.417947E-43, -1.971713E-29, 6.417947E-43, the second half will always have values 0, 0, 0, 0
if the collection's size is odd, the middle element will have half-half behaviour: -1.971737E-29, 6.417947E-43, 0, 0 with the rest following the "even" values.

What brakes my bit packing hypothesis is that "garbage" values are not deterministic based on the values of the set colors. But those values seem to follow a pattern: assuming the pattern follows RGBA then G always equals A and they always equal each other in other colors, while R and B are always different but close to each other (also in relation to other colors).
I've tried catching the values on marshalling but I can't seem to enter that particular breakpoint (I'm new to Godot source code so I might be missing something).

Well my previous post is a lot of nothing in retrospect. It looks like any .NET List<> gives garbage values when exported no matter the type used within. Duplicate of #41309


after cli.GlobalString  was removed Google Cloud Print Connector cannot be built

I have an error when building Google Cloud Print Connector:
$ go get github.com/google/cloud-print-connector/...
github.com/google/cloud-print-connector/lib
go/src/github.com/google/cloud-print-connector/lib/config_unix.go:235:15: context.GlobalString undefined (type *cli.Context has no field or method GlobalString)

What version of go are you using? I think this should not happen if you use Go that supports modules.

The issue is that https://github.com/google/cloud-print-connector does not support go module yet, so it falls back to your local urfave/cli download (master branch) so the project won't build any more.

The recent changes in git master broke our builds too. We don't use go modules.

I assume you are vendoring your dependencies somehow differently in that case?
Modules and vendoring was developed for this particular reason.
I don't think it's fair to expect projects to stop all progress because some subset of users are not use widely adopted methods for ensuring version compati ility and rely purely on luck that the upstream project will never make breaking API changes.

@AudriusButkevicius

I assume you are vendoring your dependencies somehow differently in that case?

We use git master of almost all our dependencies. It helps us keep up to date with changes in projects as opposed to having to bump everything all at once. See more info here: https://github.com/purpleidea/mgmt/blob/master/docs/faq.md#why-arent-you-using-glide-godep-or-go-mod-for-dependency-management
We've only had about 3 breaks so far in the history of the project, funny enough, this makes 4, and one of the old ones was also from this project (codegangsta/cli in: https://github.com/purpleidea/mgmt/commit/ab73261fd4e98cf7ecb08066ad228a8f559ba16a )

I don't think it's fair to expect projects to stop all progress because some subset of users are not using widely adopted methods for ensuring version compatility and rely purely on luck that the upstream project will never make breaking API changes.

Not at all. I agree, please change away. Of note, most mature quality projects do remain stable, however if there are changes to be made, we'd prefer they do make them, and improve API and code quality. What's missing this time, is that it seems the API changes were made before good docs or a porting guide were made available. That's my only big objection, and seeing as our builds are still broken, any help in knowing what to change or patches would be appreciated!
Some initial work is in here: https://github.com/purpleidea/mgmt/pull/571

As I mentioned in the other thread we expect one more of these breakages next year, so sadly expect more work in the future.

👋  hi @purpleidea!
Thanks for your feedback here, I had no idea people used go modules in this way ^^
I actually did create a ticket (https://github.com/urfave/cli/issues/921) for writing migration guide, I just didn't know that we should create the guide before merging to master. You live and you learn 🙏

Closed via https://github.com/google/cloud-print-connector/pull/470


Panic because spawn_local called from outside of a task::LocalSet

The server panics with the following error "spawn_local called from outside of a task::LocalSet" (at leptos_reactive/src/spawn.rs:87:13) when trying to connect to the server.
In the server router
.leptos_routes_with_context(
	state,
	leptos_axum::generate_route_list(App),
	move || {
		leptos::provide_context(client.clone());
	},
	App,
)

where state is my Axum state, and client is a reqwest::Client.
In the client #[component] functions
let client = use_context::<reqwest::Client>();
let resource = create_resource(|| (), move |()| {
	let client = client.clone();
	async move {
		client.get()
		// ...
	}
});

Leptos Dependencies
leptos = "0.5.1"
leptos_axum = "0.5.1"
leptos_meta = "0.5.1"
leptos_router = "0.5.1"

Could you please provide a reproducible example?

client/Cargo.toml
[package]
name = "leptos_mre-client"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["rlib", "cdylib"]

[target.wasm32-unknown-unknown.dependencies]
leptos = { version = "0.5.1", default-features = false, features = ["hydrate"] }
leptos_router = { version = "0.5.1", features = ["hydrate"] }
wasm-bindgen = "0.2.87"
[target.x86_64-unknown-linux-gnu.dependencies]
leptos = { version = "0.5.1", default-features = false, features = ["ssr"] }
leptos_router = { version = "0.5.1", features = ["ssr"] }

client/src/lib.rs
use leptos::*;
use leptos_router::*;
#[cfg(target_arch = "wasm32")]
use wasm_bindgen::prelude::*;

#[cfg(target_arch = "wasm32")]
#[wasm_bindgen(start)]
fn start() {
	mount_to_body(|| {
		view! { <App /> }
	});
}

#[component]
pub fn App() -> impl IntoView {
	view! {
		<Router fallback=|| view! {
"NOT FOUND"
 }.into_view()>
			<Routes>
				<Route path="" view=Home />
			</Routes>
		</Router>
	}
}

#[component]
fn Home() -> impl IntoView {
	let motd = create_resource(
		|| (),
		move |()| {
			async move {
				"Hello world!".to_owned()
			}
		},
	);

	view! {

{motd.get()}

	}
}

server/Cargo.toml
[package]
name = "leptos_mre-server"
version = "0.1.0"
edition = "2021"

[dependencies]
leptos_mre-client = { path = "../client" }
axum = "0.6.20"
axum-extra = "0.8.0"
leptos = { version = "0.5.1", default-features = false }
leptos_axum = { version = "0.5.1", default-features = false }
tokio = { version = "1.33.0", features = ["rt-multi-thread", "macros"] }

server/src/main.rs
use axum::{http::StatusCode, routing, Router, Server};
use axum_extra::response::{JavaScript, Wasm};
use leptos::LeptosOptions;
use leptos_axum::LeptosRoutes;
use leptos_mre_client::App;

#[tokio::main]
async fn main() {
	let leptos_options = LeptosOptions::builder()
		.output_name("main".to_owned())
		.site_pkg_dir(".".to_owned())
		.build();
	let app = Router::new()
		.route(
			"/main.js",
			routing::get(|| async {
				std::fs::read("main.js")
					.map(JavaScript)
					.map_err(|err| (StatusCode::INTERNAL_SERVER_ERROR, err.to_string()))
			}),
		)
		.route(
			"/main_bg.wasm",
			routing::get(|| async {
				std::fs::read("main_bg.wasm")
					.map(Wasm)
					.map_err(|err| (StatusCode::INTERNAL_SERVER_ERROR, err.to_string()))
			}),
		)
		.leptos_routes_with_context(
			&leptos_options,
			leptos_axum::generate_route_list(App),
			|| {},
			App,
		)
		.with_state(leptos_options);

	Server::bind(&"<IP_ADDRESS>:8080".parse().unwrap())
		.serve(app.into_make_service())
		.await
		.unwrap();
}

After some more trials, it seems the culprit is the default-features = false in leptos_axum,
the example I provided works when I remove it.

But isn't it weird to let the users disable features that are required for the program to work? Why are they not always enabled?

Thanks. Yes, default-features = false on leptos_axum is the issue. Prior to 0.5, default-features = false did nothing on this package, as there were no default features. Now, default-features = false, features = ["wasm"] is needed to support the use of Axum in JS-based WASM environments (like Cloudflare Workers or Deno Deploy), and simply having leptos_axum without explicitly disabling the default features works fine in other environments.

Now, default-features = false, features = ["wasm"] is needed to support the use of Axum in JS-based WASM environments (like Cloudflare Workers or Deno Deploy), and simply having leptos_axum without explicitly disabling the default features works fine in other environments.

Is this behavior documented somewhere? If so I could not find it.

Great point. Attached PR should both document this new feature situation, and give a much more useful error if they're used incorrectly.

Thank you!


Dev Tools CSS Reference, Print Mode Instructions are repeating

Page Affected:
https://developers.google.com/web/tools/chrome-devtools/css/reference#print-mode
Related Page:
https://developers.google.com/web/tools/chrome-devtools/css/print-preview
What needs to be done?
Hi, I'm not sure if this is correct, this is my first time creating an issue in a public repo,  I was going through the Chrome Dev Tools reference and I found a minor inconvenience in the doc:

View a page in Print Mode and Force Print Preview Mode repeat the same set of instructions, the only difference it's that Force Print Preview Mode it's explained in more detail, I believe it would be convenient to remove View a Page in Print Mode to avoid repeating the same instructions.

@kaycebasques , ran through the both pages, I am thinking probably we can remove Force Chrome DevTools Into Print Preview Mode (CSS Print Media Type) entirely.
CSS Reference - print-mode covered the page content of Force Chrome DevTools Into Print Preview Mode (CSS Print Media Type).
What do you think?


Support for ReFrame test fixtures

We need to support the notion of fixtures for a ReFrame test. A fixture is different from a test dependency and different from a test parameter. The will execute where ReFrame runs and perform operations such as cloning a repo, connecting to a resource that a test needs etc.
Test dependencies in ReFrame differ from fixtures in that they have to deal with the individual test cases (where a test can run and with which programming environments). A fixture will run regardless and will run on the same node that ReFrame itself executes.
Test parameters as discussed in #1567 differ again to fixtures in that the parameterization space is attached to a test we want it to be inherited by its children. Having parameters as fixtures, would require the children to redefine the whole parameter space everytime. We also want parameter attributes to be set.
A typical fixture example, is when you want a test to clone a repo and you don't want to do that for each test case. The current solution is by using test dependencies: have a test to run on a single partition and programming environment and the test doing the actual work depend fully on that one. The problem with this is that you can end up with unresolved dependencies if you run ReFrame with --system=x:part where x:part is not the partition that the test that clones the source is meant to run. This is in fact a restriction that should not exist. You want to clone the repo regardless of where the test executes. That's why we need to introduce the concept of fixtures. Here is an example that shows potential syntax (inspired by pytest fixtures):
import reframe as rfm

@rfm.fixture
def tmp_path():
    yield a_dir_under_stage_prefix()

@rfm.fixture
def clone_repo(tmp_path):
    def _clone_repo(repo):
        return git_clone_repo()

    return clone_repo

class MyTest(rfm.RegressionTest):
    use_fixture('repo', clone_repo('url'))

    def __init__(self):
        self.valid_systems = ['dom:gpu', 'dom:mc']
        self.valid_prog_environs = ['gnu', 'cray']
        self.sourcesdir = self.repo
        ...

Fixtures can be quite intelligent so as not to clone the same repo again and do some reference counting before deleting paths.
In this example, MyTest will clone the test once for all the test cases of MyTest without having to rely on dependencies for this sort of task.

What about a completely different test (in another dir) wants to use the same downloaded repo? would this handle that too?
I.e., tests/testA/testA.py uses repo x, tests/testB/testB.py also uses repo x, will repo x stay available once downloaded or will it eventually be cleaned up after A or B has been finished (with all of their dependencies)?

This is what I had in mind for the fixtures:
A fixture is simply another test that is required to run before the current test gets executed.
On their definition, fixtures can have a scope that sets the less restrictive hierarchy that a test can run on.
From less to more restrictive, the hierarchy levels should be:

session : Share the test results across the full session. This could be, downloading some files or cloning a git repo. This can only be a run-only test because it must not depend on any programming environment. The test variables valid_systems and valid_prog_environs must be '*'.
partition : Share the test results with the test only for the current partition. This could be fetching the topology of the nodes. This can only be a run-only test because it must not depend on any programming environment. The test variable valid_prog_environs must be '*'.
PrgEnv : Share the test results with the test on the same partition and PrgEnv. This could be a compile-only or any other type of tests.
test : Create a new private sub-test. This could be cloning a repo and patching some files in it. This must be private, because otherwise this could cause side effects in other tests using that repo.

When using a fixture, other reframe tests can override the fixture's default scope with a more restrictive one if they wish to do so. Changing the scope to a less restrictive one does not make sense. When a fixture is further restricted by a test and the less resticted fixture has already run, we can just deep-copy the fixture and its stagedir.
Some examples:
class CloneRepo(rfm.RunOnlyRegressionTest, scope='session'):
    '''Clone a repo and share it across the full reframe session.'''
    valid_systems = ['*']
    valid_prog_environs = ['*']

    # Undefined variable. Must be defined in order to use this fixture.
    repo = variable(str)

    def __init__(self):
        sourcesdir = self.repo

class CloneReframe(rfm.RunOnlyRegressionTest, scope='session'):
    '''Clone ReFrame.'''
    repo = 'git@github.com:eth-cscs/reframe.git'

class CloneAndCheckout(CloneReframe, scope='session'):
    '''Clone a repo and checkout a specific version.

    This version would also be shared across the full session. This fixture
    would also do the cloning of the repo, which can lead to repeated cloning
    if some other test has already used the fixture above.
    '''
    ver = variable(str)

    def __init__(self):
        self.postrun_cmds = [f'git checkout {self.ver}']

class Checkout(rfm.RunOnlyRegressionTest, scope='session'):
    '''Use the resources of an existing fixture.

    Instead of cloning the resources for every checkout, this fixture uses the
    logic from the fixture `CloneReframe`, and we just copy the sources from that
    fixture's directory.

    Note that this fixture has `session` for its scope. This is because the
    variable `ver` must be set by a derived fixture, and that will make a
    specific version of the code available for the full reframe session.
    '''
    clone = fixture(CloneReframe)
    ver = variable(str)

    valid_systems = ['*']
    valid_prog_environs = ['*']

    def __init__(self):
        sourcesdir = clone.stagedir
        executable = f'git checkout {self.ver}'

class CheckoutV4(Checkout, scope='session'):
    '''Specialised fixture to checkout the version 4.0.'''
    ver = 'v4.0'

@rfm.simple_test
class RemovePipelineFile(rfm.RunOnlyRegressionTest):
    '''Test that removes a file from the sources of a repo (why not).

    This will logically cause a side effect on other tests that might use these
    source files, so the fixture here has to be restricted to the test only.
    Before that, this test wants to remove a file from a specific version,
    so we must specialise the `Checkout` fixture. Now, the checkout fixture has
    a "session" scope, and removing a file from a fixture that is shared
    amonst many test is not a good idea, so we can restrict that fixture to
    act only locally on this test by further restricting the scope directly in
    the fixture built-in.

    This built-in will run the fixture if it hasn't been executed yet.
    Otherwise, this will just return the handle to the test and use the
    existing resources. Though, in this case, we're further restricting the
    scope of the fixture, so the resources of the fixture will be copied from
    its original directory onto the current test's stagedir (because the inline
    scope is now "test").
    '''

    fetch_sources = fixture(CheckoutV4, scope='test')
    def __init__(self):
        the_file = os.path.join(
            fetch_sources.stagedir,
            'reframe/core/pipeline.py'
        )
        executable = f'rm {the_file}'

class CloneMultipleRepos(CloneRepo, scope='session'):
    '''Clone a few repos.

    Here we reuse the machinery from the `CloneRepo` fixture.
    '''
    my_repo = parameter([
        'git@github.com:eth-cscs/production.git',
        'git@github.com:eth-cscs/reframe.git',
    ])

    def __init__(self):
       self.repo = self.my_repo
       super().__init__()

@rfm.simple_test
class UseFilesFromTwoRepos(rfm.RunOnlyRegressionTest):
    '''Copy files from two repos into the stage of the current test.

    This is a use case where a test might need to fetch from different srcs.
    '''
    # This will return a list with the handles for each instance from the fixture.
    my_repos = fixture(CloneMultipleRepos)

    def __init__(self):
        # Copy the files from the repos into the stagedir.
        repo = my_repos[0]
        self.prerun_cmds = [f'cp {os.path.join(repo.stagedir, file_a.txt)} {self.stagedir}']
        repo = my_repos[1]
        self.prerun_cmds += [f'cp {os.path.join(repo.stagedir, file_b.txt)} {self.stagedir}']

        # ...

@rfm.simple_test
class ForkOffTests(rf.RunOnlyRegressionTest):
    '''For each of the parameters in a fixture, run an independent test.

    The `CloneMultipleRepos` fixture is parametrized with 2 repos. This
    test will run as many times as instances of the parametrized fixture.
    This is the equivalent of parameters, but with fixtures.

    This will generate 2 test, thanks to the `foreach_fixture` built-in.
    '''
    my_repo = foreach_fixture(CloneMultipleRepos)

    def __init__(self):
        self.prerun_cmds = [f'cp {os.path.join(my_repo.stagedir, file_a.txt)} {self.stagedir}']

        # ...

This last example does exactly what is mentioned in #1618.

We have invested a lot in dependencies and they offer quite some flexibility and nice features, such as concurrent execution, restoring sessions, generating Gitlab pipelines, access to all the information of the target tests. It would be an immense effort to reimplement everything for fixtures. Why don't we look it the other way around? What is missing from the dependencies to act as fixtures? One obvious thing is the ability of a test to "execute anywhere" instead of the current "execute everywhere." I like the idea of fixtures being tests or, the other way around, normal tests acting as fixtures, but I would like to see what needs to be added to the tests and/or the dependencies, instead of implementing from scratch a new concept and ending up re-implementing the dependencies.

Where I said above "the main advantage", I should've said "the main difference instead". If the above implied that we should replaced dependencies with fixtures, that's not what I meant :)
I think that by keeping fixtures as test, both dependencies and fixtures could very easily use the same machinery in the background, so I don't think there would be a lot to implement here. Whether we end up supporting fixtures or making dependencies act as fixtures, I think the changes would be the same and only the syntax would differ.
To me, both dependencies and fixtures are very very similar things. However, the scope is the main difference between these two concepts, and also the fact that fixtures execute unconditionally whereas dependencies may or may not execute depending on the when condition. So I guess that the question really is whether we want a "oneAPI" kind of thing for this both concepts, or if instead we split them.

Here is an update on the fixtures. I've reworked a little bit the syntax from the previous comments and I've now made the examples with the affinity test. This test is ideal for fixtures, because it only needs to be compiled once and then ran multiple times with different options.
In order to maximise reusability, fixtures can use other fixtures; so in this case, the first fixture we should think of is the one that clones the repo with the sources of the affinity tool:

class CloneAffinityRepo(rfm.RunOnlyRegressionTest):
    sourcesdir = 'https://github.com/vkarak/affinity'
    sanity_patterns = sn.assert_found(1)

class PatchAffinityRepo(rfm.RunOnlyRegressionTest):
    '''Use the resources of an existing fixture and apply a patch.

    Here we're altering the files from the original repo. So to avoid
    altering any existing cached clones, we get a fresh clone by
    marking the fixture scope as 'test'.
    '''

    clone = fixture(CloneAffinityRepo, scope='test')

    # ...

    @rfm.run_before('run')
    def apply_patch(self):
        '''The sources can be accessed as self.clone.stagedir'''
        # ...

Just to illustrate the point, we've created a second fixture that applies a patch to the original sources. Fixtures are registered by the fixture or test that uses them, and its scope is set by the class that uses the fixtures. This is done with the fixture built-in which assigns a handle to the fixture. As shown later, the handle is needed to be able to override a fixture if needed and to not hard-code the name of the class fixture in hooks and so on.
So the real deal in this code snipped happens in the PatchAffinityRepo class, where the fixture built-in registers the CloneAffinityRepo as a fixture of the current class. Here, the aim of the PatchAffinityRepo is to modify the original sources of the affinity repo, so we need to have our own private copy to make these changes and prevent side effects in other tests/fixtures that may want the affinity repo sources in their original form. This is achieved by setting the scope of this fixture as 'test', which will force the fixture to execute and not to use any other cached clones that might exist.
Now that we have the sources, we can build the executable:
class BuildAffinityTool(rfm.CompileOnlyRegressionTest):
    '''Use the patched affinity sources and build the executable.

    Here we just read the sources from the `PatchAffinityRepo` fixture
    and build the executable in the current test. Because we're not
    altering the original sources, the scope of the fixture can be set
    to 'session'.
    '''

    src = fixture(PatchAffinityRepo, scope='session')

    # Build the executable ...

This BuildAffinityTool fixture uses the patched sources from PatchAffinityRepo and generates the executable. In this case, we assume that this class does not modify/write any files into the PatchAffinityRepo stage, which allows us to set the scope to 'session'. If this class were to modify at all the stage of PatchAffinityRepo the scope should be set to 'test' instead to prevent any side-effects in other tests/fixtures. The next step is to run the executable:
class RunAffinityTestBase(rfm.RunOnlyRegressionTest):
    '''Here we use the `BuildAffinityTool` to generate the executable.

    This one depends on the PrgEnv we're in, so we set that as the
    fixture's scope.
    '''

    aff_tool = fixture(BuildAffinityTool, scope='PrgEnv')

    # .... base run config.

@rfm.simple_test
class RunAffinity1(RunAffinityBase):
    '''First specialisation of the affinity base test.

    This will trigger all the above fixtures before its execution.
    '''

    # ...

@rfm.simple_test
class RunAffinity2(RunAffinityBase):
    '''Another specialisation of the affinity base test.

    This test will reuse the `aff_tool` fixture, which was triggered
    by the `RunAffinity1` test. However, if this test runs on any
    PrgEnv that was not used by `RunAffinity1`, the fixture will run
    again for these new PrgEnvs.
    '''

    # ...

Here the RunAffinityTestBase  sets the aff_tool fixture which is inherited by the specialised versions of the test. Note that this fixture contains the executable and thus it depends on the programming environment that was used for its compilation. Hence, we set the scope of this fixture to 'PrgEnv', which ensures that the executable from this fixture will have the matching PrgEnv than the tests that use the executable. With this current setup, we can have many RunOnlyRegressionTests that use the appropriate affinity tool executable, and this executable will only be compiled once per PrgEnv.
Finally, say that someone wants to specialise the build of the BuildAffinityTool  class and still reuse the tests that run the affinity tool:
class SpecialBuildAffinityTool(BuildAffinityTool):
    '''This class specialises the `BuildAffinityTool` fixture.

    This could be, for example, adding new compile options.
    '''

    @rfm.run_before('compile')
    def update_compile_opts(self):
       self.build_sytem.cxx_flags += ['-O3']

@rfm.simple_test
class RunAffinity3(RunAffinity2):
    '''Specialisation of the RunAffinity2.

    Here we override the base aff_tool fixture.'''
    aff_tool = fixture(SpecialBuildAffinityTool, scope='PrgEnv')

Because each fixture is assigned a handle in the test class, we can easily override an existing fixture and fully reuse the existing code for the RunAffinity2.
Next in line to all this is what happens when a fixture has one or more parameters. But I think we should agree on the above first 😅.

I like the interface and particularly, that any test can be used as fixture. You don't have to mark it as such and there is no need for any magic machinery there. There are two things mainly that I'm kind of missing:

How does a test get access to the information of its fixtures and what kind of information does it get?
I am missing the concept of "setup" and "teardown" which is central to the fixture concept. My guess is that pipeline hooks in the fixture test could take that role. For example, the "setup" could be implied as any "post-init" hook and the "teardown" as any "cleanup" hook in the fixture test.
A corollary to (2) is how fixtures will be executed (let aside the scopes), since this would mean that their cleanup phase should be delayed as with the dependencies. And perhaps this has to be done regardless of the "teardown" concept, because even in the "test" scope you don't want to "execute" the fixture until the end, because its cleanup phase will wipe it out.
Are the fixtures of the same test going to be reused? Imagine the following example:

class CloneAffinityRepo(rfm.RunOnlyRegressionTest):
    sourcesdir = 'https://github.com/vkarak/affinity'
    sanity_patterns = sn.assert_found(1)

class PatchAffinityRepo(rfm.RunOnlyRegressionTest):

    clone = fixture(CloneAffinityRepo, scope='test')

    @rfm.run_before('run')
    def apply_patch(self):
        '''The sources can be accessed as self.clone.stagedir'''

class BuildAffinityTool(rfm.CompileOnlyRegressionTest):

    src = fixture(PatchAffinityRepo, scope='test')
    clone = fixture(CloneAffinityRepo, scope='test')

The BuildAffinityTool "redefines" a fixture that is already defined somewhere in the hierarchy. (a) Is this valid? (b) If yes, is the clone fixture going to be executed only once? (c) What if the scopes in the "redefinitions" are different?
As a side comment: PrgEnv scope is an ❌ as a name. I would vote for environment or environ.

Some updates on the progress here. The first draft implementation uses dependencies under the hood. The fixtures are registered by the "host" test during its instantiation and they get picked up later by the loader. From this point onwards, the fixture is a full reframe test, which the host test depends on. However, a pointer to the fixture object will be injected in the host test during its setup stage. This takes me to the points raised by @vkarak above:

A fixture is a test attribute. This is injected during the setup pipeline stage. For example:

class MyFixture(rfm.RunOnlyRegressionTest):
    ...

class MyTest(rfm.RunOnlyRegressionTest):
    f = fixture(MyFixture)

    @run_before('compile')
    def print_fixture_stagedir(self):
        print(f'Fixture staged: {self.f.stagedir}')

In this case the whole fixture can be seen as the "setup" part and the teardown is the cleanup of the fixture test itself.
This is automatically taken care of by the dependencies.
The answer to this one is: It depends on the scope. For example, on the case above, both clone fixtures have a 'test' scope, so they will be executed twice. This is because a fixture with a 'test' scope will always execute as a new test. However, if this two clone fixtures use a scope they can share (for example, 'session'), they will only be executed once. In this case, the following statement would be true for the BuildAffinityTool  test clone == src.clone.


Added Korean Translation

If you fine, please add korean translation.

Translations are now to be made on Crowdin, which should automatically update the translation files on the following startup


Align and design on integration points with stakeholders (OCM, ASR).

Meet OCM, Compliance & Security and ASR teams and align on the preferred integration points between the tools involved.
The task is completed when the findings are documented in this issue.

closing, as this is not required at this stage. to be re-discussed after initial GLVD API is in place and OCM Gear integration is to be done


!B or ! text is appear in the first of printing text line

I have the same problem

I just verified here in the issues that this is a bluetooth.paperCut() call, some models do not support it, so it needs to be removed from the code.


Investigate issues with internal authenticated feeds

NuGet feeds that require authentication do not work on internal builds even though we have the correct secrets injected into the build, leading to patches like this one.  We should do this properly instead of patching feeds out and checking in binaries.

It looks like even with auth working, we still also need a way to remove these feeds dynamically so that once the commit goes public, it's able to be built. (The plan of record I remember is that the internal bits get pushed to one of the open feeds also in the nuget.config, so that we're able to do this.) I'd suggest creating a target to do these removals rather than using patches.

[Triage]  This has been addressed by the Setup Private Feeds Credentials step in CI.


Switch from the Travis container to the VM

If `sudo` is `false`, then Travis CI will use a container for testing. If
`sudo` is `required, then it will use a GCE VM. We've recently been
seeing permission errors that appeared related to the Travis CI infrastructure.
Switching to the VM resolves those errors. The downside is that it takes 50s
instead of 5s to start up the tester, but given that our tests take 18 minutes
that is okay.

https://docs.travis-ci.com/user/reference/trusty/

green >> speed

This did pass CI before I pushed with a cleaned up commit message: https://travis-ci.org/chef/chef/builds/305996472

Travis is green. Appveyor was previously green, I'm not going to wait another 20 minutes to see it happen 3 times in a row. 🤠


Compile-time error instead of runtime error

Case expressions - Destructuring in the example:

Pattern matching also works in let bindings, though patterns that do not
match all instances of that type may result in a runtime error.
let [a] = [1]    // a is 1
let [b] = [1, 2] // Runtime error! The pattern has 1 element but the value has 2

I think the comment should be // Compile-time error! The pattern has 1 element but the value has 2

It's a runtime error I'm afraid. Currently Gleam doesn't have exhaustiveness checking. https://github.com/gleam-lang/gleam/issues/34

Ahh thank you for the response - did not realise that!

No worries! Hopefully it'll be compile time soon.


feat(ion-sliding-item): Completely swipe item

Feature Description
Currently there is <ion-sliding-item> which can be added around an <ion-item> as described here.
The idea is for an event to be added onto this item that is fired if the ion-item is scrolled completely away.
For example, to remove an item completely from the list the user would swipe the item completely off the list. The event would then fire to remove the item from the list. So if I had a list of emails, I don't have to swipe and then press the delete button. I could just completely swipe the ion-item out of the list.
Which Ionic Version? 2.x
Run ionic info from terminal/cmd prompt: (paste output below)
Cordova CLI: 6.1.1
Ionic Framework Version: 2.0.0-beta.4-f23043ed
Ionic CLI Version: 2.0.0-beta.24
Ionic App Lib Version: 2.0.0-beta.14
OS:
Node Version: v5.10.1

Examples of this would be the defunct Mailbox and current Spark apps, I assume.
Let me piggyback on this one. I'd like to swipe an item completely to either side, yet keep the revealed content. The event would be fired either way, and you'd consume it by removing the item for your use case, while I'd use it to tally a vote.

@dylanvdmerwe @patrickmcd https://github.com/driftyco/ionic/pull/6686 was merged, available in next release!

@manucorporat The linked PR seems to add support for swiping the other direction, not completely swiping off. Do you have an example/documentation for how to make it swipe completely off?

@wli you are right, you can not swipe completely but! you can subscribe to the new (ionSwipe) event, like this:
https://github.com/driftyco/ionic/issues/5073#issuecomment-223768714
^ more documentation will come before next beta is released
Feel free to open a new issue if swiping completely is required for you. and please explain an use case, so we can implement and assign a priority better!

Use case is so that you can remove items from a list without tapping an extra time. I don't need it urgently since I already implemented it myself, so I'll let someone else chime in if they need it in the framework itself.

this code does not work for left side, help please
`<ion-item-sliding #item>

codeFire

            <ion-note item-right  >
              9:10 AM <ion-icon name="arrow-forward"></ion-icon>
            </ion-note>

test

test

test

          </ion-item>
          <ion-item-options side="right">
            <button dark (click)="buy(item)"><ion-icon class="iconslide" name="cash"></ion-icon>buy</button>
            <button danger (click)="sell(item)"><ion-icon class="iconslide" name="warning"></ion-icon>sell</button>
            <button  (click)="addCart(item)"><ion-icon class="iconslide" name="cart"></ion-icon>add to cart</button>
          </ion-item-options>

          <ion-item-options side="left">
            <button   (click)="unread(item)"><ion-icon  class="iconslide" name="book"></ion-icon>archive</button>
          </ion-item-options>

        </ion-item-sliding>`


Peglin Demo key

Game name
Peglin Demo
Request type
Adding a new game to the feed
Target frameworks, package dependencies
net35
Allowed assembly names
Assembly-CSharp
Assembly-CSharp-firstpass
Contact details
<EMAIL_ADDRESS>Additional information
I hope I got the frameworks/dependencies section right, I'm not entirely certain what I should be putting there.
Package ownership agreement

[X] I acknowledge and agree to the above rules

To my knowledge I'm the only plugin dev modding this game so far. I've kind of been winging things, but I've used .NET Framework 4.6 for all my plugins until now. I assume 3.5 should then work fine as well?

In that case net45 should be a good enough and allow for compiling against .NET Framework 4.x


chore: added FRs and characteristics of intended reader

New sections:
Functional Requirements (5.1)
Characteristics of Intended Reader (2.3)

LGTM BBG


raise ImproperlyConfigured(msg.format(name=self.urlconf_name))django.core.exceptions.ImproperlyConfigured:

raise ImproperlyConfigured(msg.format(name=self.urlconf_name))django.core.exceptions.ImproperlyConfigured:
''does not appear to have any patterns in it

@Deepaksinghmadan Can you provide some additional information on how to reproduce this?

Closing due to lack of response.


Upgrading 2.0 error: edgedb error: remote instances cannot be upgraded

EdgeDB Version: 1.4 trying to upgrade to 2.0
OS Version: Monterey (M1)

Steps to Reproduce:
Pic attached of entire issue

Schema:

To just clarity: this project is linked to a remote instance?
The short answer is that the CLI just isn't capable of upgrading remote instances right now. We'll post here once we have a proper remote upgrade guide — soon@

for remote instances the upgrade procedure is

create a new remote instance using EdgeDB 2.0
edgedb dump -I old_instance mydumfile
edgedb restore -I new_instance mydumpfile

The original error message seems to suggest the CLi failed to upgrade a local instance and now wrongly thinks it's a remote instance.
@jfeiwell, can you try edgedb instance revert "ag_0528" and try the upgrade again?

So that worked to get the instance running locally. When I try to upgrade this is what I get
Upgrading to a major version 2.0+88c1706 Version 2.0+88c1706 is already installed Dumping the database... edgedb error: ClientConnectionFailedError: cannot establish connection for 30s: Connection refused (os error 61)

Can you successfully create a frech 2.0 instance?

edgedb error: Project is already initialized.

A new directory.  I'm wondering if the 2.0 build is crashing on your machine for some reason.
Also, please do the edgedb instance revert and try the upgrade again with env RUST_LOG=debug and post output if possible.

It works with a new directory.
I run the project upgrade and it makes the instance inactive and gives that in progress error. I run instance start and it's running again but get same error. When I run revert it says edgedb error: cannot find backup directory to revert

@jfeiwell and I diagnosed this via Discord and it appears that Postgres 14 hangs at bootstrap time.  Switching to the native arm64 build resolved the issue.
For reference, here's how one can currently upgrade to native Apple Silicon builds:
Step 1: reinstall the CLI: curl --proto '=https' --tlsv1.2 -sSf https://sh.edgedb.com | sh
Step 2: remove the previously downloaded x86 build of EdgeDB 2.0 (edgedb server uninstall --version "2.0")
I'll leave this issue open in case others bump into this.


Support format SBOM conversion

Syft can output multiple SBOM formats, however, once you have that format you can't convert to another format. This could be most useful if you have a syftjson formatted document and you want to produce SPDX (which should be lossless). In these cases something like this would be nice:
syft my-image:latest -o json > original.json
syft convert original.json --to spdx > original.spdx
syft convert original.json --to cyclonedx > original-cyclonedx.xml

It's not clear what to do in cases where there is potentially lossy behavior (e.g. convert from cyclonedx to syftjson):

Warn the user that this is a lossy conversion and continue
Stop the conversation (possibly bypass with --force or similar option)
Do nothing --this is an end user concern (I feel that this is not a good option)
Possibly guarantee non-lossy behavior by including all additional (not in specification) fields into all document formats (there is a heavy pro, and several cons)

One question that comes to mind: do we want to restrict these conversions to only documents that syft created to begin with? Or be able to generically convert between formats for a document that was generated from another (non-syft) tool? (does thing bring on more complexity? or not?... if so, how much?)

I'd start converting Syft to any of those, as detailed in the example. Another option could be to support multiple output formats instead of a single output format as today. wdyt ?

Another option could be to support multiple output formats instead of a single output format as today. wdyt ?

This definitely makes sense — and I'd say this is a separate feature, which we happen to have captured in #325

Relevant to this is the cyclonedx's SPDX taxonomy > https://github.com/CycloneDX/cyclonedx-property-taxonomy/pull/7

from refinement:

This ties into the github dependency API work in progress, pending  https://github.com/anchore/syft/pull/836
Should we be warning on a per-field aspect? if so, how would we do this?
It may be that the cyclonedx and spdx encoders/decoders have gotten good enough where we don't need to warn on anything.
We can go an encode-decode-encode pass to detect if we should output a warning (potential loss in data). This isn't perfect as data ordering may have caused this.
Do we want to capture intent of the convert functionality? That is, this is a utility to convert SBOMs that are similar to syft output, not cover all features in all SBOM specs. Suggestion: we can add verbiage in the readme and help text around this being for "packages", thus does not consider VEX or similar components (so that information would be lost).
Maybe we cover some of the caveats in a blog post to show the most useful use cases this covers.
Consider mirroring what we do with cyclonedx properties with spdx annotations.

We can go an encode-decode-encode pass to detect if we should output a warning (potential loss in data). This isn't perfect as data ordering may have caused this.

For SPDX this the encode/decode process has data loss, I suspect: due to library differences, we encode it via our JSON definition, and decode using SPDX's go lib. Moving to SPDX's official lib might help us here in two fronts: offload code we have to maintain AND fix data loss.

Open Q&As:

Why files are relevant to SBOMs?
a: awareness of what sources/files are in the bundle. Digest-checking validation.

Encode/Decode are the only operations during conversion?
a: yes

Is encode/decode/encode distorting the use-case? Maybe just test encode/decode?
a: A better test seems to be decode/encode

What is next for this feature?
a: iterate with community about what is good and what needs improvement.

What we tell the users about data loss? Warn?
a: clearly say it is an experimental feature, and point out where to find more info.

MVPing it
Basic supported fields:

Packages (most relevant, because of pURLs)
Files (2nd most relevant)
Relationships*

Other relevant points

Provide two tables: (1) for encoding (2) for decoding -- because direction of conversion matters.
Decoding is the main operation with conversion.
We encode as much as possible.
No focus on automated tests for 1st version.


_build: fix dynamic version

Signed-off-by: Filipe Laíns<EMAIL_ADDRESS>

Sorry for the delay, I am gonna merge this and open another PR for the missing version in sdists.


Simpler CrossSection

Move routing info from CrossSection to another class RouteSettings or Interconnect
to separate CrossSection, and all routing settings

class RouteSettings(BaseModel):
    """
    Parameters:
        radius: main Section bend radius (um).
        width_wide: wide waveguides width (um) for low loss routing.
        auto_widen: taper to wide waveguides for low loss routing.
        auto_widen_minimum_length: minimum straight length for auto_widen.
        taper_length: taper_length for auto_widen.
        min_length: defaults to 1nm = 10e-3um for routing.
        start_straight_length: straight length at the beginning of the route.
        end_straight_length: end length at the beginning of the route.
        snap_to_grid: Optional snap points to grid when extruding paths (um).
        decorator: function when extruding component. For example add_pins.
        taper_to_long_routes:
       cross_section:
    """

Then we remove all parameter from CrossSection

We have simplified CrossSection quite a bit now


pkg/trace/api: add additional fields to info endpoint.

What does this PR do?
This commit exposes additional configuration information from the Trace Agent through the info endpoint.
Motivation
We need some additional configuration info from the Trace Agent in order to support client-side stats.
Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

As @pierotibou suggested in the design doc, the ProbabilisticSampler field could be replaced by a more generic name and the logic to enabled trace dropping could be moved in the agent.

/merge


Fix/intl renewal

@hugobast @sherryson
this is ready for CR. the problem earlier is renewal isn't working for Canadian subscriptions because the order's currency is being set to USD.
The changes here will set the subsequent orders to follow the last completed order's currency and store id.
I also surfaced the currency in the admin subscription listing page, similar to our admin orders listing.

@hugobast @sherryson updated - moved it into a callback instead, but i still left a comment. :)


Multiple slides in carousel

I've been looking for a port of jcarousel in angular, but haven't found anything.  Ideally I'd like to use ui's carousel but it's fairly limited.  Is there any appetite for a PR that adds support for multiple slides?

@jsdevel, what do you mean by multiple slides?  Can you please provide an example?  Thanks.

This can be viewed at http://www.republicservices.com/businesses on the top of the page.  Note that if you resize your window, the carousel shows fewer items.

This sounds much more like a pagination element than a carousel - you can probably just use the pagination directive with custom templates to accomplish this.

The issue with pagination is that the number of visible items must change based on screen width.  jcarousel implemented this nicely, but so far I haven't found a good angular solution.

This sounds much more like a pagination element than a carousel - you can probably just use the pagination directive with custom templates to accomplish this.

Actually, in looking at the current implementation on my site, there are a fixed number of items!  Thank you so much for letting me know about pagination!

Have you guys considered gitter over issues?

Gitter runs too slow, but I recommend checking out the Angular Buddies Slack - there's a nice help channel for general support issues

hi @jsdevel! Did you resolve it?

I ended up having to watch for window resize events and shuffle the items between the slides to make the correct width.  Not ideal, but it worked for our use case.


⚠ Bofrost.be has degraded performance

In efc5304, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 848 ms

Resolved: Bofrost.be performance has improved in e679ebc.


WIP: Chore/babel register

Warnings

:warning:
There are no updates provided to CHANGELOG. Ensure there are no publicly visible changes introduced by this PR.

  Generated by :no_entry_sign: dangerJS


Added batch size regulation

Which problem is this PR solving?
Some points in #75.
Short description of the changes

Now batch size is regulated by additive increase/multiplicative decrease algorithm.

Could you please add more comments what the patch does?
We should perhaps also document this in config so people know how that the batch size is variable

@pavolloffay As far as I  can see, writer.writeBatch is safe to use concurrently, 'cause only db and logger are shared between its two calls. Sql.Db is safe for concurrent use for sure. For go-hclog I couldn't find any info, but I suppose it's safe too.


Battle for Whiterun v1.0.13a Notes

During the exterior battle, I was spammed with notifications that various targets were too powerful for Hysteria. I was not using this spell directly. I was not using a weapon with this enchantment. I suspect one of the NPCs fighting in the battle had such a weapon, though. I further suspect that the effect was being erroneously attributed to me rather than them.
Most likely due to the same issue, I also received a significant amount of Illusion skill increase. I was not actually using any such skills, but it increased at an extremely high rate during the battle.
After lowering the drawbridge, I know it's vanilla behavior for the defenders to run into the city. This always seemed really weird, though. They make no effort to defend themselves from the attackers. It would make more sense for them to just keep fighting, at least if they are being attacked.
The portion in the streets of Whiterun seemed to go well.
Dragonsreach seemed fine up till defeating Balgruuf. Then it got slightly weird.
I use JK's Dragonsreach, so the extra obstacle in front of the throne seemed to cause some oddity for the scene where Vignar shows up. He did some awkward walking around the throne room before ultimately stopping way behind Balgruuf (instead of in front of him, since they're talking to each other). I also had three people and a pet skeever following me, so it's possible he had trouble pathing there even without the interior layout change.
The vanilla issue of the combat/siege music continuing even after the fighting is over persists. As usual, it thankfully goes away after I exit Dragonsreach AND fast travel to report the victory to the faction leader.
Before I could exit Dragonsreach, though, Galmar forced a conversation start with me. He didn't actually say anything, though. And he didn't have any new options. So that also seemed odd.

Oh, also, before actually entering the city gates, I noticed Galmar ended up in combat with my followers. Probably a stray ranged attack from one of them or something. Probably also a vanilla issue. But noting anyway.

Before I could exit Dragonsreach, though, Galmar forced a conversation start with me. He didn't actually say anything, though. And he didn't have any new options. So that also seemed odd.
This happens post Riften for imperials as well and I think post Markarth

During the exterior battle, I was spammed with notifications that various targets were too powerful for Hysteria. I was not using this spell directly. I was not using a weapon with this enchantment. I suspect one of the NPCs fighting in the battle had such a weapon, though. I further suspect that the effect was being erroneously attributed to me rather than them.

Thanks for reporting. I will investigate this.

Before I could exit Dragonsreach, though, Galmar forced a conversation start with me. He didn't actually say anything, though. And he didn't have any new options. So that also seemed odd.

I will look at this as well. I never liked this.

This half fixed.... https://github.com/schofida/CWORR/releases/tag/v1.0.15a

Before I could exit Dragonsreach, though, Galmar forced a conversation start with me. He didn't actually say anything, though. And he didn't have any new options. So that also seemed odd.

This should not happen anymore

During the exterior battle, I was spammed with notifications that various targets were too powerful for Hysteria. I was not using this spell directly. I was not using a weapon with this enchantment. I suspect one of the NPCs fighting in the battle had such a weapon, though. I further suspect that the effect was being erroneously attributed to me rather than them.

This should be fixed now as well.


service/AppStore: add null check in dispose method

The disposer field were of any type so TS did not catch this.
If disableSearch option is set to true, we never set up the mobx observer, effectively leading to this.disposer being undefined.

@williamboman good catch 👍
Thanks!

No probs! Would it be possible to get a new release with this included 🙈?

It's in progress: https://travis-ci.org/Rebilly/ReDoc/builds/443139170


Beam backfill

What was wrong?
Fix #951
How was it fixed?
Pretty much as planned.
Some stuff came up. Seems like the lock approach to make sure we don't ask the same peer for data twice is pretty finicky. It was triggering timeouts, even validation failures. So there's a hack to prevent asking for backfill nodes from a peer that already has an outstanding GetNodeData request.
To-Do

[x] Stop interfering with the primary beam sync, maybe maintaining a blacklist of peers that have recently been used by the beam sync importer. Currently, backfill is causing beam sync to have growing lag
[x] Still getting some timeout errors on the lock itself, which assumes all requesters use the same timeout.
[x] Maybe a more robust locking solution that doesn't break so easily :football: to later
[x] It's not finding out data as quickly as I'd like, track down why. (First guess is the sleep when there are outstanding requests to all the peers the code was asking each peer in series and waiting for the previous one to finish :man_facepalming: )
[x] A better story for what happens when we finish backfill. Right now it just keeps scanning the DB over and over :football: to later

[ ] Clean up commit history

[ ] Add entry to the release notes

Cute Animal Picture

I'm in the process of pulling things out into their own PRs:

#1034
#1035
#1043

#1045

Some more that I will rebase on when they are closed:

#1073
#1074
#1075

Still more ideas of things to work on, but I think this is a good chunk for review, and it seems to help identify the peers that can provide the node data quickly. If we can get this merged early enough tomorrow, then I can start a release to go out tomorrow. Then I'll start writing up Beam Sync, which might require a series of posts to adequately explain.

If we can get this merged early enough tomorrow, then I can start a release to go out tomorrow

I'll review this evening after kids are down to bed.


Typo in python code

At one point in the README.md, you state:
>>> a = "some_string"
140420665652016
>>> id(a)
>>> id("some" + "_" + "string") # Notice that both the ids are same.
140420665652016
...

but I believe the correct order would be
>>> a = "some_string"
>>> id(a)
140420665652016
>>> id("some" + "_" + "string") # Notice that both the ids are same.
140420665652016
...

Ah, this is bad... fixing it right away!


Add Sigmoid curve

we should be able to create Sigmoid curve element https://en.wikipedia.org/wiki/Sigmoid_function


[React 18] Chart shading broken in production builds

While making some recent commits to #2993, I noticed the random-color shading of chart backgrounds appears to be broken on production builds (including excalidraw.com), but not on development builds.  I suspect this is a React 18 upgrade regression, similar to #5503.  The following images demonstrate the issue.
From my local machine:

From the Vercel preview of #2993:

And from excalidraw.com:

@DanielJGeiger could you share a scene link for this drawing which we can check in production ?

@ad1992 The issue arises when creating charts by pasting CSV contents from the clipboard.  So, I think a scene link might not help.  Here is what I pasted to generate the charts in this issue:
\(x\),\(\bar y\) mean
\(\frac{1}{2}\),1
1,2.5
\(3x^2\),5
6,8.5

Both MathJax and the "Crisp" subtype were active in the Vercel preview.


[FEATURE]  Allowing users to download backing images

Is your feature request related to a problem? Please describe.
Allowing users to download the backing images from UI, so that those images can be shared accordingly.
Depends on: https://github.com/longhorn/longhorn/issues/3155

The corresponding Longhorn backend API is /v1/backingimages/{name}/download
And the Longhorn UI PR is: https://github.com/longhorn/longhorn-ui/pull/519

Verified this feature has been implemented.

Test Information

Environment: qemu/KVM 2 nodes
Harvester Version: master-a579442f-head
ui-source Option: Auto

Verify Steps:

Install Harvester with any nodes
Create a Image img1
Click the details of img1, Download Button should be available
Click Download button, img1 should able to be downloaded and downloaded successfully.


Fix refresh and loading status

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Better discoverability for Facebook event link

It's hard to discover that the "f" icon is in fact a link. One idea is adding some shadow to the button, and also perhaps make it larger.

On hold. We may want to change the icon to a "Join Discord" button or similar in the future. Let's decide at that time.

Nah.


How can i set password for the export file?

(Fill in the relevant information below to help triage your issue.)

Q
A

Version
0.0.1

Question
I would like to set a password for my export file because it contains some sensitive data. Can anyone help me?_
_Many thanks
Checks before submitting

[x] Be sure that there isn't already an issue about this. See: Issues list
[x] Be sure that there isn't already a pull request about this. See: Pull requests
[x] I have read, search and not found the information on the documentation website.
[x] I have read, search and not found the information on PHP related forums and/or websites.
[ ] This issue is about 1 question around the package with no business or domain specific logic related to a specific situation.
[ ] The question has a descriptive title. For example:  "Can I use the library with compressed CSV documents ?".

I would like to set a password for my export file because it contains some sensitive data. Can anyone help me?
Many thanks

@drupalex10 thanks for using the library. Unfortunately your question is out of scope for this library if you want to protect sensitive data there are many techniques and pattern to use and I am no security expert so any advice on a correct implementation from my part would be at best wrong.
You should contact a security expert for that.
Hope you will resolve your issue.


Handle when "bundled" node stops syncing blocks. At the least notify user.

Let's close this, and hope that bundled node doesn't stop syncing


Enhance GetTRTillDesiredReason func

Return the actual reason and then enhance the ginkgo assertions to display the actual reason in case of an error when calling this function. This is related with https://github.com/shipwright-io/build/pull/481
The above will provide users with the following insights in case of a failed assertion in ginkgo:

@adambkaplan this is ready, I extend the integration tests timeouts, this is already helping with what have been seeing on timeouts during integration

@adambkaplan I cannot lgtm my own pr

/lgtm