Regenerate test cases from MATLAB

@sebastien-villemot Do you have access to a MATLAB installation on a big endian machine (like old Mac on PPC or even Solaris)?

@gsjaardema @papadop Same question.

@tbeu No, sorry.

No, nothing here.
On Tue, Feb 23, 2016 at 6:27 AM, tbeu<EMAIL_ADDRESS>wrote:

@gsjaardema https://github.com/gsjaardema @papadop
https://github.com/papadop Same question.
—
Reply to this email directly or view it on GitHub
https://github.com/tbeu/matio/issues/25#issuecomment-187698515.

Sorry, nothing here too....

MATLAB R2006b is the first version that supports HDF5-based MAT-files
MATLAB R2007b is the latest version that supports PPC-based Macs


Disable Autorun not work

Hi pro,
I config autorun is false but not disble tracking.
I use Flow router + React.
Thankyou!

Sovled, I am update version 2.1.3
Thank :)

Glad you noticed the update with the fix.


label changes to organism identification data terms

The presence_data and raw_data templates are constructed so that terms in the resulting module include the organism, assay, and specimen type in their labels and definitions e.g. 'Plasmodium in umbilical cord blood by microscopy assay datum'. However, some similar terms are already in the ontology whose labels and definitions do not mention the specimen type. For example, EUPATH:0023004 is 'presence of bacteria by microscopy' even though the template gives it the label 'presence of bacteria in blood by microscopy assay'. EUPATH:0010599 is another term whose label does not mention the feces/stool sample. (This is the result of changes in ClinEpi project hierarchies.) I propose allowing the template to overwrite these labels and definitions to avoid inconsistency or confusion.

Add the old label as alternative term if the meaning is same.

We would like to add the labels of organism identification data used in the ClinEpi in the ontology as alternative labels. However, organism identification data in different sample types used same labels. For example, we have four 'Salmonella, by multiplexed qPCR' terms in clinEpi, detected from 4 different sample types, 'Salmonella in pleural fluid|Salmonella in induced sputum|Salmonella in lung aspirate|Salmonella in nasopharyngeal/oropharyngeal swabs'. Would like to know how these terms are deal with in download file. We may use same approach in the ontology.


Cannot be used in 2D rendering pipeline

Code error using 2D rendering pipeline, version 2022.3.71

Works fine for me 22.3.34


Generic pattern emission refactoring

Concrete and generic metadata builders shared a base class, but ever since generic metadata patterns became true-const with a layout distinct from instantiated metadata, the generic case no longer uses most of the functionality of the base class.
This is a refactoring in preparation for giving concrete resilient classes a proper true-const pattern.

@swift-ci Please test

@swift-ci Please test source compatibility


Basic (not backed) native Enums are not supported in casting or validation

Laravel Version: 8.78.0
PHP Version: 8.1
Database Driver & Version: Mysql 8.0.27

Description:
Backed enums are working just fine, like
enum Demo: int
{
    case AAA = 1;
    case BBB = 2;
    case CCC = 3;
}

or
enum Demo: string
{
    case AAA = 'AAA';
    case BBB = 'BBB';
    case CCC = 'CCC';
}

In my case I need to use strings, but second option is repetitive and easy for typo in long lists.
Simple (not backed) enum are simpler and suitable option:
enum Demo
{
    case AAA;
    case BBB;
    case CCC;
}

But based on changes in #39315 and #39608 it uses from() method on Enum to find value, which does not exist on non-backed enum.
Call to undefined method App\\Enums\\Demo::from()
Is there any reason for that? Is it on purpose or bug? Sure that I can just give up on enums and use strings, but non-backend enums are also helpful. In my case I want to create enum in Lighthouse to pass it directly to GraphQL schema. It's good practice to use same enum definition in both PHP and graphql schema, to avoid bugs, but currently it's not possible with Laravel/Lumen and non-backed enums.
For tests purposes I changed some lines here
illuminate/database/Eloquent/Concerns/HasAttributes.php
protected function getEnumCastableAttributeValue($key, $value)
{
    if (is_null($value)) {
        return;
    }

    $castType = $this->getCasts()[$key];

    if ($value instanceof $castType) {
        return $value;
    }

    // HERE
    return $castType::cases()[array_search($value, array_column($castType::cases(), 'name'))];
    // return $castType::from($value);
}

Sure it's just quick and ugly fix, code could by nicer and this will broke backed enums, but it worked just fine for my case.
But problem will maintain also in other places, like validation:
Illuminate\Validation\Rules\Enum
public function passes($attribute, $value)
{
    if (is_null($value) || ! function_exists('enum_exists') || ! enum_exists($this->type) || ! method_exists($this->type, 'tryFrom')) {
        return false;
    }

    return ! is_null($this->type::tryFrom($value));
}

Validation uses tryFrom, so same problem.
I can make this on app Level by making Trait (and use it in every enum file) that will mimic ::tryFrom() and ::from, but trying to reproduce PHP methods feels to much like hacking for me...
So to summary, shouldn't this be supported by Laravel itself?
I really do not see any good point of making enum like
case DEMO = 'DEMO';
or
case DEMO = 'demo';
Thanks for reading :)

Laravel Version: 8.3.1

This Laravel version doesn't supports Enums. Please update Laravel and try again. If the issue persists please try a support channel first:

Laracasts Forums
Laravel.io Forums
StackOverflow
Discord
Larachat
IRC

@driesvints Like I said, backed enums are working just fine. I simply typed wrong version in this Issue, my bad. I also showed source code from illuminate/database which is coming from new versions that supposed to support Enums.
So please reopen issue since fixing by upgrade does not apply here ;)

Hey @chojnicki. This seems like a feature request to us and we're open to PR's if you want to send one in. Thanks

@driesvints Reproduction is pretty straight forward, same as in issue. Just trying to cast enum, like described in Laravel documentation.
app/Enums/DemoEnum.php
<?php

namespace App\Enums;

enum DemoEnum
{
    case A;
    case B;
    case C;
}

app/Models/Demo.php
<?php

namespace App\Models;

use App\Enums\DemoEnum;
use Illuminate\Database\Eloquent\Model;

class Demo extends Model
{
    protected $casts = [
        'demo' => DemoEnum:class,
    ];
}

Now trying to accessing this attribute
$demoModel->demo; // enum supposed to be cased
will lead to
Call to undefined method App\\Enums\\Demo::from()
Similar thing with validation, but there will be error about tryFrom.
But if I change my enum to backed one (like described in first post), everything works fine.
Like I said, everything is caused by relying on from() and tryFrom() that are not available in PHP for basic enums, just backed ones.
So I do not feel like it's really feature request, because enums supposed to be already supported, but they are not fully. Again, in Laravel documentation, PRs, Laravel news etc everywhere it stays that Laravel supports enums, but that's not 100% true, that's just 66% true because there are three types of enums: basic, backed strings and backed integers, while Laravel works with last two ;) Hope I described this well enough.
Or maybe I'm missing something and it supposed to works with basic as well (even that I do not see this in illuminate code)?

I'm sorry but I'm going to leave it at this. Feel free to PR something if you really believe things can improve.

