nl2br with html table problem

test markdown with wrong (no empty line between title and table):
## title

123123

generate to:
$ markdown_py -x nl2br test.md

title

123123

test markdown with right (empty line between title and table):
## title

123123

generate:
markdown_py -x nl2br test.md

title

123123

Although  the first case is not a good write way, but I tried GFM and found it can parse this right.

Based on markdown spec, Markdown should be surrounded by blank lines.

The only restrictions are that block-level HTML elements — e.g.
,
,
,
, etc. — must be separated from surrounding content by blank lines, and the start and end tags of the block should not be indented with tabs or spaces. Markdown is smart enough not to add extra (unwanted)
 tags around HTML block-level tags.

If you change your code to the following, you will have no issues:
## title

123123

First of all, GFM is a CommonMark variant (not Markdown) and they follow a different set of rules than we do (@facelessuser quoted the relevant rule above).
The primary different here is that CommonMark does not require a blank line between the heading and the raw HTML. However, Markdown does require a a blank line. The missing blank line causes Markdown to not identify the table as a raw HTML block. Once that happens, all bets are off that any other behavior will be as you expect. The thing about Markdown is that the rules only discuss what happens when you have valid syntax. There are no rules about what happens when you provide invalid syntax. I'd say the actual output is a reasonable result. Each line is identified as inline raw HTML, which the nl2br extension sees no differently than inline Markdown. Thus, you get a br tag at the end of each line.
I'm closing this as there is no bug here.

@facelessuser @waylan, Thanks, I got it. 👍


How do i fix this???

Describe your problem here.
every time I build my mod, this pops up after it opens(no title screen, or text pops up before)

I don't know what happened, it worked before, all iI did was change the Icon16 file
Are you modding a build from source or with Lua?
Source
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
I made a new main menu, and added a few new awards, and changed the name, and icon of the Executable file(that's all I remember adding)

Missing XML file for a TitleState object

Can you give me an example of a Title state object?
On Tue, Oct 11, 2022, 10:37 PM frantastic24 @.***>
wrote:

Missing XML file for a TitleState object
—
Reply to this email directly, view it on GitHub
https://github.com/ShadowMario/FNF-PsychEngine/issues/10831#issuecomment-1275576933,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AY5TVGZYRRBYHFJPDFI5HP3WCY57HANCNFSM6AAAAAARC4BQLU
.
You are receiving this because you authored the thread.Message ID:
@.***>

Missing XML file for a TitleState object

Can you give me an example of a TitleState object?

It's an animated sprite, I don't know what you edited in the state so I can't tell you which one

It's an animated sprite, I don't know what you edited in the state so I can't tell you which one

I didn't edit the TitleState.hx file

Would've been easier if you just looked up the lines of code
It looks like logoBumpin is missing texture files


Add conflict of interest check

This PR:

Adds an action to auto comment when a PR author does not check the conflict of interest checkbox

Love

Love


Ged style update

:tada: This PR is included in version 1.2.0-rc.8 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix lower earnings limits on adoption pay

The legislation says that

(2)(d)that [their] normal weekly earnings [lower earnings limit] for the period of 8 weeks ending with the relevant week are not less than the lower earnings limit in force under section 5(1)(a) at the end of the relevant week; and
...
(3)The references in subsection (2)(b) and (d) above to the relevant week are to the week in which the person is notified that he has been matched with the child for the purposes of adoption.

In the case of birth this "relevant week" is 16 weeks before the due date.  For adoption it's the match week, analogous to the due week in most cases.
As such we should be using the end of the match week as the point to check the rates file.
https://trello.com/c/SViOJG0s/991-employers-maternity-calculator-change-calculation-in-adoption-paternity-branch

.


AssertionError when using LINE Coverage

I copied "queue_example.py" from the quickstart guide on https://pynguin.readthedocs.io/en/stable/user/quickstart.html.
When i try to get the coverage report "LINE i get the error:

Commands used:
pynguin --project-path ../Badge5 --output-path ./tmp/pynguin-results --module-name main -v --create-coverage-report True --seed<PHONE_NUMBER>714481067 --coverage_metrics LINE
pynguin --project-path ../Badge5 --output-path ./tmp/pynguin-results --module-name main -v --create-coverage-report True --seed<PHONE_NUMBER>714481067 --coverage_metrics BRANCH LINE
I just followed the guide. What am I doing wrong?

Sorry for the inconvenience. The default algorithm (DynaMOSA) only works with branch coverage as of now.
Choosing a different algorithm, e.g., --algorithm MOSA, should work.

Thank you for your fast response and thank you for the help. MOSA did work


Add support for multiple hard drives

Add support for multiple HDDs for any device type
Add support for SSDs.
.md formatting

Example smartctl output for one of my SSDs:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       7
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       5
148 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       0
149 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       0
167 Write_Protect_Mode      0x0000   100   100   000    Old_age   Offline      -       0
168 SATA_Phy_Error_Count    0x0012   100   100   000    Old_age   Always       -       0
169 Bad_Block_Rate          0x0000   100   100   000    Old_age   Offline      -       4
170 Bad_Blk_Ct_Erl/Lat      0x0000   100   100   010    Old_age   Offline      -       0/19
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
173 MaxAvgErase_Ct          0x0000   100   100   000    Old_age   Offline      -       1
181 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
182 Erase_Fail_Count        0x0000   100   100   000    Old_age   Offline      -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
192 Unsafe_Shutdown_Count   0x0012   100   100   000    Old_age   Always       -       2
194 Temperature_Celsius     0x0022   024   031   000    Old_age   Always       -       24 (Min/Max 23/31)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
199 SATA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       0
218 CRC_Error_Count         0x0032   100   100   000    Old_age   Always       -       0
231 SSD_Life_Left           0x0000   100   100   000    Old_age   Offline      -       100
233 Flash_Writes_GiB        0x0032   100   100   000    Old_age   Always       -       6
241 Lifetime_Writes_GiB     0x0032   100   100   000    Old_age   Always       -       9
242 Lifetime_Reads_GiB      0x0032   100   100   000    Old_age   Always       -       0
244 Average_Erase_Count     0x0000   100   100   000    Old_age   Offline      -       0
245 Max_Erase_Count         0x0000   100   100   000    Old_age   Offline      -       1
246 Total_Erase_Count       0x0000   100   100   000    Old_age   Offline      -       168

The following line caused an error because 0/19 it is not an int:
170 Bad_Blk_Ct_Erl/Lat      0x0000   100   100   010    Old_age   Offline      -       0/19

So added the following condition at line 98 to make sure it is an int before adding:
if match_found and match_found.group(2).isdigit():
    stats[match_found.group(1).lower()] = int(match_found.group(2))

@Tyler-Brenneman thanks for the update! I wanted to implement that feature but I did non find the time to do that :) I've moved SATA and NVME disks paths' definitions into ENV VARS and updated also the readme. I've added you to the AUTHORS.md file.
Have a nice day, thanks!


Query keys containing computeds that evaluate to undefined aren't cloned properly

If a ref in the query key returns undefined, undefined will be returned here: https://github.com/DamianOsipiuk/vue-query/blob/main/src/vue/utils.ts#L151
But at https://github.com/DamianOsipiuk/vue-query/blob/main/src/vue/utils.ts#L128-L130, we only return the result if it wasn't undefined. undefined is interpreted as "okay, it wasn't a ref, let's keep going", but undefined could in fact have been the actual value of the computed. The end result of this is that you don't get the computed value in your query key, but the full computed object with all of Vue's internal attributes. For me this ultimately ends in a TypeError: cyclic object value when react-query tries to JSON.stringify the query key containing the computed.

Thanks for the very quick fix!


Populating json file

Hi BeauNouvelle,
This is a great resource!  I'm going to use it in one of my apps for learning chords.  What did you use to populate the json file for the chords?
Regards Gerard

Yeah I can't remember where I pulled that data from. I wish I could so I could give credit on it.


shim 0.8 can't be executed in vmware <IP_ADDRESS>495

I've complile and test shim 0.2/0.3/0.7,and shim works fine.
but I complile shim 0.8 then test it in vmware, the vmware halt.
My gcc version:
/usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc/libexec/gcc/x86_64-linux-gnu/4.7.4/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --prefix=/usr/local/gcc --enable-shared --enable-linker-build-id --without-included-gettext --enable-threads=posix --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-plugin --with-system-zlib --disable-browser-plugin --with-arch-directory=amd64 --enable-multiarch --disable-werror --with-arch-32=i686 --disable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.4 (GCC)

I‘ve just tried gcc 4.9.2, and shim(0.8/mater) still halt

Does this work for you?
https://github.com/lcp/shim/commit/61f1bfea2250c38b6c381a3876b41acf007f4289
There is a known issue that objcopy in binutils < 2.24 didn't support asterisks and some sections of the efi file would be gone. The change(*) was introduced between 0.7 and 0.8.
(*) https://github.com/rhinstaller/shim/commit/99d7b5e858945b8bb160fe3fea77596b2daf07ff

Thanks, I update binutils and it works.


Makes arrow cursor clickable in fair details

Hi,
I was playing around with Eigen and noticed that the arrow cursor in fair details was not clickable, which was not consistent with the behaviour seen in the actual fair page. So I changed it to be 😉
Before

After

          1 Warning

  :warning:
  Please assign someone to your PR

  Generated by :no_entry_sign: danger

Hi @pedrovereza, great catch and thanks for submitting the change. I chatted with our designer about this and it looks like the entire area should be clickable. Meaning .art-fairs--fair-details should be a clickable link. If you'd like to go ahead and make that change, I'd be happy to merge. Again, thanks for the PR!

@xtina-starr Oh right, didn't notice there is a non-clickable area between the arrow and the actual description 😞

So in order to make the whole area clickable just like this:

I added display:block in fairs-link (which is present in fair-nav-item-link):

If you are ok with this approach I can update the PR 😄

👍  This works for me! Thanks for making the change and thanks for your contribution!


How to train/create control codes?

Hi. I am thinking about to train my own control codes. How it is possible?

The FAQ answers this:
Q: Will you be releasing the training code and data?
A: We plan to release the training code soon. We will not be releasing the training data, but we will release tips and scripts related to data collection.

Closing this since it's a duplicate of https://github.com/salesforce/ctrl/issues/8
I'll be adding some discussions there.


Fix contributed icons for ModelView trees not showing

For https://github.com/microsoft/azuredatastudio/issues/18429

I also went through our code and verified that other uses of background-image are being done correctly.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 48.264%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
14817

