nanopolish variants

Hi,
I am using MinION to call multiple SNPs and in-dels from a multiplex PCR. in total, I have 15 amplicons. One of my reference samples have 2 SNPs and 1 one-base deletion (Heterozygotes).
"/media/WORKSPACE/cen/nanopolish/scripts/nanopolish_makerange.py" 15amplicon_formated.fasta | parallel --results barcode022_nanopolish.results -P 8 nanopolish variants --consensus polished.{1}.fa -w {1} -r barcode02_nanopolish.fa -b barcode02_nanopolish.sorted.bam -g 15amplicon_formated.fasta -t 4 --min-candidate-frequency 0.1
I have several questions:

in both of the SNPs called by nanopolish variants, it gave me two lines:
#CHROM	POS	ID	REF	ALT	QUAL	FILTER	INFO	FORMAT	sample
ABCB1	102	.	T	C	51976.9	PASS	TotalReads=3821;AlleleCount=1;SupportFraction=0.413547	GT	1
ABCB1	102	.	T	C	51667.2	PASS	TotalReads=3824;AlleleCount=1;SupportFraction=0.969851	GT	1

#CHROM  POS     ID      REF     ALT     QUAL    FILTER  INFO    FORMAT  sample
VKORC1rs7294    115     .       G       A       7746.0  PASS    TotalReads=1595;AlleleCount=1;SupportFraction=0.792303  GT      1
VKORC1rs7294    115     .       G       A       7718.2  PASS    TotalReads=1595;AlleleCount=1;SupportFraction=0.891691  GT      1
what is the difference between those two lines? For ABCB1, the sample should have CC genotype, so I think the second line is correct. But, if I don't know the genotype, how can I tell which one should I use?

I try to write the results into vcf file, using this command:

"/media/WORKSPACE/cen/nanopolish/scripts/nanopolish_makerange.py" 15amplicon_formated.fasta | parallel --results barcode022_nanopolish.results -P 8 nanopolish variants --consensus polished.{1}.fa -w {1} -r barcode02_nanopolish.fa -b barcode02_nanopolish.sorted.bam -g 15amplicon_formated.fasta -t 4 --min-candidate-frequency 0.1 --o barcode022_nanopolish.vcf
but the vcf file only contained the ABCB1 variants, and don't the other one, what arguments should I add?

the nanopolish variants failed to call the one-base deletion. when I looked at the bam file (IGV), the deletion site has 1213 read depth, and the deletion depth is 664, which is quite good. Do you have any idea, so the deletion would be called by nanopolish variants?

Thanks a bunch!
Cen

Hi,
If you are calling variants with respect to a reference genome I suggest you do not use the --consensus option and use --ploidy 2 since you are looking for heterozygotes.
The syntax of running in variant-calling mode is similar:
nanopolish variants -r barcode02_nanopolish.fa -b barcode02_nanopolish.sorted.bam -g 15amplicon_formated.fasta -t 4 --min-candidate-frequency 0.1 -w CHR:START-END --ploidy 2 > variants.vcf

You'll need to change CHR, START, END to the region of the reference genome that you want to call.
Running in this mode with --ploidy 2 should help with the issues you had. Let me know how it goes after you re-run it.
Jared

Hi,
THanks! so if I just want to call variants, I do not need to run the makerange.py command, am I right?
Above syntax that you gave me, run ok, and give me the vcf file. Just wondering, because I have 15 contigs in my reference genome. Can I call the variants in all contigs in one command and create a single vcf file, or do I need to run it one by one and have 15 different vcf file for each sample?
Thank you so much!
Cen

That's right, you don't need makerange.py, but you will have to run it on each contig separately.

Thanks! from my initial random run on several contigs, it seems like I still failed to call some variants in my reference sampel. I have more than 80 samples, I'll have them all run and get back to you to get some more advice on the failed variant calling.
Thanks,
Cen

Ok

Hi Jared,
Thank you for helping so far! I've called the variants from all my samples. It seems like variants were not called for some contigs (CYP2C1927, CYP4F2, CYP2C96 (del)).
I've attached some fa, bam, and the reference file if you could have a look?
and I also wonder, what is the default min-frequency to call a homozygote? is there any options to set to another number?
nanopolish.zip
Thanks,
cen

Hi,
Did you include the fast5 files? I'll need those to look. What variants are you expecting? I'll try to look when I have a chance.
Jared

Hi Jared, I put the fast5 files for sample Barcode01, barcode02, and barcode71 on google drive as below:
https://drive.google.com/file/d/0B1_0hZNTRL0hMFk5aGJ2bjUyRFU/view?usp=sharing
barcode01 should have GA genotype on CYP2C1927 at position 37
barcode02 should have heterozygous delA on CYP2C96 at position 140
barcode71 should have GA genotype on CYP4F2 at position 40
Thanks a lot!

Hi Jared,
I know it's been a while, but wonder if you know why the variant calling failed for some SNPs? the SNPs was quite visible on the BAM file, but I couldn't call it in the vcf file using nanopolish variant.
Thanks

Hi,
Sorry I haven't looked yet. I will have more time next week and I will try to look then.
jared

Thanks!

Hi,
Can you tell me the command you used to basecall these reads?
Jared

Hi,
I had a look at the barcode01 test case. The problem is the variant is too close to the end of the amplicon. Nanopolish will skip anything within about 40bp of the end of the contig as the reads and alignments are less reliable here. If you'd like to change this you have to edit this value in the code:
https://github.com/jts/nanopolish/blob/master/src/nanopolish_call_variants.cpp#L127
If you set this to 10bp it will work.
I suspect that barcode71 and barcode02 is the same problem (I couldn't verify this because I don't have the fast5 files).
Is it possible to redesign your amplicons to provide more flanking sequence surrounding the region of interest?
Jared

Hi,
I see! Yes, the 2 other SNPs are less or equal to 40 bp to the end of the amplicon.
I'll give it a try! Hope it works.
I can redesign the primers, but I don't have the DNA samples anymore.
Thanks a lot

I have tried changing the value for min_flanking_sequence in the nanopolish_call_variants.cpp from 30 to 10 and them 5, but it didn't seem to work. Am I doing it right? the cpp file is in the scr directory.

Hi,
Wonder if I did it wrong, but changing the min_flanking_sequence didn't seem to work to call variants in the 40 bp from the end. Really hope you can help, as I found nanopolish works the best compared to other variant calling tools for MinION, but I just couldn't get these three variants to work.
thanks

Did you recompile the code after making the change (by running make)?

No, I didn't. It works now :). Thanks a lot!


How to link LLVM libraries when building the instrumenter?

Hi, thanks for your nice tool and research work!
I encountered a building error when I tried to play this instrumenter, could you please take a look and see how to fix it? I know the problem may come from the failed linking of LLVM libraries, but I don't know how to handle it.
I have built LLVM-13, and exported the clang/llvm environment to the .bashrc by adding the export PATH=/home/haoxin/disk-dut/research/compilers/llvm-project-old/build-clang-13/bin/:$PATH. However, when I used cmake to build the instrumenter, the errors came out:
haoxin@server:~/disk-dut/research/github/dead_instrumenter/build$ cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
-- The CXX compiler identification is Clang 13.0.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/haoxin/disk-dut/research/compilers/llvm-project-old/build-clang-13/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11")
-- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.9.4")
CMake Error at /home/haoxin/disk-dut/research/compilers/llvm-project-old/build-clang-13/lib/cmake/llvm/LLVMConfig.cmake:291 (include):
  include could not find load file:

    /home/haoxin/disk-dut/research/compilers/llvm-project/build-clang-13/lib/cmake/llvm/LLVMExports.cmake
Call Stack (most recent call first):
  CMakeLists.txt:3 (find_package)

CMake Error at /home/haoxin/disk-dut/research/compilers/llvm-project-old/build-clang-13/lib/cmake/llvm/LLVMConfig.cmake:292 (include):
  include could not find load file:

    /home/haoxin/disk-dut/research/compilers/llvm-project/build-clang-13/lib/cmake/llvm/LLVMBuildTreeOnlyTargets.cmake
Call Stack (most recent call first):
  CMakeLists.txt:3 (find_package)

-- Found LLVM 13.0.1
-- Using LLVMConfig.cmake in /home/haoxin/disk-dut/research/compilers/llvm-project-old/build-clang-13/lib/cmake/llvm
CMake Error at /home/haoxin/disk-dut/research/compilers/llvm-project-old/build-clang-13/lib/cmake/llvm/LLVMConfig.cmake:291 (include):
  include could not find load file:

    /home/haoxin/disk-dut/research/compilers/llvm-project/build-clang-13/lib/cmake/llvm/LLVMExports.cmake
Call Stack (most recent call first):
  /home/haoxin/disk-dut/research/compilers/llvm-project-old/build-clang-13/lib/cmake/clang/ClangConfig.cmake:5 (find_package)
  CMakeLists.txt:8 (find_package)

CMake Error at /home/haoxin/disk-dut/research/compilers/llvm-project-old/build-clang-13/lib/cmake/llvm/LLVMConfig.cmake:292 (include):
  include could not find load file:

    /home/haoxin/disk-dut/research/compilers/llvm-project/build-clang-13/lib/cmake/llvm/LLVMBuildTreeOnlyTargets.cmake
Call Stack (most recent call first):
  /home/haoxin/disk-dut/research/compilers/llvm-project-old/build-clang-13/lib/cmake/clang/ClangConfig.cmake:5 (find_package)
  CMakeLists.txt:8 (find_package)

CMake Error at /home/haoxin/disk-dut/research/compilers/llvm-project-old/build-clang-13/lib/cmake/clang/ClangConfig.cmake:14 (include):
  include could not find load file:

    /home/haoxin/disk-dut/research/compilers/llvm-project/build-clang-13/lib/cmake/clang/ClangTargets.cmake
Call Stack (most recent call first):
  CMakeLists.txt:8 (find_package)

-- Using ClangConfig.cmake in /home/haoxin/disk-dut/research/compilers/llvm-project-old/build-clang-13/lib/cmake/clang
-- Configuring incomplete, errors occurred!
See also "/home/haoxin/disk-dut/research/github/dead_instrumenter/build/CMakeFiles/CMakeOutput.log".

It seems the required libraries were not linked successfully. Could you please give me some hints on how to fix this issue?
Thank you very much and looking forward to your response!
Best regards,
Haoxin

Hi Haoxin!
Unfortunately I've never seen this error before. One guess:
Is /home/haoxin/disk-dut/research/compilers/llvm-project/build-clang-13  a build directory or did you install LLVM there? If you did not install it,  could you try to install LLVM and check if this fixes the issue?