@driesvints thanks for fast replies. Sorry to hear that but really no any explanation just "leave at it is" (meaning broken)?
Closing issues without resolving them is just like swiping under carped :( I get that this is open source project, and I know that I or someone else can try to make PR, but this does not mean it is resolved in any way. Also less people will be willing to do PR's to issue that's is closed and forgotten by that. Any issue in any repository can be resolved by "do a PR" and close, but what's the point of issues then? My comment is offtopic, but I spend a lot of time trying to debug that and to write that issue with as much info I could to help address issue. All for nothing, just so it can be closed to meet some Issues (0) goal by maintainers? Well, I can just hope that it will be fixed in future, maybe if more people will have similar problem. Anyway, have a nice day :)

@chojnicki only BackedEnum is supported at the moment. Feel free to open a PR to introduce support to regular Enums.
Thanks.


Allow urllib3 2.0.0 to be installed

Describe the feature
There is a new version of urllib3 (v2.0.0) that can't be installed in projects that use botocore because, in the setup.py file, it has the version restriction urllib3>=1.25.4,<1.27.
Use Case
So other projects that want to upgrade to urllib3 2.0.0 can without being blocked by the botocore library.
Proposed Solution
No response
Other Information
No response
Acknowledgements

[ ] I may be able to implement this feature request
[ ] This feature might incur a breaking change

SDK version used
latest
Environment details (OS name and version, etc.)
all

Hi @epicserve, thanks for reaching out. The pin is currently intentional while we wait for the major version bump to stabilize. We intend to move the pin shortly after Requests does to ensure we're not negatively impacting users.
We'll keep this issue updated and feel free to follow along in psf/requests#6432 as well if you like.

I started getting this error message in my Lambda logs after doing a recent deploy which I believe is pulling in urllib3 >=2.0.0
Runtime.ImportModuleError: Unable to import module 'app.lambda_handler': cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_' (/opt/python/urllib3/util/ssl_.py)

which is coming from https://github.com/boto/botocore/blob/master/botocore/httpsession.py#L52
try:
    from urllib3.util.ssl_ import DEFAULT_CIPHERS
except ImportError:
    # Defer to system configuration starting with
    # urllib3 2.0. This will choose the ciphers provided by
    # Openssl 1.1.1+ or secure system defaults.
    DEFAULT_CIPHERS = None

which is concerning because urllib3 removed DEFAULT_CIPHERS in https://github.com/urllib3/urllib3/pull/2705 which is part of v2.0.0
What I'm not understanding is why the ImportError isn't being caught?

Hi @jplock, this was already resolved in https://github.com/boto/botocore/pull/2924. You'll likely want to ensure you're not upgrading to urllib3 2.0 for the time being or add a more recent version of Botocore to your Lambda as detailed here.

Same as @jplock here. I started seeing this error today on a lambda after I made deployment. Tried rolling back but error remained.

Hi @jplock, if you're still encountering this error you'll want to add this to your dependency closure in the same way you're specifying the dependencies you've listed above. Make sure this is the last entry:
urllib3<2

One of your dependencies is pulling in the latest version of urllib3 which contains a handful of breaking changes.

requests 2.30 added support for urllib3 2.0: https://github.com/psf/requests/releases/tag/v2.30.0

As of requests-2.30.0, urllib3-2.0* is already allowed. This package is now blocking urllib3-2.0* upgrade for Gentoo users.

Hi @mgorny, we're aware that Requests has moved their pin. We've seen there are a number of breaking cases in common workflows for AWS customers with the introduction of the new major version which has slowed how quickly we might move towards using urllib3 2.0 by default.
Botocore is properly pinned for version support at the moment to limit unnecessary blast radius. Gentoo is free to move the constraints for their distribution of botocore if there's a strong need for urllib3 2.0 migration. I don't think that can reasonably done here with the auto-upgrade behavior of PyPI though.

Could you at least fix the test suite to pass with urllib3 2.0*, please? IIUC the mocks currently rely on some internal behavior that's no longer correct.

Same: botocore 1.29.102 requires urllib3<1.27,>=1.25.4, but you have urllib3 2.0.2 which is incompatible.

The conflict here with what a common package like requests has pinned, combined with the prolific release cadence of botocore, makes this especially inconvenient for projects using poetry. The resolver there is almost comically bad at traversing the many dead ends this produces in resolving the dependency graph.
https://github.com/python-poetry/poetry/issues/7858
https://github.com/python-poetry/poetry/issues/8074

Hi @ahvigil, to quickly clarify, Requests does not have urllib3 2.0 pinned. I provided how you'd do this with poetry in the primary Requests thread.

Hi @ahvigil, to quickly clarify, Requests does not have urllib3 2.0 pinned. I provided how you'd do this with poetry in the primary Requests thread.

yes thats the suggested workaround in the linked poetry issues as well. Doing so nudges poetry in the right direction, reduces the dependency search space, and everything works great. Its just an odd thing to have to do to avoid combinatorial explosions for two pretty commonly used packages. Obviously botocore devs aren't responsible for how poetry performs for this one weird edge case but just thought I'd make a note of it.

Hi team, please forgive me bumping this to draw attention to https://github.com/boto/botocore/pull/2984. This is my attempt to move us closer to being able to support urllib3>=2 by addressing the failing unit tests around the "100 Continue" code path (which are catching a legitimate issue). It ought to also allow urllib3 to stop skipping these tests in its CI since https://github.com/urllib3/urllib3/pull/2565 was merged.
Feedback appreciated! Hopefully it is of high enough quality to be iterated on and merged, or perhaps Amazon is exploring a different approach internally.

I can't upload anything to s3 from aws lambda because this isn't fixed.

@mgorny, providing a quick update that the test suite should be compatible with urllib3 2.0 now. We removed the upstream patch in urllib3 with https://github.com/urllib3/urllib3/pull/3098. Please let me know if you're still seeing issues.

Thank you. I can confirm that the tests now pass w/ botocore 1.31.15 and urllib3 2.0.4.

Is there anything else that is needed, or can we upgrade to urllib3 v2?

We've been allowing urllib3-2 in Gentoo since 2023-05-19 and we haven't had any reports of problems. That said, I have no clue how many people actually use these packages.

any update on this? Need to install a compatible version of botocore with urllib>2.0
@tjni @nateprewitt @ahvigil

Hi @mridul97-dev, to clarify: I'm working on packaging this in nixpkgs, which builds and distributes Python packages from source independently of PyPI, which offers us the possibility to patch botocore to lift the version cap on urllib3. I believe that @mgorny is in a similar situation with Gentoo. We can do this in part because our part of the world is smaller (e.g. for me, just nixpkgs users).
If you are using stock poetry, you'll need to rely on the maintainers of this package (e.g. @nateprewitt) to lift the restriction when they feel it is ready for a wider audience.

You can currently install urllib3 2.0.x with boto3/botocore/awscli and it will work as we've unblocked Gentoo and nixpkgs to do. The primary reason that the pin is still in place for general python installations is because urllib3 2.0 has compatibility issues with Amazon Linux 2 and some versions of AWS Lambda. These are detailed in the urllib3 migration guide here.
Because of the way pip works by always choosing to install the latest version of packages, moving the pin for urllib3 will unexpectedly break everyone not pinning urllib3 or using OpenSSL 1.1.1+. That's something we take very seriously with AWS products and try to ensure never happens. We're still working on a plan to smoothly migrate this customer base, but don't have any immediate timeline.
For the time being, users are free to install urllib3 2.x after they've installed boto3/botocore/awscli, and should be able to use each package. Something like this would work in automated environments returning a successful response code. We realize it's not ideal, but is the most tractable solution we have currently that maintains stability:
python -m pip install boto3==x.y.z
python -m pip install urllib3==2.0.4 --no-deps

Hi @nateprewitt, @tjni  thank-you for providing a workaround for this. Allow me to explain my usecase - currently we use poetry for all dependency management - we came upon a problem of backoff_max parameter which only gets added within a patch of urllib3=2.0.x, but updating this version within poetry is resulting in failures as botocore is complaining that it can only go as high as urllib<1.7.
As an alternative workaround, i took out urllib3 from the poetry env and tried installing it separately with pip install urllib3==2.0.4 but this resulted in another import error cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_'.
From what i can see, neither poetry OR poetry+pip seems to be agreeing with the library installation - which is worrysome at our end.

this resulted in another import error cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_'.

You may want to ensure you've updated Boto3 and Botocore in your poetry lock file before installing urllib3. This issue was patched in April with botocore 1.29.123.

This is going to start to become a real problem as libraries start to insist on urllib 2.x - google-auth just has for example.
The hack you provide with --no-deps does not work in environments where you're installing requirements from requirements.txt.
We're going to end up stuck on old versions of dependencies, and someone will miss a security fix because of it.

wait, this STILL hasn't been fixex? :/

I'm just surprised they haven't vendored it to avoid version conflicts like this..
They did it with requests forever.
I realise this comment is not constructive 'to maintainers' because my aim was to set expectations here.
This project is dying and it's no person's fault, it's just the way Amazon treats Python (or rather avoids it) and the good folks trying to cover all the python needs need at least 100 more people to help them - i'm seeing this across all of AWS consulting with government, FSI, startups, banks, everyone feels this pain for at least 5 years and it get's longer each time.
We see current stable python version only make it into Lambda runtimes when 3 releases behind, for a while it was 2 (3.7 came when we had 3.9), recently we got 3.10 when we were 4 behind and now still behind, almost 2 versions behind, at the time it was released!
Don't get me started on pSpark (Glue EMR Sagemaker) or anything else, the Lambda was a good new story, we got 3.10, forgetting 3.12 is pretty much ready, we actually got 3.10 which is a 'W' - the other python bits across AWS are worse than this good (actually bad) news!

FYI, types-requests is now requiring urllib3>=2.0.0; this fact greatly increases the likelihood that other HTTP-oriented projects will force a newer version and will be in conflict with boto*.

Hi everyone, for any readers who didn't see the previous post, lack of support for urllib3 2.0 in Amazon Linux 2 and some versions of Lambda are what is currently blocking us removing the pin. These compatibility issues are unlikely to change so we're continuing to find options minimize the current dependency friction.
I've put up #3034 which will relax our pin to allow urllib3 2.0 on Python 3.10 and later. This should allow users on versions of Python that only support OpenSSL 1.1.1+ to safely upgrade. We'll continue to keep this thread updated as we have more to share.

Hi everyone, for any readers who didn't see the previous post, lack of support for urllib3 2.0 in Amazon Linux 2 and some versions of Lambda are what is currently blocking us removing the pin. These compatibility issues are unlikely to change so we're continuing to explore options to minimize the dependency friction.
I've put up #3034 which will relax our pin to allow urllib3 2.0 on Python 3.10 and later. This should allow users on versions of Python that only support OpenSSL 1.1.1+ to safely upgrade. We'll continue to keep this thread updated as we have more to share.

Thanks @nateprewitt, completely understand the reason why this is pinned and the challenges you face. I just wanted to share new context -- as of this week and led to a great discussion in typeshed --  in case it wasn't widely known; I was certainly caught by surprise.

@nateprewitt  I can now install urllib3 2.0 with boto3, but now my tests reported some warnings, after some debugging, I thought it's related to:
https://github.com/boto/botocore/blob/develop/botocore/httpsession.py#L338

Maybe you should consider remove the strict option?

Thanks for the report, @xcaptain. We're currently pinned at urllib3<2.1 since it will contain a handful of breaking changes. We'll take a look at getting this addressed to reduce warning noise, but there shouldn't be any other impact from these. For the time being, you should be able to suppress the deprecations or downgrade to "urllib3<2" if needed while we get a patch together.

@Morgomor could you provide more info on what import error occurred? We have reasonable adoption on 3.10 now without issue so it sounds like you may have a unique setup.

Is there anything we can do to help unblock an upgrade to a more recent version of urllib3, especially for those using Python 3.11 or 3.12?

Hi @brodybits, botocore currently supports urllib3<2.1 for Python 3.10+. There are some breaking changes in 2.1 (and more recently 2.2.0) that have prompted the current pinning. Once we have confidence we can safely move to the latest release, we'll look at updating the pin to catch up to the last couple months of releases.

Given we've resolved the 2.0 move on Python 3.10+ and don't have any immediate plans to add support for earlier versions, it's probably best to close this issue.
For tracking catching up to the latest minor release we can have a separate feature request, that will help with some of the confusion this thread has had in the last few months. Thanks everyone for your participation and patience!

@nateprewitt can you please give us a link to the feature request for the update to urllib >= 2.1?

@SamStephens I just filed https://github.com/boto/boto3/issues/4025


Cannot unlock vault

Hi,
I am trying to unlock the PSTs i left in the vault.
i have tried both with the community xyz dapp and with the js library, its not working and the vault balance is still locked.
Also if i check the vaultbalance with the js ibrary,it says 0, but viewblock and communityxyz are still showing that the PSTs are still locked.
Also, when i check the state of the weave contract,its still showing the PSts are in the vault

Any luck with this,
It still seems unresolved

Hey Layinka, this has been resolved a long time ago. That's why I closed the issue here. It was due to a caching issue happening on the server we were used to cache smartweave states.

Ok, thanks


Service annotation with uppercase letters does not seem to correctly map?

I have setup k8s_gateway on my Kubernetes server instance and have deployed this configuration:
apiVersion: v1
kind: Namespace
metadata:
  name: k8s-dns-test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: www-depl
  namespace: k8s-dns-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wsa
  template:
    metadata:
      labels:
        app: wsa
    spec:
      containers:
        - name: wsc
          image: python:3
          command:
            - python
            - -m
            - http.server
          ports:
            - containerPort: 8000
---
# https://kubernetes.io/docs/concepts/services-networking/service/
apiVersion: v1
kind: Service
metadata:
  name: www
  namespace: k8s-dns-test
spec:
  selector:
    app: wsa
  ports:
    - name: 80-8000
      port: 80
      protocol: TCP
      targetPort: 8000
  sessionAffinity: None
  type: LoadBalancer
---
# https://kubernetes.io/docs/concepts/services-networking/service/
apiVersion: v1
kind: Service
metadata:
  name: www2
  namespace: k8s-dns-test
  annotations:
    "coredns.io/hostname": "sctst-www"
spec:
  selector:
    app: wsa
  ports:
    - name: 80-8000
      port: 80
      protocol: TCP
      targetPort: 8000
  sessionAffinity: None
  type: LoadBalancer
---
# https://kubernetes.io/docs/concepts/services-networking/service/
apiVersion: v1
kind: Service
metadata:
  name: www3
  namespace: k8s-dns-test
  annotations:
    "coredns.io/hostname": "scBRB-www"
spec:
  selector:
    app: wsa
  ports:
    - name: 80-8000
      port: 80
      protocol: TCP
      targetPort: 8000
  sessionAffinity: None
  type: LoadBalancer
---
# https://kubernetes.io/docs/concepts/services-networking/service/
apiVersion: v1
kind: Service
metadata:
  name: www4
  namespace: k8s-dns-test
  annotations:
    coredns.io/hostname: sc-brb-www
spec:
  selector:
    app: wsa
  ports:
    - name: 80-8000
      port: 80
      protocol: TCP
      targetPort: 8000
  sessionAffinity: None
  type: LoadBalancer

When redeploying this manifest I get the following DEBUG output in the k8s_gateway:
[DEBUG] plugin/k8s_gateway: Adding index www.k8s-dns-test for service www
[DEBUG] plugin/k8s_gateway: Adding index www.k8s-dns-test for service www
[DEBUG] plugin/k8s_gateway: Adding index www.k8s-dns-test for service www
[DEBUG] plugin/k8s_gateway: Adding index sctst-www for service www2
[DEBUG] plugin/k8s_gateway: Adding index sctst-www for service www2
[DEBUG] plugin/k8s_gateway: Adding index sctst-www for service www2
[DEBUG] plugin/k8s_gateway: Adding index scBRB-www for service www3
[DEBUG] plugin/k8s_gateway: Adding index scBRB-www for service www3
[DEBUG] plugin/k8s_gateway: Adding index scBRB-www for service www3
[DEBUG] plugin/k8s_gateway: Adding index sc-brb-www for service www4
[DEBUG] plugin/k8s_gateway: Adding index sc-brb-www for service www4
[DEBUG] plugin/k8s_gateway: Adding index sc-brb-www for service www4

So far so good ... then I do dig queries directed to the externally available server and I get the following results:
[DEBUG] plugin/k8s_gateway: Computed Index Keys [scTST-www.k8tst.my.lan scTST-www]
[DEBUG] plugin/k8s_gateway: Found 0 matching Ingress objects
[DEBUG] plugin/k8s_gateway: Found 1 matching Service objects
[DEBUG] plugin/k8s_gateway: Computed response addresses [<IP_ADDRESS>]
[INFO] <IP_ADDRESS>:24863 - 20402 "A IN sctst-www.k8tst.my.lan. udp 67 false 4096" NOERROR qr,aa,rd 86 0.000235097s
[DEBUG] plugin/k8s_gateway: Computed Index Keys [scBRB-www.k8tst.my.lan scBRB-www]
[DEBUG] plugin/k8s_gateway: Found 0 matching Ingress objects
[DEBUG] plugin/k8s_gateway: Found 0 matching Service objects
[DEBUG] plugin/k8s_gateway: Computed response addresses []
[INFO] <IP_ADDRESS>:21874 - 38837 "A IN scbrb-www.k8tst.my.lan. udp 67 false 4096" NXDOMAIN qr,rd 197 0.000197097s
[DEBUG] plugin/k8s_gateway: Computed Index Keys [sc-BRB-www.k8tst.my.lan sc-BRB-www]
[DEBUG] plugin/k8s_gateway: Found 0 matching Ingress objects
[DEBUG] plugin/k8s_gateway: Found 1 matching Service objects
[DEBUG] plugin/k8s_gateway: Computed response addresses [<IP_ADDRESS>]
[INFO] <IP_ADDRESS>:29058 - 21746 "A IN sc-brb-www.k8tst.my.lan. udp 68 false 4096" NOERROR qr,aa,rd 88 0.000213096s
[DEBUG] plugin/k8s_gateway: Computed Index Keys [scTST-www.k8tst.my.lan scTST-www]
[DEBUG] plugin/k8s_gateway: Found 0 matching Ingress objects
[DEBUG] plugin/k8s_gateway: Found 1 matching Service objects
[DEBUG] plugin/k8s_gateway: Computed response addresses [<IP_ADDRESS>]
[INFO] <IP_ADDRESS>:59905 - 11249 "A IN sctst-www.k8tst.my.lan. udp 67 false 4096" NOERROR qr,aa,rd 86 0.000220096s

Dig query
dig scBRB-www.k8tst.my.lan @host
or
dig scbrb-www.k8tst.my.lan @host
fails with 0 Service objects.
Interesting enough changing upper case letters to lower case letters in annotation seems to solve the issue. Any chance to fix this?

yep, I was expecting domain names to be the same as metadata labels or name: must consist of lower case alphanumeric characters
What's your use case? would it be ok if we just lowercase the value from annotation before saving it in the cache?

No use case, just testing what we can and should not input.
It should be noted that there is no limitation on annotation values (https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/#syntax-and-character-set) as opposed to the other two types (name and namespace) which hint in documentation that they should reflect a part o domain name and hence follow the FQDN limitations.
I am fairly sure I can put in the annotation value<EMAIL_ADDRESS>:) will test it out to see what will happen. I am also sure I can configure and deploy this annotation value "abcd0123456789012345678901234567890123456789012345678901234567890" :) - I am also wandering what will happen with this one. Would this also be valid from annotation perspective "ôóčćšž12345"?
I would suggest a validation of the annotation value (RFC 1035 - section 2.3.1 and RFC 2181 - section 11).
I would also suggest to validate the length of the fully setup DNS record - probably for all types you support (should not be greater than 253 characters if I understand everything correctly - first DNS label should not be larger than 63 bytes I believe).
As per character case treatment I do expect that DNS names are treated in all lower case. Weather that means a failure to deploy or fixing the business logic to check everything in lower case is up to you :)