Relevant Lines:
29138

💛  - Coveralls


VM Configuration Never Completes

I am using this for the first time so might be doing something wrong. I am trying to create the lab environment for the AD Certificate Services course Pluralsight. The standalone machine worked as expected, however, the lab setup using "AutoLab\Configurations\POC-MultiRole" never completes. Apart from the Nano Server all the other machines just sit at the Hyper-V black screen with the spinning dots. I have left this for 24 hours and the Pester test constantly fail. Apart from that I have seen no other error messages.
I have tried removing all the modules, including Lability but still get the same issue. I also tried running the lab setup up command individually and I am seeing the same results.
Any suggestions on what I am doing wrong? Thanks in advance for any help.

Let's start with some background information. What OS are you running this on? What is the value of $PSVersionTable? I'm pretty sure I've run this configuration without error. The other thing you could do is start a PowerShell transcript, run the commands, then Ctrl+C the operation, stop the transcript and post it. Maybe we'll find something useful.

Hi
I am running this on a server 2016 std edition build. The PSVersion is 5.1.14393.953.
I will try running the transcript and post it.
One other thing I noticed during the configuration process for the VMs is that it says it is Decompressing the some of DSC resources to the E: drive. The Server 2016 host definitely doesn't have an E: drive so do the VMs have an E: drive once built? I had a look through the configs for the VMs but couldn't see this being configured anywhere:

The build process creates a new VHD file which gets mounted so that files can be copied to it. That's where the E: drive is coming from. It gets automatically cleaned up when the VHD is dismounted.  Do any other configurations work?  Also make sure you have plenty of free drive space.

I have attached a transcript of the session. I appreciate that I didn't let this run as long as it could have but I am assuming it won't work again. The main initial error appears to be "TerminatingError(Resolve-Path): "The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Cannot find path 'C:\Program Files\WindowsPowerShell\Modules\Lability\0.10.1\Config\CustomMedia.json' because it does not exist." I have visually confirmed that this file does not exist in the directory above.
I have nearly 170GB of free space on the drive where the VMs are being created.
I haven't tried any other configurations beside the standalone server which worked.
POCMultiroleTrans.txt

Try another configuration while I look at this.

Will do. Thanks Jeff

This is looking like a Lability related issue. Do you have multiple versions installed?
get-module lability -list

The latest version is 0.10.3. Running Setup-Host may download an older version. I'd verify you only have the latest version installed for starters.  Still trying to dig into this.

OK, currently the version of Lability I have installed via Setup-Host is 0.10.1
I will upgrade to the latest version.

There must be something different about your setup. I ran the POC-multirole on Win10 (5.1.15063.0) without errors. I'm curious to know if any other configurations work.

I am running the Test-SingleDC configuration now. The only configuration that has worked successfully so far is the Test-SingleServer configuration.

I'm assuming you downloaded the most current zip file for this project. I'd say wipe all lab configurations.  Reboot. Then go back to POC multirole and start a transcript. Run Setup-Lab. If that runs without error then run Run-Lab. I'm assuming that is where you'll have problems. If so, stop the transcript and post it again.

Yeah, I downloaded what was the latest version yesterday. I will try removing everything and starting from scratch and see how I get on.
Thanks for your help looking into this.

After completely removing everything, including any DSC resources that had been downloaded for the labs, I first installed the latest version of Lability, then re-ran the PSAutoLab setup. I have now been able to successfully create the POC multirole configuration. Thanks for your help in looking into this with me.


Changing the default dimension order

Currently by default we interpret the dimensions of arrays as (chain, draw, param_dims...). I propose a breaking change that uses the new default ordering (param_dims..., draw, chain) for several reasons.
TL/DR: The main arguments for this are motivated by efficient memory usage in Julia. The main arguments against this are consistency with Python and current Julia code, but when using deserialized data, this choice actually makes us more consistent with how Python ArviZ does things.
To demonstrate the reasons for doing this, let's generate "data" in a sensible default structure we might expect from a PPL. When sampling with MCMC, each chain is usually sampled separately (whether parallel or in serial), so the draws are separate in memory. For a given chain, the draws are taken in a sequence, so by default for a single draw, the values of the different parameters are stored adjacent to each other in memory. So suppose we have 2 parameters a and b with sizes (3,) and (2, 2). Our samples might then take the form:
julia> nchains = 4;

julia> ndraws = 10;

julia> nparams = 7;

julia> samples = map(1:nchains) do chain
           map(1:ndraws) do draw
               a = [("a[$i]", draw, chain) for i in 1:3]
               b = [("b[$i,$j]", draw, chain) for i in 1:2, j in 1:2]
               return vcat(vec(a), vec(b))
           end
       end;

julia> samples[1][1]  # let's look at the parameters for a single chain and draw
7-element Vector{Tuple{String, Int64, Int64}}:
 ("a[1]", 1, 1)
 ("a[2]", 1, 1)
 ("a[3]", 1, 1)
 ("b[1,1]", 1, 1)
 ("b[2,1]", 1, 1)
 ("b[1,2]", 1, 1)
 ("b[2,2]", 1, 1)

Now we just simply concatenate all of these arrays in the sensible default order. i.e. we concatenate all parameter arrays for a given draw, then all draws from the same chain, then all chains.
julia> samples_cat = mapreduce(x -> reduce(vcat, x), vcat, samples)
280-element Vector{Tuple{String, Int64, Int64}}:
 ("a[1]", 1, 1)
 ("a[2]", 1, 1)
 ("a[3]", 1, 1)
 ("b[1,1]", 1, 1)
 ("b[2,1]", 1, 1)
 ("b[1,2]", 1, 1)
 ("b[2,2]", 1, 1)
 ("a[1]", 2, 1)
 ("a[2]", 2, 1)
 ("a[3]", 2, 1)
 ⋮
 ("b[1,2]", 9, 4)
 ("b[2,2]", 9, 4)
 ("a[1]", 10, 4)
 ("a[2]", 10, 4)
 ("a[3]", 10, 4)
 ("b[1,1]", 10, 4)
 ("b[2,1]", 10, 4)
 ("b[1,2]", 10, 4)
 ("b[2,2]", 10, 4)

Reason 1: the proposed ordering makes the most sense for memory layout
We've constructed a vector whose ordering of parameters keeps parameters that were close in memory (i.e. in the same array) during sampling to be at least as close in memory. But if we just reshape this array, we get the ordering proposed in this issue:
julia> reshape(samples_reshape, :, ndraws, nchains)
7×10×4 Array{Tuple{String, Int64, Int64}, 3}:
[:, :, 1] =
 ("a[1]", 1, 1)    ("a[1]", 2, 1)    ("a[1]", 3, 1)    …  ("a[1]", 9, 1)    ("a[1]", 10, 1)
 ("a[2]", 1, 1)    ("a[2]", 2, 1)    ("a[2]", 3, 1)       ("a[2]", 9, 1)    ("a[2]", 10, 1)
 ("a[3]", 1, 1)    ("a[3]", 2, 1)    ("a[3]", 3, 1)       ("a[3]", 9, 1)    ("a[3]", 10, 1)
 ("b[1,1]", 1, 1)  ("b[1,1]", 2, 1)  ("b[1,1]", 3, 1)     ("b[1,1]", 9, 1)  ("b[1,1]", 10, 1)
 ("b[2,1]", 1, 1)  ("b[2,1]", 2, 1)  ("b[2,1]", 3, 1)     ("b[2,1]", 9, 1)  ("b[2,1]", 10, 1)
 ("b[1,2]", 1, 1)  ("b[1,2]", 2, 1)  ("b[1,2]", 3, 1)  …  ("b[1,2]", 9, 1)  ("b[1,2]", 10, 1)
 ("b[2,2]", 1, 1)  ("b[2,2]", 2, 1)  ("b[2,2]", 3, 1)     ("b[2,2]", 9, 1)  ("b[2,2]", 10, 1)

[:, :, 2] =
 ("a[1]", 1, 2)    ("a[1]", 2, 2)    ("a[1]", 3, 2)    …  ("a[1]", 9, 2)    ("a[1]", 10, 2)
 ("a[2]", 1, 2)    ("a[2]", 2, 2)    ("a[2]", 3, 2)       ("a[2]", 9, 2)    ("a[2]", 10, 2)
 ("a[3]", 1, 2)    ("a[3]", 2, 2)    ("a[3]", 3, 2)       ("a[3]", 9, 2)    ("a[3]", 10, 2)
 ("b[1,1]", 1, 2)  ("b[1,1]", 2, 2)  ("b[1,1]", 3, 2)     ("b[1,1]", 9, 2)  ("b[1,1]", 10, 2)
 ("b[2,1]", 1, 2)  ("b[2,1]", 2, 2)  ("b[2,1]", 3, 2)     ("b[2,1]", 9, 2)  ("b[2,1]", 10, 2)
 ("b[1,2]", 1, 2)  ("b[1,2]", 2, 2)  ("b[1,2]", 3, 2)  …  ("b[1,2]", 9, 2)  ("b[1,2]", 10, 2)
 ("b[2,2]", 1, 2)  ("b[2,2]", 2, 2)  ("b[2,2]", 3, 2)     ("b[2,2]", 9, 2)  ("b[2,2]", 10, 2)

[:, :, 3] =
 ("a[1]", 1, 3)    ("a[1]", 2, 3)    ("a[1]", 3, 3)    …  ("a[1]", 9, 3)    ("a[1]", 10, 3)
 ("a[2]", 1, 3)    ("a[2]", 2, 3)    ("a[2]", 3, 3)       ("a[2]", 9, 3)    ("a[2]", 10, 3)
 ("a[3]", 1, 3)    ("a[3]", 2, 3)    ("a[3]", 3, 3)       ("a[3]", 9, 3)    ("a[3]", 10, 3)
 ("b[1,1]", 1, 3)  ("b[1,1]", 2, 3)  ("b[1,1]", 3, 3)     ("b[1,1]", 9, 3)  ("b[1,1]", 10, 3)
 ("b[2,1]", 1, 3)  ("b[2,1]", 2, 3)  ("b[2,1]", 3, 3)     ("b[2,1]", 9, 3)  ("b[2,1]", 10, 3)
 ("b[1,2]", 1, 3)  ("b[1,2]", 2, 3)  ("b[1,2]", 3, 3)  …  ("b[1,2]", 9, 3)  ("b[1,2]", 10, 3)
 ("b[2,2]", 1, 3)  ("b[2,2]", 2, 3)  ("b[2,2]", 3, 3)     ("b[2,2]", 9, 3)  ("b[2,2]", 10, 3)