Hi @thetheodor, thanks for your response!
I have installed LLVM-13 in the build-clang-13 folder. For now, after I changed the CMakeList.txt file to let it to find the required libraries, I can successfully build and run it.
Thanks again for your kind help!


Inform language servers that we really only supports utf-32

I think this configures clangd to talk utf-32, and also informs other servers that we would like to do the same.
I havn't been able to find any server that can be configured with general.positionEncoding yet, but clangd have their own way to be configured which AFAIK works in clangd14.

Is there a reason why we don't support variable-length encodings like UTF-8 and UTF-16? Only supporting UTF-32 seems like sweeping the issue under the rug.
What's the "character offset" anyway? What to you mean by "character"? Unicode can be quite confusing, and "character" is a vague term. Are you referring to unicode scalar values or grapheme clusters? What does the LSP spec mean?

Is there a reason why we don't support variable-length encodings like UTF-8 and UTF-16? Only supporting UTF-32 seems like sweeping the issue under the rug.

Well for now it's how we use the range directly from the language server with setcursorcharpos which sets the cursor position based on character offset.
As well as how a range is calculated based on the current cursor position, see util#GetLineByteFromPos. Both of these works on character offsets.

What's the "character offset" anyway? What do you mean by "character"? Unicode can be quite confusing, and "character" is a vague term. Are you referring to unicode scalar values or grapheme clusters? What does the LSP spec mean?

I don't know much about this stuff, the examples mentioned above uses vim functions, so I think the answer can be found in the source code of vim itself.

What does the LSP spec mean?

The language server specification: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/
Note that before 3.17 the specification expects that character positions are based on text being in UTF-16, meaning that this "😄😄😄" would be counted as 8 characters.
This client have been coded to always count characters in a way that this "😄😄😄" will be counted as 5 characters.
In 3.17 of the specification it was made possible to reference positions in other encodings than UTF-16. Since this client really only speaks UTF-32, when it comes to positions, it's worth informing the servers that, thats what it does. Worst case is that the servers doesn't respect the request for UTF-32 and keeps talking UTF-16 character positions, meaning the example above would be counted wrongly, but most cases works, as things like var ಠ_ಠ = 1 is counted the same in UTF-16 and UTF-32, as 11 characters. See "New in 3.17": https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocuments

Il giorno mer 5 apr 2023 alle 15:12:26 -07:00:00, Andreas Louv
@.***> ha scritto:

The language server specification:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/
Note that before 3.17 the specification expects that character
positions are based on text being in UTF-16, meaning that this
"😄😄😄" would be counted as 8 characters.
This client have been coded to always count characters in a way that
this "😄😄😄" will be counted as 5 characters.
In 3.17 of the specification it was made possible to reference
positions in other encodings than UTF-16. Since this client really
only speaks UTF-32, when it comes to positions, it's worth informing
the servers that, thats what it does. Worst case is that the servers
doesn't respect the request for UTF-32 and keeps talking UTF-16
character positions, meaning the example above would be counted
wrongly, but most cases works, as things like var ಠ_ಠ = 1 is
counted the same in UTF-16 and UTF-32, as 11 characters. See "New in
3.17":
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocuments

It seems that there's a bit of confusion about the meaning of
"character" (and it doesn't surprise me, since Unicode is quite
complex).
In Unicode there are different things that could be called characters:

A Scalar Value, which is what a programmer would call a character,
but doesn't always map to it in all spoken languages. "a" is a scalar
value, and so is "😄"; "ñ" is also a scalar value, but not always,
as that "ñ" could be made up of two different scalar values, a regular
"n" and a "Combining Tilde" (U+0303, ◌̃). See for example this C
program:
#include <stdio.h>
int main(void) {
 puts(u8"man\u0303ana");
}

It prints "mañana", but using two different scalar values "n" and
"Combining Tilde", instead of the single scalar value "ñ" (Latin Small
Letter N with Tilde, U+00F1).

A Grapheme Cluster, which is what regular people would call a
character. In the example before, "ñ" and "n"+"Combining Tilde" would
both represent a single Grapheme Cluster, but one is composed of a
single scalar value while the other uses two of them. (you can see the
difference by running the C example above and piping the output into
"wc -m")

A Code Unit, which is dependent on the UTF encoding used and is as
large as the number of the UTF used. UTF-8 has 8 bit code units, UTF-16
has 16 bits code units and (you've guessed it) UTF-32 has 32 bit code
units. As UTFs are variable-length encodings, each scalar value could
require one or more code units to be represented. "n" requires only one
code units in all encodings, "ñ" requires two in UTF-8 and one in
UTF-16, "∫" requires three in UTF-8 and one in UTF-16, and "😄"
requires four in UTF-8 and two in UTF-16. Now, it is pretty easy to
calculate the code unit, you just need to get the byte length of the
string and divide it by the size of a single code unit of the used UTF.

A C "char". Not really a character, just a byte, but I've put this
here just to note that no, C characters are not actual characters. They
are bytes. Maybe it can represent a character in ASCII or other legacy
latin encodings, but not today.

To make understanding all this a bit easier, I'd recommend taking a
quick look at sites like https://www.compart.com/en/unicode/U+222B
and https://unicodes.jessetane.com/∫, since they show how
each Scalar Value is made up in different UTFs.
The LSP spec is not super explicit about this, but it seems that they
are referring to Code Units when talking about offsets. From the spec:

Prior to 3.17 the offsets were always based on a UTF-16 string
representation. So in a string of the form a𐐀b the character offset
of the character a is 0, the character offset of 𐐀 is 1 and the
character offset of b is 3 since 𐐀 is represented using two code
units in UTF-16.

Now that you (hopefully) better understand the issue at hand, what do
you think would be the most appropriate solution? I think it'd be
better for the vim9 lsp client to always report offsets in UTF-16 code
units, since that's what all language servers must support.

To properly support UTF-16 code points, the following Vim patch is needed:
https://github.com/vim/vim/pull/12216
I created this PR last week.  Bram hasn't merged this yet.  Once this is merged, the LSP plugin can use the new functions to support the UTF-8, UTF-16 and UTF-32 code points properly.


Able to query without cache

I'm trying to run background service to fetch results.
But I get below exception when I try without cache
Unhandled Failure NoSuchMethodError: The method 'write' was called on null.

Why is cache mandatory?
I don't want to use cache. Please make it optional. It's not wise to inject cache, even when you don't need it.
I am running service in background using workmanager.

BTW I agree with this, I am not quite happy with current cache behaviour and I was thinking about using this library only as a network client and dumping result to my personal cache or store and I was also quite surprised about having cache as mandatory.

@insanebaba you can try the defaultPolicies api to avoid writing to the cache. Try without a cache argument and lmk if it works:
  final policies = Policies(
    fetch: FetchPolicy.networkOnly,
  );

  return ValueNotifier<GraphQLClient>(
    GraphQLClient(
      cache: null,
      link: link,
      defaultPolicies: DefaultPolicies(
        watchQuery: policies,
        query: policies,
        mutate: policies,
      ),
    ),
  );

In the future, we should possibly make cache not required and set the default policies based on it being defined

Hi @micimize , I implemented a new cache class with empty implementations. passing null doesn't work, Throws error at runtime

@insanebaba this library is modeled after Apollo, where client is pretty much link + cache. If you do not want to use cache, client - cache is pretty much only the link.
Did you try using your link directly?

@insanebaba this library is modeled after Apollo, where client is pretty much link + cache. If you do not want to use cache, client - cache is pretty much only the link.
Did you try using your link directly?

How to try bro? Im error when flutter pop to list, and cannot load new list after add new posts/

The cache calls are fairly integrated into the QueryManager, and making the cache itself optional makes the policy api nonsensical. Instead, I think we'll follow apollo-client's lead on this and just say to use the no fetch policy.
Even if we tried to offer this option, a user not wanting to use (or eventually use) the cache would probably be better off with a client composed of nothing but gql links. Maybe we should make a gql_fetch for that use-case. Would also serve as a gql_link example in general


optionally include auth header for download

replaced by https://github.com/shapediver/GeometryBackendSdkTypeScript/pull/16


Adding Service

Is there a tutorial or Help page showing how and what to put in the Services Adding page to make it work?
I tried to add a Service.  It shows up on the HSMM-Pi node, but not on the Linksys nodes in the network.
How do I redirect it to port 80 and a path other than /var/www ?
It only gives me a choice of TCP or UDP.  What if I want 'http' ?  Is this the same as one of those choices?
Gary

@ghinton77 There was a bug preventing services from appearing on the rest of the network, which I've fixed in version 0.7.0. I also added support for setting a path. To use the http protocol for the service, put that in the "Service Protocol Name" field. Hope that helps!


feat: text alignment and simpler extendability for rich text editor

Description
This PR adds a new TextAlignment element to the default Rich Text Editor. This element was created by modifying the toggleElement function to accept a new blockType variable. This variable defaults to the standard type field so as not to cause breaking changes. The Element component now also features an optional type prop to go along with format. The default value "type" is used if type is not specified.
TextAlignment required modifications to the RichText.tsx file, specifically the renderElement function. This function now checks for textAlign on the element being modified. It appends a style field with alignment to the attributes of the element.  if there is no text alignment specified, will not be added to the attributes.

[x] I have read and understand the CONTRIBUTING.md document in this repository

Type of change

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] I have added tests that prove my fix is effective or that my feature works
[x] Existing test suite passes locally with my changes
[x] I have made corresponding changes to the documentation

Hi @MarkAtOmniux! Great work on this so far. A couple things I am noticing in the admin panel:

Lists and toggling alignments. Changing between alignments on a list is causing li tags to break, adding another li tag within itself for every alignment change. This prevents the user from being able to remove that text from a list/change indentation.
Aligning non-text elements. For elements like uploads, it would make sense for the whole component to be aligned to the textarea. Currently only the text inside the component obeys the alignment set.

Hi @MarkAtOmniux! Great work on this so far. A couple things I am noticing in the admin panel:

Lists and toggling alignments. Changing between alignments on a list is causing li tags to break, adding another li tag within itself for every alignment change. This prevents the user from being able to remove that text from a list/change indentation.
Aligning non-text elements. For elements like uploads, it would make sense for the whole component to be aligned to the textarea. Currently only the text inside the component obeys the alignment set.

Thanks for raising those issues. That's a good point about the list item, i'll look at how style is being applied to it. As for non-text elements, that's a relatively simple fix, however it will require changes to the element's margin and possibly also flex position. I'll look into it :)

@MarkAtOmniux I just went ahead and fixed the list styling issue! Well, almost. There's still an issue when you try to align a list item with level 2 indenting (no clue why):