I've done a few changes in 0.3.2 that should address most of the serious issues. It should be checking the length of the DNS label and treat upper/lower case similarly now. let me know when you test it.

I think falling back here would be a bad idea. If someone specified a hostname in annotation, that means they want to use that value, falling back could be an unexpected side effect.
Regarding "here:you_myfaivourite.value.com" and "ôóčćšž12345", how do you know they are not valid domain names? based on https://www.rfc-editor.org/rfc/rfc2181#section-11, the only restriction is the length, not the value:
The DNS itself places only one restriction on the particular labels
   that can be used to identify resource records.  That one restriction
   relates to the length of the label and the full name.  The length of
   any one label is limited to between 1 and 63 octets.  A full domain
   name is limited to 255 octets (including the separators).  The zero
   length full name is defined as representing the root of the DNS tree,
   and is typically written and displayed as ".".  Those restrictions
   aside, any binary string whatever can be used as the label of any
   resource record.  Similarly, any binary string can serve as the value
   of any record that includes a domain name as some or all of its value
   (SOA, NS, MX, PTR, CNAME, and any others that may be added).
   Implementations of the DNS protocols must not place any restrictions
   on the labels that can be used.  In particular, DNS servers must not
   refuse to serve a zone because it contains labels that might not be
   acceptable to some DNS client programs.  A DNS server may be
   configurable to issue warnings when loading, or even to refuse to
   load, a primary zone containing labels that might be considered
   questionable, however this should not happen by default.

Granted that is true ... Although I must warn you that RFC2181 was superseded by RFC4343. As I recall RFC4343 refers to some other RFC's that deal with the internationalization of domain names. If this is a hole you want to drop into then there will need to be a consensus how to find the "ôóčćšž12345.k8tst.my.lan" host's IP on the g8s_gateway ... I believe there is a UNICODE mapping that should be defined and implemented for internationalized domain names. Nslookup, dig, browsers implement it the same way and I am guessing that you can implement the translation (or call a go function - should be related to "stringprep" or something) of the DNS labels of "ôóčćšž12345" to "xn--12345-ztag7m3b58cej" when you discover them in annotation based host names.
So this issue;
[DEBUG] plugin/k8s_gateway: Adding index ôóčćšž12345 for service www6
[DEBUG] plugin/k8s_gateway: Adding index ôóčćšž12345 for service www6
[DEBUG] plugin/k8s_gateway: Adding index ôóčćšž12345 for service www6
[DEBUG] plugin/k8s_gateway: Adding index ôóčćšž12345 for service www6
[DEBUG] plugin/k8s_gateway: Computed Index Keys [xn--12345-ztag7m3b58cej.k8tst.my.lan xn--12345-ztag7m3b58cej]
[DEBUG] plugin/k8s_gateway: Found 0 matching Ingress objects
[DEBUG] plugin/k8s_gateway: Found 0 matching Service objects
[DEBUG] plugin/k8s_gateway: Computed response addresses []
[INFO] <IP_ADDRESS>:25624 - 5601 "A IN xn--12345-ztag7m3b58cej.k8tst.my.lan. udp 58 false 512" NXDOMAIN qr,rd 211 0.000241796s
[DEBUG] plugin/k8s_gateway: Computed Index Keys [xn--12345-ztag7m3b58cej.k8tst.my.lan xn--12345-ztag7m3b58cej]
[DEBUG] plugin/k8s_gateway: Found 0 matching Ingress objects
[DEBUG] plugin/k8s_gateway: Found 0 matching Service objects
[DEBUG] plugin/k8s_gateway: Computed response addresses []
[INFO] <IP_ADDRESS>:34765 - 64092 "A IN xn--12345-ztag7m3b58cej.k8tst.my.lan. udp 81 false 4096" NXDOMAIN qr,rd 211 0.000191996s

will be resolved.
The issue I still have is that people can really type in anything - there is no limitation on annotation in Kubernetes so - "username:password@mylabel" will probably fail though and full URI's like "ftp://username:password@mylabel2" will probably fail too - so fallback to name.namespace should be warned in those cases. Granted it is a user error and IMHO if it is possible I would fail creation of the resource on cluster :)

ok, so I definitely don't want to implement anything complicated for this, rather niche, feature. Since annotations are less strict than labels, there's not much I can do to prevent user error. I can't fail the creation of a resource (I don't manage any of them), but I can log that I failed to create a DNS entry for it.
WRT the hostnames, what I can do is borrow the label checking logic from the kubernetes code and apply it to k8s_gateway annotations. That means, I would restrict the hostname to the following regex ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$. This should be fairly simple.

Should work ... and should fix all the above problems :)

should be fixed in the #144. @RRunner1337 are you able to test?

should be fixed in the #144. @RRunner1337 are you able to test?