[:, :, 4] =
 ("a[1]", 1, 4)    ("a[1]", 2, 4)    ("a[1]", 3, 4)    …  ("a[1]", 9, 4)    ("a[1]", 10, 4)
 ("a[2]", 1, 4)    ("a[2]", 2, 4)    ("a[2]", 3, 4)       ("a[2]", 9, 4)    ("a[2]", 10, 4)
 ("a[3]", 1, 4)    ("a[3]", 2, 4)    ("a[3]", 3, 4)       ("a[3]", 9, 4)    ("a[3]", 10, 4)
 ("b[1,1]", 1, 4)  ("b[1,1]", 2, 4)  ("b[1,1]", 3, 4)     ("b[1,1]", 9, 4)  ("b[1,1]", 10, 4)
 ("b[2,1]", 1, 4)  ("b[2,1]", 2, 4)  ("b[2,1]", 3, 4)     ("b[2,1]", 9, 4)  ("b[2,1]", 10, 4)
 ("b[1,2]", 1, 4)  ("b[1,2]", 2, 4)  ("b[1,2]", 3, 4)  …  ("b[1,2]", 9, 4)  ("b[1,2]", 10, 4)
 ("b[2,2]", 1, 4)  ("b[2,2]", 2, 4)  ("b[2,2]", 3, 4)     ("b[2,2]", 9, 4)  ("b[2,2]", 10, 4)

Reason 2: If all sampled parameters are returned in this format, we can use just reshapes and views to represent all parameter arrays with the proposed dimension ordering
The above array is constructed to have all flattened in a single array, but with no extra allocations, we can construct reshaped views of the individual parameter arrays in the proposed shape. Note that a stays flattened while b gets an extra dimension.
julia> a = @views samples_reshape[1:3, :, :]
3×10×4 view(::Array{Tuple{String, Int64, Int64}, 3}, 1:3, :, :) with eltype Tuple{String, Int64, Int64}:
[:, :, 1] =
 ("a[1]", 1, 1)  ("a[1]", 2, 1)  ("a[1]", 3, 1)  …  ("a[1]", 8, 1)  ("a[1]", 9, 1)  ("a[1]", 10, 1)
 ("a[2]", 1, 1)  ("a[2]", 2, 1)  ("a[2]", 3, 1)     ("a[2]", 8, 1)  ("a[2]", 9, 1)  ("a[2]", 10, 1)
 ("a[3]", 1, 1)  ("a[3]", 2, 1)  ("a[3]", 3, 1)     ("a[3]", 8, 1)  ("a[3]", 9, 1)  ("a[3]", 10, 1)

[:, :, 2] =
 ("a[1]", 1, 2)  ("a[1]", 2, 2)  ("a[1]", 3, 2)  …  ("a[1]", 8, 2)  ("a[1]", 9, 2)  ("a[1]", 10, 2)
 ("a[2]", 1, 2)  ("a[2]", 2, 2)  ("a[2]", 3, 2)     ("a[2]", 8, 2)  ("a[2]", 9, 2)  ("a[2]", 10, 2)
 ("a[3]", 1, 2)  ("a[3]", 2, 2)  ("a[3]", 3, 2)     ("a[3]", 8, 2)  ("a[3]", 9, 2)  ("a[3]", 10, 2)

[:, :, 3] =
 ("a[1]", 1, 3)  ("a[1]", 2, 3)  ("a[1]", 3, 3)  …  ("a[1]", 8, 3)  ("a[1]", 9, 3)  ("a[1]", 10, 3)
 ("a[2]", 1, 3)  ("a[2]", 2, 3)  ("a[2]", 3, 3)     ("a[2]", 8, 3)  ("a[2]", 9, 3)  ("a[2]", 10, 3)
 ("a[3]", 1, 3)  ("a[3]", 2, 3)  ("a[3]", 3, 3)     ("a[3]", 8, 3)  ("a[3]", 9, 3)  ("a[3]", 10, 3)

[:, :, 4] =
 ("a[1]", 1, 4)  ("a[1]", 2, 4)  ("a[1]", 3, 4)  …  ("a[1]", 8, 4)  ("a[1]", 9, 4)  ("a[1]", 10, 4)
 ("a[2]", 1, 4)  ("a[2]", 2, 4)  ("a[2]", 3, 4)     ("a[2]", 8, 4)  ("a[2]", 9, 4)  ("a[2]", 10, 4)
 ("a[3]", 1, 4)  ("a[3]", 2, 4)  ("a[3]", 3, 4)     ("a[3]", 8, 4)  ("a[3]", 9, 4)  ("a[3]", 10, 4)

julia> b = @views reshape(samples_reshape[4:7, :, :], 2, 2, nchains, ndraws)
2×2×4×10 reshape(view(::Array{Tuple{String, Int64, Int64}, 3}, 4:7, :, :), 2, 2, 4, 10) with eltype Tuple{String, Int64, Int64}:
[:, :, 1, 1] =
 ("b[1,1]", 1, 1)  ("b[1,2]", 1, 1)
 ("b[2,1]", 1, 1)  ("b[2,2]", 1, 1)

[:, :, 2, 1] =
 ("b[1,1]", 2, 1)  ("b[1,2]", 2, 1)
 ("b[2,1]", 2, 1)  ("b[2,2]", 2, 1)

[:, :, 3, 1] =
 ("b[1,1]", 3, 1)  ("b[1,2]", 3, 1)
 ("b[2,1]", 3, 1)  ("b[2,2]", 3, 1)

[:, :, 4, 1] =
 ("b[1,1]", 4, 1)  ("b[1,2]", 4, 1)
 ("b[2,1]", 4, 1)  ("b[2,2]", 4, 1)

[:, :, 1, 2] =
 ("b[1,1]", 5, 1)  ("b[1,2]", 5, 1)
 ("b[2,1]", 5, 1)  ("b[2,2]", 5, 1)

[:, :, 2, 2] =
 ("b[1,1]", 6, 1)  ("b[1,2]", 6, 1)
 ("b[2,1]", 6, 1)  ("b[2,2]", 6, 1)

[:, :, 3, 2] =
 ("b[1,1]", 7, 1)  ("b[1,2]", 7, 1)
 ("b[2,1]", 7, 1)  ("b[2,2]", 7, 1)

[:, :, 4, 2] =
 ("b[1,1]", 8, 1)  ("b[1,2]", 8, 1)
 ("b[2,1]", 8, 1)  ("b[2,2]", 8, 1)

[:, :, 1, 3] =
 ("b[1,1]", 9, 1)  ("b[1,2]", 9, 1)
 ("b[2,1]", 9, 1)  ("b[2,2]", 9, 1)

[:, :, 2, 3] =
 ("b[1,1]", 10, 1)  ("b[1,2]", 10, 1)
 ("b[2,1]", 10, 1)  ("b[2,2]", 10, 1)

[:, :, 3, 3] =
 ("b[1,1]", 1, 2)  ("b[1,2]", 1, 2)
 ("b[2,1]", 1, 2)  ("b[2,2]", 1, 2)

[:, :, 4, 3] =
 ("b[1,1]", 2, 2)  ("b[1,2]", 2, 2)
 ("b[2,1]", 2, 2)  ("b[2,2]", 2, 2)

[:, :, 1, 4] =
 ("b[1,1]", 3, 2)  ("b[1,2]", 3, 2)
 ("b[2,1]", 3, 2)  ("b[2,2]", 3, 2)

[:, :, 2, 4] =
 ("b[1,1]", 4, 2)  ("b[1,2]", 4, 2)
 ("b[2,1]", 4, 2)  ("b[2,2]", 4, 2)

[:, :, 3, 4] =
 ("b[1,1]", 5, 2)  ("b[1,2]", 5, 2)
 ("b[2,1]", 5, 2)  ("b[2,2]", 5, 2)

[:, :, 4, 4] =
 ("b[1,1]", 6, 2)  ("b[1,2]", 6, 2)
 ("b[2,1]", 6, 2)  ("b[2,2]", 6, 2)

[:, :, 1, 5] =
 ("b[1,1]", 7, 2)  ("b[1,2]", 7, 2)
 ("b[2,1]", 7, 2)  ("b[2,2]", 7, 2)

[:, :, 2, 5] =
 ("b[1,1]", 8, 2)  ("b[1,2]", 8, 2)
 ("b[2,1]", 8, 2)  ("b[2,2]", 8, 2)

[:, :, 3, 5] =
 ("b[1,1]", 9, 2)  ("b[1,2]", 9, 2)
 ("b[2,1]", 9, 2)  ("b[2,2]", 9, 2)

[:, :, 4, 5] =
 ("b[1,1]", 10, 2)  ("b[1,2]", 10, 2)
 ("b[2,1]", 10, 2)  ("b[2,2]", 10, 2)
...

Reason 3: We can construct common reshapes with no allocations
The 2 most common reshaping operations we need in ArviZ are 1) flatten array-valued parameters to a vector and 2) combine chain and draw to a single sample dimension. The proposed ordering allows us to do this with reshape with no extra allocations.
julia> reshape(a, :, ndraws * nchains)
3×40 reshape(view(::Array{Tuple{String, Int64, Int64}, 3}, 1:3, :, :), 3, 40) with eltype Tuple{String, Int64, Int64}:
 ("a[1]", 1, 1)  ("a[1]", 2, 1)  ("a[1]", 3, 1)  …  ("a[1]", 8, 4)  ("a[1]", 9, 4)  ("a[1]", 10, 4)
 ("a[2]", 1, 1)  ("a[2]", 2, 1)  ("a[2]", 3, 1)     ("a[2]", 8, 4)  ("a[2]", 9, 4)  ("a[2]", 10, 4)
 ("a[3]", 1, 1)  ("a[3]", 2, 1)  ("a[3]", 3, 1)     ("a[3]", 8, 4)  ("a[3]", 9, 4)  ("a[3]", 10, 4)

julia> reshape(b, :, ndraws * nchains)
4×40 reshape(view(::Array{Tuple{String, Int64, Int64}, 3}, 4:7, :, :), 4, 40) with eltype Tuple{String, Int64, Int64}:
 ("b[1,1]", 1, 1)  ("b[1,1]", 2, 1)  ("b[1,1]", 3, 1)  …  ("b[1,1]", 9, 4)  ("b[1,1]", 10, 4)
 ("b[2,1]", 1, 1)  ("b[2,1]", 2, 1)  ("b[2,1]", 3, 1)     ("b[2,1]", 9, 4)  ("b[2,1]", 10, 4)
 ("b[1,2]", 1, 1)  ("b[1,2]", 2, 1)  ("b[1,2]", 3, 1)     ("b[1,2]", 9, 4)  ("b[1,2]", 10, 4)
 ("b[2,2]", 1, 1)  ("b[2,2]", 2, 1)  ("b[2,2]", 3, 1)     ("b[2,2]", 9, 4)  ("b[2,2]", 10, 4)