but honestly, if someone really needs that and makes an issue, that person is a maniac and we should run. Their content would have to be beyond cursed if someone needs that - and at that point, payload will be the least of their issues. So, I think it's fine like that!
One more thing: can you make sure that the alignment element is not included in the richtext editor by default? Instead, just make it clear in the docs how to enable that, so if someone needs it, they can easily add it to their editor.
Most people probably don't want to have it enabled by default, given that they have stricter editorial guidelines as to how the content needs to be formatted and don't want editors to be aligning stuff all over the place.

@AlessioGr I'll add in those changes tonight :)


[Feature requested] Could you please a PyTorch version?

Thanks for the excellent work! I 'll appreciate it if a PyTorch version of code provided!

Thanks for the excellent work! I 'll appreciate it if a PyTorch version of code provided!

Hi @CaptainEven , would you mind to share how did you able to run the the test.py ?
I am trying to reproduce the work , but my session keep crash when i run till this line https://github.com/MinfengZhu/EEMEFN/blob/87168dc7f5d9cce9d1db2a4af7a83601707cd285/src/test.py#L71
in test.py?

Thanks for the excellent work! I 'll appreciate it if a PyTorch version of code provided!

Do you currently have a pytorch version of EEMEFN?


Generate record type based on propTypes

Map from React.PropTypes to JSTypeExpressions. Use it to annotate the <Component>Interface.prototype.props property.

Also cast the props param of React.createElement callsites to do checks at creation time.

Completed in 2016.


Javascript-Based Select "Deluxe"