I would love to but I don't have a "go build" environment :/ could you build and release it. I checked the code that was changed and I believe it should do the trick.

The 070f8b7 tag now includes the fix. Let me know once you've tested it and I'll cut a new release.


experimental hydroserver resource type

build a  hydroserver resource type for learning and training. However it may prove to be useful.

this branch (issue) was created 4 months ago for training. Now it is deprecated. closed


Add support for Java7 language features

Java 7 was released in 2011, however its syntax features are still unsupported in JavaCC.
The proposed change introduces the support of all the syntax features introduced in Java 7 (see here  for reference):

Try-with resources.
Multiple exception catching.
Underscores in numeric literals.
Binary literals.
Type Inference for Generic Instance Creation (change in JavaCC.jj was cherry-picked from #75).

Test is also added (in test/java7features and build.xml), as well as one TODO from build.xml was implemented to include SimpleExamples into test process.

Hi @new-javacc! could you please comment on this PR? Any chance to have it merged into JavaCC?

Since the new code generators are in a different branch, I think it's ok for now. I would appreciate it more if you can fix the Java grammar to be the latest (Java 11?) so that we can use that for parsing in the new world.

@inponomarev Could you backport your PR to the 8.0.0 branch? TIA


Opt-in/opt-out mechanism for individual rules

I find this project really great, and it's definitely going to be a key piece of the puzzle I have to build to make VS work as I want it without depending on R#.
However, some of the rules (e.g. RECS1029 'internal' modifier is redundant) are in conflict with a different ruleset we enforce in my project through StyleCop analyzers, which requires all types to have an explicit access modifier. Thus, there's no way I can get both analyzers to stop reporting a fix there.
It would be awesome to have a checklist under Tools->Options somewhere, where I can check and uncheck various rules to decide which ones will be active. It should be possible to save these locally, in the project (for only me) or in the project (team-shared). It should also be possible to select "disable this rule" from the quick-action menu and not ever have to go to the options.
Maybe parts of this feature already exists, and I just can't find them, but I think this extension would be even more awesome if it was there.

https://github.com/icsharpcode/RefactoringEssentials/wiki/Custom-Rule-Sets-for-Analyzers

@christophwille Nice! Not as easy to find as I would have liked, but works well (and, I realize, standardized for analyzers, so probably something most users will just have to learn to find anyway).
It would be awesome to add a suppress option to the quick actions, though. Although that might be something that VS has to do, rather than RefactoringEssentials?

That would be a feature request for VS (or a power tool maybe that is x-analyzer libraries): eg "Suppress RECSxxxxx in current rule set"


Controller(s) should dynamically reload based on config-leader-election changes

As of today, the controller(s) do not react to the config-leader-election configmap, you need to restart (kubectl rollout) the controller each time you change it.
Ideally, this wouldn't be needed. A change of the config-leader-election configmap should be reflected directly on the controllers "tracking" it.
This depends no knative.dev/pkg so we should probably see "upstream" if this is doable first.

/lifecycle frozen


Attempted to tackle #1622

Trying to fix #1622

Looks great, thanks! Can you be sure to add a smoke test or two as well?
I also think for now we'll probably want to leave bind0 as bind to avoid a breaking change, but we can file an issue about changing it on the next major breaking version?

Looks great, thanks! Can you be sure to add a smoke test or two as well?
I also think for now we'll probably want to leave bind0 as bind to avoid a breaking change, but we can file an issue about changing it on the next major breaking version?

Sounds good

@alexcrichton The tests have been written, I've added declarations for bind() and bind0()

Thanks!


Update correct link reference on mozilla web docs, also update the hyperlinks texts accordingly

[ x] I have read freeCodeCamp's contribution guidelines.
[ x] My pull request has a descriptive title (not a vague title like Update index.md)
[ x] My pull request targets the master branch of freeCodeCamp.
[ x] None of my changes are plagiarized from another source without proper attribution.
[ x] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[ x] My changes do not use shortened URLs or affiliate links.

Closes #XXXXX

Plus I would like to know how to keep updated with the master branch without using git bash.
like in this,
https://github.com/KirstieJane/STEMMRoleModels/wiki/Syncing-your-fork-to-the-original-repository-via-the-browser
when I did the above I had a commit merge to my forked repo and I was worried that commit will conflict with the master .
so I deleted my repo and forked again.
Can you suggest a new way?

In general, you do not want to make changes on your forked master.  You want to first make sure you master branch is in sync with the main repo's and then create a new branch with any of your changes.  This way, you always keep your master "clean".

Thanks for contributing to the freeCodeCamp repository. Congratulations on your first PR! 🎊
Look forward to more contributions from you! ✈


2.1.2 seems to fail tests on ppc64le with musl libc

 1/67 Test  #1: example ..........................***Failed    0.19 sec
zlib-ng version 2.1.2 = 0x020102f0, compile flags = 0xa9
uncompress error: -3

      Start 65: makecrct
 2/67 Test  #2: infcover .........................   Passed    0.19 sec
      Start 66: makefixed
 3/67 Test  #3: CVE-2002-0059 ....................   Passed    0.19 sec
      Start 67: maketrees
 4/67 Test  #4: CVE-2004-0797 ....................   Passed    0.19 sec
 5/67 Test  #5: CVE-2005-1849 ....................   Passed    0.19 sec
 6/67 Test  #6: CVE-2005-2096 ....................   Passed    0.19 sec
 7/67 Test  #7: CVE-2018-25032-fixed-level-6 .....

It looks like one bit gets flipped... We test all supported non-Windows platforms with just GNU libc, so it might be possible compiling against musl toolchain reveals some broken functions.

i don't have access to a ppc64le machine without musl on it (or with a shell on it either, this is from a pipeline sadly). i could probably scrape together something but it would most likely be easier for you to compare and verify

Ok, so probably musl, but it might be something else as well, thanks.
It might also be a musl-on-ppc64le specific bug, in case someone tests with musl on x86* and it works fine.
I don't have access to any ppc* machines personally unfortunately. @mtl1979 did you have something like that?

it passes on every other architecture, yeah

Ok, so probably musl, but it might be something else as well, thanks. It might also be a musl-on-ppc64le specific bug, in case someone tests with musl on x86* and it works fine.
I don't have access to any ppc* machines personally unfortunately. @mtl1979 did you have something like that?

I remember ppc64le and sparc64 having issues even with glibc (GNU libc), but that was with specific gcc versions. As much as I want to blame musl, it might be just that musl toolchain is based on broken commit of gcc toolchain. I tried same gcc version on two different Ubuntu versions and it failed only on the newer one.

ppc64le is a bit special in that VSX needs to perform a flip on loads because the memory load / store on certain sizes are natively big endian.  Most of the time it doesn't matter but maybe we're looking at one of those times where it might?  If you disable VSX and VMX, do the tests pass?  That will at least tell us if it's an issue with vectorization or not.

On glibc ppc64 (big endian), I get 100% tests passed, 0 tests failed out of 68 on develop.
On glibc ppc64le, I get many failures as well as one test which hangs:

Running tests...
Test project /root/zlib-ng/build
      Start  1: example
 1/68 Test  #1: example ..........................***Failed    0.00 sec
      Start  2: infcover
 2/68 Test  #2: infcover .........................   Passed    0.00 sec
      Start  3: CVE-2002-0059
 3/68 Test  #3: CVE-2002-0059 ....................   Passed    0.01 sec
      Start  4: CVE-2004-0797
 4/68 Test  #4: CVE-2004-0797 ....................   Passed    0.01 sec
      Start  5: CVE-2005-1849
 5/68 Test  #5: CVE-2005-1849 ....................   Passed    0.01 sec
      Start  6: CVE-2005-2096
 6/68 Test  #6: CVE-2005-2096 ....................   Passed    0.01 sec
      Start  7: CVE-2018-25032-fixed-level-6
 7/68 Test  #7: CVE-2018-25032-fixed-level-6 .....   Passed    0.04 sec
      Start  8: CVE-2018-25032-default-level-6
 8/68 Test  #8: CVE-2018-25032-default-level-6 ...***Failed    0.04 sec
      Start  9: CVE-2018-25032-fixed-level-1
 9/68 Test  #9: CVE-2018-25032-fixed-level-1 .....   Passed    0.04 sec
      Start 10: CVE-2018-25032-default-level-1
10/68 Test #10: CVE-2018-25032-default-level-1 ...***Failed    0.04 sec
      Start 11: CVE-2018-25032-fixed-level-2
11/68 Test #11: CVE-2018-25032-fixed-level-2 .....   Passed    0.04 sec
      Start 12: CVE-2018-25032-default-level-2
12/68 Test #12: CVE-2018-25032-default-level-2 ...***Failed    0.04 sec
      Start 13: minigzip-fireworks.jpg-R
13/68 Test #13: minigzip-fireworks.jpg-R .........   Passed    0.10 sec
      Start 14: minigzip-fireworks.jpg-h
14/68 Test #14: minigzip-fireworks.jpg-h .........   Passed    0.10 sec
      Start 15: minigzip-fireworks.jpg-T
15/68 Test #15: minigzip-fireworks.jpg-T .........   Passed    0.04 sec
      Start 16: minigzip-fireworks.jpg-0
16/68 Test #16: minigzip-fireworks.jpg-0 .........   Passed    0.11 sec
      Start 17: minigzip-fireworks.jpg-1
17/68 Test #17: minigzip-fireworks.jpg-1 .........***Failed    0.04 sec
      Start 18: minigzip-fireworks.jpg-2
18/68 Test #18: minigzip-fireworks.jpg-2 .........***Failed    0.04 sec
      Start 19: minigzip-fireworks.jpg-4
19/68 Test #19: minigzip-fireworks.jpg-4 .........***Failed    0.04 sec
      Start 20: minigzip-fireworks.jpg-5
20/68 Test #20: minigzip-fireworks.jpg-5 .........***Failed    0.04 sec
      Start 21: minigzip-fireworks.jpg-F
21/68 Test #21: minigzip-fireworks.jpg-F .........   Passed    0.10 sec
      Start 22: minigzip-fireworks.jpg-6
22/68 Test #22: minigzip-fireworks.jpg-6 .........***Failed    0.04 sec
      Start 23: minigzip-fireworks.jpg-9
23/68 Test #23: minigzip-fireworks.jpg-9 .........***Failed    0.04 sec
      Start 24: minigzip-fireworks.jpg-f
24/68 Test #24: minigzip-fireworks.jpg-f .........***Failed    0.04 sec
      Start 25: minigzip-lcet10.txt-R
25/68 Test #25: minigzip-lcet10.txt-R ............   Passed    0.15 sec
      Start 26: minigzip-lcet10.txt-h
26/68 Test #26: minigzip-lcet10.txt-h ............   Passed    0.14 sec
      Start 27: minigzip-lcet10.txt-T
27/68 Test #27: minigzip-lcet10.txt-T ............   Passed    0.05 sec
      Start 28: minigzip-lcet10.txt-0
28/68 Test #28: minigzip-lcet10.txt-0 ............   Passed    0.14 sec
      Start 29: minigzip-lcet10.txt-1
29/68 Test #29: minigzip-lcet10.txt-1 ............***Failed    0.05 sec
      Start 30: minigzip-lcet10.txt-2
30/68 Test #30: minigzip-lcet10.txt-2 ............***Failed    0.06 sec
      Start 31: minigzip-lcet10.txt-4
31/68 Test #31: minigzip-lcet10.txt-4 ............***Failed    0.06 sec
      Start 32: minigzip-lcet10.txt-5
32/68 Test #32: minigzip-lcet10.txt-5 ............***Failed    0.08 sec
      Start 33: minigzip-lcet10.txt-F
33/68 Test #33: minigzip-lcet10.txt-F ............***Failed    0.09 sec
      Start 34: minigzip-lcet10.txt-6
34/68 Test #34: minigzip-lcet10.txt-6 ............***Failed    0.09 sec
      Start 35: minigzip-lcet10.txt-9
35/68 Test #35: minigzip-lcet10.txt-9 ............***Failed    0.14 sec
      Start 36: minigzip-lcet10.txt-f
36/68 Test #36: minigzip-lcet10.txt-f ............***Failed    0.09 sec
      Start 37: minigzip-paper-100k.pdf-R
37/68 Test #37: minigzip-paper-100k.pdf-R ........   Passed    0.10 sec
      Start 38: minigzip-paper-100k.pdf-h
38/68 Test #38: minigzip-paper-100k.pdf-h ........   Passed    0.10 sec
      Start 39: minigzip-paper-100k.pdf-T
39/68 Test #39: minigzip-paper-100k.pdf-T ........   Passed    0.04 sec
      Start 40: minigzip-paper-100k.pdf-0
40/68 Test #40: minigzip-paper-100k.pdf-0 ........   Passed    0.09 sec
      Start 41: minigzip-paper-100k.pdf-1
41/68 Test #41: minigzip-paper-100k.pdf-1 ........***Failed    0.04 sec
      Start 42: minigzip-paper-100k.pdf-2
42/68 Test #42: minigzip-paper-100k.pdf-2 ........***Failed    0.03 sec
      Start 43: minigzip-paper-100k.pdf-4
43/68 Test #43: minigzip-paper-100k.pdf-4 ........***Failed    0.04 sec
      Start 44: minigzip-paper-100k.pdf-5
44/68 Test #44: minigzip-paper-100k.pdf-5 ........***Failed    0.04 sec
      Start 45: minigzip-paper-100k.pdf-F
45/68 Test #45: minigzip-paper-100k.pdf-F ........***Failed    0.04 sec
      Start 46: minigzip-paper-100k.pdf-6
46/68 Test #46: minigzip-paper-100k.pdf-6 ........***Failed    0.04 sec
      Start 47: minigzip-paper-100k.pdf-9
47/68 Test #47: minigzip-paper-100k.pdf-9 ........***Failed    0.04 sec
      Start 48: minigzip-paper-100k.pdf-f
48/68 Test #48: minigzip-paper-100k.pdf-f ........***Failed    0.04 sec
      Start 49: minigzip-detect-text-A
49/68 Test #49: minigzip-detect-text-A ...........***Failed    0.09 sec
      Start 50: minigzip-detect-binary-A
50/68 Test #50: minigzip-detect-binary-A .........***Failed    0.04 sec
      Start 51: GH-361
51/68 Test #51: GH-361 ...........................   Passed    0.09 sec
      Start 52: GH-364
52/68 Test #52: GH-364 ...........................   Passed    0.08 sec
      Start 53: GH-382
53/68 Test #53: GH-382 ...........................   Passed    0.04 sec
      Start 54: GH-536-segfault
54/68 Test #54: GH-536-segfault ..................***Failed    0.04 sec
      Start 55: GH-536-incomplete-read
55/68 Test #55: GH-536-incomplete-read ...........***Failed    0.05 sec
      Start 56: GH-536-zero-stored-block
56/68 Test #56: GH-536-zero-stored-block .........***Failed    0.04 sec
      Start 57: GH-751
57/68 Test #57: GH-751 ...........................***Failed    0.03 sec
      Start 58: minigzip-file_compress
58/68 Test #58: minigzip-file_compress ...........***Failed    0.02 sec
      Start 59: minideflate-file_compress
59/68 Test #59: minideflate-file_compress ........***Failed    0.02 sec
      Start 60: minigzip-help
60/68 Test #60: minigzip-help ....................   Passed    0.01 sec
      Start 61: minigzip-invalid
61/68 Test #61: minigzip-invalid .................   Passed    0.01 sec
      Start 62: minideflate-help
62/68 Test #62: minideflate-help .................   Passed    0.01 sec
      Start 63: minideflate-invalid
63/68 Test #63: minideflate-invalid ..............   Passed    0.01 sec
      Start 64: switchlevels-help
64/68 Test #64: switchlevels-help ................   Passed    0.01 sec
      Start 65: makecrct
65/68 Test #65: makecrct .........................   Passed    0.10 sec
      Start 66: makefixed
66/68 Test #66: makefixed ........................   Passed    0.03 sec
      Start 67: maketrees
67/68 Test #67: maketrees ........................   Passed    0.03 sec
      Start 68: gtest_zlib

-DWITH_ALTIVEC=OFF -DWITH_POWER8=OFF -DWITH_POWER9=ON

this fixes them

fails with 12.2 based gcc the same way

I went back to gcc 9 before everything started to work...

Are you sure they did?

We've still got active POWER8 users in Gentoo w/ 13 and I still see it at https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html#index-mcpu-10.

For a long time, forcing to target Power8 has been same as targeting Power9... I tried forcing Power8 but it crashed, because I don't have Power9...

Yeah I'm almost certain this is what we're seeing:
https://gcc.gcc.gnu.narkive.com/cJndcMpR/vec-ld-versus-vec-vsx-ld-on-power8

@mtl1979 found a fix for adler_vmx, that is a separate issue from this one.  He's investigating the POWER9 issue now.

applying https://github.com/zlib-ng/zlib-ng/commit/e5ab5890a89860a7f4115fca9b0fc7c778b26ef1 to 2.1.2 still seems to have the same failures

The adler32 checksum should be fixed at least for Altivec. Which compiler are you using?  The POWER9 fix tests the GCC version and applies a manual inline asm call if it's less than 13 to the vectorized count leading and trailing zeros intrinsic. Perhaps our fix is relying on an endianness convention that GCC recently fixed? That, or you're using clang and clang also got it wrong.  The comment for the wrapper says we're working around this bug: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3f30f2d1dbb3228b8468b26239fe60c2974ce2ac

psykose and I are both using latest 13s from the release branch, so I'd expect us to be fine wrt any bugs

If you change that macro to always be true does that fix things? If so we may be missing an adjustment for endianness when using the intrinsic.

Hm, everything passes for me w/ fresh 12 (not 13) on glibc ppc64le on develop..

My guess, and I don't have power9 systems to verify this but, gcc's fix for endianness inverted the need to switch between trailing and leading zero. Perhaps gcc flips which instruction gets used based on endianness?
@mtl1979 maybe see what instruction gcc 12 is generating?

@KungFuJesus I used inline assembly for gcc 13 too and it passed all tests... Seems like someone forgot to apply the patch to gcc 13 series...

Either that or that fix for gcc for endianness was actually swapping the emitted instruction based on endianness.

Either that or that fix for gcc for endianness was actually swapping the emitted instruction based on endianness.

I really want to keep the workaround simple... But in the end we might need to use inline assembly always...

Hm, everything passes for me w/ fresh 12 (not tried 13) on glibc ppc64le on develop..

I'll build a bunch of GCCs overnight and give some more results later. Maybe @nekopsykose can check with a few different GCCs too to see what's going on.
I can probably give y'all access to a container if needed as well (it's what the machines I'm using here are for, so..)

Uh oh, I can indeed reproduce the failures again with 13 (note that my initial confirmation before the fix was with 12; not sure how possible it is for the fix to have not been cherry-picked with how GCC development works though).
I get the same behaviour as I did before with 12 pre-fix (12.2.1 20230428 - note that this isn't quite the latest, although not that old)) now with 13.1.1 20230527. I'll give a proper summary once all the latest GCCs for each series are done building,.

Yeah so I know what happened here and I'm not exactly sure I agree with GCC's decision.  It's just a question of what we do for the workaround now.
Semantically, the "LSBB" here means least significant bits (byte vector variant).  Because they say "least significant", they are changing from which end bytes are being counted depending on endianness.  Now, for a __builtin function, ok that might be understandable, but the "vec_cntlz_lsbb" intrinsic they also flip it around just like the builtin, too.
Usually when we use intrinsics, they are supposed to closely translate to (often producing the same) instruction with the same mnemonics.  And the instruction is defined such that it's cntlz or cnttz and it will do whatever in the native byte order.  You could think an intrinsic that closely matches the instruction name would produce that instruction, not flip the direction if a different endianness.
So essentially, on GCC's prior to 12, __builtin_vec_vctzlsbb generated the vclzlsbb instruction, regardless of endianness and vice versa.  Now, on GCC >= 12, it generates:
vclzlsbb on big endian and vctzlsbb on little.
There's a million ways to fix this but I'm not sure what the best way to fix it is. It's not great that we have to constantly work around how GCC wants to emit instructions for this. The current suggested, (maybe best?) is to just use the GNU style inline assembly regardless. The other way involves a whole maze of preprocessor macros to detect if GCC or Clang (yeah I don't even know what clang does for this yet), and if old enough, then switch the intrinsic or otherwise just use leading zero, and if old enough to not support the intrinsic, then use the inline asm as well?

clang-13 and clang-14 have own intrinsic that seems to work for little-endian PPC64... I'm assuming it does also work for big-endian, but I haven't verified it yet...

Instead of preprocessor checks, CMake/Configure could have a test that verifies what intrinsic to use. Of course cross-compiles might have to fall back to inline ASM just to be sure.
Inline ASM might prohibit the compilers optimizer from doing some of its job.

I agree that it should probably be a cmake/configure check at this point.

We still need preprocessor test to support clang. As much as I hate broken compilers, gcc is still too widely used for us being able to force all PPC64 users to use clang instead. I know Android forces use of clang for 64-bit processors but that was done already when it was only 32-bit.

Instead of preprocessor checks, CMake/Configure could have a test that verifies what intrinsic to use. Of course cross-compiles might have to fall back to inline ASM just to be sure. Inline ASM might prohibit the compilers optimizer from doing some of its job.

If we know that for gcc < 12 and clang we need to use different built-in function(s) for little- and big-endian processors, we can just do that without using inline assembly... That way it doesn't prohibit optimizer from doing its job.
The problem with the old code was that it sometimes tried to do the "element reversing" trick twice.

The problem with the old code was that it sometimes tried to do the "element reversing" trick twice.

Well, the assembly was always correct. It's the intrinsics that double reversed depending on the version of GCC because apparently we can't name intrinsics after their instructions anymore (according to IBM).

The problem with the old code was that it sometimes tried to do the "element reversing" trick twice.

Well, the assembly was always correct. It's the intrinsics that double reversed depending on the version of GCC because apparently we can't name intrinsics after their instructions anymore (according to IBM).

We can blame either GCC team or IBM... But taking account all the possible gcc and clang versions available on my build cluster, the latest version of the patch is pretty much as clean as it can get without using configure-time checks...

We should really check to find out which gcc versions had the fix if doing that. I suspect some minor versions of 11 include it as well. That or configure time checks would also work.

We should really check to find out which gcc versions had the fix if doing that. I suspect some minor versions of 11 include it as well. That or configure time checks would also work.

Like I said earlier, we can add configure-time check, but it has to be compatible with cross-compiling, otherwise it will serve no purpose for verifying in CI workflows.

We could have a configure/CMake check that chooses intrinsics, and use asm for cross-compiling. That way it should always be correct.

Yeah, that was what I was thinking.  Do we already have something in our build configuration that checks for endianness?  If not I guess it wouldn't be hard to write some generic C that would.

Yeah, that was what I was thinking. Do we already have something in our build configuration that checks for endianness? If not I guess it wouldn't be hard to write some generic C that would.

cmake has macro for testing endianess, but configure needs a test.
https://cmake.org/cmake/help/v3.0/module/TestBigEndian.html

Just testing endianess does not really help in this case I think.
I think it should test the intrinsics on the selected compiler, and find out what intrinsic actually returns the correct answer, that way we don't need to care whether it is GCC, Clang, ICC, AOCC or something else. If one of the intrinsics works, we choose that, if not we fall back to asm as a last resort.
For cross compile, we can default to asm always. We can also document the C define needed, so distros can choose to build with the correct intrinsic manually. The best would be to support running the test in qemu as well, but that would only be a good bonus.
The question now is what to do about #1520, do we merge as is and improve it later, or do we wait until we have the desired solution? This is mostly in @mtl1979 court now, do you want to implement the above? If not, we could merge the PR and let someone else work on the configure/CMake improvements.

#1520 likely needs a more fine grained check on gcc. From what I can tell a minor version of gcc 11 got that patch.

Of course, we could just do this by supplying a vector with mismatched zeros in either end and check which returns versus expected, taking compile time endianness into account with a macro.

Yes, this is what I was thinking.

@mtl1979 Ok, I take that as meaning that you don't plan on implementing the CMake/configure tests in #1520.
That means the floor is open for someone else to add those bits.

Personally I don't think the tests are absolutely necessary and even if they will be implemented, it doesn't make #1520 any cleaner or less accurate... There will always be bad compilers but we can only work around the already released versions.

not presently, no, i don't have access to any ppc64le hardware anymore. someone else here might


Add Utility calculators and a small Clarification to the interface

This adds three "utility" calculators.
First is CombinationCalculator that can be used to combine group of calculators to one calculator. It allows serial or parallel execution of the calculators. Finally it has an option to edit keywords that are passed to the calculators.
Second is ReportingCalculator that can be used to collect information during calculation.
Third is SubSystemCalculator that splits the systtem to a smaller part and performs the calculation on that part.
Interface Clarification
There is also a clarification on the interface definition here. Non allocating force calculator has two options: 1) overwrite the given force array or 2) add to the given force array. The original definition did to clarify which of these two options the interface expects.
It should be noted that, if more than one calculator is needed option 1) becomes invalid. Also in option 1) the calculator has to overwrite the whole array, while in option 2) it can only write a part of the array.
This became a clear problem when implementing CombinationCalculator. So, I did the liberty of making option 2) the official interface. This of course needs approval from everyone @cortner, @mfherbst, @jgreener64 and @rkurchin