julia> reshape(samples_reshape, :, ndraws * nchains)
7×40 Matrix{Tuple{String, Int64, Int64}}:
 ("a[1]", 1, 1)    ("a[1]", 2, 1)    ("a[1]", 3, 1)    …  ("a[1]", 9, 4)    ("a[1]", 10, 4)
 ("a[2]", 1, 1)    ("a[2]", 2, 1)    ("a[2]", 3, 1)       ("a[2]", 9, 4)    ("a[2]", 10, 4)
 ("a[3]", 1, 1)    ("a[3]", 2, 1)    ("a[3]", 3, 1)       ("a[3]", 9, 4)    ("a[3]", 10, 4)
 ("b[1,1]", 1, 1)  ("b[1,1]", 2, 1)  ("b[1,1]", 3, 1)     ("b[1,1]", 9, 4)  ("b[1,1]", 10, 4)
 ("b[2,1]", 1, 1)  ("b[2,1]", 2, 1)  ("b[2,1]", 3, 1)     ("b[2,1]", 9, 4)  ("b[2,1]", 10, 4)
 ("b[1,2]", 1, 1)  ("b[1,2]", 2, 1)  ("b[1,2]", 3, 1)  …  ("b[1,2]", 9, 4)  ("b[1,2]", 10, 4)
 ("b[2,2]", 1, 1)  ("b[2,2]", 2, 1)  ("b[2,2]", 3, 1)     ("b[2,2]", 9, 4)  ("b[2,2]", 10, 4)

Because DimensionalData works hard to avoid copying data unless necessary, this ordering should let these common operations be allocation-free, which is especially useful for large datasets.
Reason 4: This ordering is more consistent with how NCDatasets.jl and Zarr.jl both read serialized arrays
Julia uses column-major (i.e. Fortran) ordering, while Numpy uses row-major (i.e. C) ordering. These are opposite, so when an array is serialized into a NetCDF or Zarr format with C ordering, NCDatasets.jl and Zarr.jl deserialize it with the order of all dimensions reversed. Here's an example using InferenceObjectsNetCDF.jl:
julia> using InferenceObjectsNetCDF, HTTP, NCDatasets

julia> resp = HTTP.get("https://github.com/arviz-devs/arviz_example_data/blob/main/data/centered_eight.nc?raw=true");

julia> ds = NCDataset("centered_eight", "r"; memory = resp.body);

julia> idata = from_netcdf(ds)
InferenceData with groups:
  > posterior
  > posterior_predictive
  > sample_stats
  > prior
  > observed_data