I needed a dropdown that supported icons and option groups.  The .dropdown() wasn't automatically converting optgroups and it definitely wasn't supporting semantic icons, descriptions, labels, etc.
I'm not even sure if I would call this a 'select' anymore (and wasn't sure what to call the element- select-flex, dropdown-deluxe?  who knows), and these changes removed the select element entirely.  But what this does allow you to do is do a searchable dropdown with icons and all the other bells and whistles.  Let me try to show some examples here, for thought at least.
Example
Not the best, but hopefully gets the idea across.
In Template
{{> afQuickField name='country' type='select-deluxe' withSearch=true withSpan=true withIcon=true firstOption="(Select Country)" options=countryOptions}}
You can also use withDiv=true and withImage=true.  If you pass something besides a boolean (i.e. withIcon="myDatabaseFieldClass" the passed-in string will be used as the key in the options lookup instead of the default iconClass.  Because I thought it was getting too complex, span, div and image content always have to be in spanContent, divContent and imageSrc respectively.
Of course, you can leave off withSearch to take away the search abilities.
In JavaScript (Autoform "options" Helper)
Template.registerHelper('countryOptions', function () {
    return [
      {
        optgroup: "Nordic Countries",
        options: Countries.find({code: { $in: ['fi','dk','is','se','no']}}).map(function (c) {
          return {label: c.name, iconClass: c.code + ' flag', spanClass: 'right floated description', spanContent: "Cold!", value: c.code};
        })
      },
      {
        optgroup: "Everyone Else",
        options: Countries.find({code: { $nin: ['fi','dk','is','se','no']}}).map(function (c) {
          return {label: c.name, iconClass: c.code + ' flag', value: c.code};
        })
      }
    ];
});

Screenshot

I guess let me know about any thoughts you have.  I did get a little extreme in the template because it was so repetitive with the loops and made the itemElementUpgrades helper, but it seems okay.  A little less clear for making changes than having it in the template directly.

Commentary in other pull request (#2).
Continuing on that... The code does exactly what you described, and I don't think it's too complicated.
I looked at the Semantic-UI approach to fixing optgroups but I don't actually think it's always going to be possible to convert <select> items fully (with all the bells and whistles), so going full-on Semantic markup is probably the only way for the fancier features, do you not think?  I might do it anyway, but will probably wait for 2.0 to be released, which looks like it might be in the next couple weeks.

But yea, take your time, no rush. :)

What I meant by "single dropdown" was eliminate the multiple files "select", "select-search"... and use only one file, one template, with options to enable search and other options. Your "deluxe" dropdown seems to do that (I haven't look closely at the code yet), so maybe using only this template could be possible.
Eliminating <select> markup and using only <div> could make things easier for sure, but I have to make sure it doesn't break anything on mobile (iOS, Android). I need to take a closer look at Semantic-UI dropdown scripts. If there is a fallback somewhere, to show the <select> instead of the <div> on any version, nothing would show up in case we use <div> only... <select> on mobile are  very different depending on the OS, so... better be careful!
If you can test your deluxe dropdown on mobile, and make sure every options work at they should, that would be great! And even better if you can test both on Android and iOS!

0.3.0 should fix all your problems, and allow to use placeholder, groups, icons and search.
I ended up removing the <select> markup, which made things a lot simpler.


Buildings

What does this PR do?
Fixes Issue #42
This PR aims at enabling to download all data of a primary feature.
It builds upon PR #45
Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Chore (refactoring code or workflow improvements)
[x] New feature (non-breaking change which adds functionality)
[ ] This change requires a documentation update

Checklist

Checks done

Codecov Report

Merging #46 (a715f3a) into main (b9543d6) will increase coverage by 0.47%.
The diff coverage is 89.47%.

@@            Coverage Diff             @@
##             main      #46      +/-   ##
==========================================
+ Coverage   61.57%   62.04%   +0.47%
==========================================
  Files          12       12
  Lines         726      735       +9
==========================================
+ Hits          447      456       +9
  Misses        279      279

Files
Coverage Δ

earth_osm/args.py
0.00% <ø> (ø)

earth_osm/config.py
100.00% <100.00%> (ø)

earth_osm/filter.py
98.36% <100.00%> (+0.11%)
:arrow_up:

earth_osm/utils.py
53.77% <100.00%> (+1.05%)
:arrow_up:

earth_osm/eo.py
76.92% <33.33%> (+1.16%)
:arrow_up:

... and 1 file with indirect coverage changes

Fantastic! @mnm-matin !
Do you think we can release a new version for the repo?


[ERROR] io.javalin.TestCustomJetty.no warnings in log file when adding static files to a custom server(io.javalin.TestCustomJetty)

Build is currently broken on Ubuntu because of this test. It looks like this is your test @mpe85:
@Test
fun `no warnings in log file when adding static files to a custom server`() {
    val baos = ByteArrayOutputStream()
    val origErr = System.err
    try {
        System.setErr(PrintStream(baos))

        Javalin.create {
            it.server { Server() }
            it.enableWebjars()
        }

        System.err.flush()

        assertFalse(baos.toString().contains("WARN"))
    } finally {
        System.setErr(origErr)
    }
}

Can you explain what the purpose of this test is? It also looks a bit brittle, it should probably check for a specific warning, not just "any warning"? I can't actually find any log.warn for static files,  so maybe this test is outdated? I will remove it for now.

Hey, the test was added because there were warnings logged when a custom server was used.
See https://github.com/tipsy/javalin/pull/597
The test just confirms that no warning is logged anymore.

@mpe85 aah, thanks, I remember now. I actually removed the dummy-server, so the warning should be there now. It's logged by Jetty though, and that logger is now disabled during startup. Not sure why this changed on Ubuntu recently, but I think it's safe to remove the test.


[5.6] Adds Ability to disable callbacks

Adds the withoutCallbacks method to disable callbacks when using factories.
eg: factory(User::class)->withoutCallbacks()->create();

Thanks for the PR. Please send to 5.7 or 5.8.


[Event Request] Codeunit::"Sales Post" - Function PostUpdateReturnReceiptLine - OnPostUpdateReturnReceiptLineBeforeLoop

We like to request the following Event:
Object: Codeunit::"Sales Post"
Function: PostUpdateReturnReceiptLine
Publisher Event: OnPostUpdateReturnReceiptLineBeforeLoop
Reason: To implement custom business logic
Where is the event placed:
if FindSet() then
repeat
ReturnRcptLine.Get("Return Receipt No.", "Return Receipt Line No.");
SalesOrderLine.Get(
SalesOrderLine."Document Type"::"Return Order",
ReturnRcptLine."Return Order No.", ReturnRcptLine."Return Order Line No.");
OnPostUpdateReturnReceiptLineBeforeLoop(TempSalesLine, ReturnRcptLine, SalesOrderLine);
if Type = Type::"Charge (Item)" then
UpdateSalesOrderChargeAssgnt(TempSalesLine, SalesOrderLine);
SalesOrderLine."Quantity Invoiced" += "Qty. to Invoice";
SalesOrderLine."Qty. Invoiced (Base)" += "Qty. to Invoice (Base)";
Event Code:
[IntegrationEvent(false, false)]
local procedure OnPostUpdateReturnReceiptLineBeforeLoop(var TempSalesLine: Record "Sales Line" temporary; ReturnRcptLine: Record "Return Receipt Line"; SalesOrderLine: Record "Sales Line");
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


CL Nightmare inconsistency

Nightmare cl is inconsistent with the ingame osrs cl, osrs shows phosani KC too
OSB LOG

OSRS LOG

whilst looking at this i also noticed that the lists on osrs are sorted alphabetically but ignore the word ‘the’, osb doesnt do this
eg nightmare on osrs is after nex and before obor, but on osb its after Tempoross and before Thermy


CommonJS+AMD support

OK, so this works for me..and the same number of tests fail with this change (21) as without. There wasn't an obvious/simple way (at least for me) to export MarkerCluster.QuickHull and MarkerCluster.Spiderfier so I didn't go there.

Please remove the dist/ changes from this commit.

K done

Hrm, can we do this a different way? I think leaflet wraps it as part of the build script rather than having the wrapping in the source all the time.
I don't like that this requires a whitespace change on every line :(

Yeah I can do that. Would it be unacceptable to use a template though? The current approach is ok for simple stuff, but won't be very maintainable for significant chunks of code. I could just add a `build/umd.tpl' or something..

Have a go, should be fine if you think it will :)

OK three times a charm?

Looks good!
I'll try check it out fully in the next week or two before I merge. Need to test loading a built version.

Cool, no worries thanks


template for dotnet new on the cli

allows creating a new project automatically without visual studio, using the command line or most other IDEs

This will require writing all-new templates and I am not a huge fan of an idea of using cli to create new projects.

bigger use case probably is that visual studio templates cant be used on all systems and this is a cross-platform engine

Problem is, I'll have to support two sets of templates for OSes I don't even use. The migration will happen, but only when Visual Studio will start supporting the dotnet new templates. Right now they claim they have that, but the support is incredibly buggy.


Adding a name to @accessible

Since 0.5.0, this causes it to generate the object extending the trait.

@hmemcpy Thanks :pray:!


Implement modal for Concentrated Liquidity Pool creation

What is the purpose of the change:

Address #2727. Implement a modal for the creation of a concentrated liquidity pool
TODOs

~Compute real poolId after pool creation~
~Compute implied value~
~Compute max tick into sendCreateConcentratedLiquidityPositionMsg tx~
~Refactor step 1 flow~
~Investigate listbox re-render issue~

Linear Task
Brief Changelog

Testing and Verifying

This change has been tested fully against the official testnet and it works as expected.

Build failed


Add required for companyId in CompaniesController on Sample project

The method for get companies by id don't sinalize id with requered. Add required for this atribut receive corectly indication.

merged


Error parsing comment before DDL statement

Very small issue:
In a script if I add a comment before DDL statement, it throws SQL script execution.
(without the comment the script executes fine)

Fixed in 0.20. Comments in DDL-statements will no longer be sent to Cloud Spanner, as Cloud Spanner itself does not accept these as a part of a DDL-statement.

Great! Thanks


Is there pretrained weights available with this repository?

Can you brief me on where this weights there and how to run this by replying this?

base pre-trained models are taken here https://keras.io/api/applications/ and custom trained
I will add the  related model training scripts


fix: explicitly using exit code 0 for successful hook exits

Codecov Report

Merging #24 (b844f4c) into beta (82c722d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             beta      #24   +/-   ##
=======================================
  Coverage   85.71%   85.71%
=======================================
  Files           2        2
  Lines          28       28
  Branches        5        5
=======================================
  Hits           24       24
  Partials        4        4

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


oic/cbor: encode cbor to/from packets on the wire

Don't allocate extra sol_vector sctrucs to hold data from cbor fields
contained in oic packets. Read and write them directly from/to the
packet payload.
To read data from oic packets the user will now get a struct
sol_oic_map_reader, intead of a sol_vector and use the macro
SOL_OIC_MAP_LOOP to loop through all elements contained in the cbor map.
To write data in an oic packet the user won't need to add all elements
in a sol_vector. The user will need to create a callback that receives
a struct sol_oic_map_writer and add all elements to it using
sol_oic_map_append function. The callback strategy was used because the
used doesn't have access to the packet and the cbor element needs to be
created in the packets before adding elements to it and closed after
adding elements.
Fixes #1080

merged.


Cleanup after importing modules into kernel

Fixes #10559

Codecov Report

Merging #10575 (7608c52) into main (521eda2) will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff           @@
##            main   #10575   +/-   ##
======================================
  Coverage     71%      71%
======================================
  Files        472      472
  Lines      28013    28013
  Branches    4697     4697
======================================
  Hits       19943    19943
+ Misses      6196     6195    -1
- Partials    1874     1875    +1

Impacted Files
Coverage Δ

...-window/debugger/interactiveWindowDebugger.node.ts
68% <ø> (ø)

src/kernels/debugger/kernelDebugAdapterBase.ts
79% <100%> (ø)

src/kernels/helpers.node.ts
39% <100%> (-30%)
:arrow_down:

src/notebooks/outputs/tracebackFormatter.ts
93% <0%> (-7%)
:arrow_down:

...ctive-window/editor-integration/codeLensFactory.ts
88% <0%> (-1%)
:arrow_down:

src/kernels/raw/launcher/kernelProcess.node.ts
70% <0%> (-1%)
:arrow_down:

...c/kernels/execution/cellExecutionMessageHandler.ts
78% <0%> (-1%)
:arrow_down:

src/standalone/api/kernelApi.ts
73% <0%> (+1%)
:arrow_up:

src/kernels/helpers.ts
63% <0%> (+1%)
:arrow_up:

... and 3 more


refactor: Tigris operations to use enums for Status

Returning response statuses for users to assert against:
DeleteResponse:
      status: "deleted"

UpdateResponse:
       status: "updated"

CreateResponse:
       status: "created"

Alternatives (need feedback)
1. Boolean in responses
Another option is to replace status: Status with success: boolean for easy assertion. Opinions?

Essentially these operations can have a success: true:

How will it work if updateMany() succeeds partially and returns num of updated rows?

2. Promise from api

DDL operations  (drop collection. create/delete branch etc.) or cache.set() can instead return a Promise<boolean>. Having them return an object later would be a breaking change.

How best to test these changes

Tests

I prefer the enum response that is nice and clear.
For CouchDB, we would have status: ok for successful responses. So it is common for users to have a generic response to check.
For partial updateMany, I think we would have to return a status for each document in the update:
[
   {doc: "id-1", status: "updated"},
   {doc: "id-2", status: "updated"},
   {doc: "id-2", status: "failed", error: .....},

]

How do we return errors for now? Also, do we have detailed errors as well?

All apis return Promises. Errors - explicit or implicit are all part of Promise rejection.


Update README to release v1.2.0

🚀New Features

Support optional Inputs style, extensions, tidy-checks,  repo-root, version

#4 PR  by @2bndy5

Add compatibility for push events

#8 by @2bndy5
#6 by @2bndy5

Support intuitive action exit code

#7 by @2bndy5

Support versions of clang-format and clang-tidy

https://github.com/shenxianpeng/clang-tools/issues/1 by @2bndy5 @shenxianpeng

🚨 Removed

Removed Cppcheck

#2 by @shenxianpeng

I was just going to update the README about the demo picture and make the table a little more readable.

Yes, it has a duplicate paragraph and the demo sections need also updated.

Before you make a new release it may be prudent to delete any previously posted comments (made by the bot) when posting new comments to the same thread.


remove-node: fix assert for ansible_version

A small fix for those who use Ansible >2.7.0. Should use same logic as other asserts.

/lgtm
/approve
thanks


[#5059]-HOTFIX Filter out duplicate collectable resources

Pull Request Checklist:

[ ] Positive Test Case Written by Dev

[ ] Automated Testing

[ ] Sufficient User and Developer Documentation

[ ] Passing Jenkins Build

[ ] Peer Code review and approval

Positive Test Case

Create couple of resources. Assing multiple users as owners of these resources.
Create a collection resource. Access the modal to add resources to collection. Verify that duplicate resources are not listed in this modal.

METRIC
VALUE

https://sonarqube.cuahsi-workstation.com:9000/dashboard?id=hydroshare-5062


Scan only happens once, then stops after the first onceover (and is terribly inefficient)

Like title.
I have a radius of 7 patrolled by 12 accounts, but instead of cycling through it, once they're done going through the radius once, they just stop, and the app needs to be restarted manually to make the scan restart from the center.
Also, the scanning pattern seems to be absurdly inefficient, with no option to ignore spawnless areas, and with scanned areas often being scanned more than once.
In practice, whereas the three accounts should be three times as fast as a single one, it actually ends up being barely one time and a half faster.
Although the main problem remains that the scan doesn't cycle and just ends after one runthrough.
EDIT: Deleting the Appdata pogo folder or rebooting didn't do anything

The program still has it quirks.  There is more variables in play.

That's just a pet peeve.
The real issue is that after scanning ONCE it stops doing so.
It's an app-breaking issue.

Same problem here, the problem started since patch 0.2.1 for me when there was no account merge so this is longer time problem for me.

Scanning starts to slow down after one full hexagon scan, circles starts to turn from green to yellow->red->gone (less and less pokemons are picked up after the color changes)
Accounts are still working as "operational" even tho they are not scanning anything
Re logging accounts makes them function normally again for a while until the problem starts again
The size of the hexagon or the amount of accounts that are linked to scanning does not make difference really, the scanning slowdown always starts happening anyway.
I'm using 11 PTC accounts, and even with different hexagon sizes, the results are always the same.
-Scanning used the work as long as the app was turned on before this bug started happening (no, these accounts are not banned)

I have found out that using scanning  in a less Pokemon dense area doesn't cause scanning slowdown, I wonder has the problem something to do with the amounts of spawn points there is for pokemons. (If I recall right the problem started for me when patch notes introduced these spawn point markers but I'm not sure.)
http://imgur.com/8X25YSP
http://imgur.com/p2ZQbL1
http://imgur.com/foqH9Uk
This is what is going on. I started taking pictures when the slowdown started, all of the accounts were working normally and being bright green at the start (pictures are from 0.3.3 but the problem is same even with one big scan in 0.3.4).
0.3.3 The accounts always start to slowdown in random amount of time and also which accounts slowed down was random also (around 80% of the accounts stopped working in 15min to 2h period)
Now in 0.3.4 the one big scan always slows down after one full scan and slowly stops scanning completely and reboot is required.

To this I'll add that sometimes logging out and back into an account my make it work again, but it breaks after a couple circles, often before even completing a radius 3 hexagon.

On one computer, I have the same issue.  It scans great once around, then slowly dies until it completely stops.  I then have to close and reopen the program.  My other computer works fine, it's been running all day.  Uninstalling and rebooting does not help.  Any suggestions?


gosnappi v0.10.3 via renovate bot

added renovate dependency tracking bot configuration (the bot runs in a separate org otg-staging)
latest otg-examples submodule
gosnappi v0.10.3

System Tests successful run in the forked repo https://github.com/otg-staging/otgen/actions/runs/3743040916


remove pytest dependency from utils.py

Description
This reverts part of a change from #463 which used pytest from utils.py without adding it as a runtime dependency. An alternative fix would be to change the dependencies.
Fixes #503
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
n/a - no new code to comment
[ ] I have made corresponding changes to the documentation
n/a - no new code to document
[X] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
n/a - no new code to test
[X] New and existing unit tests pass locally with my changes
428 passed, 2 skipped, 3 warnings, same as main
[X] I have not rewritten tests relating to key interfaces which would affect backward compatibility

Closing in favor of the fix in #532

The underlying issue has been fixed now. Thanks for submitting this earlier. You should be able to use TransformerLens without having pytest in your env now.


Application Error in Demo1

I guess this was temporarily...

Yes, I'm currently working on that. Please disregard for now


Split up Arrow Crate

TLDR rather than fighting entropy lets just brute-force compilation
Is your feature request related to a problem or challenge? Please describe what you are trying to do.

The arrow crate is getting rather large, and is starting to show up as a non-trivial bottleneck when compiling code, see #2170. There have been some efforts to reduce the amount of generated code, see #1858, but this is going to be a perpetual losing battle against new feature additions.
I think there are a couple of problems currently:

Limited build parallelism, especially if codegen-units is set low
Upstream crates have to "depend" on functionality they don't need, e.g. parquet depending on compute kernels
Minor changes force large amounts of recompilation, with incremental compilation only helping marginally
Codegen is rarely linear in complexity, consequently larger codegen units take longer than the same amount of code in smaller units

All these conspire to often result in an arrow shaped hole in compilation, where CPUs are left idle.
Some numbers from my local machine

Release with default features: 232 seconds
Release with default features without comparison kernels: 150 seconds
Release with default features without compute kernels: 70 seconds
Release without default features without compute kernels: 60 seconds

The vast majority of the time all bar a single core is idle.
Describe the solution you'd like

I would like to propose we split up the arrow crate, into a number of sub-crates that are then re-exported by the top-level arrow crate. Users can then choose to depend on the batteries included arrow crate, or more granular crates.
Initially I would propose the following split:

arrow-csv: CSV reader support
arrow-ipc: IPC support
arrow-json: JSON support (related to #2300)
arrow-compute: contents of compute module
arrow-test: arrow test_utils (not published)
arrow-core: everything else

There is definitely scope for splitting up the crates further after this, in particular the comparison kernels might be a good candidate to live on their own, but I think lets start small and go from there. I suspect there is a fair amount of disentangling that will be necessary to achieve this.
Describe alternatives you've considered

Feature flags are another way this can be handled, however, they have a couple of limitations:

It is impractical to test the full combinatorial explosion of combinations, which allows for bugs to sneak through
They are unified for a target which limits build parallelism, just because say DataFusion depends on arrow with CSV support, shouldn't force the parquet crate to wait for this to compile before it can start compiling
Poor UX:

Discoverability is limited, it can be hard to determine what features gate what functionality
Hard to determine if the feature flag set is minimal, no equivalent of cargo-udeps
It can be a non-trivial detective exercise to determine why a given feature is being enabled
Necessitate counter-intuitive hacks to play nicely in multi-crate workspaces - see workspace hack

Additional context

@Jimexist recently drove an initiative to do something similar to DataFusion which has worked very well - https://github.com/apache/arrow-datafusion/issues/1750
FYI @alamb @jhorstmann @nevi-me

I've started work on this with #2693, I think the final split will likely end up being a different from what was initially proposed based on what components can easily be separated. I next plan to split out array data, followed by the arrays themselves. This should then allow splitting out some of the heavier kernels, e.g. sort, compare, cast, etc...

If the history with the datafusion split is any indication, this work is likely to end up generating lots of PRs
You can see how @Jimexist broke that down and we tracked it in https://github.com/apache/arrow-datafusion/issues/1750 -- perhaps something similar could be applied here.
I am happy to try and review these mechanical PRs more quickly so we can get the project done more quickly

How feasible would it be to move the type definitions (such as DataType, Field, and Schema) into an arrow-types crate? Maybe this is a path to arrow2 being able to use a common type system.

I don't see an obvious reason why that would not be possible, I'm not sure how generally useful the types will be without the array definitions though...

The datafusion-sql crate only uses arrow::datatypes for example, so just depending on arrow-types there would presumably help with compilation times.

Hey, Thanks for the ping!
I think it would not benefit arrow2 directly right now as it has different declarations for Field (e.g. we do not have dict_id on it). Arrow2 also has an extension (DataType::Extension).
With that said, imo it is still a good design - there are systems that only require DataType, Field, Schema, and functionality to read them from a file. One example is a data catalog based on arrow logical types.
I think that datafusion's logical plans could also only depend on types, but I could be wrong (it depends on how List scalars are represented there?).

I think that datafusion's logical plans could also only depend on types, but I could be wrong (it depends on how List scalars are represented there?).

List scalars are represented as Vec<Box<Field> so I agree it may be the case the logical plans could depend only on type
https://github.com/apache/arrow-datafusion/blob/d16457a0ba129b077935078e5cf89d028f598e0b/datafusion/common/src/scalar.rs#L81

I've created https://github.com/apache/arrow-rs/pull/2711 which splits out the schema definitions into a crate called arrow-schema. I thought this was more clearly the logical types than something called arrow-types. PTAL :smile:

As a downstream user of Arrow, one of the things we find is that we need to fork Arrow-ecosystem crates to quickly integrate patches for missing features or bugs and I think one thing that I'm dreading is having to do that with an exploded Arrow crate, having to fork half a dozen Arrow packages, Parquet, all of the Datafusion crates, ..., seems like it'll be a royal pain.

Hi @maxburke, the intention is to follow the work that was already performed for DataFusion, and would not involve splitting the repository. So I think you shouldn't have to maintain any more or less forks following this?

Put another way, @maxburke  -- if you use the patch.crates-io directive in your workspace Cargo.toml it will automatically pull in dependent crates
For example, to change datafusion to use arrow (and a new arrow-buffers) in https://github.com/apache/arrow-rs/pull/2693 I only had to add this to the datafusion/Cargo.toml
[patch.crates-io]
arrow = {  git = "https://github.com/tustvold/arrow-rs.git", rev="f47a878"}
parquet = {  git = "https://github.com/tustvold/arrow-rs.git", rev="f47a878" }
arrow-flight = {  git = "https://github.com/tustvold/arrow-rs.git", rev="f47a878" }

We have been following this model in IOx (where we use a different upstream datafusion). Specifically, adding these lines:
https://github.com/influxdata/influxdb_iox/blob/main/datafusion/Cargo.toml#L12-L14
upstream = { git = "https://github.com/apache/arrow-datafusion.git", rev="97b3a4b37f54aaa52f8705db3e57b15ee98c24a7", default-features = false, package = "datafusion" }
datafusion-proto = { git = "https://github.com/apache/arrow-datafusion.git", rev="97b3a4b37f54aaa52f8705db3e57b15ee98c24a7" }

Is enough to get us all the datafusion crates (like datafusion-core, datafusion-expr, etc....)

Maybe we could try to split one crate out in this next release and see how easy/hard it is on downstream consumers?

I wonder if we can claim this project is complete?

Mostly, what do you think of splitting out the following and calling it a day

arrow-row - row format
arrow-ord - sort, comparison and partition kernels
arrow-arith - arithmetic, boolean and temporal kernels

We can then move the window kernels to arrow-select, and all the kernels will have been moved out of the top-level crate.
I think that would be a concrete end milestone?

I wonder is it done yet 🙏

arrow-row and arrow-arith then yes


MDBGA: Prevent users from trying to use referential actions on inline m-n's

(This issue is a follow-up to: https://github.com/prisma/prisma/issues/10498)
Currently, the Prisma Schema allows:
model A {
  id  String  @id @default(dbgenerated()) @map("_id") @db.ObjectId
  gql String?

  b_ids String[] @db.Array(ObjectId)
  bs    B[]      @relation(fields: [b_ids], onDelete: Cascade)
}

model B {
  id  String  @id @default(dbgenerated()) @map("_id") @db.ObjectId
  gql String?

  a_ids String[] @db.Array(ObjectId)
  as    A[]      @relation(fields: [a_ids], onDelete: Cascade)
}

But we don't support referential actions on m-ns for MongoDB. We should:

Invalidate this in prisma format and provide a helpful error. Perhaps link to the documentation to learn how to workaround it.
Document this limitation in our documentation. We can tell people to use an explicit join table as a workaround.

Later on, we can consider adding referential action support to this type of schema.

This appears to already be the case:

Just tested with combos of onUpdate, onDelete, Cascade and SetNull. The errors are correct.

Indeed via https://github.com/prisma/prisma-engines/pull/2561, unfortunately no issues were closed like this one or https://github.com/prisma/prisma/issues/10861.


Update stress app

Yep.

I need to rebase this on master now that we have new deps!
Either way things, were hanging in the new stress runs. I'll check if it's a client or server issue in this PR too.

Going to put this on hold as all scenarios that were added would need to be disabled.

Closing as we don't need this update.


"A communication error has occurred" after selecting 'Create a Group' button

Having a problem where after selecting the 'Create a Group' button in the local multiplayer menu, the screen fades to black followed by a "A communication error has occurred" error message.
Including this information in case it helps:
The MK7 on the modded device is not updated, and the version of the device is 11.16 - while the version of the nonmodded device is 11.17.

This could either be the network not enabled or the Mario kart 7 dump being bad

Right - when you say network not enabled do you mean the wireless of the 3ds device not being switched on?
Thanks for the quick reply, I appreciate it.

Yes that's what I mean.
(I'll be closing this issue as it's not related to kartdlphax itself. You can keep posting if you need more help)


Propagate IsProductPriceIncludeTax in CartService.MigrateCart (#886)

Please check benevolently ...

The code looks nice. Thanks!

@thiennn: Sorry about the 7a223f1 commit. I didn't think it would make it into the pull request ...

@fhebel no problem. I have revert it back.
Thank you again for your great work


Hoverover for users show them as "Player" rather than their displayname

I'd expect this to say "Matthew Test", not "Player"

This is because sync doesn't give us the display name.


[WIP] Refs #27025 -- Fixed servers test for Python 3.6.

After https://hg.python.org/cpython/rev/4ea79767ff75/, test_strips_underscore_headers fails with 'Stub' object has no attribute 'sendall'. I added that stub and now it fails like this:
Traceback (most recent call last):
  File "/home/tim/code/django/tests/servers/test_basehttp.py", line 117, in test_strips_underscore_headers
    body = list(wfile.readlines())[-1]
IndexError: list index out of range

@carljm, I wonder if you can advise on this without digging in too much? The fix isn't obvious to me but I haven't taken much time to understand the test and it's interaction with the Python changes.


Fix to write events using custom column names

As it turns out, I apparently never unit-tested actually writing an event to the log using custom column names. While the table structure got created as expected, once you attempted to actually write an event to the table you'd get an error.
Spent several days untangling an Autofac/serilog-extensions-logging mess only to discover that the problem wasn't in my code, it was in the sink. The bit that I modified. So, my code.
I'll create another PR for the local db test additions.

:+1: good catch! Will fast-track this through. It's well worth the few bumps along the road to see this sink start moving forward again. Merge ahoy!

And in the grand tradition of checking in changes at the end of the day, it's 11PM here in Florida, and I'm off to bed. I'll check it out against my day job code I'm trying to consume this from in the morning.


Stabilizing Edit Positions During Concurrent Editing

Proposal
We need to solve the problem where anchor offsets unintentionally move due to user actions during concurrent editing.
VSCode's TextDecoration feature might be a viable solution for this problem.

Apparently, this is an unsolved problem:

https://github.com/microsoft/vscode/issues/54147

And there is a code to use edit events for tracking:

https://github.com/srares13/vscode-position-tracking


figure out how delegates vs. retries

Once we have a channel pool (#105), we need to think about retries because there's a slightly higher chance that a request may fail.
We'll need to have the delegates take part in that retry dance. @adtrevor & @Lukasa  discussed this here:

https://github.com/swift-server/async-http-client/pull/105#issuecomment-531478596
https://github.com/swift-server/async-http-client/pull/105#issuecomment-531724724

Reposting the relevant part of https://github.com/swift-server/async-http-client/pull/105#issuecomment-531478596:

Make a breaking change before the 1.0.0 tag by requiring all delegate implementations to explicitly handle retries, this way a connection pool with retries can be added entirely transparently in the future.

Make no change to the current requirements of the delegate and add an an opt-in change in the future (by making a new type of delegate for retries or adding a default implementation): in this case, a connection pool could still be added, but no SemVer minor change could automatically add the retry mechanism for everyone except if the library user explicitly starts handling the retry.

I originally had a preference for the first option, but I also realise locking the API right now requires a really careful consideration of all possible cases to avoid being blocked when a connection pool is added in the future.
For instance, what are the failures the client should notify the delegate retry method about? There are the obvious ones like closed connections on idempotent HTTP requests, but there are multiple other cases: one thing we had previously discussed was error responses such as 429 Too Many Requests or 503 Service Unavailable that contain a Retry-After header. In the case of non-idempotent HTTP requests, should they also be retried if there is a connection failure before the request has been fully sent?
I see there are a number of things to take into account, which makes me wonder if there is enough time to get this right or if it would be safer to add this as an opt-in option later?
I also thought about a solution that could be a mix of the two: for now, a new retryPreference option would be added, as well as a didRetryRequest(...) method on the delegate:
public struct RetryPreference {
    /// All errors are directly transmitted to `didReceiveError(...)`
    public static let noRetries: RetryPreference

    /// If the client knows how to retry a certain error
    /// it will do this and inform the delegate through
    /// `didRetryRequest(...)`, otherwise it calls `didReceiveError(...)`
    public static let automaticRetries: RetryPreference

    ...
}

public protocol HTTPClientResponseDelegate: AnyObject {
    ...
    func didRetryRequest(task: HTTPClient.Task<Response>)
}

The kind of errors the client can retry itself coud evolve at any time, the actual error that caused the retry would be opaque to didRetryRequest whose only goal would be to reset the delegate state.
When we want to allow retry customisation in the future, it would be easy to add a new RetryPreference option, for instance:
public struct RetryPreference {
    public func custom(handler: RetryHandler, mask: RetryHandlerMask) -> RetryPreference
    ...
}

public protocol RetryHandler {
    func shouldRetryRequest(task: Task, for error: Error)
}

public enum RetryHandlerMask {
    /// Transmit all errors to RetryHandler
    case allErrors

    /// Only transmit errors the client doesn't know how to handle
    case unsupportedErrors
}

@Lukasa

I'm quite tempted by this approach, as it allows us to potentially shim a solution in by having an automatic-retry delegate that can be composed with a user-provided delegate in some way. In general, trying to do too much is likely to go badly for us.

Do you think RetryPreference + RetryHandler + RetryHandlerMask would allow this?

My honest inclination is to not worry too much about this. If we find ourselves in a place where the delegate cannot be leveraged to solve this problem, we can break the API and go to v2 to solve the issue. We're running into a lot of roadblocks right now where we are trying to solve multiple things at once, combined with a desire to get a v1 out the door, and I am beginning to think that this is just causing us to be at risk of rushing APIs for no good reason.

@Lukasa / @adtrevor so what I don't quite understand (anymore?) is why we can't decide that later.
For now, we should say: No retries and once we're ready to introduce that, we just add two delegate methods:

shouldRetry(task: Task, error: Error, responseHead: HTTPServerResponseHead?) -> EventLoopFuture<Bool> (called for the delegate to decide)
willRetry(task: Task) (called to notify the delegate that we've committed to retry)

Adding those two protocol methods with default implementations isn't breaking. For now, we could just imagine that we return false in the (non-existant) shouldRetry (and therefore the non-existant) willRetry will never be called.
To make it easy for delegate providers to have sensible retry policies, we could offer standard implementations for those that do certain things.
We could even build in the user's retry policy and also hand that to the delegate on shouldRetry. We could even make its signature shouldRetry(task: Task, error: Error, responseHead: HTTPServerResponseHead?, userRetryPreference: RetryPreference?) -> EventLoopFuture<Bool> or so.
All this isn't breaking API and should work. Am I missing anything?

@Lukasa / @adtrevor so what I don't quite understand (anymore?) is why we can't decide that later.
For now, we should say: No retries and once we're ready to introduce that, we just add two delegate methods:

I think I'm agreeing with you: I'd rather do nothing and worry about the API consequences later. I care less about whether we think we can do it without breaking: it's ok to iterate on the API once we've shipped it, IMO. Swinging for perfection the first time out the gate is excessive.
That said, your approach does seem reasonable and it seems like it could well be added without too much difficulty.

@Lukasa @weissi I agree with what you said, I think I was too much worried about not being blocked after 1.0.0, but it looks like your solution solves this @weissi. 🙂

Ok, let's hope and assume so :)


Featur Suggestion

Could you add an config, to invert the health and level,
how more level you gain, your health drain away?
Thanks a lot :)

Have you tried putting a negative number in "levelHealth"? Although you would obviously die after a certain amount of levels..

No had not tried, if possible i will try it. Would be really interesting on my survival soft HC server :)
Gesendet von Outlook für iOShttps://aka.ms/o0ukef

Von: Badgerson @.>
Gesendet: Monday, September 30, 2024 9:16:43 PM
An: ViciousBadger/level-is-health @.>
Cc: suerion @.>; Author @.>
Betreff: Re: [ViciousBadger/level-is-health] Featur Suggestion (Issue #1)
Have you tried putting a negative number in "levelHealth"? Although you would obviously die after a certain amount of levels..
—
Reply to this email directly, view it on GitHubhttps://github.com/ViciousBadger/level-is-health/issues/1#issuecomment-2383971367, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANET6NZMP25BARAXGV7NQD3ZZGPRXAVCNFSM6AAAAABPDZ46N2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBTHE3TCMZWG4.
You are receiving this because you authored the thread.Message ID: @.***>


Thanks

Very useful. It worked perfectly.

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

ID: 660b0f7c-9941-2db3-63bf-fc8a97765b1e
Version Independent ID: 5aa1e6f6-534a-05b9-c44a-1f62b24c201a
Content: Hello, Android: Quickstart - Xamarin
Content Source: docs/android/get-started/hello-android/hello-android-quickstart.md
Product: xamarin
GitHub Login: @conceptdev
Microsoft Alias: crdun

Hi @donkanmcleod
Thanks for the feedback.


Add Service Workers

Overview
Draft
Add service workers to web
References and additional details
Service Workers - Pendo/IPFS
Acceptance Criteria
TBD
Need By Date
No response
Screenshots/Mockups
No response
Estimated effort
one to two days

closing for now based on discussion this week re: MM on ios mobile and incompatibility with service workers


htmlunit doesn't register event listener on 'readystatechange'

Hi! First of all, thank you very much for this beautiful tool. It's extremely useful, and we use it all over the place in our projects.
Last week we decided to upgrade it from 2.14 to the latest version (yeah-yeah, we didn't rush with it, I know :smile: )
but we noticed that now Htmlunit behaves a bit differently than any browser:
We compose a small HTML:
<html>
    <body>
        <script>
            alert('Initial State:' + document.readyState);
            document.addEventListener('readystatechange', function() {
               alert('Changed:' + document.readyState);
            });
        </script>
    </body>
</html>

I kick it off  with python HTTP server like
python3 -m http.server

If I open http://localhost:8000 in my browser (I tested with chrome and firefox)
I will see the next notifications:

Initial State:loading
Changed:interactive
Changed:complete

Now I try to "open" this page with htmlunit:
public static void main(String[] args) throws Exception {
    final WebClient webClient = new WebClient(BrowserVersion.CHROME);
    WebClientOptions webClientOptions = webClient.getOptions();
    webClientOptions.setJavaScriptEnabled(true);
    webClient.setAlertHandler((AlertHandler) (page, message) -> System.out.println(message));

    Page page = webClient.getPage("http://localhost:8000");
    System.out.println("HTMLUnit Doc ready state: "
            + ((HtmlPage) page).getDocumentElement().getReadyState());

}

in the output I see just the following:
Initial State:loading
HTMLUnit Doc ready state: complete

So, correct me if I'm wrong, but it seems like htmlunit didn't create a listener, or it did handle readystatechange  some other way as a browser does.

Hi @QIvan,

First of all, thank you very much for this beautiful tool. It's extremely useful, and we use it all over the place in our projects.

Thanks a lot (at least if you use this for your business - think about sponsoring https://github.com/sponsors/rbri )

Last week we decided to upgrade it from 2.14 to the latest version (yeah-yeah, we didn't rush with it, I know 😄 )

Right in time, version 3 is on the finish lane (https://twitter.com/HtmlUnit)

Htmlunit behaves a bit differently than any browser

Did a quick check and i can reproduce your finding - thanks for the explanation / well done!
Will have a look...
Was this ever working in the old version?

Thank you for a quick response.

Right in time, version 3 is on the finish lane

Sweet! Will look forward some awesome new features =)

Was this ever working in the old version?

Yes, with version 2.14 it worked just fine (I didn't test on my small example, but in our project this is the place where tests become red after upgrade)

think about sponsoring

Good idea, will cosider that.
Thanks!

Yes, with version 2.14 it worked just fine (I didn't test on my small example, but in our project this is the place where tests become red after upgrade)

Strange - i have no idea why this got lost on the way.

Sweet! Will look forward some awesome new features =)

Not so many but you have to change all package names... (org.htmlunit....)

I have a snapshot build ready with your fix.... (and all the changed package names)
There is a new snapshot repo at
    <repository>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>always</updatePolicy>
        </snapshots>
        <releases>
            <enabled>false</enabled>
        </releases>
        <id>S01 OSS Sonatype snapshots</id>
        <url>https://s01.oss.sonatype.org/content/repositories/snapshots/</url>
    </repository>
</repository>

You have to change the dependency to
<dependencies>
  <dependency>
      <groupId>org.htmlunit</groupId>
      <artifactId>htmlunit</artifactId>
      <version>3.0.0-SNAPSHOT</version>
  </dependency>
  <!-- ... -->
</dependencies>

and finally adjust all your imports from com.gargoylesoftware.htmlunit... to org.htmlunit...
Hope this fixes your problem

Released with Version 3.0.0

Thank you, @rbri sorry I missed your last comments (I had a few days off and tried to be afk as much as possible :smiley:)
I'll double-check with your last release later this week (atm we put a workaround in the tests)


Added Bootstrap Classes

Removed custom styles and replaced them with Bootstrap classes. Also, removed some redundant styles. Replaced bootstrap cdn link from 4.0.0 to the latest version 4.5.2. Fixes #92

Code looks good, but style the entire leftbar including <input>(you can use grid here) tag and toggle-collapse button, the container containing room name and description, because soon I am going to create another issue to style the chat window using bootstrap, so at the end whole thing needs to be styled by Bootstrap.

I thought I shouldn't disturb the original code too much. Would it be fine if I make 'big' changes in styling?

I thought I shouldn't disturb the original code too much. Would it be fine if I make 'big' changes in styling?

Yes it will disturb code if you delete styling from style.css, solution to this problem is that you add bootstrap classes in .ejs files and don't touch style.css. Disturb style.css only if you find that some custom class name is same as bootstrap's class name. In this case add app- in beginning of any custom class, for example container class in style.css was changed to app-container in #87.

I don't understand. The left bar is already styled using bootstrap classes. What else is there?


[from qiskit] SamplingMinimumEigensolverResult and subclasses thereof when printing

What should we add?
Printing a SamplingVQE result shows a limited number of fields -it should show the full result as we do for other algorithms.
AlgorithmResult, which SamplingMinimumEigensolverResult inherits, defines a str which prints all the fields in a manner similar to a dict print with field name and value.
SamplingMinimumEigensolverResult however overrides this https://github.com/Qiskit/qiskit-terra/blob/9d336182f41533888a728609ce9e7102bb143180/qiskit/algorithms/minimum_eigensolvers/sampling_mes.py#L128-L138 and prints a limited amount of information. A user then using SamplingVQE or QAOA and printing the result, unlike other algorithm results that print based off AlgorithmResult, sees just this limited data - no info about optimizer, optimal point etc.
I could see this being removed from SamplingMinimumEigensolverResult - but maybe this was done for a nicer format of the fields it does print. The other thought is to have AlgorithmResult prepended to this; or even rework the code to be more like AlgorithResult except these chosen fields to do an improved format. Bottom line is that I think the SamplingVQE result, or other result subclasses should print all their info.

Opened by @woodsp-ibm
Original issue & discussion: https://github.com/Qiskit/qiskit/issues/9755


Update MD file on new branch 2017-22-08_03-11-53

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon.md
:white_check_mark:Succeeded

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.


[RFC][ARITH] Introduce FloorDiv/Mod for Context-Independent Simplifications

Many parts of our code base rely on integer simplifications that involves div/mod. These simplifications are in particular tricky due to the different division mode, and the dependence on knowing the sign of the operand.
DIvMod Variants
Trunc div/mod
IEEE standard integer division is truncated division, directly maps to the hardware. This is the division used by C and TVM by default. The problem of trunc div is that we usually relies on knowing the sign of both operands. For example, we cannot simplify (x * 4 + 3)/4 => x  if x can be negative.
Floor div/mod
Always round down. This is the division mode adopted by python. To simplify floordiv, we usually need to know the sign of divisor, but not necessarily the sign of dividend  floordiv(x * 4 + 3,4) => x .
Euclidean div/mod
Always ensures that the remainder is non-negative. This is the division mode used by Halide by default. Note that when the divisor is positive, Euclidean and floordiv are equivalent. But floordiv will produce a negative remainder when the divisor is negative.
Discussion
Different division mode has its own advantage and disadvantages. While Floor and Euclidean mode enjoys better invariance in simplification. However, we don't really want to emit those operators in the low-level code, as we cannot find direct instruction correspondence. So ideally we will need to lower them back to truc div/mod after simplification is done, in which case we still want to know the sign of the operands. In summary, the two ways are:

Always use trunc div, but need to know sign of the operands during every transformation
Use floor/euclidean div, no need to know the sign of dividend during simplification, but need to know the sign when lowering back to trunc div.

We also need to be aware of potential risk of over-simplification (simplify something to a floordiv where we don't know the sign of dividend)

To give a concrete example about the difference, consider the following case:
for (x = 0; x < 100; x++) {
   // trunc division
   a [(x * 4 + 3)/ 4] =  xyz.
}

(x * 5 + 3)/4 can be simplified to (x * 5 /4) , if we setup the simplifier, with currect context(x in [0, 100]). However, there can be cases where we forget to do so in our code, i that scenario the simplifcation cannot be done. If instead we use
for (x = 0; x < 100; x++) {
   // floor division
   a [floordiv(x * 4 + 3, 4)] =  xyz.
}

(x * 4 + 3)/4 can be simplified to x in the analysis. However, to get the most efficient version of the code. We need to lower the floor division to x  knowing that x is non-negative. The context information is only needed during the floor division lowering.
In summary, using trunc div during analysis requires m
ore information each time we transform it, using floor/euclidean div makes simplification easier, but still requires us to provide context information to most efficiently lowers to trunc div/mod.
Proposal to be Discussed: Adding Floor Div/Mod
It might be helpful to encourage the use of floor div/mod for integer analysis while providing an effective way to lower to trunc div when necessary. To avoid confusion between division mode, I propose we add an explicit floordiv/floormod node and operator to the IR.
The reason to choose floordiv/mod over Euclidean is mainly due to floor is more common(used by python) and easier to understand. The difference in behavior happens when the divisor is negative. In most cases, we will know the sign of divisor.
The original truc div/mod simplification will be kept around for a while, but we will encourage most index calculations to use floordiv/mod, and provide rewriter to rewrite truc div/mod into floor version when the sign of the dividend is positive
Embed more information in the IR
Besides introducing floor div/mod to make the transformation context independent. We can also start to think about embedding more information in the IR.  For example, in the case of (x * 4 + 3) / 4, if we directly embed the bound information about x inside the Var itself, we can directly do the same analysis without manually injecting the context information to the analyzer. This is an interesting design trade-off that we might want to consider in the future.

cc @dmlc/tvm-team

Can you clarify the example above? the simplifications seem invalid to me, how can you drop the addition by 3?

Sorry it should be (x * 4 + 3) / 4=>x

@derisavi @sgrechanik-h @yzhliu @wweic  @merrymercy would be great to also get your thoughts about this.

I think Euclidean division should be preferred since it is used in Halide and smt-lib, which I think are more relevant than python (e.g. it will be easier to borrow algorithms from Halide and to use SMT solvers to perform some proofs if we ever need it).

I agree that Euclidean and Floor could be an interesting tradeoff.
When possible, I want to be able to make most of the proofs internally. This is especially true with respect to div/mod simplifications. Given that the division/mod we will ever encounter will most likely have positive divisor, they are just fine and can be viewed as Euclidean if necessary.
I think the main reason to choose floordiv (along with trunc-div support) was to have fewer surprises. For the same reason, we default Div to serve the same behavior as C's division, so the developer won't get confused. Given that floordiv and euclidean div will give us a similar effect for the things we care about, being able to match python's semantics and easy to understand would be a plus here, and that is why I think FloorDiv/Mod should be preferred.

Not sure whether the decision has already been done but I'll put my two cents here.
You have covered all the tradeoffs. Since in most cases, the divisor is positive, I believe the important move was to add one of floordiv or euclideandiv (which you are doing now). The difference between floordiv and euclideandiv will not have drastic effect on how much we can simplify the code.
Nevertheless, IMHO, we should choose Euclidean for the followin reasons:

it's more important to care about ease/strength of simplification and analysis and less about familiarity.
familiarity is a subjective matter and it depends on the audience. The audience of this operator (and in general Halide IR) are mostly people who are developing the core compiler. In the long run, this audience cares mostly about what's more powerful in terms of analysis, simplification, and interoperability with other libs and I expect people to become familiar (if they are not already) with euclideandiv very quickly.

Thanks, @derisavi @sgrechanik-h for putting in your thoughts. Let me try to summarize the trade-offs dimensions so far.
Power of simplification

They are going to be similar because in most cases divisors are positive.
Floordiv and euclidean div are the same when divisors are positive.

Consistency with Existing Choices

Floordiv is used by python, which means we could in the future change operator overload in python to make use of it for better consistency.
Euclidean div is used by Halide and smt-libs.
Floordiv seems was used by isl and MLIR.

Developer familarity
Floordiv is relatively easier to explain, and can be written as floor(a/b). Low-level compiler developers might be able to understand both after some time.
Cost of Lowering
Need to think about the cost of lowering:

When both signs of dividend and divisor are known, can lower to trunc div
When sign of divisor is known, floordiv and eucildean div are can have the same rule.
A bit unclear when the sign of divisor is unknown, which I hope would never happen, but need to discuss the rules.

To summarize the discussion so far. I think everyone agrees that we should introduce one of FloorDiv or EuclideanDiv, and this is a pretty close call (see the technical summary above).
@derisavi @sgrechanik-h suggested eucildean div for the reason of being consistent with Halide smt-libs. My understanding atm is that while we have different thoughts, we mostly agree that adding either floordiv or eucildean div would be a good improvement. We just need to decide which one. I am still slightly lean toward floordiv given that it is conceptually easier and consistent with python3, MLIR, but would still love to hear further thoughts if we have a strong opinion against the choice.

+0.5 to floordiv given the familarity and the usage in isl and MLIR.

I also prefer floordiv as its use in MLIR.

https://github.com/dmlc/tvm/issues/3977

Move the thread to https://github.com/dmlc/tvm/issues/3977


[FEATURE]: Add option to use updated logo

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe.
I wish I had the option to display the updated logo from the PayPal brand identity guide in the PayPalButtons component.  I see the logo included in the buttons in the PayPal Javascript SDK documentation, however the addition of the PayPal logo on the buttons would be a great option to include as props for the PayPalButtons Component:

Developers and designers seek to stay on trend with the latest logo available from company brand guides, and allowing for either customization or updating the logo on the PayPal Buttons component would be a great addition to this package.
Describe the solution you'd like
Ideally we would have props passed to the style object to allow for either this logo:

Or this logo:

Describe alternatives you've considered
We considered adding the logo manually and placing it on top of the button, however it would be much easier to allow users the ability to decide which PayPal logo to use, especially since the updated logo from the brand guide isn't currently the one that appears on the buttons.  Adding more options would increase the usage of this npm package and allow for more customization on the user side.
➕ Anything else?
No response

Bump

Bump

Sent this request to product/engineering for advice/solution.

@michaeljamie are you referring to this react component which only has “PayPal” instead of “:pp: PayPal” https://paypal.github.io/react-paypal-js/?path=/docs/example-paypalbuttons--default

Thank you @devchristina .  That's correct.  It would be great if we could update those components to use the “:pp: PayPal” icon/logo (possibly as a prop) if possible.  Thanks for looking into this 👍

Bump

Bump

hi @michaeljamie thank you for reaching out!
Our team took a look and turns out those screenshots on the developer docs are from the previous version of the PayPal SDK, v4 or checkout.js. That page has been up for so long and we've never noticed!
Unfortunately there isn't a configurable way to bring those logos to the v5 version of the SDK. We do have a project planned in the near future to do the following:

update styling of the buttons
expose more options for styling to merchants
more configurable labels

We'll bring up adding in logos too or making a configuration option for turning them on.
In the meantime, we are going to update those screenshots on the developer documentation site to match what merchants will actually see when they render the PayPal JS SDK.
Thanks again!


Old tag in goreportcard.com

Hello,
I don't understand why a old tag of my repo is reported in goreportcard.com ?
https://goreportcard.com/report/github.com/smutel/terraform-provider-netbox => v1.3.0
This tag has been released one year ago ...
How to use the last tag ?
Thanks.

Hi @smutel
I think Go treats anything above v1 differently:
https://go.dev/doc/modules/release-workflow#breaking
You may be able to update your go.mod to:
module github.com/smutel/terraform-provider-netbox/v4

I updated the go.mod and I click on the refresh button.
However the version is still 1.3.0 in goreportcard.com.

@smutel Not totally sure but you may need a v4 dir:
https://research.swtch.com/vgo-module

In this case, v2.0.0 is created not by forking the whole tree into a separate branch but by copying it into a subdirectory. Again the go.mod must be updated to say "my/thing/v2". Afterward, v1.x.x tags pointing at commits address the files in the root directory, excluding v2/, while v2.x.x tags pointing at commits address the files in the v2/ subdirectory only.

We are basically doing the same thing as pkg.go.dev

It would be nice if we just use the latest github release. I had a typo on my v1.0 which is the only thing that keeps me from a perfect score and it seems ott to make a new go mod version just for that.

still facing this issue


Improve observation by providing more tracing tags

Opentelemetry defines standards for specifying and providing proper information for tracing spans (so called tags).
This PR improves the observation by providing proper opentelemetry defined tags.
Fixes #2609
As discussed in the issue, the remote service name is not explicitly set, because optentelemetry defines it as the name of the broker or service the message will be sent to, which would be a list of multiple brokers in the kafka service. For that reason, users are encouraged to override KafkaTemplateObservationConvention and KafkaListenerObservationConvention if they want it to have a unique name instead of the cluster-id.
Note: Some informations are not available on the time the observation in the KafkaTemplate starts and would be null. Therefore I have not included in this PR, if you have suggestions on that feel free to share.

@cmergenthaler Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@cmergenthaler Thank you for signing the Contributor License Agreement!

Please also fix the checkstyle problems; run ./gradlew clean check.

Thanks for the reviews, @garyrussell & @artembilan!
I have updated the files as you said. I also moved partition and offset to high-cardinality keys as the values change a lot and while load testing my service we have encountered memory issues when having them as low-cardinality (metrics also get them as tags).
I think having different implementations that the user can use would be very helpful - maybe on all related spring projects (e.g. spring-data-mongo).

I just took another look and some of the new tags are high cardinality (..._PARTITION, ..._OFFSET) but they are in the ListenerLowCardinalityTags enum.
Also, with high concurrency, the client id can be high cardinality too; each child container gets its own client id.
My preference is to make this an alternative observation, even when these cardinality issues are fixed. But, yes, the code to create the context will have to remain.

@cmergenthaler Hello, if you don't mind, i want work on this PR, please give me Developer role to push code, thanks.

@Wzy19930507 ,
thank you for considering!
This PR is one year old, so might be better to start from scratch, even if you will use same code base from this PR and mention original author.

Superseded by #3169


Updating POC URL

Signed-off-by: Madia Wilder<EMAIL_ADDRESS>

Just before merging - do we def want this to be PoC still?

Updated the url to app.rkvst.io


Support coverage in Mojo::Template

As requested in #956, this is an issue to get Devel::Cover support for Mojo::Template.
Since the original pull request, I've done some further experiments. The following patch is enough to make Devel::Cover give correct coverage for template files:
diff --git a/lib/Mojo/Template.pm b/lib/Mojo/Template.pm
index 8f17b40..f0a7382 100644
--- a/lib/Mojo/Template.pm
+++ b/lib/Mojo/Template.pm
@@ -167,6 +167,9 @@ sub process {
     return Mojo::Exception->new($@)->inspect($self->unparsed, $code)
       ->trace->verbose(1)
       unless $compiled = eval $self->_wrap($code, @_);
+    no strict 'refs';
+    *{$self->namespace . "::" . Mojo::Util::md5_sum $self} = $compiled;
+    use strict 'refs';
     $self->compiled($compiled);
   }

@@ -186,7 +189,7 @@ sub render { shift->parse(shift)->process(@_) }
 sub render_file {
   my ($self, $path) = (shift, shift);

-  $self->name($path) unless defined $self->{name};
+  $self->name($path);
   my $template = slurp $path;
   my $encoding = $self->encoding;
   croak qq{Template "$path" has invalid encoding}

This is just for illustration, I'm aware that there are quite a few issues with the patch.
Using the above patch, the sub name in exceptions is still __ANON__, so the sub isn't named.
So basically, for coverage to work two things are needed:

Correct #line directives in the template code (e.g. referencing the correct line number and file name).
The anonymous sub that the template is compiled into, needs to be accessible from the symbol table upon exit.

If injecting the sub into the symbol table is a performance/memory issue, this could be dependent on an environment variable as suggested by @jberger.

I know you said that you're aware of the shortcomings of the example patch, but i think it's worth pointing out that the whole approach doesn't work because it results in a serious memory leak.

Yes, I can see how my patch will result in a memory leak.
However, the anonymous sub needs to be available when the program exits for Devel::Cover to see it, so there is no way around leaking it.
That basically leaves the MOJO_TEMPLATE_COVER solution as the only viable option, if this feature is desired?

If a memory leak is required, then i'm not sure we should be doing this at all.

An env variable like MOJO_TEMPLATE_COVER results in a lot of technical debt, i just don't see Devel::Cover support being worth it.

For our part, I think that this is one of our most wanted features, that is missing from Mojolicious.
If it isn't the most wanted feature, it is at least the feature that we've spent the most time discussing how to implement. And our previous best suggestion (generating template code, save it to a file, and then use it), is even more of a kludge.
FWIW, I've prepared a patch to make EP/EPL templates use the file path instead of the name: af9743db3b0f76e809b863f2f5a0393b72110003
I've also prepared a patch which makes the sub accessible from the symbol table if MOJO_TEMPLATE_COVER is set:<PHONE_NUMBER>27db0bc96a8d6e82cacf1609cb05d3

For now i'm afraid i'll have to give this feature a 👎 vote, because there's no clean way to implement it.

Something that has not been mentioned yet is support for templates in DATA sections and inline templates, which i think are important parts for making this an officially supported feature.

I feel that this feature could bring tremendous value even with only being supported in file templates. (And a disclaimer could be added in the documentation, saying that it's only supported on those.)
We have the use-case, that we have a rather large codebase, and would like to make sure that our testcases exercise as much of our code as is possible. Using Devel::Cover, we can get a pretty good idea if we've covered all the code-paths in our testing.
However, since we cannot get coverage information on templates, they can easily not be fully covered by our tests without us knowing. This relatively often comes back to bite us, when the some un-covered part turns out to produce some sort of error when it is run. A large part of these sorts of bugs can be avoided more easily with the ability to see coverage. (Hence why we've been discussing it back and forth in the office for quite a while.)

There are many other solutions worth exploring. Like changing the names assigned in Mojolicious::Plugin::EPLRenderer a little, to make them more suitable for these kinds of use cases, and then having a hook somewhere that allows for the monkey patching hack to be added on demand.

Actually, i bet it's already possible with a clever prepend value.
my $prepend = 'no strict "refs"; *{"Mojo::Template::Sandbox::" . Mojo::Util::md5_sum __FILE__} = __SUB__;';
plugin EPRenderer => {name => 'ep', template => {prepend => $prepend}};

Something that has not been mentioned yet is support for templates in DATA sections and inline templates, which i think are important parts of making this an officially supported feature.

How would you find the originating line for an inline template? It quite hard to come up with a correct originating line-number for code like:
$c->render(inline => EOF);
Content
ABC
EOF

$c->render(inline => 'Content\nABC\n');

And completely impossible for string variables.
I believe that it is feasible for __DATA__ templates. However, since the line numbers needs to be correct, it also means that error messages will be referencing the line number from the originating file, instead of the line number from the start of the template. So Mojo::Exception will also have know about this.

Actually, i bet it's already possible with a clever prepend value.

That actually works, if af9743db3b0f76e809b863f2f5a0393b72110003 is also applied (and then only for file based templates).
I was afraid that it would hit pjcj/Devel--Cover#72, but it seems that the code needs to call the __SUB__, in order to trigger that bug.

@ksmadsen You'll have to come up with a new consistent naming scheme for log messages then, because that patch messes things up quite a bit.
[Fri May 13 17:51:55 2016] [debug] Rendering cached /Users/sri/repo/mojo/lib/Mojo/../Mojolicious/resources/templates/mojo/debug.html.ep
...
[Fri May 13 17:53:19 2016] [debug] Rendering template "foo/bar.rss.ep"
...
[Fri May 13 17:53:19 2016] [debug] Rendering cached template "foo/fun.html.ep" from DATA section

Instead of af9743db3b0f76e809b863f2f5a0393b72110003, the following gives the right filenames in the line directive and the right template name in the debug messages:
diff --git a/lib/Mojolicious/Plugin/EPLRenderer.pm b/lib/Mojolicious/Plugin/EPLRenderer.pm
index 9d8df28..3c5fd41 100644
--- a/lib/Mojolicious/Plugin/EPLRenderer.pm
+++ b/lib/Mojolicious/Plugin/EPLRenderer.pm
@@ -38,7 +38,8 @@ sub _render {
       # Try template
       if (defined(my $path = $renderer->template_path($options))) {
         $c->app->log->debug(qq{Rendering template "$name"});
-        $$output = $mt->name(qq{template "$name"})->render_file($path, @args);
+        $$output = $mt->render_file($path, @args);
+        $mt->name(qq{template "$name"});
       }

       # Try DATA section

The patch for lite_app.t from af9743db3b0f76e809b863f2f5a0393b72110003 is still needed to make the tests pass.

Crap... Too quick. That one doesn't work if the template doesn't compile in the first try.
Then I see no other solution than having a path attribute in Mojo::Template? Passing the path/name around within the functions in Mojo::Template seems like it would complicate things unnecessarily?

@ksmadsen Please stop with the hacks, i want a clean solution like a new naming scheme.

@ksmadsen Please stop with the hacks, i want a clean solution like a new naming scheme.

Said differently, it is ok if we look at rearchitecting a few things here.

Looks like this issue went stale.


⚠ ClamAV has degraded performance

In e164a08, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 68 ms

Resolved: ClamAV performance has improved in 4fbe850.