So you are saying that the in-place calculators are never allowed to zero-out the output array. It is always the responsibility of the caller. I'm ok with that, but it is a big potential source of bugs and therefore needs to be very prominently documented.

Agree that the non-allocating force calculator should add not overwrite. We should document that clearly in the docs and relevant docstrings though, e.g. by saying that fill!(f, 0) can be called before forces!.
I also prefer ArgumentError to @assert for argument checking since asserts can be turned off.

This is a summary of our Zoom discussion
CombinationCalculator
This was agreed to be useful. A point was asked, should the multithreading be on by default or not?
A question about using a tuple of calculators, was also asked. This could cause some issues with dispatch and would need a solution on interface level.
Concern rouse on the keyword argument edit functionality. Is it needed? Would it hide details from user?...
ReportingCalculator
There was a discussion on how the messaging part should be done and is the name ReportingCalculator a correct one.
We discussed on possibility of implementing message calls to calculators. The issue with these is that every calculator would need to implement a call check.
The use of Channel in ReportingCalculator was questioned. Would a simple method call be a better one?
SubSystemCalculator
It was agreed that this is a needed feature.
Possible issue was pointed on that this could hide the type of the calculator that could be needed e.g. in geometry optimisation.
We came to a conclusion that we should look for SciML on how subsystem and messages are handled there.