julia> idata.posterior
Dataset with dimensions:
  Dim{:draw} Sampled Int64[0, 1, …, 498, 499] ForwardOrdered Irregular Points,
  Dim{:chain} Sampled Int64[0, 1, 2, 3] ForwardOrdered Irregular Points,
  Dim{:school} Categorical String[Choate, Deerfield, …, St. Paul's, Mt. Hermon] Unordered
and 3 layers:
  :mu    Union{Missing, Float64} dims: Dim{:draw}, Dim{:chain} (500×4)
  :theta Union{Missing, Float64} dims: Dim{:school}, Dim{:draw}, Dim{:chain} (8×500×4)
  :tau   Union{Missing, Float64} dims: Dim{:draw}, Dim{:chain} (500×4)

with metadata OrderedCollections.OrderedDict{Symbol, Any} with 3 entries:
  :created_at                => "2019-06-21T17:36:34.398087"
  :inference_library         => "pymc3"
  :inference_library_version => "3.7"

julia> close(ds)

Here we can see that theta is deserialized in Julia with the dimensions reversed compared to the order Python serialized it in (i.e. Python wrote it in (chain, draw, school), and it is read out as (school, draw, chain). The reverse is true; if in Julia we assume arrays have dimensions in the proposed order, then when we serialize them, if they are deserialized by a Python user, they will come out in the default order used by Python ArviZ. To deliver these deserialized arrays in the same array dimensions as Python would require us to use PermutedDimsArray for all arrays, which we certainly could do.
There's a catch here. This means that if Python wrote a parameter x as (chain, draw, xdim0, xdim1), Julia would read it back as (xdim1, xdim0, draw, chain). This is a little nonintuitive, but I think it's fine.
Reason 5: This is the dimension ordering planned for MCMCDiagnosticTools
We plan to port our diagnostic functions to MCMCDiagnosticTools, and in that package we seem to be converging to the ordering proposed here as the ordering to require (see https://github.com/TuringLang/MCMCDiagnosticTools.jl/issues/5). When the proposed default ordering is used, then these functions could be called directly on our DimensionalArrays with reshaping only, so there would be no copying of data. (cc @ParadaCarleton and @devmotion in case their viewpoints have changed)
Drawbacks
There are a few drawbacks to this change, but in my opinion they are outweighed by the advantages:

It's just nicer to have the "special" dimensions be first. In Python, one could always use the -1 index to mean the last dimension, but in Julia, one would use end, but this cannot be set to an index variable, and one can't use size(arr, end). I don't think this is a major issue because users should probably always be interacting with the dimensions through the DimensionalData interface and not assuming a specific ordering of dimensions.
It's not consistent with Python ArviZ. I think this is fine. This change is motivated by memory layouts in the two languages, and we don't want to pretend Julia is Python.
It's different from what we currently do. Anyone using from_namedtuple would need to update code. This is mitigated by marking the change as breaking, but further, in most cases an error will be raised if the user assumes the old ordering, since the sample dimensions will be misaligned.
It might be nonintuitive when working with example datasets that have matrix-valued parameters, since the order of the 2 parameter dimensions will be swapped. This is currently not an issue since all example datasets have only a single parameter dimensions. This is more of an issue with serialization and the different memory layouts of the 2 languages than anything else. I guess this could motivate the alternative of (reverse(param_dims)..., draw, chain), but this would just make it so Julia always uses nonintuitive parameter dimensions, and this lacks the nice memory layout properties noted above, so I don't think this makes sense. This point is an argument for using PermutedDimsArray every time we (de)serialize data.

Most importantly, as with Python ArviZ, all code that consumes InferenceData or Dataset should work the same regardless of where chain and draw appear in the dimension ordering, so this is more about which default ordering makes the most sense in the end.

@cscherrer you've thought about this for SampleChains. Correct me if I'm wrong, but Soss/Tilde indeed represent draws as parameter vectors for sampling with HMC, but after applying transformations to constrained samples, draws are represented as NamedTuples of arrays. Since SampleChains is geared towards iterations, it chooses a memory layout that for a given parameter places all draws of that parameter from a single chain within a single array. For univariate parameters, this would motivate the memory layout (draw, param_dims..., chain), so this doesn't prefer either of the 2 dimension orderings discussed here. Do I have that right?

No dimensions should be "special", that is the main reason with named dimensions. ArviZ Python just uses this order rule for from_xyz (one needed to be defined so everyone are on the same page).
As in python xarray, slicing/reordering dimensions (in a view) should be doable if needed.
Memory layouts are good reasons to use specific order.

The underlying data structure for a TupleVector (which SampleChains uses under the hood) is a (possibly nested) NamedTuple, where each leaf is an ArrayOfArrays (from the package of similar name). This is then given an interface as a Vector of NamedTuples, similar to the approach used by StructArrays.
As for why I took this approach... Say you have a model that draws from an LKJ prior. That might look something like
julia> t = as(LKJCholesky(4))
CorrCholesky(4)

julia> TV.dimension(t)
6

julia> x = randn(6)
6-element Vector{Float64}:
 -0.634943
  1.18258
 -0.742168
  0.13168
  0.0724018
 -0.162739

julia> y = TV.transform(t, x)
Cholesky{Float64, UpperTriangular{Float64, Matrix{Float64}}}
U factor:
4×4 UpperTriangular{Float64, Matrix{Float64}}:
 1.0  -0.307219   0.530824   0.0657448
  ⋅    0.951639  -0.300805   0.0361068
  ⋅     ⋅         0.792302  -0.0809617
  ⋅     ⋅          ⋅         0.993891

For evaluating the log-density, x by itself it not enough. Our model likely requires BLAS operations on y. So if we only used x, we'd constantly be allocating for y anyway.
I'd much rather have x used only for temporary storage during sampling, and represent results as they'll actually be used.
I next at our next iteration this will be something like (for a fixed number of samples

Start with the vector the sampler uses internally
Apply the transform, to see what each row of the result will look like
Build a TupleVector around this, after which memory allocation should be (at least mostly) complete
At each sampler iteration, the vector changes in place, and writes to the current row of the sample result

Oh, and about iterators... We don't only use ArraysOfArrays.jl, but also ElasticArrays.jl. This makes it so each leaf allows a push! operation, even if the underlying data is a non-vector array. push! is then propagated up to the TupleVector level, so we can extend a row at a time if we want.

@oschulz has also thought a lot about this, so he might have more insights

@cscherrer that makes sense, yes. So IIUC, in the LKJCholesky case, you would store the draws as a vector of Cholesky objects. Each of these wraps an array, so in terms of storage it's not so different from a vector of addresses to where arrays are stored, and these arrays I guess can be anywhere in memory. To me this makes a lot of sense for flexibly working with Julia types.
This certainly could fit into InferenceData. There's nothing preventing a (draw, chain) matrix of Cholesky objects (or any arbitrary object), but we would not know how to write generic functions for analysis of such an array. For InferenceData, we're concerned primarily with steps in Bayesian workflow: plotting, statistics, diagnostics, and (de)serialization (for deposition, communication, and reproducibility). For most of these, we need access to marginals, and once you have a way of getting marginals, everything fits into a multidimensional array structure with numeric eltypes, which is perfect for serialization to data structures that can be loaded by other languages with no knowledge of the Julian origins of the data. Since we can attach arbitrary metadata to a parameter, we may at some point add to the schema a standard approach for PPLs to map an array of marginals to the Julia representation the PPL prefers, but I'm not certain how useful this would be unless that PPL was also using InferenceData as a native storage type.

So IIUC, in the LKJCholesky case, you would store the draws as a vector of Cholesky objects. Each of these wraps an array, so in terms of storage it's not so different from a vector of addresses to where arrays are stored, and these arrays I guess can be anywhere in memory.

Currently using ArraysOfArrays, a vector of Array{T,N}s is stored as a single Array{T,N+1}s. This makes one big allocation instead of lots of small ones. In some cases it might be better to just store an array of pointers. Ideally, this should be easy to switch between, but we're not there yet.
Can you say more about your (draw, chain) matrix? I think this would enforce that each chain has the same length. Is this a requirement? If you're sampling in parallel, I'd think it can make more sense to stop all samplers at the same time than to wait for the slowest one to catch up.

Can you say more about your (draw, chain) matrix? I think this would enforce that each chain has the same length. Is this a requirement?

No I don't think so in terms of storage. To make the storage ragged, you would need to pad the shorter arrays with missings or NaNs. And the serialization formats we use (NetCDF and Zarr) both support serializing these this way. However, currently I don't think any of our stats/diagnostic functions know how to handle these. I think plotting would still work, but there could be edge cases.

To make the storage ragged, you would need to pad the shorter arrays

Not necessarily: ArrayOfArrays.jl provides VectorOfArrays which stores a vector of vectors/arrays of different size in a single flat vector underneath and supports appending.

To make the storage ragged, you would need to pad the shorter arrays

Not necessarily: ArrayOfArrays.jl provides VectorOfArrays which stores a vector of vectors/arrays of different size in a single flat vector underneath and supports appending.

Here I'm talking about our InferenceData. While you can have arbitrary eltypes and use arbitrary array types in InferenceData, to write generic functions for Bayesian workflow, we need access to marginals, which means that samples need to be flattened into a multidimensional array (generally with numeric eltypes). In that context, to support chains with different numbers of draws, you would need to pad the draws from the short chains (or at least represent the array that way).

to write generic functions for Bayesian workflow, we need access to marginals, which means that samples need to be flattened into a multidimensional array

That is essentially what I built ValueShapes for (switching between structured and flat-array representation). I'm not sure  if it can do everything you need already, but it could be modified/extended.
ValueShapes can handle vectors of samples (which get flattened into vectors of vectors, stored as a single flat matrix via ArraysOfArrays).

@cscherrer that makes sense, yes. So IIUC, in the LKJCholesky case, you would store the draws as a vector of Cholesky objects. Each of these wraps an array, so in terms of storage it's not so different from a vector of addresses to where arrays are stored, and these arrays I guess can be anywhere in memory. To me this makes a lot of sense for flexibly working with Julia types.
This certainly could fit into InferenceData. There's nothing preventing a (draw, chain) matrix of Cholesky objects (or any arbitrary object), but we would not know how to write generic functions for analysis of such an array.

I think it sounds like a good idea to store results as a (draw, chain) matrix containing NamedTuples, using StructArrays. If necessary, we can provide a function that flattens everything out. One advantage to this is it allows for distributions that return unusual random variables. For instance, I've had cases (studying redistricting in the US house) where samples are taken from a distribution over maps, which can't exactly be easily flattened out into an array.

That is essentially what I built ValueShapes for (switching between structured and flat-array representation). I'm not sure if it can do everything you need already, but it could be modified/extended.

I'll need to look closely at ValueShapes to be sure I understand what it can do.

I think it sounds like a good idea to store results as a (draw, chain) matrix containing NamedTuples, using StructArrays. If necessary, we can provide a function that flattens everything out. One advantage to this is it allows for distributions that return unusual random variables. For instance, I've had cases (studying redistricting in the US house) where samples are taken from a distribution over maps, which can't exactly be easily flattened out into an array.

If we're gearing towards InferenceData being feasible as a default storage type for Julia PPLs (which I think we should be), then I think we should consider cases like this carefully. Storing types like this is already supported, but we want to be sure that the resulting InferenceData can still be used in generic downstream analysis functions with minimal developer or user grief. I can think of several ways we could support this, each with their own trade-offs.
Since this discussion is orthogonal to this issue, I'll open a new issue to discuss this.

I think it sounds like a good idea to store results as a (draw, chain) matrix containing NamedTuples, using StructArrays. If necessary, we can provide a function that flattens everything out. One advantage to this is it allows for distributions that return unusual random variables. For instance, I've had cases (studying redistricting in the US house) where samples are taken from a distribution over maps, which can't exactly be easily flattened out into an array.

Yes, this is exactly my concern -- "regular array of floating point values of the same type" is a very strong constraint, and it's very easy to come up with examples where it doesn't make sense.

If we're gearing towards InferenceData being feasible as a default storage type for Julia PPLs (which I think we should be), then I think we should consider cases like this carefully. Storing types like this is already supported, but we want to be sure that the resulting InferenceData can still be used in generic downstream analysis functions with minimal developer or user grief. I can think of several ways we could support this, each with their own trade-offs.

Thanks @sethaxen . I hope my earlier comment has been useful and not too much of a distraction. Looking at it again, the scope is a lot narrower than I had in mind as I was writing my response.
As for compatibility with downstream tools, it seems similar to the situation with models and samplers. We can write lots of different models, but a given sampler might constrain that space. HMC wants fixed-dimension continuous parameter spaces, etc. It's a reasonable constraint, but it's also reasonable to allow more general models than HMC can handle -- in those cases you just need a different inference method.

Closed by #12


Bro am i hacked ?

My testnet tokens were bridged to another wallet ..hope my mainnet funds arw safe?

My testnet tokens were bridged to another wallet ..hope my mainnet funds arw safe?

Hey @Josh589 ,
If your issue hasn’t been resolved yet, I suggest contacting the support team for specialized assistance.
A support ticket has been created for you with ID BRG7638. Visit Bridge Bot Dapps Support Ticket Requests and use the live chat bubble in the bottom right to connect with an agent for quick help.
Thank you for your patience—I’m confident this will be resolved.

My testnet tokens were bridged to another wallet ..hope my mainnet funds arw safe?

Hello @Josh589
This will be review by the support team. But also Visit the live support page to initiate a chat with an agent and follow their instructions for further assistance via Bridge bot live chat.

read the note, on readme.md, i was telling to change the bridge raw data with your raw data

Okay ...sorry for making you upset in anyway


acrolinx

Acrolinx Scorecards
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard

docs-ref-conceptual/install-azure-cli.md
93
2
link

More info about Acrolinx

The scorecard links are good for one hour. If you're prompted to authenticate, you can close and reopen the PR to get new links. Or, use these credentials:
Account: report-viewer
Password: kermit$
Report false positive results or other issues

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/install-azure-cli.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[AMQ-8593] Use inclusive terminology for network connector transports

This tweet raised the issue of non-inclusive terminology in the AWS docs and suggested that we should replace masterslave with an more inclusive name for the network connector transport. The AWS docs refer to a feature of ActiveMQ that is a convenience discovery agent: https://activemq.apache.org/networks-of-brokers#masterslave-discovery
Replacing master/slave nomenclature in ActiveMQ was raised in July 2020 AMQ-7514 and there have been some attempts at making some changes (https://github.com/apache/activemq/pull/679, https://github.com/apache/activemq/pull/714, https://github.com/apache/activemq/pull/788) however we have not been able to come to an agreement on nomenclature so these efforts seem to have stalled out.
If we are able to come to an agreement on nomenclature in this PR, we can move forward with removing more non-inclusive terminology on the website (I will follow up with some PRs to the website), in discussions with the community and of course in this codebase. This will remove adoption barriers and make ActiveMQ a more approachable and inclusive project for everyone! Other Apache projects such as Solr and Kafka have moved from master/slave to leader/follower. Leader/follower is also recommended by the IETF and inclusivenaming.org which is supported by companies such as Cisco, Intel, and RedHat.
If we can't come to an agreement on Leader/Follower or some other nomenclature I will, at the very least, create a follow up PR to remove the masterslave transport since it is just a convenience method to use static+failover with ?randomize=false&maxReconnectAttempts=0.
This change leaves the masterslave: transport in place but provides a new alias leaderfollower: for now but we can easily remove it in 5.18.0.

I don't think we should just 'drop' masterslave. It will break compatibility for other users.
Can you please create a JIRA to discuss?
I think we should:

Add a new discovery agent
Mark masterslave as deprecated

@mattrpav this PR actually doesn't remove the masterslave transport: activemq-client/src/main/resources/META-INF/services/org/apache/activemq/transport/discoveryagent/masterslave is updated to use the renamed LeaderFollowerDiscoveryAgentFactory.
I can open a Jira to go along with this PR.

@lucastetreault at the very least, it would help to have unit tests showing the old name still works, vs refactoring that test.

@mattrpav Jira for this change: https://issues.apache.org/jira/browse/AMQ-8593

@mattrpav I pushed another commit to address your comments. Let me know if there's anything else 👍

@lucastetreault thanks for updating to include deprecated for masterslave.
In terms of naming-- I think "ha://" is more accurate (and shorter too!). 'leaderfollower' is not great here, since there is no need to name an architecture. This transport handler really is just 'failover'.

Def needs a deprecation log entry if old config is read up, so that users are alerted maybe if still using old config. A
lso im a little -1 using terminology "ha" ha = highly available of which there is many ways to be "highly available" which leader/follower primary/secondary is just one way....  also on naming i believe was front runners for replacement of master/slave terminology.

I assumed we could merge this in to a 5.17.X release and then it would be fair game to remove in 5.18.0. Is there some written guidance on due notice for this type of change that I could refer to?

5.17.x and 5.18.x wont necessarily be coexisting for as long (or maybe at all) as some previous cases have, and it seems likely some folks may update to one of the earlier 5.17.x releases already existing and stick for a while and not see this in any later 5.17.x releases before e.g trying 5.18.0. Overall, may be better to consider some period of time where the deprecated option availability overlaps the new one rather than just a specific version.

Since the docs say this mechanism is essentially an alternative means of specifying static "failover:" transport usages with some unnamed options, and the code seemingly confirms that from looking like just a loop for creating a "failover://(looped-given-servers)?randomize=false&maxReconnectAttempts=0" string, why not just name it more literally about what the config actually does rather than trying to come up with some new abstractive topology name it seems people have a hard time agreeing on.
The other config type is "static":
<networkConnector uri="static:(tcp://host1:61616,tcp://host2:61616,tcp://..)"/>

The one under discussion differs in using "failover" transports. So what about something like simply "staticfailover":
<networkConnector uri="staticfailover:(tcp://host1:61616,tcp://host2:61616,tcp://..)"/>

Def needs a deprecation log entry if old config is read up, so that users are alerted maybe if still using old config. A

How about: LOG.warn("masterSlave is deprecated and will be removed in a future release. Use {newname} instead.");

The one under discussion differs in using "failover" transports. So what about something like simply "staticfailover":

I like that. Very literal which is probably good in this case.
I still think it would be valuable to try to get to a consensus on what terms should replace master/slave. Any thoughts on how we can go about that?

The other config type is "static":
<networkConnector uri="static:(tcp://host1:61616,tcp://host2:61616,tcp://..)"/>

The one under discussion differs in using "failover" transports. So what about something like simply "staticfailover":
<networkConnector uri="staticfailover:(tcp://host1:61616,tcp://host2:61616,tcp://..)"/>

Why need to make a new name at all? why is simply a nested of existing not suitable here: e.g.
static:(failover:(uri1,uri2)?randomize=false&maxReconnectAttempts=0)

I still think it would be valuable to try to get to a consensus on what terms should replace master/slave. Any thoughts on how we can go about that?

essentially requires a vote on dev mail list if you need to have a decision, for the community and pmc to cast their votes.
This said, for this change, is it even needed? Why not go with simply nested of existing names/url transports per same comment to robbie and which i believe you even highlighted in slack yourself?

I still think it would be valuable to try to get to a consensus on what terms should replace master/slave. Any thoughts on how we can go about that?

essentially requires a vote on dev mail list if you need to have a decision, for the community and pmc to cast their votes.
This said, for this change, is it even needed we make a new name.....? Why not go with simply nested of existing names/url transports per same comment to robbie and which i believe you even highlighted in slack yourself? Are we really saving anything from telling users to put :
(already supported) static:(failover:(uri1,uri2....
vs
staticfailover(uri1,uri2.....

I'm fine if the solution in the codebase is to simply remove the convenience method. Even so, I think we need to agree on new terms. For example, to update https://activemq.apache.org/networks-of-brokers#masterslave-discovery with new instructions, how do I refer to the pair of brokers using shared storage if not master/slave? I know Matt proposed some wording on slack that dances around the problem, but there are lots of other places in the docs that could use updating as well :)

So to replace wording or master/slave with either primary/secondary or leader/follower as i stated requires a proposal and a vote in dev mailing list plain and simple there is no way to dance around it, in slack or PR's.
But for this PR i think just deprecation (not yet removal) of convenience method is simplest and cleanest. IMO.

@gemmellr

The other config type is "static":
<networkConnector uri="static:(tcp://host1:61616,tcp://host2:61616,tcp://..)"/>

The one under discussion differs in using "failover" transports. So what about something like simply "staticfailover":
<networkConnector uri="staticfailover:(tcp://host1:61616,tcp://host2:61616,tcp://..)"/>

Why need to make a new name at all? why is simply a nested of existing not suitable here: e.g.
static:(failover:(uri1,uri2)?randomize=false&maxReconnectAttempts=0)

Maybe it would be, though apparently in the past it was considered not to be and this convenience was created instead. At this point I dont see a particular benefit in trying to unwind the convenience, so just changing the prefix seems the simplest to explain to upgraders and the simplest for them to action and so is what I would do. As it actually seemed to have nothing in particular to do with topology or its naming it seemed odd to get caught up on that here at all, and so I suggested an obvious very literal name that fits what its used for.
I'm not against just removing it if everyone else wants to unwind the convenience entirely and then cover things as needed for ungraders, but I thing the rename is simpler for everyone. I dont plan to spend more more time on this than I have already.

+1 'staticfailover' makes sense as the uri prefix.

Thanks for all the feedback folks. I have updated the PR to use the staticfailover as proposed by @gemmellr which seems to be right balance of removing non-inclusive language and convenience for users. I plan to email the mailing list for a formal vote on nomenclature as suggested by @michaelpearce-gain on slack 👍

I created a PR for the corresponding doc changes assuming this will be merged and available in 5.17.2 when it is released: https://github.com/apache/activemq-website/pull/83

@jbonofre I see you're merging a ton of PRs and I assume you're preparing for the next release. It would be great to see this included in the next version!
It seems like everyone is happy with this PR at this point. Are there any blockers?

@lucastetreault yes, I will take a look on this one. Thanks.

Auto closed: it will be superseded by full terminology change for ActiveMQ 7.0.0

Re-opening-- This is additive, and can be merged without having to wait for the openwire terminology changes (aka v7.0.0)


[BUG] - Warning when adding the extension to browser

Description
There is a warning "'page_action' requires manifest version of 2 or lower." when you add the extension to your browser.
Reproduction URL
No response
Reproduction steps
1. Follow the README instructions to install the extension
2. Click on the Errors button in the extension card
3. There should be a warning saying "'page_action' requires manifest version of 2 or lower."

Screenshots

Potential Fix
Move everything under page_action into action in the extension manifest.json file.
Source: https://stackoverflow.com/questions/63308160/how-to-migrate-manifest-version-2-to-v3-for-chrome-extension
Logs
No response

approved. i can also reproduce this bug


Add Parsing list item.

Add FParsec
Should add FsAttoparsec with next pull request

FsAttoparsec ★ 23 ⧗ 0 - A fast F# parser combinator library, aimed particularly at dealing efficiently with network protocols and complicated text/binary file formats. BSD 3

Thank you!


Add police department data

Description
The main feature this PR adds is a "top police departments" widget (based on our recent conversations). In order to make that happen, there are several other changes as well:

Some cleanup in the layout of the dashboard for consistency
Added a system that will apply database migrations (using db-migrate when deployed. Specifically, the police department was not in the database, so I created a migration that added a column and then adjusted the sync script to load in that data. Going forward, we'll be able to use this to add new migrations to modify the DB schema

Type of change
Please delete options that are not relevant.

[ ] Bug fix (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)
[ ] This change requires a documentation update

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] Any dependent changes have been merged and published in downstream modules

@jacobdfriedmann
It seems the that the component "TopPoliceDepartments" referenced in "components/widgets/TopPoliceDepartments" folder is not available in the commit and ends of producing an error. Perhaps something erroneous happened in the push.


'Your connection is not private'

Hi!
Great repo and article on towardsdatascience! Thanks for that!
I am getting the 'Your connection is not private' when trying to access https://localhost:5601 (kibana) in my web browser (NET::ERR_CERT_AUTHORITY_INVALID).
Do you have any ideas on what might be missing in order to get the certificate validated?
Best regards,
Stian

That's normal, we're using a "self-signed" certificates, so your browser will warn you about this because in an actual production website you'll need to sign your certificate with a Certificate Authority Service.
Anyway, I'll assume you're using Chrome, just click "Advanced Options" -> "Proceed To Website Anyway"


Default protocol and bitcore-lib updates

Default protocol should be 70001 instead of 70000 since there really
was no protocol in the 70000 series.

Coverage remained the same at 100.0% when pulling c41681d6c27ee99e71d735ebde9690e2e047b682 on kleetus:updates/protocol into b7a6845a4f4c7940884247113a208fe30fcc0e39 on bitpay:master.


Default key bindings and rust-format-on-save doesn't work with rust-ts-mode

My configuration:
(use-package rust-mode
  :hook
  ((rust-mode rust-ts-mode)
   .
   (lambda ()
     (setq indent-tabs-mode nil)
     (prettify-symbols-mode)))
  :config
  (setq rust-format-on-save t)
  :init
  (setq rust-mode-treesitter-derive t))

Default key bindings and rust-format-on-save doesn't work with rust-ts-mode.

The hook you secificied doesn't seem to be right, can you remove the hook and try without it ?

I tested it locally and this works for me:
(use-package rust-mode
  :ensure t
  :defer t
  :init
  (setq rust-mode-treesitter-derive t)
  :config
  (setq rust-format-on-save t))

I tested it locally and this works for me:
(use-package rust-mode
  :ensure t
  :defer t
  :init
  (setq rust-mode-treesitter-derive t)
  :config
  (setq rust-format-on-save t))

This works, thanks!


fix(android): auto cancel and close notification drawer when action is pressed

There's an issue currently where if an action is performed on a notification, the notification drawer remains open and the notification isn't canceled (unlike when a notification is pressed).
Closes https://github.com/invertase/notifee/issues/268
TODO:
Test on Android 12

@mikehardy tested with a real device and read more about the Android 12 updates (here).
So for now, we can use this method if the app does not target android 12. If the app targets android 12, we need look into another way how we open the app

When I see you say "I tested on a real device" my immediate question is "what BUILD_VERSION on the device?" which then makes me think "Hmm well what targetSdkVersion on the app?" which expands to wanting a 2x2 matrix of test
1a) targetSdkVersion 30 / R / android 11 or 1b) targetSdkVersion 31 / S / android 12 as one axis
2a) combined once with phone running Android 11, 2b) once with phone running Android 12 as other axis
I think those might show positive results that answer your question 'If the app targets android 12, we need look into another way how we open the app', unless you already have negative results vs desired behavior for some quadrant there?
It seems via https://developer.android.com/about/versions/12/behavior-changes-all#close-system-dialogs / https://developer.android.com/about/versions/12/behavior-changes-all#close-system-dialogs-exceptions that we may actually fall into the exceptions or simply not need to run it and we will get expected behavior?

Your app targets Android 11 or lower. In addition, the user has interacted with a notification, possibly using the notification's action buttons, and your app is processing a service or broadcast receiver in response to that user action.

combined with:
https://developer.android.com/reference/android/content/Intent#ACTION_CLOSE_SYSTEM_DIALOGS

The platform will automatically collapse the proper system dialogs in the proper use-cases.

That makes me think that your last commit - where you send the deprecated intent on < API31/R/12 should actually work in all quadrants of that testing 2x2

new flake? 3 CI jobs all blew up on a 14minute long yarn install. Yarn install in this repo also does some cocoapods work if it's on macos, perhaps there's a maximum time exceeded issue or perhaps a transient network issue and the yarn install needs a retry (or tuning on retry, if it already has a retry). Just noting for future

@mikehardy that's strange. don't have much faith in the Android tests... I think we should try and increase the time limit on that job as the install can take a long time as you say 😓 .

Keep the faith 😂, takes time to stabilize CI but we're almost there, and it's worth it

For what it's worth, once merged to main, all CI jobs ran to completion first time. There's clearly some time-related tuning to be done, but it's not 100% useless at least ;-)


ResponseBuilder custom task factory

Currently the response builder allows passing in a custom task factory
https://github.com/Readify/Neo4jClient/blob/master/Neo4jClient/Execution/ResponseBuilder.cs#L120
Most of the code always uses null.
What is the design reason for this? HttpClient calls are pure IO based operations and should not be wrapped in Task.Run or factory.StartNew. So why even support it?

All of the code uses null!
These are public methods so my assumption is that @arturosevilla is using them? Is this the case?

I'm not using them. It could have been that during development I left it for testing and forgot to remove them.
If nobody is using them we should probably remove them.

They are removed now and not in 2.0.0


Updated k-interface

This PR is needed for another pull request about kytos/UI #24 based on UI issue #17

PR has landed https://github.com/kytos-ng/ui/pull/24, so let's merge this one


setting up java dependencies

Set up pom file to help with our java setup and to include any required dependences we might have. This is particularly useful for grabbing lyrics from the MusixMatch API, since they provide a link to a wrapper which will help alot. I'm sure that this will be of help to everyone else as well.
Link to the wrapper: https://github.com/sachin-handiekar/jMusixMatch

@seunomonije Accepting the patch created the commit under<EMAIL_ADDRESS>which is not recognized by the CLA bot. I already signed the CLA as<EMAIL_ADDRESS>so I'm not sure if I can fix this. Can you please delete that commit (git reset and force push) and then re-do it without including<EMAIL_ADDRESS>as a co-author (which is what happened automatically when you accepted the patch)?

@laptou ill just wait till it's merged since this branch probably won't last long anyways

I changed my primary email address to<EMAIL_ADDRESS>for now, so you can just commit the patches.

It keeps screwing everything up when I commit inline. I'll just close this one and make a fresh one..it's getting too cluttered


grab keeper version from different contract

Grabs the contract not from the OceanToken contract, because that one is not always updated.
Fixes squid-js contract mismatch detection in v2 commons.

Fixed in Brizo v0.8.0


DubboConfigConfiguration's Single and Multiple to be public classes

DubboConfigConfiguration.Single and DubboConfigConfiguration.Multiple to be public classes

Their will exposed in  2.5.9


BRS-237 - Migration for Historical Data 2000-2016

Ticket:
BRS-237
Ticket URL:
#237
Description:

Copy over and update /migrations-data/legacy-data/2017-2019 into new migrations folder for SAM
Small tweaks to remove Keycloak params and subsequent role creation functionality
Update to use AWS SDK v3
Small logic tweaks to avoid importing empty cells in .xlsx file

One small consideration, which I'm not sure has been accounted for - the original isLegacy tag was used in the event that we needed to back out the migration entirely. Wondering if we need to differentiate the new records you're going to be migrating in from the ones that I imported (2017-2019)...

I was initially going to just snapshot the database and save it in S3 and reimport if need be, but it's probably best to use the code if it exists and save time that way. I've added the purgeLegacy.js function and updated to use SDK v3 as well. I've used your recommendation and added legacyMigrationVersion: 2 for all these records and will purge legacy records using that attribute. Good call!
Also added some scan constraints to the Export Report option for when the user selects Export all - opted to not scan past 2017 (so not scanning the 150,000+ records added).


checkplot.png: minor kwarg addition

I was using _make_phased_magseries_plot, and noticed for stars with flares (or other "ramp" like systematics) that the phase-folded ylimits would be totally off. Sigma clipping (or windowed sigma clipping) goes some way to a workaround, but if the light curve has other variability it can fail. So: the option implemented here is a simple fix that usually works, and doesn't change any of the default options.

Thanks! Will look through and merge this weekend.

Merged. Thanks for the PR!


Fix for 'NoneType' object has no attribute 'email'

Fixes #807

Thank you! Hmm, any thoughts why the tests fail on Python 2?

Not sure, actually.  I tried in my own env and everything passes (see log below). It's odd though, the error is in the CC handling test which makes me think it might be legit.  However, the error seems to be involving date handling.
(django-helpdesk) $ python2.7 --version
Python 2.7.17
(django-helpdesk) $ git branch
  master
* patch-2
(django-helpdesk) $ python2.7  quicktest.py helpdesk
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
.................................................................
----------------------------------------------------------------------
Ran 65 tests in 2.705s

OK
Destroying test database for alias 'default'...

Hi, regarding the test failure, I don't think it has anything to do with the change in this PR.
I triggered a build with just a text change and it fails in exactly the same way: https://travis-ci.org/github/ilikerobots/django-helpdesk
I think it's an issue with pytz, probably related to this: https://bugzilla.redhat.com/show_bug.cgi?id=1295709/
I can't reproduce locally, but i'm on a debian based not rpm.

I created a fix for the test failure here: https://github.com/django-helpdesk/django-helpdesk/pull/813

Sounds good thanks!


[bug]: skipEnteringNoNeckPainBuffer = true can make cursor get stuck in non-focusable window

Description
First of all, thanks for the plugin!
I have some plugins installed that can open up non-focusable floating windows. I noticed that my cursor can get stuck inside a floating window by skipping over a side buffer, even though the window is not normally focusable by clicking on it directly.
For me, the expected behavior would be that non-focusable windows get skipped over, just like the side buffers.
Neovim version
0.10.x
Steps to reproduce
Here's a minimal config for reproducing the issue with noice.nvim:
-- save as repro.lua
-- run with nvim -u repro.lua
-- DO NOT change the paths
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "runtime", "cache" }) do
    vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
    vim.fn.system({
        "git",
        "clone",
        "--filter=blob:none",
        "--single-branch",
        "https://github.com/folke/lazy.nvim.git",
        lazypath,
    })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
    "folke/tokyonight.nvim",
    {
        "shortcuts/no-neck-pain.nvim",
        opts = {
            autocmds = {
                skipEnteringNoNeckPainBuffer = true,
            },
        }
    },
    {
        "rcarriga/nvim-notify",
        opts = {
            -- This should make it so that the window is not focusable
            on_open = function(win)
                vim.api.nvim_win_set_config(win, { focusable = false })
            end,
        },
    },
    {
        "folke/noice.nvim",
        config = true,
    },
}
require("lazy").setup(plugins, {
    root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")

Steps:

Enable NNP.
Trigger some kind of notification in noice.nvim (e.g., vim.notify("some message").
Try to move the cursor to the right-side buffer (CTRL-W + Right).
The cursor ends up inside the notification. Trying to move the cursor back out with CTRL-W + [some direction] does not work.

Relevant log output
No response
Self-service

[X] I'd be willing to fix this bug myself.

Thanks for the update!
I see that the cursor doesn't get stuck anymore. But, I still sometimes run into the issue of accidentally opening a file inside a non-focusable floating window.
Locally, I have applied this patch as a workaround:
diff --git a/lua/no-neck-pain/util/api.lua b/lua/no-neck-pain/util/api.lua
index 411dd54..fc34f13 100644
--- a/lua/no-neck-pain/util/api.lua
+++ b/lua/no-neck-pain/util/api.lua
@@ -181,6 +181,7 @@ function api.find_next_side_idx(start_idx, step, wins, current_side, other_side,
             not api.is_side_id(current_side, wins[index])
             and not api.is_side_id(other_side, wins[index])
             and wins[index] ~= previously_focused
+            and vim.api.nvim_win_get_config(wins[index]).focusable
         then
             return index
         end

Would it make sense to add such a change, at least as a setting?

Good point, I guess that would be a sane condition, feel free to create a PR I'll review it right away!


Environment Variables and Docker standalone support

This allows for customization of the database engine to be set as well as an easier way (rather than modifying the code) for people to set their own personal Youtube API key (in reference to a request on #1 )
References #6

Looks good to me so far, if you are finished I can merge.

I believe all my changes to be complete and am comfortable with the merge.
I've tested both the compose and dockerfile deployments on my linux swarm servers and it runs, functions and operates correctly

Awesome, thank you very much for the PR 👍


TensorBoard Callback Deprecated

Just did fresh upgrades of Keras and TensorFlow today, and there seems to be a change to the TensorBoard API that isn't reflected in the Keras callback implementation. When I train a model with the TensorBoard callback:
tb = TensorBoard(log_dir='./logs')
model.fit(X_train, y_train, batch_size=nb_batches, nb_epoch=nb_epochs,
    verbose=1, validation_data=(X_test, y_test), callbacks=[tb])

I get a warning:

WARNING:tensorflow:Passing a GraphDef to the SummaryWriter is deprecated. Pass a Graph object instead, such as sess.graph.

That would be a one line fix, replacing sess.graph_def with sess.graph in the TensorBoard callback (callbacks.py, line 461). Could you try it, check that it works, check that it also works with the previous version of TF, and submit a PR?

The warning went away after applying the fix suggested by @fchollet.

I made the same change in my fork but this change does not work with previous versions of Tensorflow. Would a check like this be acceptable?
tf_version = tuple(int(i) for i in tf.__version__.split('.'))
if tf_version >= (0, 8, 0):
    ...
else:
    ...

There is a PR for the fix, please post there. Yes, I think a conditional
statement would be the right way to handle this.


Remove @pmlandwehr as a maintainer

I haven't done any work on this feedstock in ages! Removing myself as a remainder.

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin please rerender


Perf: improve the performance of using scrollToItem method with non-dynamic-size items

Perf: improve the performance of using scrollToItem method with non-dynamic-size items

Pull Request Test Coverage Report for Build 888304964

0 of 5 (0.0%)  changed or added relevant lines in 1 file are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage increased (+2.1%) to 2.098%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/useVirtual.ts
0
5
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/useVirtual.ts
3
0%

Totals

Change from base Build 888286827:
2.1%

Covered Lines:
7

Relevant Lines:
264

💛  - Coveralls


i have written a code. can anyone check it out why it is not running

So, i have written a code using the sdk and ROS; it compiles and builds using catkin all well without any error but once i use rosrun to run the code; everything runs fine but there is no output. this is the code
#include <OVR_CAPI.h>
#include "/home/adham/bebopOculus_ws/src/ros_ovr_sdk/sdk/ovr_sdk_linux_<IP_ADDRESS>/LibOVR/Include/Extras/OVR_Math.h"
#include
#include<ros/ros.h>
int main(int argc, char **argv)
{
ros::init(argc,argv, "bebopocu");
ros::NodeHandle nh;
ros::Rate rate(2);
while (ros::ok){
	if(ovr_Initialize(NULL))
	{
		ovrHmd hmd = ovrHmd_Create(0);

		if (hmd)
		{
			ROS_INFO("Created");

		ovrSizei resolution = hmd->Resolution;

		ovrHmd_Destroy(hmd);

		}
ovr_Shutdown();
rate.sleep();

}

}
}
or at least can i have an example of how this is written or where to learn it ?
thanks !

You only need to  create and destroy the hmd object once. This program seems to be doing it continuously in a loop, so it might not have finished destroying the object when it calls create again. I don't think the resolution will change so you could save the resoluton before starting the while loop.
Here's an example. Look at Oculus::setupOculus and Oculus::shutDownOculus.
https://github.com/OSUrobotics/oculus_rviz_plugins/blob/groovy-devel/src/ogre_oculus.cpp
And check out the section API Interfaces in the include file.
https://github.com/OSUrobotics/ros_ovr_sdk/blob/master/sdk/ovr_sdk_linux_<IP_ADDRESS>/LibOVR/Include/OVR_CAPI_0_5_0.h

I have tried running the create and destroy hmd object once, still same
problem it gets stuck. I saw the example but can you please tell me what
can I understand from that article.
On Mon, Jan 25, 2016 at 10:57 PM, David Rebhuhn<EMAIL_ADDRESS>wrote:

You only need to create and destroy the hmd object once. This program
seems to be doing it continuously in a loop, so it might not have finished
destroying the object when it calls create again. I don't think the
resolution will change so you could save the resoluton before starting the
while loop.
Here's an example. Look at Oculus::setupOculus and Oculus::shutDownOculus.
https://github.com/OSUrobotics/oculus_rviz_plugins/blob/groovy-devel/src/ogre_oculus.cpp
And check out the section API Interfaces in the include file.
https://github.com/OSUrobotics/ros_ovr_sdk/blob/master/sdk/ovr_sdk_linux_<IP_ADDRESS>/LibOVR/Include/OVR_CAPI_0_5_0.h
—
Reply to this email directly or view it on GitHub
https://github.com/OSUrobotics/ros_ovr_sdk/issues/8#issuecomment-174621205
.

and when i open the configUtil software it shows that the hmd service is
unavailabe
On Tue, Jan 26, 2016 at 7:48 PM, Adham Al-Khaja<EMAIL_ADDRESS>wrote:

I have tried running the create and destroy hmd object once, still same
problem it gets stuck. I saw the example but can you please tell me what
can I understand from that article.
On Mon, Jan 25, 2016 at 10:57 PM, David Rebhuhn<EMAIL_ADDRESS>wrote:

You only need to create and destroy the hmd object once. This program
seems to be doing it continuously in a loop, so it might not have finished
destroying the object when it calls create again. I don't think the
resolution will change so you could save the resoluton before starting the
while loop.
Here's an example. Look at Oculus::setupOculus and Oculus::shutDownOculus.
https://github.com/OSUrobotics/oculus_rviz_plugins/blob/groovy-devel/src/ogre_oculus.cpp
And check out the section API Interfaces in the include file.
https://github.com/OSUrobotics/ros_ovr_sdk/blob/master/sdk/ovr_sdk_linux_<IP_ADDRESS>/LibOVR/Include/OVR_CAPI_0_5_0.h
—
Reply to this email directly or view it on GitHub
https://github.com/OSUrobotics/ros_ovr_sdk/issues/8#issuecomment-174621205
.

meaning that the service is not connected. should i install some kind of
driver?
On Tue, Jan 26, 2016 at 8:42 PM, Adham Al-Khaja<EMAIL_ADDRESS>wrote:

and when i open the configUtil software it shows that the hmd service is
unavailabe
On Tue, Jan 26, 2016 at 7:48 PM, Adham Al-Khaja<EMAIL_ADDRESS>wrote:

I have tried running the create and destroy hmd object once, still same
problem it gets stuck. I saw the example but can you please tell me what
can I understand from that article.
On Mon, Jan 25, 2016 at 10:57 PM, David Rebhuhn<EMAIL_ADDRESS>
wrote:

You only need to create and destroy the hmd object once. This program
seems to be doing it continuously in a loop, so it might not have finished
destroying the object when it calls create again. I don't think the
resolution will change so you could save the resoluton before starting the
while loop.
Here's an example. Look at Oculus::setupOculus and
Oculus::shutDownOculus.
https://github.com/OSUrobotics/oculus_rviz_plugins/blob/groovy-devel/src/ogre_oculus.cpp
And check out the section API Interfaces in the include file.
https://github.com/OSUrobotics/ros_ovr_sdk/blob/master/sdk/ovr_sdk_linux_<IP_ADDRESS>/LibOVR/Include/OVR_CAPI_0_5_0.h
—
Reply to this email directly or view it on GitHub
https://github.com/OSUrobotics/ros_ovr_sdk/issues/8#issuecomment-174621205
.


calculatePoolTokenOptimalAmount(pairAddress, tokenAddress, inputAmount

Create function calculatePoolTokenOptimalAmount(pairAddress, tokenAddress, inputAmount → Calculate) optimalOtherAmount Given a contract_id (I mean pair contract address) an amount and a token Address it returns an integer that indicates what’s the optimal amount of the other token in the pair contract to deposit.
Check github preriphery contracts and uniswap sdk https://github.com/Uniswap/v2-sdk/
Write this in a good way.

Específicamente
https://github.com/Uniswap/v2-sdk/blob/main/src/entities/pair.ts

We need to test after doing a swap


Automated cherry pick of #2599: schedtag: create support scope

Cherry pick of #2599 on release/2.12.
#2599: schedtag: create support scope

/lgtm

/approve


Translations update from Hosted Weblate

Translations update from Hosted Weblate for Morse/Metadata.
Current translation status:

@comradekingu, do you know if F-Droid supports yewtu.be / Invidious?

@comradekingu In what capacity?

@comradekingu In what capacity?

So that the video gets shown in the F-Droid Android client.
Maybe @IzzySoft or @jugendhacker know about that.

idk. AFAIK the client doesn't support video.txt (from Fastlane or Triple-T) yet, nor have I seen any app with a video yet in the client. That doesn't stop you from using video.txt of course.

idk. AFAIK the client doesn't support video.txt (from Fastlane or Triple-T) yet, nor have I seen any app with a video yet in the client. That doesn't stop you from using video.txt of course.

Alright, thanks for the answer @IzzySoft. 😘

Oh wait, I just found it. The link to the video is a bit hidden.

Ah! Good to know!


Add units to AxisLabel

Adds dedicated prop for units on AxisLabel to standardize styles. If special styles are needed, customized children can still be provided.

nice addition! lgtm


Migrate to "afl++" from "afl"

Following #769, backport #766 onto stable too to fix the build.
Ignore changes in CHANGELOG.md, there is no "Unreleased" section on the stable branch. It will get here in due time.
Checklist

[X] Change is covered by automated tests
Oh why yes, it is covered.

Oh well, it seems even more stuff needs to be backported as the jobs are failing. Since this PR touches some Themis Core files, it should trigger all the jobs and expose whatever is currently broken for stable CI.

I've submitted fixes to the issues above. These are separate pull requests so that history clearly shows what has been cherry-picked from where (instead of one squashed commit "fix stuff by integrating all these changes").
Once those three are all merged and this one is added on top, I'd expect stable build to go green at last.


Adapt manifest to fractal v1.x

Move it to specific file
Conform to JSON schema

Ref https://github.com/fractal-analytics-platform/fractal-server/pull/188

@jacopo-exact
Could you provide an minimal example of __FRACTAL_MANIFEST__.json?
My guess was something like
{
    "manifest_version": "1",
    "task_list": [
        {
            "name": "Create OME-ZARR structure",
            "executable": "/tmp/some/path",
            "input_type": "image",
            "output_type": "zarr",
            "default_args": {"num_levels": 2}
        }
    ]
}

but validating it via
with open("__FRACTAL_MANIFEST__.json", "r") as fin:
    manifest_dict = json.load(fin)
print(json.dumps(manifest_dict, indent=4))
manifest = ManifestV1(manifest_dict)

fails with
Traceback (most recent call last):
  File "validate_manifest.py", line 45, in <module>
    manifest = ManifestV1(manifest_dict)
  File "pydantic/main.py", line 333, in pydantic.main.BaseModel.__init__
TypeError: __init__() takes exactly 1 positional argument (2 given)

My bad, I was missing the meta parameter.
@jacopo-exact, can we make it Optional?


configure args is in the metadata file but not the main SBoM file

I thought we had the configure args in the main SBoM now - I guess not 😢
Ideally we'd just pull the SBoM from the API but since we need the metadata file as well I guess it makes sense to have the two lines look similar.
We typically don't want to encourage people going directly to our backend location on github.
Originally posted by @sxa in https://github.com/adoptium/adoptium.net/pull/2949#discussion_r1707377946
We should ensure that all information required for reproducibility is in the main SBoM file so the metadata file (Primarily for use by the adoptium API) is not required for reproducibility verification.
The goal here should be to ensure that out documentating like this for Linux/x64 does not include curl -L -O https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.4%2B7/OpenJDK21U-sbom_x64_linux_hotspot_21.0.4_7-metadata.json because all of the information has been added to the SBoM file.

i can do this

@sxa is this something i should somehow try doing in the TemurinGenSBOM.java (if so, how do i build it/pull in dependencies - I'm not sure how i can pull in the cyclonedx libs without having a maven/gradle build file)

https://github.com/adoptium/temurin-build/blob/master/cyclonedx-lib/README.md contains pretty much everything I know about the SBoM generation process, and specifically my experience of adding things. Hopefully the referenced parts of build.sh in there will give you an idea of how to get started. For anything more complex we may need the assistance of @andrew-m-leonard :-)

not quite sure what @andrew-m-leonard means - is it that BUILD_CONFIGURATION_PARAM thing which is all the sbom needs (still needs converting into a name-value pair list to match the definition in https://cyclonedx.org/docs/1.4/json/#metadata_component_properties
the thing in the pr matches the validator here https://cyclonedx.github.io/cyclonedx-web-tool/validate (with the caveat that I manually bumped minor version back down to 1.5 because they don't support 1.6 yet)

the addSBOMComponentProperty should do all the work, we just need to add the following line to sbin/build.sh, so that CONFIGURE_ARGS:
addSBOMComponentProperty "${javaHome}" "${classpath}" "${sbomJson}" "${componentName}" "Configure Args" "${CONFIGURE_ARGS}"

note, CONFIGURE_ARGS is kept as a single String property value.

@Scanteianu Does Andrew's comment above sound good to you?

sorry, missed the notification, not sure why. I will try to add that line