@tjjarvinen  -- I think utilitiy calculators now go elsewhere and interface clarification will happen in a separate PR - renewing Cedric's large PR. Can this be closed?


Vue 3 Support

Can we make @next release that natively supports Vue 3 Composition api ?
Without the need to import the dependency ?
If you are busy, I could take the task

Good day. Sure it is a good idea. Please feel free to make a branch as you proposed.


Improve developer experience

Improve docs around building
Speed up maven build
Debugging
Running cassandra
Iterating on modules without restarting persistence

Good ideas, but for actual work would need bit more specific; let's re-file with ideas, wrt Stargate v2.


[BUG] - Next UI Skeleton animation is doing conflict with tailwindcss-animate

NextUI Version
2.4.6
Describe the bug
When i'm using the skeleton component i notice that the animation is going way too fast, so i started to debug and i find that if i commented the tailwindcss-animate in plugins in the tailwind.config.ts the animation worked correctly.
Your Example Website or App
https://codesandbox.io/p/devbox/nextui-tailwindcss-animate-issue-y89x4c?layout=%257B%2522sidebarPanel%2522%253A%2522EXPLORER%2522%252C%2522rootPanelGroup%2522%253A%257B%2522direction%2522%253A%2522horizontal%2522%252C%2522contentType%2522%253A%2522UNKNOWN%2522%252C%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522id%2522%253A%2522ROOT_LAYOUT%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522UNKNOWN%2522%252C%2522direction%2522%253A%2522vertical%2522%252C%2522id%2522%253A%2522cm0dt1t630006356mmti2mhro%2522%252C%2522sizes%2522%253A%255B70%252C30%255D%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522EDITOR%2522%252C%2522direction%2522%253A%2522horizontal%2522%252C%2522id%2522%253A%2522EDITOR%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL%2522%252C%2522contentType%2522%253A%2522EDITOR%2522%252C%2522id%2522%253A%2522cm0dt1t630002356m4cvfs1fd%2522%257D%255D%257D%252C%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522SHELLS%2522%252C%2522direction%2522%253A%2522horizontal%2522%252C%2522id%2522%253A%2522SHELLS%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL%2522%252C%2522contentType%2522%253A%2522SHELLS%2522%252C%2522id%2522%253A%2522cm0dt1t630004356m33yuvxk6%2522%257D%255D%257D%255D%257D%252C%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522DEVTOOLS%2522%252C%2522direction%2522%253A%2522vertical%2522%252C%2522id%2522%253A%2522DEVTOOLS%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL%2522%252C%2522contentType%2522%253A%2522DEVTOOLS%2522%252C%2522id%2522%253A%2522cm0dt1t630005356mkuyx6uhs%2522%257D%255D%257D%255D%252C%2522sizes%2522%253A%255B50%252C50%255D%257D%252C%2522tabbedPanels%2522%253A%257B%2522cm0dt1t630002356m4cvfs1fd%2522%253A%257B%2522tabs%2522%253A%255B%257B%2522id%2522%253A%2522cm0dt1t620001356mlcnqn8x0%2522%252C%2522mode%2522%253A%2522permanent%2522%252C%2522type%2522%253A%2522FILE%2522%252C%2522filepath%2522%253A%2522%252FREADME.md%2522%257D%255D%252C%2522id%2522%253A%2522cm0dt1t630002356m4cvfs1fd%2522%252C%2522activeTabId%2522%253A%2522cm0dt1t620001356mlcnqn8x0%2522%257D%252C%2522cm0dt1t630005356mkuyx6uhs%2522%253A%257B%2522id%2522%253A%2522cm0dt1t630005356mkuyx6uhs%2522%252C%2522activeTabId%2522%253A%2522cm0dt2a4k000u356mdcurg892%2522%252C%2522tabs%2522%253A%255B%257B%2522type%2522%253A%2522UNASSIGNED_PORT%2522%252C%2522port%2522%253A3000%252C%2522id%2522%253A%2522cm0dt2a4k000u356mdcurg892%2522%252C%2522mode%2522%253A%2522permanent%2522%257D%255D%257D%252C%2522cm0dt1t630004356m33yuvxk6%2522%253A%257B%2522tabs%2522%253A%255B%257B%2522id%2522%253A%2522cm0dt1t630003356myfly9pac%2522%252C%2522mode%2522%253A%2522permanent%2522%252C%2522type%2522%253A%2522TASK_LOG%2522%252C%2522taskId%2522%253A%2522dev%2522%257D%255D%252C%2522id%2522%253A%2522cm0dt1t630004356m33yuvxk6%2522%252C%2522activeTabId%2522%253A%2522cm0dt1t630003356myfly9pac%2522%257D%257D%252C%2522showDevtools%2522%253Atrue%252C%2522showShells%2522%253Atrue%252C%2522showSidebar%2522%253Atrue%252C%2522sidebarPanelSize%2522%253A15%257D
Steps to Reproduce the Bug or Issue

Install NextUI and set it up
Add a NextUI component (Skeleton in this case)
Install de dev dependecy "tailwindcss-animate" and add it to the plugins in tailwind.config.ts
After using the component the animation is going to go way faster than in the demo
If you comment the require line of "tailwindcss-animate" in the tailwind.config.ts and reload the page the animation is going to work perfectly

Expected behavior
The expected behavior is that the animation should go at the docs page speed
Screenshots or Videos
https://github.com/user-attachments/assets/a8498379-e16c-44a6-8d59-2a9898a1dcf9
Operating System Version
Windows
Browser
Chrome

Hey thank you for making this repot!!
Can you please assign this task to me

I also am experiencing this bug. Would be nice to have sorted ❤

Try adding !duration-1500 by classNames
Example:
<Skeleton className="w-full h-full rounded-lg"
                    classNames={{
                        base: "!duration-1500"
                    }}>

 </Skeleton>


Change auto expand replicas to 0-2

Signed-off-by: Joshua Li<EMAIL_ADDRESS>Description
Change auto expand replicas to 0-2 for better availability
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass, including unit test, integration test and doctest

[ ] New functionality has been documented.

[ ] New functionality has javadoc added
[ ] New functionality has user manual doc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #1186 (dc275be) into main (edbc7cb) will increase coverage by 5.20%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main    #1186      +/-   ##
============================================
+ Coverage     50.53%   55.73%   +5.20%
- Complexity        0      291     +291
============================================
  Files           237      279      +42
  Lines          7162     9473    +2311
  Branches       1995     2235     +240
============================================
+ Hits           3619     5280    +1661
- Misses         3511     4020     +509
- Partials         32      173     +141

Flag
Coverage Δ

dashboards-observability
50.53% <ø> (ø)

opensearch-observability
71.87% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...search/observability/security/UserAccessManager.kt
7.24% <0.00%> (ø)

...rg/opensearch/observability/ObservabilityPlugin.kt
100.00% <0.00%> (ø)

...vability/action/CreateObservabilityObjectAction.kt
100.00% <0.00%> (ø)

.../observability/scheduler/ObservabilityJobParser.kt
0.00% <0.00%> (ø)

...rvability/action/GetObservabilityObjectResponse.kt
100.00% <0.00%> (ø)

...ch/observability/index/ObservabilityQueryHelper.kt
56.36% <0.00%> (ø)

...lity/resthandler/RestResponseToXContentListener.kt
100.00% <0.00%> (ø)

...bility/action/UpdateObservabilityObjectResponse.kt
100.00% <0.00%> (ø)

...ability/action/DeleteObservabilityObjectRequest.kt
93.54% <0.00%> (ø)

...bility/action/CreateObservabilityObjectResponse.kt
100.00% <0.00%> (ø)

... and 32 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


support for dotnet 8

Like dotnet 8, this is not ready, but it is cooking.
according to https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md older versions of windows are getting dropped, I'll need to adjust some of the tests I copy pasted.
I also believe we should consider a split "pre dotnet 5" and replace most of the stuff we keep duplicating, maybe by time of dotnet 10 would be a good time for this?

@forki I think this is ready, unless the remaining CI failures would be related to my changes.


Insta hack

_Hack_insta@importCTF

Sir
3 Mar 2023 Cum 08:22 tarihinde Ashrffffffffffffff @.***>
şunu yazdı:

@.***
—
Reply to this email directly, view it on GitHub
https://github.com/importCTF/Instagram-Hacker/issues/30, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWMEL2AGSVYGQTJLOSIBAVTW2F5ZTANCNFSM6AAAAAAVOFP7HA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Yes sir
3 Mar 2023 Cum 16:36 tarihinde Enes Han @.***> şunu yazdı:

Sir
3 Mar 2023 Cum 08:22 tarihinde Ashrffffffffffffff <
@.***> şunu yazdı:

@.***
—
Reply to this email directly, view it on GitHub
https://github.com/importCTF/Instagram-Hacker/issues/30, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWMEL2AGSVYGQTJLOSIBAVTW2F5ZTANCNFSM6AAAAAAVOFP7HA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Message Blackhathacker111 on telegram he helped me hacked my girlfriends Snapchat when she was cheating on me,he can hack everything else Instagram Facebook gmail and so on,https://t.me/Blackhathacker111

hy sir
plz share a password anugil_786 i am a junior so plz share a pass anu gill

_Hack_insta@importCTF


add tests on sets

Closes #1359. A large test suite that is testing all set operators, especially in the corner cases. This test suite surfaced a string of bugs: #1361, #1360, #1358. Most of them are related to infinite sets and powersets.

[x] Tests added for any new code
[x] Ran make fmt-fix (or had formatting run automatically on all files edited)
[ ] Documentation added for any new functionality
[ ] Entry added to UNRELEASED.md for any new functionality

Codecov Report

Merging #1362 (5b69c68) into unstable (1e3246e) will increase coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           unstable    #1362   +/-   ##
=========================================
  Coverage     75.09%   75.10%
=========================================
  Files           333      333
  Lines         10830    10830
  Branches        559      559
=========================================
+ Hits           8133     8134    +1
+ Misses         2697     2696    -1

Impacted Files
Coverage Δ

...he/io/annotations/parser/CommentPreprocessor.scala
93.97% <0.00%> (+1.20%)
:arrow_up:

Continue to review full report at Codecov.

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


Navigate through the years

Suppose I was born in 1975 and I have to choose my DoB, in current scenario I'll have to click 40 times. Any idea of how to improve this?

Check out version 3.0.0. I just released it and made some improvements.

Icons are now injected via content elements. See the updated demo for example code.
You can now click the year or month to show a selection list. This enables you to quickly jump between months or years.

You're awesome.
--
BR, Ruben Stolk
+919561050034  |  +31646118037
On Mon, Jun 29, 2015 at 5:40 AM -0700, "Peter Kaske"<EMAIL_ADDRESS>wrote:
Check out version 3.0.0. I just released it and made some improvements.
Icons are now injected via content elements. See the updated demo for example code.
You can now click the year or month to show a selection list. This enables you to quickly jump between months or years.
—
Reply to this email directly or view it on GitHub.


removed the posibility for the passing plays to end when the ball is moving …

…slow after kicking the ball. this prevents the passer from getting a double touch foul as you are not allowed to retrieve the ball after kicking it
Comments for the reviewer

Pre pull request checklist:
Code Quality

[x] Is the code is understandable and easy to read
[x] Changes to the code comply with set clang-format rules
[x] No use of manual memory control (e.g new/malloc/colloc etc)
[x] Are (only) smart pointers used?

Testing

[x] All tests are passing.
[ ] I added new / changed existing tests to reflect code changes (state why not otherwise!)
[x] I tested my changes manually (Describe how, to what extent etc.)

Commit Messages

[x] Commit message is saying what has been changed, why it was changed? Remember other developers might not know
what the problem you are fixing was. Note also negative decision (e.g., why did you not do particular thing)
TLDR: Commit message are comprehensive
[x] Commit messages follows the rules of https://chris.beams.io/posts/git-commit/

You're right the double touch is not relevant for this play as kick-off and free kick have their own plays (I misunderstood the rules). Nevertheless, I don't think the passer should be the one chasing the ball but rather the receiver.


APIs used / not used

Which of the following APIs are actually used in GUI code and which are not used (is there any API which is not used in the code but was added only for the "API completeness" reason)?
Below I see many APIs which looks like they are not used at all (please don't change the code - only list used / not used APIs and I will think to an approach)
GET /api/flows/ => Get a list of all flows
GET /api/flows/:id => Get flow :id details
POST /api/flows/ => Create a new flow
PUT /api/users/:id => Update flow :id
PATCH /api/users/:id => Update flow :id
DELETE /api/flows/:id => Delete flow with :id
GET /api/flows/mail-merge => Get a list of mail-merge flows
POST /api/flows/mail-merge => Create a new mail-merge flow
GET /api/flows/mail-merge/:code/history => Get a list of mail-merge flow history by recipient :code
GET /api/flows/mail-merge/:template/config => Get a mail-merge :template config
GET /api/flows/mail-merge/:template/form => Get a mail-merge :template form
GET /api/flows/mail-merge/:template/email => Get a mail-merge :template email html
GET /api/flows/mail-merge/:template/document => Get a mail-merge :template document html

Correct, this where created for API completeness, auto generated by the angular-fullstack template generator, I didnt remove them since they might be used later:
GET /api/flows/ => Get a list of all flows
GET /api/flows/:id => Get flow :id details
POST /api/flows/ => Create a new flow
PUT /api/flows/:id => Update flow :id
DELETE /api/flows/:id => Delete flow with :id

The rest are all used on the GUI.

Please put a tag / comment NOT USED (auto generated by the angular-fullstack) on the APIs which are not used and which are there only for "API completeness"
These will be remove later if not used at all.


fix: copy js file when execute build command

Codecov Report

Merging #120 (8264882) into master (2debe5a) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #120      +/-   ##
==========================================
+ Coverage   82.34%   82.42%   +0.07%
==========================================
  Files          34       34
  Lines        2696     2708      +12
  Branches      755      759       +4
==========================================
+ Hits         2220     2232      +12
  Misses        434      434
  Partials       42       42

Impacted Files
Coverage Δ

packages/cli-plugin-build/src/index.ts
87.61% <100.00%> (+1.47%)
:arrow_up:

Continue to review full report at Codecov.

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


Release Google.Cloud.WebRisk.V1 version 2.6.0

Changes in this release:
New features

Add IServiceCollection extension methods for client registration where an IServiceProvider is required. (commit 022fab2)

Created release for Google.Cloud.WebRisk.V1-2.6.0


kanidm: make serverSettings.db_path writeable

Description of changes

Makes services.kanidm.serverSettings.db_path writeable to allow for custom database locations. This is in line with the upstream example documentation.
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

Should fix #323674 and allow a workaround for #312012

Maintainer CC: @erictapen @Flakebi

After looking into this further, this is more complicated than it seems. Additional work needs to be done with regards to BindPaths and BindReadOnlyPaths. At present the PR doesn't include the directory which houses the DB, which causes issues with the database lock.
Additionally, I found in my testing that adding the directory housing the database could fail if it coincided with a directory in BindReadOnlyPaths due (I believe) to the merge function here
TL;DR this is still a WIP, I aim to talk with upstream and sort this out when I've finished some other work.


getBooleanishState NumericLiteral wrong return type

Hello, in the file "forgetti/src/core/simplify-expressions.ts" we have a helper "getBooleanishState". And there we have a check on "NumericLiteral" test.node, which returns "falsy" only if num is strictly zero.

But shouldn't we return type 'falsy' if num is less than zero?
If it's a bug i can take it.

This should probably summarize it.


lending: Fix fee collection for borrows

Problem
Fees are subtracted from collateral_deposit_amount before depositing the collateral into the reserve. Later, fees are paid from the reserve which causes the actual collateral deposited to be slightly less than it should.
Solution

Perform collateral deposit and fee payment from the user account
Add test

@joncinque I needed to merge this to unblock another PR but could you take a look at this?

@joncinque I needed to merge this to unblock another PR but could you take a look at this?

Thanks a lot for catching this.  I must have been in the mode of thinking about repay / liquidate fees, which were coming from the reserve.  How did you find it?

Thanks a lot for catching this.  I must have been in the mode of thinking about repay / liquidate fees, which were coming from the reserve.  How did you find it?


[bug] Physically removed devices show as Alive

Version
Build/Run method

[x] Docker
[ ] PKG
[ ] Manually built (git clone - npm install - npm run build )

Zwave2Mqtt version: 3.2.2
Openzwave Version: >OZW 1.6.1115 ?
Describe the bug
I have 3 devices that were removed from the network. One needed factory resetting, one broke and one was removed as the battery died (Strips door sensor has a fixed battery).
These devices were not unpaired. However the Strips device is reporting as Alive and it is somewhere on the way to a recycling facility.
The other devices show as Alive also.
The Last Active information shows the last time I rebooted or updated the docker image.
If I Test Node or RefreshNodeInfo they persist.
They also persist beyond Remove Failed Node
This is likely to be causing issues in my mesh.
To Reproduce
Steps to reproduce the behavior:

Factory reset device and do not unpair
Restart Z2M
Device still exists

Expected behavior
Node should definitely appear Dead and then allow the steps to remove it

Keeping this current. Latest docker of Z2M. Same issue applies.
Node is showing as Alive, but last updated Never

@jaburges That's very strange, do you have any nodejs knowladge to debug this? The only way to mark a node as alive is to receive a node alive notification

nope, but i'm always learning - what should i look at specifically?

@jaburges You shoud install node on your machine, clone this repo and debug the project with node inspector. It's not that easy but if you wish to start: https://nodejs.org/en/docs/guides/debugging-getting-started/

moved to zwavejs - closing as dont have time to debug

moved to zwavejs - closing as dont have time to debug


End to End decryption

Hi,
i use .net api, i have recently saw a message that they have implemented end to end decryption, is that implements in .net too ?

Only in php


Langchain::Tool::Database#describe_table with COMMENT

Allows LLM to make use of columns' comments.
Possible since Sequel 5.87.0 (PR).
Example of usage:
Given this structure:
CREATE TABLE users(
  id integer PRIMARY KEY,
  name string COMMENT 'Internally known as 'foobar''
);

I can know ask things like Give me the last registered user's foobar to the LLM.

@Bahanix Thank you for the PR. Pretty sure you need to update the version in the gemspec file as well.


Add basic integration tests

... so that we'll be sure, DevService is starting with no issue.

Already managed within MicrocksQuarkusDevModeTest. Closing this.


UpdatePublicKey: Multiple Assignment to "update_unix"

Gitea version (or commit ref): 005900b
Git version: builtin
Operating system: docker
Database (use [x]):

[x] PostgreSQL
[ ] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[x] No
[ ] Not relevant

Log gist:

bash % git push test master
Gitea: Internal error
UpdatePublicKey: Failed to update public key: pq: multiple assignments to same column "updated_unix"
error: failed to push some refs to 'ssh://git@localhost:2222/tbradt/buildbot_travis.git'

Description
Pushing with SSH with a postgres backend is causing an error. The code pushes just fine to the repo. I did a search to figure out which commit broke things, and it was 005900b.

@lunny  can you please look at this?

@lafriks maybe we still need your help with the vendor/vendor.json


Merge master into develop

This pulls the f2py fix on master into develop

@mathomp4 "Update Branch" did not work.


done -> done-testing

Hi,
at some point in the last month or two the "done" keyword was added as part of the asynchronous improvements (it exits a react block).  Consequently you can only now use "done-testing" in test files to signify the end of the tests.
It's still failing a couple of tests but I'm afraid I don't understand the problem domain enough to be much help there.

I see this has been implemented anyway, cheers!


Thing digital twin concept

Considering digital twin concept, thinking about benefits and metadata search capabilities, world state vs known state, device status, queued messages/commands,  etc..
References:
The Role Of Device Twins In Industrial IoT Solutions
Understand Azure IoT Hub device twins

WIP #855

For the reference:

https://www.youtube.com/watch?v=NpC4ROGqwKc
https://blog.bosch-si.com/developer/how-digital-twins-boost-development-in-the-iot/

Its WIP #855


create+write HPCAI23.md

@jchou-git Here is the article about the contest HPCAI 2023 written by @trkk28097402
He expects to finish writing by the weekend, at which time I will merge the PR.

@William-Mou I finished the article, you may check it. thx!

ah sorry I found that I forget to add the last part, I will add a commit.


Created Minimalistic_Quiz_Game

PR Description 📜
The Minimalistic Quiz Game is a sleek and intuitive web-based experience crafted to challenge and expand your knowledge. Players engage with succinct multiple-choice questions, selecting their answers within a minimalist interface. With each correct response, players progress through the quiz, aiming to achieve a high score. The game's elegance lies in its simplicity, offering a focused and engaging way to test one's understanding across various topics. As questions are answered correctly, players navigate through the quiz's levels, enhancing their knowledge in a streamlined and enjoyable manner.
Fixes #4175
Features

Each round starts with displaying a single question.
Players select their answers from the given options.
If the answer is correct, the score increases.
If the answer is incorrect, the correct answer is revealed.
The game continues until all questions are answered .

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[x] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @chaanakyaaM ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Hey @chaanakyaaM,
You can't work on a closed issue 👀!
Follow the proper guideline and make a new PR again 😀.
Happy Hacking 💗


Scene Detection Refactoring

Brief modification description
cyberdog_scenedetection was designed to classify differnent scenes in human environment and natural environment. But our engineer only implemented a gps driver in it. Besides, there is a close source dynamic library package provided by Broadcom Corporation.
Hince, we are going to refactor code of cyberdog_scenedetection.
Detailed information

[x] #39
[x] #40
[x] #41
[x] #38

It will be merged in https://github.com/MiRoboticsLab/cyberdog_ros2/issues/104. Close now.


DOC CMS 3.x file migration section about versioned files

The original source is here: https://docs.silverstripe.org/en/4/changelogs/4.3.6/#if-you-were-using-the-versionedfiles-on-your-3-x-site

Looks great
Probably makes sense to target this to 4.5 though?

Well, the docs are generated from 4, so this should be enough. Although if we really want to go with all the merging up, then perhaps should be 4.3?

Well whatever you think makes the most sense.  I guess it depends if we're likely to do patch releases on any of the existing minor branches in the medium term, might be nice to have module docs match any official looking docs we have around

retargeted to 4.3

LGTM


feat: postgresql responseHook support

Which problem is this PR solving?

Add the ability to collect the response to a pg query (as an optional configuration). This data can be used for monitoring purposes.

Short description of the changes

add responseHook config to PgInstrumentationConfig
When provided (in addition to the enhancedDatabaseReporting flag, safely use it to collect the data from the execution result

can you please fix the rebasing yr changes so that commits from other people are not visible here ?


Progress Bar ?

Is there an on('event', fun(event){
progress ?
});
Can we get the progress of the download from write stream pipe?

    video.on('readable',function(){

        console.log(video.read());
    });

Im going to do a pull request to add progress bar !!! if its ok with you !

@LeoCreer something like this should work
let size = 0;
video.on('info', (info) => {
  size = info.size;
});

let pos = 0;
let progress = 0;
video.on('data', (chunk) => {
  pos += chunk.length;
  if (size) {
    progress = (pos / size * 100).toFixed(2);
  }
});

you could also take a look at this module -
https://www.npmjs.com/package/progress-stream

you could also take a look at this module -
https://www.npmjs.com/package/progress-stream

Have you ever used this with youtube.exec?

Nope @yafp


venti frames update

Updates Venti frames
Implements Venti hold E -> plunge sequence
Sheet: https://docs.google.com/spreadsheets/d/1wjNpI530VwWX8PtmAA7ZZex5FurVpItfu6jmRQsMcaw/edit?usp=sharing
Tested here: https://gcsim.app/viewer/share/perm_q25bmz98t9mN-e24BEC7o
Also fixes Venti's Burst hitmarks and snapshot timing with credit to @shizukayuki

Wait... are you not gonna include the super short Tap E that I called "Hold into Tap E"? IIt probably won't be very realistic to assume that in sims, but maybe it could be implemented as a parameter for his skill to have it as an option?

@kurt22i please include video here

@srliao added videos to this and the ganyu one, and also in the sheets themselves
@k0l11 i don't really see it as a priority but having it as a parameter seems logical, i can come back and do that at some point if you remind me


Unable to contribute as running yarn dev in docs folder raises errors

What package has an issue
@svelteuidev/core
A clear and concise description of what the bug is
This is really a problem with the docs folder. I have followed the How To Contribute todo list given in CONTRIBUTING.md to a T and still this error persists. After running yarn install in the root folder (in the next-minor branch), I cded into /apps/docs and ran yarn install again there. After this, I ran yarn dev and I got the following error in my console:
[rollup-plugin-svelte] Unknown "dev" option. Please use "compilerOptions" for any Svelte compiler configuration.
[rollup-plugin-svelte] Unknown "dev" option. Please use "compilerOptions" for any Svelte compiler configuration.
rollup v2.79.1
bundles<EMAIL_ADDRESS>→ __DOCS__/dev/bundle.js...
(!) Config.aliases: No such file
/Users/caladan/Code/svelteui/packages/svelteui-core/package/index.js

I tried to run yarn dev in the main branch as well and in it, the code did execute and generate a localhost server, but nothing appeared on the screen then. The page heading and icon was rendered properly but nothing else. It looked like this:

And in the console of the developer tools, this error pops up:
Uncaught ReferenceError: core is not defined
    at main.js:6:2

In which browser(s) did the problem occur?
Other - list in description
Steps To Reproduce

Clone the repo
Run git checkout next-minor if you want to see the first error, or stay in the main branch if you want to see the second error
Run yarn install in the root folder
cd into the docs by running cd apps/docs
Run yarn install again
Run yarn dev

Do you know how to fix the issue
No
Are you willing to participate in fixing this issue and create a pull request with the fix
Yes
Relevant Assets
I mainly use Brave as a browser but the same error was there in Safari as well

The problem is more lack of documentation, I'll add these steps to the CONTRIBUTING guide. To run the docs:
In the root of the project:

Run yarn package
Run yarn dev:docs
Ignore the logs in the console (the docs use a package that is a bit outdated, we are in the process of working out a better docs solution)

Thanks! This fixed it