[Feature Request] List Operation -- Jump to specific page.

Feature Request
What's the feature you think Backpack should have?
When paging through items in a List Operation, you basically only have 4 options: 1 page forward, 1 page backward, first page, or last page. I would be useful to be able to jump to any page in the range.
Have you already implemented a prototype solution, for your own project?
I have not attempted this myself yet.
Do you see this as a core feature or an add-on?
Core feature.

Hey @trip-somers ,
Thanks for the suggestion - we'll keep it in mind, but I don't think we'll include this any time soon.
It seems like a very specific feature that very few people will actually use. When viewing a table, I think it's unlikely that somebody knows what page they want to see. Most likely they know what entries they want to see, and for that we have search and filtering. For that reason, I don't think it should be part of the core... it seems like a pretty niche feature to me.
Please don't let this stop you from adding other suggestions - we never lock issues on purpose, so that other people can come in and give their opinions. If it turns out we were wrong, we'll gladly admit that and go back on our decision. Of course, let us know if you disagree.
Cheers!
PS. You should be able to create that feature yourself, however, either by

(A) publishing and changing datatables.logic.blade.php (but you'll be forfeiting updates to this file)... OR
(B) creating a widget (a blade file) with a dropdown and JS that does this, and including it before/after the table


Unify Estimate behavior

Up until now Estimate would be in a fully initialized state after
calling new, however after calling reset it would get fully
initialized only on the next call to record_step. This is an
unexpected disparity that this commit unifies. Now, when calling reset
you must also provide a start_value, so that the Estimate can not be
in a semi-initialized state anymore.

Thanks!


API fails for non-pyquil

import json
import requests

url = "https://api.rigetti.com/qvm"
api_key = "****************************"
headers = {'Accept': 'application/octet-stream',
           "x-api-key": api_key}

payload = {
    "type": "multishot",
    "addresses": [0, 1],
    "trials": 2,
    "compiled-quil": "H 0\nCNOT 0 1\nMEASURE 0 [0]\nMEASURE 1 [1]\n"
    }
response = requests.post(url, data=json.dumps(payload), headers=headers)
print(response)

Returns a 401 error.

@vtomole Can you print response.text to see what the specific error is? I believe the problem may be related to supplying a user_id in your headers as well as your API key. In _base_connection.py, the get_session function sets the headers as such:
session.headers.update({
     'X-Api-Key': api_key if api_key else config.api_key,
     'X-User-Id': user_id if user_id else config.user_id,
     'Content-Type': 'application/json; charset=utf-8'
})

Let me know if this is helpful.

@cbosborn Ah! There we go. Works now!


Basic settings reference

Is there a reference for the basic settings anywhere? I've search the repo and I've been able to find some explanations in tickets, but a lot of them are hard to understand. I can create a doc similar to the environment variables reference and fill in what I can, but I wonder if that will end up the same way as that reference, fairly devoid of info. :)

@dahamsta albeit not the most complete or helpful, this has been started some time ago.
Updates to this are certainly a welcome PR. Check this out: https://github.com/PowerDNS-Admin/PowerDNS-Admin/blob/master/docs/wiki/configuration/Environment-variables.md


CH3 is parent fragment of CH4 when using Scaffold Generator

Scaffold Generator was applied to the attached test set (please remove the .txt extension) in default settings.
ertl_alkenes.sdf.txt

You imported without adding implicit hydrogens to open valences, correct? At first, I thought the issue was about all the open valences i the input mols.
And you set the Scaffold Generator Side chain setting to either "only side chains" or "scaffolds and side chains", correct?
In your SDF, the "CH3" input mol has a "3" set as the 6th property in its atom block. Does this define three explicit hydrogen atoms?
I'm guessing that the CH3 input mol gets saturated by Scaffold Generator into CH4. This looks weird at first glance but would actually be expected behaviour, in my opinion.

You imported without adding implicit hydrogens to open valences, correct? At first, I thought the issue was about all the open valences i the input mols. And you set the Scaffold Generator Side chain setting to either "only side chains" or "scaffolds and side chains", correct?

Yes, the file was imported without adding implict hyrdogens. And the side chain setting was set to "scaffolds and side chains", so not quite default settings after all, sorry.

In your SDF, the "CH3" input mol has a "3" set as the 6th property in its atom block. Does this define three explicit hydrogen atoms?

The 6th property in the atom block of a v2000 connection table stands for the valences. By default it is set to 0, which indicates the default valence.

I'm guessing that the CH3 input mol gets saturated by Scaffold Generator into CH4. This looks weird at first glance but would actually be expected behaviour, in my opinion.

If you say so, and that reflects the desired behavior, feel free to close the issue. I opened it at your request.

For the sake of completeness:


Packet Post Endpoint: Stream status updates

Posting large pcap files to a space can often take a long time as zeek slowly chugs away. When a pcap is posted to a space via the POST /space/:space/packet endpoint api now provides streaming updates in order to provide clients with an idea of how far along the ingest process is:

When a the request is initiated, a zeek subprocess is spawned, and the contents of the posted pcap is piped sequentially into zeek stdin and a pcap index writer. Assuming this all starts with no errors, a 200 ok status messaged is returned once the first zeek log files in temp zeek log file directory have been written to disk. A TaskStart response is transmitted over the response stream. What data that has been written is also transformed to sorted bzng. At this point the space is queryable.
On a hardwired two second interval, the server streams back piped json status update payloads that contain: The start timestamp of ingest, the update timestamp, the total size of pcap file and the size of bytes read from the pcap file. From this information a client should be able to approximate the percentage completion of the ingest process (this won't be entirely accurate, however, it doesn't account for the time it will take transform the zeek logs in to time sorted bzng at the end).
A TaskEnd message is sent at the completion of ingest. If TaskEnd.Error is not null users will know that an error occurred during ingest. If an error occurs during ingest, the process is aborted and the space is reset.

Also:

Add api.Stream/JSONPipe functionality to make it easier to read/write piped json files over the wire.

This looks good!

This looks good!

@mccanne is that an approval I hear?

I’ve asked nibs to verify this works with existing Brim before merging

This looks great to me. It can be merged now without breaking the app, since the app just waits for the request to finish before showing the table. I'll follow soon with the UI bits.

This looks great to me. It can be merged now without breaking the app, since the app just waits for the request to finish before showing the table. I'll follow soon with the UI bits.

Thanks @jameskerr, much appreciated.

@mattnibs I'm late to this PR, but I see the ingest zql has changed  from
sort -limit<PHONE_NUMBER> -r ts
to
sort -limit 10000000 ts
is that change intentional? (just checking as it seems unrelated to the PR, and isn't easily apparent in the diff)

@mattnibs I'm late to this PR, but I see the ingest zql has changed from
sort -limit<PHONE_NUMBER> -r ts
to
sort -limit 10000000 ts
is that change intentional? (just checking as it seems unrelated to the PR, and isn't easily apparent in the diff)

Another good catch. I'll fix this in my follow up pr.

@mattnibs<PHONE_NUMBER> (the original limit) might be too high? at 100 bytes per record, that would be 100GB in mem.

ok


translation for section admin4

related: #29329
Translation for the 'admin 4' section in issue 29329.

THanks.
/lgtm
/approve


[SDPA-1941] Use forked version of vue-social-sharing to fix IE issue.

JIRA issue: https://digital-engagement.atlassian.net/browse/SDPA-1941
Changed

Use forked version of vue-social-sharing to fix IE issue - https://github.com/nicolasbeauvais/vue-social-sharing/issues/130 NOTE : If https://github.com/nicolasbeauvais/vue-social-sharing/pull/131 is merged we need to update this again to use updated version.

Screenshots

https://github.com/nicolasbeauvais/vue-social-sharing/pull/131 has been merged, need to use v2.4.3 instead


simplify definition of never and nonCanceler

_ -> pure mempty ~~ _ -> mempty ~~ mempty

You're correct that these are all equivalent, but I find it a little easier to see what's going on when everything is written out -- mempty can be a bit magical as it can fit the shape of so many different things. As this didn't get a response from other maintainers I'm going to go ahead and close it, but thank you for the PR!


update deployed URL in doc

The URL in the README is drupalvm.test but the current version now serves at drupalvn.dev (as correctly notified by the vagrant file)
thanks!

It's a bit unfortunate but the current README on GitHub always points the the development branch rather than the current stable release. I think I read @geerlingguy comment on this somewhere and back then he wasn't really into switching the git workflow model as even if the current model has it's shortcomings, it's far simpler to maintain.

Yeah, sorry about that! I'll be creating a release very soon: https://github.com/geerlingguy/drupal-vm/issues/1573


Is it possible to have rounded cells?

Is there a way of having rounded corners in cells? I have a few cells with background colours and I'd like to have them rounded, is that even possible?

The library can only produce what's available in PowerPoint.
Can you produce what you're looking for in a presentation?

Fair enough


Inserted a cpp file

This is my own personal implementation of a vector. It works better than the STL c++ vector class.

More pull requests to come on 5th October. Stay tuned.


FIX Handle TRAIT in i18nTextCollector

Applies fix committed to v5 to v4.13. Addresses issue identified in https://github.com/tractorcow-farm/silverstripe-fluent/issues/823 and https://github.com/tractorcow-farm/silverstripe-fluent/pull/824
Original PR: https://github.com/silverstripe/silverstripe-framework/pull/10813
Attn: @GuySartorelli

Thanks @GuySartorelli. I'll use the template next time.


🐞 Bug Fix: Include napari.yaml in build

Noticed that the napari plugin wasn't discovered when installing from pypi.
This was due to defining strict package data. I added napari.yaml to that list.
To check it worked, I built a wheel and installed from it locally.
This means we will need to release again, sorry @jni

@jni I don't think I caused that test to fail? I'm not sure why that's happening.

https://github.com/jni/skan/actions/runs/5076459713/jobs/9118648227?pr=202#step:5:88

E       AttributeError: 'OpenpyxlWriter' object has no attribute 'save'

Looks like a new pandas or openpyxl release has stuffed us up... Well, that's probably another good reason for a new release! 😂 Do you mind trying to get to the bottom of it (install test deps in a clean environment and check that test) and making a separate PR for the fix? 🙏


META-INF folder missing in recompiled apk...

Hey, i'm having a problem with apktool.....the original apk im decompiling has a "META-INF" folder in it...but when i decompile and recompile it... the "META-INF" folder goes missing.....What can i do?please help....Thanks in advance.

As per - http://ibotpeaches.github.io/Apktool/documentation/#rebuild
You can use -c / --copy-original to retain the META-INF and original AndroidManifest.xml. Note the warning that this method of retaining original signature doesn't appear to work past API 18.
Either way, this isn't a support forum at all. This is a bug tracker.

Thanks that helped...


fix(auth): Update GoTrue Image to avoid signup link generation bug

What kind of change does this PR introduce?
GoTrue version 2.145.0 has a bug where generating a signup link will fail with "user_not_found", which was fixed in 2.146.0 (https://github.com/supabase/auth/pull/1514). Since 2.145.0 is locked in the CLI, we can't get the bug fix out, and the only fix is to downgrade to an older version.
This PR updates the image to 2.149.0 which is the most recent version as of 2024-04-22 so the signup link generation works again.
What is the current behavior?
The CLI is fixed on GoTrue version 2.145.0 which has a bug related to signup link generation.
What is the new behavior?
The CLI now uses GoTrue version 2.149.0 which does not have a bug related to signup link generation.
Additional context

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
7 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.03%) to 58.174%

Files with Coverage Reduction
New Missed Lines
%

internal/storage/rm/rm.go
2
92.86%

internal/gen/keys/keys.go
5
11.76%

Totals

Change from base Build<PHONE_NUMBER>:
-0.03%

Covered Lines:
6494

Relevant Lines:
11163

💛  - Coveralls

Also you can overwrite the local gotrue version with echo "v2.149.0" > supabase/.temp/gotrue-version
This works without updating CLI


new item: slime in a bucket

also from tweakin, and apparently also from quark.
how it works: pick up a slime by right-clicking it with an empty bucket. You receive a slime in a bucket. If you are standing in a slime chunks the slime will cutely wobble up and down. I'd like to use the same animations as in quark, but we need to ask Vazkii for permission as it will be hard to properly attribute the texture in-game.

Got permission from Vazkii a while ago, implementing this now :)


Compiling becomes slowly when running via gulpfile.coffee

Compiling becomes slowly when running via gulpfile.coffee.
If I'm running gulpfile.js directly then foundation compiling in < 10 ms
Otherwise it compiles in ~2-3 sec.
Have tried to precompile gulpfile.coffee and require('./compiled/gulpfile.js'); but also foundation compiles in ~2-3 sec.

Ahhhh nvm, gulp shows that task compiles in < 10ms if I don't return gulp.src. It's not real time compilation. I did not pay attention on return because coffee automatically return last object in function, my bad


PORT 5000 is no longer a good default port

On the new versions of macOS 12.0.1, the port 5000 is used by the operating system for the Control Center. We should choose a new default port (ex: 3000) that would conflict with the majority of macOS installations out there.

Just fyi, I'd say avoid using 3000 since it is used by default for a lot of programming frameworks and things of the like.  Perhaps something less (for lack of a better word) round, (ie 3000, 4000, 5000, etc), such a 5001, 5050, etc.?


FIX double links in external, from scrap, refine extracting links

Extracting links from bato is working but it:

[ ] Doubles links if it is already in extracted links, or if link is like xxxx.com/ and xxx.com/info. It is the same, so i need to check only 'www.link.xxx/some-number-title'.
[ ] add message what links got extracted, after i click bato link add, so I can see if manga updates link was present on bato.
IF there wasn't, I need to add finction to manually add it.

done with recent pull request


Update libgit2 dependencies

Pulls in a few fixes for libgit2, including some security-related
updates.

r? @ehuss
(rust_highfive has picked a reviewer for you, use r? to override)

@bors r+

:pushpin: Commit 2a670c128b7da4fbf303b10dd73991a324119a51 has been approved by ehuss

:hourglass: Testing commit 2a670c128b7da4fbf303b10dd73991a324119a51 with merge 4bdb6fd371111e2ec80811822c130dde66af18df...

:sunny: Test successful - checks-azure
Approved by: ehuss
Pushing 4bdb6fd371111e2ec80811822c130dde66af18df to master...


Generalize debug endpoint

Description
One endpoint to get all the debug/diagnostic information.
How was this PR tested?
In progress.

I want to add more unit tests to this PR, but it is essentially ready for review.


Update NeuroTreeModels extensions

NeuroTreeClassifier is now the constructor for classification models. This has been reflected in the docs examples: https://evovest.github.io/NeuroTreeModels.jl/dev/tutorials-classification-iris

cc @izagorac I think this is an easy fix here: https://github.com/JuliaTrustworthyAI/CounterfactualExplanations.jl/blob/0e2c0fb0ef6f65920613571b0682b56e0cb60a0d/ext/NeuroTreeExt/neurotree.jl#L60


Copilot does not answer

Copilot Chat Extension Version:
VS Code Version:
OS Version:
Logs:

Steps to Reproduce:

Can you please describe what type of request you're making so we can reproduce the issue? Example files / queries will help a lot. You can also try clearing your chat history.


how to startup seata-server in background mode

[ ] I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description
seata-server 0.5.2
when I startup the server in  centos7 , command is sh seata-server.sh 8099 file,but it is not a  background mode, By use ctrl+c seata server will not work,and client will have exception like
com.alibaba.fescar.common.exception.FrameworkException: can not register RM,err:can not connect to fescar-server.
so how to startup seata-server in background mode?
Ⅱ. Describe what happened
If there is an exception, please attach the exception trace:
Just paste your stack trace here!

1、 When I used debug to test http://<IP_ADDRESS>:8084/purchase/rollback, but I found that storage_tbl didn't rollback, it Subtract 1
Ⅲ. Describe what you expected to happen
Ⅳ. How to reproduce it (as minimally and precisely as possible)

xxx
xxx
xxx

Ⅴ. Anything else we need to know?
Ⅵ. Environment:

JDK version :
OS :
Others:

seata server have no logs dir


Iteration based on "prefix"

Is it possible to Iterate item with just providing "prefix" of the key. Just like Badger - https://github.com/dgraph-io/badger#prefix-scans

As we cache web page using the URL's path, I cached something with keys like /foo/bar and /foo/bar/baz . So removing cache /foo/bar should be able to remove /foo/bar cache and /foo/bar/*/**. At least the we could have something like
func (c *Cache) AllKeys() []string {
    var ret []string
    for i,_ := range c.items {
        ret = append(ret, i)
    }
    return ret
}

So we can iterate of all cached keys.

I have a similar use-case. I'm thinking of creating a pull request.

At the moment, It's not possible.
I have a similar use-case. I'm thinking of creating a pull request.


query has no method for ::SQLite.DB

db = SQLite.DB("foo.sqlite")
query(db, "select * from bar")
Error: MethodError: query has no method matching query(::SQLite.DB, ::ASCIIString)
Closest candidates are:
 query(::SQLite.SQLiteDB(T<:AbstractString), ::AbstractString)
 query(::SQLite.SQLiteDB(T<:AbstractString), ::AbstractString, Any)

I'm not sure, but maybe this could have the same origin as https://github.com/JuliaDB/SQLite.jl/issues/84

@Ph0non , also try
julia> Pkg.checkout("SQLite")

if checking out DataStreams doesn´t do the job.

This is actually by design for the moment to ensure backwards compatibility with 0.3, though I can't remember exactly why at the moment.

Since both DataStreams and SQLite packages were updated today on METADATA, I can´t reproduce this error after doing a Pkg.update() on vertion 0.4.2-pre.

Same for me.


Add issue and PR templates

Add templates that will automatically appear in the editing window whenever someone opens an issue or a pull request.
This means that we can gently steer people towards providing the information we want, rather than having to ask for it every time.
These templates were adapted from https://github.com/stevemao/github-issue-templates/tree/master/conversational

LGTM

LGTM 2


Am I using this wrong ?

Puppet Version: 7.30 (client and server)
Module version: 1.1.0
Client/Agent OS: Windows 11
Server OS: RHEL8
Trying to use this module to handle cases where the hostname of a client changes so we have code that does this:
if ( $facts['networking']['hostname'] != $trusted['certname'] ) {
  # Save off the old name
  $oldcertname = $trusted['certname']
  file { 'update_csr':
          ensure  => file,
          path    => "${::puppetconfdir}/csr_attributes.yaml",
          content => template('puppetagent/csr_attributes.yaml.renewal.erb'),
          owner   => $::rootuser,
          group   => $::rootgroup,
          mode    => '0644',
   }
   ~> puppet_certificate { $facts['networking']['hostname']:
          ensure      => 'valid',
          waitforcert => 60,
          onrefresh   => 'regenerate',
   }
   ~> ini_setting { 'update_puppet_conf':
            ensure  => present,
            path    => "${::puppetconfdir}/puppet.conf",
            section => 'agent',
            setting => 'certname',
            value   => "${facts['networking']['hostname']}",
    }
}

We have autosign enabled, so the first step moves in a csr_attributes.yaml with a password set for that autosign to run, second steps calls for the new cert, last step changes puppet.conf 'certname' to the new name.
During testing we get this (server names redacted) in the agent logs:
- Submitted certificate request for 'rename1002' to https://<puppetserver>:8140/puppet-ca/v1
- Downloaded certificate 'rename1002' with fingerprint (SHA256) A9:04:2E:49:43:86:DA:1F:1D:21:7D:6C:CD:95:73:87:03:1D:D6:F8:B6:23:B0:DA:1A:A2:C2:A1:09:71:27:94
- created
- Failed to call refresh: Could not submit certificate request for 'rename1002' to https://<puppetserver>l:8140/puppet-ca/v1 due to a conflict on the server
- Could not submit certificate request for 'rename1002' to https://<puppetserver>:8140/puppet-ca/v1 due to a conflict on the server
Wrapped exception:
Bad Request

So am I calling "puppet_certificate" wrong in this use case or possibly missing a required step ?

I'll answer myself - yes, yes I was.
Don't need "onrefresh   => 'regenerate'," in this use case.


Update the demo with v2

While we have merged code for v2, we are working to create a demo Shopify store for easier cloning and deploying. You currently need to provide the environment variables outlined in the .env.example file.
SHOPIFY_STOREFRONT_ACCESS_TOKEN=
SHOPIFY_STORE_DOMAIN=
SHOPIFY_REVALIDATION_TOKEN=

What is the SHOPIFY_REVALIDATION_TOKEN used for? I cannot see any reference in the code.  Also, the code is functionally broken, as the homepage hasn't completed.

@iamzifei I am actually removing it in #974. It's not needed currently. Eventually it will be re-added when on-demand ISR is ready and documented.

Thank you for moving to this v2, I find the v1 more complex and easy to understand without documentation.
I'm still working with the v1, I hope to move to this new version very soon, it seems to give us more possibilities.
Thank you again guys for this incredible work.

Is there any roadmap or timeline about when the V2 will be the working version and replace the current demo site?
It would also be good if we could have Shopify Admin API options that allow writing data in some circumstances.

v2: https://demo.vercel.store
v1: https://commerce-v1.vercel.store


Common Table Expressions (CTE's) do not work for Microsoft SQL Server database

Problem
Common Table Expressions (CTE) queries are not working as expected in SQL Lab against SQL Server databases. These are queries written using the WITH clause.
Steps to Reproduce
Start superset using:
superset run -p 8080 --with-threads --reload --debugger

Add a SQL Server database and tables in Sources.
Make sure to place a check for Allow DML and ensure that it is selected and set to True.
Navigate to SQL Lab. Run the following query:
WITH t AS (SELECT 1 a) SELECT * FROM t

Expected Result
------
| a  |
------
| 1  |
------

Observed Result
The following error message is seen:
2019-08-20 14:07:53,005:ERROR:root:('42000', "[42000] [FreeTDS][SQL Server]Incorrect syntax near the keyword 'WITH'. (156) (SQLExecDirectW)")
Traceback (most recent call last):
  File "/home/user/anaconda3/envs/superset/lib/python3.6/site-packages/superset/sql_lab.py", line 190, in execute_sql_statement
    db_engine_spec.execute(cursor, sql, async_=True)
  File "/home/user/anaconda3/envs/superset/lib/python3.6/site-packages/superset/db_engine_specs.py", line 421, in execute
    cursor.execute(query)
pyodbc.ProgrammingError: ('42000', "[42000] [FreeTDS][SQL Server]Incorrect syntax near the keyword 'WITH'. (156) (SQLExecDirectW)")
2019-08-20 14:07:53,017:INFO:werkzeug:<IP_ADDRESS> - - [20/Aug/2019 14:07:53] "POST /superset/sql_json/ HTTP/1.1" 500 -

System and Environment Details
Database: Microsoft SQL Server 2017
Operating System: Red Hat Enterprise Linux 7 x86_64
Python: Python 3.6.7 (Anaconda Python)
Superset:
Superset 0.33.0rc1
flask 1.1.1
werkzeug 0.15.5

Other packages:
sqlalchemy 1.3.7
sqlparse 0.3.0
unixodbc 2.3.7
pyodbc 4.0.23

FreeTDS 1.1.11

Additional Notes
The query runs as expected against the same database:

Directly in Microsoft SQL Server Management Studio 17
Through FreeTDS (by running tsql -S <FQDN> and then executing the query)
Through pyODBC and SQLAlchemy in a python program.

The query runs as expected against a PostGreSQL database through SQL Lab.

Reproduced on master; running the same on sqlite works just fine. Will take a closer look.

Looking into this, it turns out that the bug stems from the fact that MSSQL uses the non-ANSI TOP syntax for limiting row count (SQL Lab sticks on a limit on each query, which is currently causing this problem). I'm sure we can work around this issue somehow, e.g. by disabling auto-limiting for non-ANSI DBs. However, I don't expect non-ANSI functionality to be as highly prioritized as ANSI SQL compliant syntax, i.e. expect some functionality in Superset to be less comprehensive for MSSQL than e.g. Postgres. We'll be sure to add a warning in the docs for this once we establish to what extent non-standard syntax is supported.

Looking into this, it turns out that the bug stems from the fact that MSSQL uses the non-ANSI TOP syntax for limiting row count (SQL Lab sticks on a limit on each query, which is currently causing this problem). I'm sure we can work around this issue somehow, e.g. by disabling auto-limiting for non-ANSI DBs.

AFAIK, only SQL Server and Access use the TOP syntax and while Access is not commonly used anymore, SQL Server is still quite prevalent in "Enterprise" settings. This particular use-case should be handled because CTEs are a very mainstream and extremely useful feature to use.

However, I don't expect non-ANSI functionality to be as highly prioritized as ANSI SQL compliant syntax, i.e. expect some functionality in Superset to be less comprehensive for MSSQL than e.g. Postgres.

I totally understand and agree with this. I avoid non-ANSI SQL functionality in any database like plague and lack of support for non-ANSI features in tools hasn't caused me any pain yet!

We'll be sure to add a warning in the docs for this once we establish to what extent non-standard syntax is supported.

That would be great!

Please take a look at my PR that fixes the immediate problem with CTEs on MSSQL (apparently this should also fix the same problem on DB2, Oracle and Teradata). Adding full support for limits on non-ANSI engines is not something I feel an immediate urge to do, and quite frankly I don't want to encourage DB vendors to procrastinate on moving away from bespoke syntax. But anyway, let me know if this is ok for your use case.

@villebro I am currently unable to test the fix. The docker environment for development fails to initialize:
Step 13/23 : RUN pip install --upgrade setuptools pip     && pip install -r requirements.txt -r requirements-dev.txt -r requirements-extra.txt     && rm -rf /root/.cache/pip
 ---> Running in 757208a956a6

Collecting setuptools
  Downloading https://files.pythonhosted.org/packages/b2/86/095d2f7829badc207c893dd4ac767e871f6cd547145df797ea26baea4e2e/setuptools-41.2.0-py2.py3-none-any.whl (576kB)
Collecting pip
  Downloading https://files.pythonhosted.org/packages/8d/07/f7d7ced2f97ca3098c16565efbe6b15fafcba53e8d9bdb431e09140514b0/pip-19.2.2-py2.py3-none-any.whl (1.4MB)
Installing collected packages: setuptools, pip
  Found existing installation: setuptools 41.0.1
    Uninstalling setuptools-41.0.1:
ERROR: Could not install packages due to an EnvironmentError: [Errno 39] Directory not empty: 'packaging'

WARNING: You are using pip version 19.1.1, however version 19.2.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
ERROR: Service 'superset' failed to build: The command '/bin/sh -c pip install --upgrade setuptools pip     && pip install -r requirements.txt -r requirements-dev.txt -r requirements-extra.txt     && rm -rf /root/.cache/pip' returned a non-zero code: 1

Do you have any suggestions on what might be causing this? Thanks!

Unfortunately I an not that familiar with how the docker setup under contrib works (we use a custom Dockerfile in our env). But seems like rebuilding from scratch should help.

@villebro - I was able to test this and can confirm that everything works as expected. The test CTE as well as CTEs fetching records from the database work.
A couple of things to note:

Users would have to be careful trying to pull more data than the browser can handle
The SQL Lab UI shows the Limit 1000 button below the query box which wouldn't have any effect for queries against non-ANSI compliant databases

If you check the diff, I added a warning about using CTEs on non-ANSIs.
Btw, I'm working on something that might improve CTE support on all engines and should fix this problem on non-ANSIs, too, but we'll see how that works out. But in the meantime this is probably the best compromise I can offer.

Btw, I'm working on something that might improve CTE support on all engines and should fix this problem on non-ANSIs, too, but we'll see how that works out. But in the meantime this is probably the best compromise I can offer.

Sounds like a plan!
BTW, another tab where a user can enter custom SQL is Charts > Edit Data Source > Advanced > SQL. Users must understand that CTEs have no place there because any aggregates are done on the results of the provided query - so if someone absolutely needs to use the results from a CTE, the right way to do this would be to create a view and use that view instead, as the data source.

The query under data source is what is created when you click explore in SQL Lab. What I'm currently tinkering with is adding full CTE support, i.e. being able to write a CTE in SQL Lab and then using that as a data source in charts. Having to create a view is an inconvenient step, and being able to bypass that should make data exploration slightly easier.

Having to create a view is an inconvenient step, and being able to bypass that should make data exploration slightly easier.

Definitely an inconvenience that I am dealing with right now but would have preferred not to!

What I'm currently tinkering with is adding full CTE support, i.e. being able to write a CTE in SQL Lab and then using that as a data source in charts.

So this sounds fantastic! Thank you!

Looking more closely at this problem, it seems MSSQL is one of the few engines that doesn't support wrapping CTEs in subqueries (even Oracle supports this). Furthermore, most engines do equal predicate pushdown for CTEs and subqueries, which means that wrapping SQL Lab queries in CTEs in most cases wouldn't have a significant positive performance impact (on Postgres 11 and below CTEs actually perform worse than subqueries!). As this problem seems to be mostly an MSSQL problem, I think I'll leave this on the backlog for now, as making this work correctly would require a rather significant development effort that's difficult to justify given other more pressing issues/features.


.env file, and configuration variables with newlines

Moving this on behalf of @JeanMertz from https://github.com/deis/controller/issues/891

I've seen this issue being tested in #268, except that that involves deis config:set, not deis config:push.
I have a .env file, that I want to contain a public key:
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEMF802GSVwt2ZsFlmYR6Yy4rzZR8A
o5XaElze2V5JBjeT4fUnGrK0mjvYK/CTaCVHTwq8QsC1osfN7OifH4R+fQ==
-----END PUBLIC KEY-----
The question is: how to I get this into a .env file, and have it loaded properly as an environment variable? My attempts so far have failed.
I tried:
PUBLIC_KEY="-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEMF802GSVwt2ZsFlmYR6Yy4rzZR8A
o5XaElze2V5JBjeT4fUnGrK0mjvYK/CTaCVHTwq8QsC1osfN7OifH4R+fQ==
-----END PUBLIC KEY-----"
PUBLIC_KEY="-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEMF802GSVwt2ZsFlmYR6Yy4rzZR8A\no5XaElze2V5JBjeT4fUnGrK0mjvYK/CTaCVHTwq8QsC1osfN7OifH4R+fQ==\n-----END PUBLIC KEY-----"
and the same as above, but with single quotes.
None of these seem to do the trick.
I ended up base64 encoding the key, and decoding it on runtime, but that just seems like a workaround, not a proper solution.

@bacongobbler suggested we take a look at https://github.com/joho/godotenv to handle the env file parsing.

I like the idea of using godotenv to replace some of the custom parsing logic of the .env file. Some initial testing shows that it does correctly handles /n within a quoted value (ie QUOTED_LINEBREAK="multiline\nstring") but quoted values bring up a potential additional bug and backwards compatibility question.
Quoted values (ie QUOTED_VAR="quoted string") currently include the quotes in the environment variable value. If we consider this a bug, then we can implement linebreak support without breaking backwards compatibility by implementing the above godotenv library.
If we want to maintain backwards compatibility with old .env files that might contain quotes, this gets complicated. I have a suspicion that we would have received a bug report if users were already trying to use quotes within a .env file and they noticed the quotes ended up within the environment variable values. So this feels like an acceptable solution to me.


Investigate data at http://ml.stat.purdue.edu/xdata-taxi/ - what could be useful to plot?

We added data from some of the statistical models.  Anything else should be added as a new issue.


Implement the interface for asynchronous queries

Done in https://github.com/grafana/sqlds/pull/70


Added an event filter field to MetricCalculationSpec.

Allow for an event filter on MetricCalculationSpec in order to allow ReportingSets to be used without filters. This is in response to a request from @mariolamassaavedra.

This change is


[stable/fluent-bit] Adds support for GELF output

Is this a new chart
No

NOTE: We're experiencing a high volume of PRs to this repo and reviews will be delayed. Please host your own chart repository and submit your repository to the Helm Hub instead of this repo to make them discoverable to the community. Here is how to submit new chart repositories to the Helm Hub.

What this PR does / why we need it:
Adds support to the Fluent Bit chart for outputting to a GELF[1] server.
Which issue this PR fixes
Related to #21578
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

1 - https://docs.graylog.org/en/3.3/pages/gelf.html

@edsiper just stumbled upon -> https://github.com/fluent/helm-charts/. Couldn't help but notice that you are affiliated to Fluent. What's the difference between the Fluent Bit chart in this repo and Fluent's? Which would you recommend?

@jasonrogena This chart will be replaced with the one in the fluent repo. The entire stable repo will be depricated in two months so I would suggest switching to the fluent chart.


Rename rst to md

Just FYI -- for Python projects this should always be README.rst
(restructured text). It's cool now since we're not using this, but just a
FYI for future.
On Tue, Jun 19, 2018 at 10:24 AM, Nate Barbettini<EMAIL_ADDRESS>wrote:

Merged #68 https://github.com/okta/okta-sdk-python/pull/68.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/okta/okta-sdk-python/pull/68#event-1689239571, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFgh3kKWqhBFr8W2ZVAhfR9SH4pPOOaks5t-TOwgaJpZM4Ut7Am
.

--
Randall Degges
818-217-9229
https://www.rdegges.com/

This change actually breaks the build when pip install
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/private/var/folders/vp/8zt3wxsx4gn7xbmnq6fnlbqc0000gn/T/pip-req-build-7n4reob5/setup.py", line 17, in <module>
        with open(path.join(here, 'README.rst'), encoding='utf-8') as f:
      File "/usr/local/bin/../Cellar/python/3.6.5/bin/../Frameworks/Python.framework/Versions/3.6/lib/python3.6/codecs.py", line 897, in open
        file = builtins.open(filename, mode, buffering)
    FileNotFoundError: [Errno 2] No such file or directory: '/private/var/folders/vp/8zt3wxsx4gn7xbmnq6fnlbqc0000gn/T/pip-req-build-7n4reob5/README.rst'

See: https://github.com/okta/okta-sdk-python/blob/master/setup.py#L17
Anyways, it should be an easy fix, but I'm not sure how willing you guys are to keep maintaining this project.


⚠ RPC server - Fantom has degraded performance

In aca46e1, RPC server - Fantom ($FANTOM_RPC_URL) experienced degraded performance:

HTTP code: 200
Response time: 15077 ms

Resolved: RPC server - Fantom performance has improved in 3d46326.


Updated CLU cross-match to 50 kpc

Also added distance_kpc for physical distance to cross-matched galaxies

@dekishalay Looks like there are some merge conflicts. Can you resolve those on the command line so the tests and CI can run?
https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-using-the-command-line

@dekishalay Looks like there are some merge conflicts. Can you resolve those on the command line so the tests and CI can run?
https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-using-the-command-line

thanks @dekishalay! Please pull in the latest master, that should probably resolve the conflict. Also, please make sure to install our pre-commit hook:
pip install pre-commit
pre-commit install

thanks @dekishalay! Please pull in the latest master, that should probably resolve the conflict. Also, please make sure to install our pre-commit hook:
pip install pre-commit
pre-commit install

@dekishalay another note: you are implementing your changes on your master branch; it's better to create a dedicated branch (so that, for example, if someone wants to submit a PR to it, they'll be able to do it).
We have very good dev guidelines on Fritz here. It might be a good idea to make Kowalski's own docs page as opposed to just dumping everything to readme...

@dekishalay another note: you are implementing your changes on your master branch; it's better to create a dedicated branch (so that, for example, if someone wants to submit a PR to it, they'll be able to do it).
We have very good dev guidelines on Fritz here. It might be a good idea to make Kowalski's own docs page as opposed to just dumping everything to readme...

@dekishalay just updated the developer guidelines, please take a look: https://github.com/dmitryduev/kowalski#developer-guidelines

@dekishalay just updated the developer guidelines, please take a look: https://github.com/dmitryduev/kowalski#developer-guidelines


Adjust page structure on style guide site (change H1 to H2, etc.)

Note: At the moment, this is in the blocked / waiting column. The issue was originally created without any additional context beyond the issue/subject line. Will need to investigate more

migrated LG-2648


Get pre-release updates into devel

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.
Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the devel branch until you have checked off each task.

[x] Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
[x] Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
[x] Updated relevant unit tests or have written new unit tests - See Unit Test Guide
[x] If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
[x] Update to all relevant roxygen headers and examples
[x] Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
[x] Address any updates needed for vignettes and/or templates
[x] Update NEWS.md if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
[x] Build admiral site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
[x] Address or fix all lintr warnings and errors - lintr::lint_package()
[x] Run R CMD check locally and address all errors and warnings - devtools::check()
[x] Link the issue in the Development Section on the right hand side.
[x] Address all merge conflicts and resolve appropriately
[x] Pat yourself on the back for a job well done! Much love to your accomplishment!

Shouldn't we also merge the patch branch in here too so that we have the hotfix (https://github.com/pharmaverse/admiral/pull/1426) included?

Will do that in a separate PR once the hotfix release has made it onto CRAN.


MeshRenderer Layout

resolves #403
Moving path members in MeshRenderer behind a pointer to shrink its memory footprint. The common access pattern just looks at the views, while paths are primarily used by the editor. I also removed some of the #ifdef stuff for simplicity.
Fixed some spacing/separator issues with the built in editor.

Can you make these same changes to ToonRenderer as well?

Definitely, #410.


Rolling back to rubycas-client 2.2.1 indeed solved the problem, thanks eriko !


[BUG]: Text is not visible on dark background

Is there an existing issue for this?

[x] I have searched the existing issues.

🐞 Describe the Bug
All texts, titles, and the close button are designed for a light background, using a dark background results in these texts being barely visible.
Does the package support dark mode? Or is there any way to use white color for texts instead of black?
😕 Current Behavior
All texts, titles, and the close button are not visible like in the screenshot below

Here's the highlighted texts as well

🤔 Expected Behavior
These texts and close button should be white when using a dark background
🔬 Minimal Reproduction
1- Create a new app
2- use a dark background
3- Integrate PayPal Buttons

🌍 Environment
| Software         | Version(s)      |
| ---------------- | --------------- |
| react-paypal-js  | 7.8.1           |
| Browser          | FireFox 101.0.1 |
| Operating System | Windows 10      |

Relevant log output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

➕ Anything else?
I only found one issue about this and it was closed recently with no solution.

For anyone wondering, I ended up creating a transparent background for the buttons, and when the purchase button is clicked, the background's color is set to white, and when the screen is closed the background will return to be transparent again.
Not the best solution, but it works.

Why this issue is closed?
I have the similar problem with black background. Please give the option to change debit card label font color.


Jekyll Documentation Site

A more full-featured, Jekyll-based documentation website would be preferable to the current README system that is used right now.

Started


Get a single note of an issue

Is there a way to do this besides gettings all notes and iterating over them? It should be possible by calling
GET /projects/:id/issues/:issue_id/notes/:note_id
right?
Thanks!

@CWolff92 if it doesn't exist, feel free to add it!


commands to manage wallet accounts

Reference https://github.com/ethereum/go-ethereum/blob/master/cmd/geth/accountcmd.go
We currently use

ecdsa

get accounts

bc-cli get accounts --wallet ~/.bestchains/wallet

create account

bc-cli create account  --wallet ~/.bestchains/wallet

delete account

bc-cli delete account --wallet ~/.bestchains/wallet  {account_address}

{"address":"b7f5a632ae0d561c6609be8507b1bdde0d669a59","crypto":{"cipher":"aes-128-ctr","ciphertext":"6670befcd092d4e57b0d19560c802660b83483d308abe12a749da1d72d98bc84","cipherparams":{"iv":"9a52fa38e51deabb43d0df9f1bb502f9"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"51364fc5fdae858cef2d70e4c0072b3704581bb39c199dd5c08108b323a8687d"},"mac":"e9e7c7cd37d47bd4557f9726ce380513cfc8d8c6ba283a21e518ee532889102c"},"id":"0c4cab9a-1b00-40d9-a8d0-cb50b6e0e11b","version":3}

{"address":"b7f5a632ae0d561c6609be8507b1bdde0d669a59","crypto":{"cipher":"aes-128-ctr","ciphertext":"6670befcd092d4e57b0d19560c802660b83483d308abe12a749da1d72d98bc84","cipherparams":{"iv":"9a52fa38e51deabb43d0df9f1bb502f9"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"51364fc5fdae858cef2d70e4c0072b3704581bb39c199dd5c08108b323a8687d"},"mac":"e9e7c7cd37d47bd4557f9726ce380513cfc8d8c6ba283a21e518ee532889102c"},"id":"0c4cab9a-1b00-40d9-a8d0-cb50b6e0e11b","version":3}

etherem use a password to encrypt priv key before store it into local file which is not must required for us. we only need to keep
{
  "address": "",
   "privKey": ""
}

address computation in https://github.com/bestchains/bestchains-contracts/blob/main/library/address.go#L58
For privKey, we can save it as base64 encoded string


Requests for Base

Routing for individual documents to see how to handle props with react router and komposer
potentially an SSR branch?
Custom user data and handling multiple subscriptions on the same route

Added #1 on your list to 4.8.0! The other two I'll log as considerations for the 5.0.0 release.


[TU-35] The toggle component

fyi: it's still WIP

Toggle has been finalised, please review!

Is this ready to be merged or are there any styleguide changes to be implemented here too? (cfr. stand up)

I don't think it needs changes, I asked Stephen to confirm. But in the meanwhile, you can still review 👍

Stephen confirmed, no changed needed.


Add all payload fields to Linux Kernel Parser

Add more payload fields and their debug validations to Linux Kernel Parser

@ooooolivia, overall looks good.  I think this warrants a new test to validate that this code is able to parse the events properly.  Can you add a new test along with a trace that contains these kernel events and validates that they are correct?

@brianrob Sure! Thanks for the review.


I have every intention of getting this merged, however the progress stalled pending review of @scanny. I do think the biggest part of the work on this is done so it would be great to regain some momentum and get it merged.
regards,
Ben


Fix openvino/test_training.py

What does this PR do?

Ignored scope is updated for CUSTOMIZED_QUANTIZATION_CONFIG
Number of expected quantizers is decreased for the impacted cases.

Reasons:
After nncf update (2.7.0 -> 2.8.0), NNCFGraph was fixed for the Bert model: now head masks path is visible for the quantization algorithm:

This led to head masks path quantization:

I've updated Ignored scope with IS from the default config, and now amount of quantizers was decreased.
CC: @AlexKoff88

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

It looks good and fixes a subset of tests. Let's merge. The rest of them are fixed in #538 and #535.


Fix parsing string with trailing z to ZonedDateTime

Close #1

Codecov Report

Merging #2 into master will decrease coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master       #2      +/-   ##
==========================================
- Coverage   93.75%   93.68%   -0.07%
==========================================
  Files           1        1
  Lines          96       95       -1
==========================================
- Hits           90       89       -1
  Misses          6        6

Impacted Files
Coverage Δ

src/GPX.jl
93.68% <100%> (-0.07%)
:arrow_down:

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 b93cf48...2615a26. Read the comment docs.


fix: Removed entity name validation for widgets

Removed name validation for widgets as before.

/ok-to-test


Multi GPU support

Do you have a plan?

the code is based on vits repo, so you can take a look at that repo to see how distributed training is implemented. almost all you need is to uncomment the code related to distributed training, which is already there.


Consider adding lenient() option for string inputs

I was in the process of migrating my existing yup schemas to zod and found that the main sticking point is handling the parsing/validation of request path and query string parameters. Since they are typically considered raw strings and the parsing is left to the application level, zod doesn't really provide a great DX in these scenarios. Specially when compared to how yup does it out-of-the-box.
// My existing `yup` schema
const schema = yup.object({ params: yup.object({ id: yup.number().required() }) })

// GET /user/42
// req -> { params: { id: '42' } }
schema.validateSync(req) // { params: { id: 42 } } -> Passes

// `zod` equivalent
const schema = z.object({ params: z.object({ id: z.number() }) })

// GET /user/42
// req -> { params: { id: '42' } }

schema.parse(req) // -> Fails

/*
Uncaught:
[
  {
    "code": "invalid_type",
    "expected": "number",
    "received": "string",
    "path": [
      "params",
      "id"
    ],
    "message": "Expected number, received string"
  }
]
*/

Which leads me to write custom preprocess() validators, along with custom error messages, for each expected type, every time. Here's an example for validating numerical strings.
const DEFAULT_ZOD_NUMERICAL_PARAMS = Object.freeze({
  errorMap: (issue, _ctx) => {
    const message =
      issue.code === z.ZodIssueCode.invalid_type
        ? `Expected ${issue.expected}, received ${issue.received === 'string' ? `'${_ctx.data}'` : issue.received}`
        : _ctx.defaultError

    return { message }
  },
})

function numerical(params) {
  return z.preprocess(value => {
    const num = isNilOrEmpty(value) ? NaN : Number(value)
    return Number.isNaN(num) ? value : num
  }, z.number(params ?? DEFAULT_ZOD_NUMERICAL_PARAMS))
}

export default numerical

I know this has been discussed before, but having something close to a .lenient() parsing option, allowing for values to be internally coerced would be great.
z.lenient(z.number()).parse('42')
// 42

IMHO, this is such a common scenario when dealing with serialized data, that it only makes sense for a library such as this to support it without extra hassle. In addition, while the .preprocess() method above works, it transfers the responsibility of the parsing to the user,  which is arguably the main use case of zod.

Thanks for the write up and the thoughtful suggestion @nfantone !
Speaking for myself, I do not view Zod's main use case as parsing JSON or query strings but as safely turning an unknown to a T. Assuming that the input data is of any particular serialized type (query strings, JSON, form data, protobuf, csv, etc) is a level of abstraction above what I feel Zod should be focused on. However, all of those use cases are important and making it easier to build the right thing for each use case is definitely something I think we should try to make easier.
Your proposal (lenient) is ergonomic, but I'm not sure that we want to hard-code this into core since there are so many ways you might want to coerce the input. A library (or a module in your own application) seems like a good place to have wrapped versions of most types that attempt to coerce their input from strings (or whatever else: Date, null -> 0, false -> 0, etc). This is the approach that I've personally taken and it gives us the flexibility that we absolutely require when doing these kinds of transformations.
Definitely open to continue discussing this and trying to support making this as easy as possible.
FWIW, this is our numeric string schema: CodeSandbox
const numericString = z
  .string()
  .refine((s) => {
    const n = Number(s);

    return Number.isFinite(n) && !Number.isNaN(n);
  })
  .transform(Number);

Hi @scotttrinh. Thanks for your reply! You raise good points. Let me see if I can expand on them inline.

Speaking for myself, I do not view Zod's main use case as parsing JSON or query strings but as safely turning an unknown to a T.

Well, at the risk of sounding a bit cheeky, saying that while having your core/main library function be named .parse is a tough sell 😛.
In all seriousness, I get what you mean here - but I really didn't want to circumscribe the uses of zod to "parsing query strings". More like parsing arbitrary typed data.  It just so happens that, this being JavaScript, you can expect plenty of very valid use cases dealing with web servers where that data is pretty much always represented as either strings or byte streams.

A library (or a module in your own application) seems like a good place to have wrapped versions of most types that attempt to coerce their input from strings

It would a good place, absolutely. A better place? zod. Or maybe a companion library? Obviously, your milage may vary, but to me, without this concept of being able to coerce string values without effort, because I always end up writing boilerplate code, zod comes in second when deciding which validation library to use for most projects.

FWIW, this is our numeric string schema

Thanks for sharing that! That's really good. Doesn't quite fit my needs (i.e., the semantics of the lenient() approach), though:

doesn't work with numbers;
parses empty/blank strings as 0;
default error message doesn't provide any hints on what is actually expected (reads "Invalid input").

Of course, you can go ahead and try to fix those things.
z.number().or(
  z
    .string()
    .min(1)
    .refine(
      s => {
        const n = Number(s);
        return Number.isFinite(n) && !Number.isNaN(n)
      },
      value => ({ message: `Expected number, received ${value}` })
    )
    .transform(Number)
)

But I guess this kinda further proves the point I am trying to raise.

Well, at the risk of sounding a bit cheeky, saying that while having your core/main library function be named .parse is a tough sell 😛.

😆

More like parsing arbitrary typed data. It just so happens that, this being JavaScript, you can expect plenty of very valid use cases dealing with web servers where that data is pretty much always represented as either strings or byte streams.

Yeah, I 100% agree with you that dealing with serialized data is something you have to do often. I guess my feeling is that Zod is an abstraction below that as a runtime type system. In a similar way to TypeScript, a z.number should be a number and if it's not, you should have to be explicit about that. TypeScript doesn't let you be lose about it, and I feel pretty strongly that Zod should be as explicit as possible about what it is doing and not offer coercion or transformation as a hidden or implicit effect. Now, I know you're proposing something explicit (lenient) here, but what lenient does seems pretty sensitive to case-by-case variation.

It would a good place, absolutely. A better place? zod. Or maybe a companion library? Obviously, your milage may vary, but to me, without this concept of being able to coerce string values without effort, because I always end up writing boilerplate code, zod comes in second when deciding which validation library to use for most projects.

Totally fair! If Zod isn't the style of runtime type system that works for you, I think it's totally fine to say something like yup is a better fit. As it is, I appreciate that Zod is very close to TypeScript and doesn't come with any (many?) assumptions about your use cases so you can adapt it to your domain. Which brings me to the point you make here:

Doesn't quite fit my needs (i.e., the semantics of the lenient() approach), though:
But I guess this kinda further proves the point I am trying to raise.

On the contrary, I think that points to the point I'm trying to make: For us, we want to be absolutely certain that if something is a numeric string, it's a numeric string, not a date or null or something else that can be coercible to a number. And parsing empty strings as 0 is precisely what coercion should do, in my opinion, but as you've pointed out, you feel differently (it should return an error?). So, if we bring your (or my) opinion into core about how to convert between types, we risk increasing our maintenance burden, introducing more complexity (bugs), and still only properly serving a portion of users.
I think this is why I feel like building a library (or having an internal module/library) is really the best way forward here: It allows Zod to focus on just representing and narrowing TypeScript types at runtime while providing affordances to do transformations/refinements/coercions as needed. This approach seems to be successful for io-ts which similarly has a "core" and libraries that you can opt into depending on your needs. Superstruct has taken a similar core vs library approach as well. I absolutely support the idea of an ecosystem building up around Zod that supports these use cases in opinionated and ergonomic ways that align to the values and opinions of those library maintainers.

As a separate note, here is another wrinkle in the proposed solution:
And think of all of the other types beyond the primitives. What is a lenient(intersection)? Or do we need to distinguish between primitives and complex types?

Ok, so I'm 100% behind everything you are saying here, in principle. Except (there's always a "but"), I have a small issue with the implicit implication that the original use case I provided for something like lenient() is "opinionated" and/or can be dismissed as being "sensitive to case-by-case variation". I think it's fair to say that no library will cover every use case. That's a given. But I frankly can't remember the last time I had to work on a node web service and did not need to parse/validate string data. It's so quintessential to web development that, to me, if feels like a glaring omission on zod's part. Whether this logic should be housed within zod core or not, is not really the point, I believe. The argument is more centered around developer experience.
Since you brought up the topic of libraries, after seeing what other libraries closer to zod exist in the ecosystem, I think it's safe to say that a very important function of zod is to provide safe typings and parsing to web APIs (tRPC, json-schema-to-zod, etc.). With that in mind, I can't help but wonder: what is it not straightforward to express the type for something like GET /users/:id, with id being a number, with a zod schema?

And think of all of the other types beyond the primitives. What is a lenient(intersection)? Or do we need to distinguish between primitives and complex types?

I admit I didn't go deep into the implementation details of my proposal. But I suppose that lenient() should provide a "best effort" approach at coercing your input value (think JSON.parse). The next parser in the pipeline shouldn't really matter.

I have a small issue with the implicit implication that the original use case I provided for something like lenient() is "opinionated" and/or can be dismissed as being "sensitive to case-by-case variation". I think it's fair to say that no library will cover every use case. That's a given. But I frankly can't remember the last time I had to work on a node web service and did not need to parse/validate string data.

Right, but as your example pointed out, you think the parser should accept numbers also, and if the string is empty it should throw an error. I think that's perfect valid, but that's not at all how I would want something similar to act. I think that's what I'm trying to say when I say that I think each developer (or team) needs to make decisions about how, when, and in what way serialized data in converted, and that providing functionality that picks a way is necessarily opinionated. I don't mean to be dismissive: I think your approach is a good one that makes sense for some use cases!

The argument is more centered around developer experience.

I 100% agree, and a lot of people have brought up other such use cases: especially forms. In each case, you might want to make different decisions about how to cast. For another example, pg converts some "serialized" data already for you, but leaves some types as strings since they can be round-trip lossy without BigInt. Making it easy to write the layer on-top of Zod that is appropriate for each team and use case is absolutely a part of what I see as Zod's responsibility (preprocess, transform, refine, etc). Providing implementations for each use case is something I wouldn't want to see Zod take on, and as the link you posted in your first comment attests to, I don't believe @colinhacks wants there to be multiple ways to transform data for certain cases like number -> string, etc.

Since you brought up the topic of libraries, after seeing what other libraries closer to zod exist in the ecosystem, I think it's safe to say that a very important function of zod is to provide safe typings and parsing to web APIs (tRPC, json-schema-to-zod, etc.). With that in mind, I can't help but wonder: what is it not straightforward to express the type for something like GET /users/:id, with id being a number, with a zod schema?

From my perspective, the schema for that (z.string().transform(Number)) is perfectly straightforward. And if you're writing a library like tRPC maybe you have some more robust schemas that check for NaN and undefined and return some appropriate error, but I think that kind of logic belongs in that library rather than in Zod. I think it makes sense that Zod treats types in a similar way to TypeScript (TypeScript treats that "type" as string also) while giving the affordances for transformation such that the input type and the output type might be different.

I don't mean to come across as confrontational, and I very much appreciate your perspective and thoughtful answers and suggestions here. My hope is that users with the right vantage point based on their expertise and opinions can provide the layer that you feel we're missing, and I very much agree with you that the ecosystem is missing these sorts of developer-friendly and use-case specific libraries. I am also frustrated that I have to write these transforms by hand, but even if we provided your specific solution, I would still write them by hand since they do not align with my team's specific viewpoint on the proper way to specify these schemas for the multitude of use cases we have (json, query strings, form data, database data, etc.). I hope my comments help to situate my opinion (and that's all this is: my opinion!) about the direction I'd like to see Zod take and don't dissuade you from continuing to advocate for your own perspective.

You're not coming across as confrontational - quite the contrary. Don't stress about it! And many thanks for taking the time to reply thoughtfully.
And again, I do agree with your points, even if we don't see things exactly the same colour. Perhaps I'm expecting things from zod that it's just not meant to be providing. That's on me and it's absolutely fine.
The one comment I would like to address is:

From my perspective, the schema for that (z.string().transform(Number)) is perfectly straightforward.

I would like to challenge that. IMHO, there are (several) issues with your suggestion. These are the ones I can think of off the top of my head.

Unlike z.number(), produces NaN for most inputs.
Unlike z.number(), produces unexpected results for some inputs (i.e, z.string().transform(Number).parse('    ') // 0).
The error messages arising from failing to parse that are completely useless/misleading.
Can't chain extra number validators, such as min, max, etc.
...and more importantly, semantics and documentation. yup.number() explicitly states intention and unequivocally determines the expected input type. z.string().transform(Number) doesn't.

So, no - sadly, I don't think it's straightforward in zod (or useful, at all, in my perspective, for that matter). Like I mention before: yes - you can work around (some) of these limitations, currently. The natural question is: why?

I ran into this for a rather weird use case where we're currently using a system that "stringifys" all the properties passed in. So we get a correctly shaped object, but all the booleans/numbers/etc... are stringified. It's another edge case I'll admit, but it is a case.
Of the above the most "significant" issue personally is the inability to chain. So even if I wanted to write my own "type" I end up having to go through contortions to make it look like a normal type.

So, if we bring your (or my) opinion into core about how to convert between types, we risk increasing our maintenance burden, introducing more complexity (bugs), and still only properly serving a portion of users.

This is true for every design decision on every project, ever. Any and all additions to an existing stack bear forward a certain opinion, dismissing (voluntarily or not) others. I frankly don't see this being an argument against implementing new stuff.
Also, I'm not convinced that the fact that there might be "different opinions" on how to convert data, prevents us from giving users the option. There are also different opinions on how to parse functions, objects and every other type out there and still zod provides ways to handle those. Like any other library on npm, zod is alredy very opinionated.
const z = require('zod')

typeof null // 'object'
z.object().parse(null) // 'Expected object, received null' <--- Opinion 👀

I'd like to share what I've been experimenting with while working on a project to convert the outputs of openapi-typescript to Zod in order to implement a strongly typed REST API server.
Parsing JSON bodies is straightforward. But, as already mentioned in the thread, parsing path, query, and header parameters is trickier because, although the Open API spec and Zod schemas may specify a parameter to be boolean-valued, numeric, etc., these parameters always arrive as strings.
I've taken the approach of preprocessing my Zod schemas (ZodObjects) for handling these parameters. I do this by preprocessing each ZodObject property:

Detect whether the property could be boolean-valued or numeric. This requires recursing through ZodLazy and ZodUnion, looking for instances of ZodBoolean and ZodNumber. (I may need to handle other types, too, but I haven't gotten there yet.)
Wrap the property's schema in z.preprocess:

If the property could be boolean-valued, arrives as a string, and its trimmed lowercase representation equals "true" or "false", return the corresponding boolean.
If the property could be numeric, arrives as a non-empty string, and the result of parsing it as a Number is neither NaN nor Infinity, return the number.
Otherwise, return the unparsed input.

I give precedence to boolean values and then numeric values before falling back to whatever the ZodSchema is looking for (which hopefully can be parsed from a string). Although it's a bit annoying to do this, I am forced to take some decisions that may not be applicable to other use cases. I think I generally agree with @scotttrinh's comment here: https://github.com/colinhacks/zod/issues/804#issuecomment-983793979

FWIW I'm encountering similar struggles when attempting to work with number inputs, using zod as a react-hook-form resolver. It is.....pretty challenging to figure out.
https://codesandbox.io/s/stupefied-moser-0fpq94?file=/src/App.tsx
Given...

 a strongly typed endpoint
 a matching zod schema (consider tRPC)
 a form design for HTTP PATCH; a partial update
 the need to represent NO CHANGE as an empty input

            {" "}
            HTML's native behavior to represent EMPTY as empty string ('')

How do you represent a number input?????

Please see coercion: https://github.com/colinhacks/zod#coercion-for-primitives


ScreenSpaceCanvas not resized properly on canvas resize

When resizing canvas after page load, ScreenSpaceCanvas elements get distorted instead of resizing along with scene.
I think it used to work properly at some point.
It can't be seen in a PG because it doesn't resize the canvas according to window size, but test on any window with canvas width and height set to % of window (e.g. 100%) and you'll notice it immediately.

In this PG: http://www.babylonjs-playground.com/#22PLQU#0
When the window is resized, the Sprite's position is unstable (DesignMode, should be stable)
Also report to @wyklion

Might be related, if size of the ScreenSpaceCanvas is null it resize automatically relatively well but its width and height are not updated / correct when accessed like so canvas.width.


Arabidopsis' model

Hi ,
Thank you for this software.
it's been a few days since i tried to work with your software.
I'm working on arabidopsis thaliana , and i want to build a model. but i don't know how to split data?
Can you please provide an example of training and validation data ?
Thank you in Advance
Best Regards

Hi Fadwa7,
At the Preprocess step, adding the -sf flag toDeepMP preprocess  should automatically split the data into train, validation and test sets.
Please let us know if this works for you.
Cheers,
Mandi

Thank you , it works :)


Big code refactor

I started by making a small improvement (to create a small PR) to the @qualweb/locale package and ended up overly excited. One thing led to another and here we are with a PR with more than 300 files... sorry not sorry 😅
In the end, a lot of ideas that I had previously were implemented, and even tho this is a big change, I'm far from done. The goal is to improve future developments. A lot of testing is still needed but I'm opening already a draft PR so if anyone has time, to start questioning it!
Major points of this refactor:

Code declutter (removed a lot of useless code, and files);
Better abstractions (especially on the evaluation modules);
Better typing;
Better separation of responsibilities of each module/class.

Hey @joao-vicente!
Apologies for the silence.
I hope to have some time to go through the commit tomorrow or Thursday. As We discussed, I'm going to check out the changes in a copy of the main branch and see if I can't organize them in more granular commits.

Alright, so I've been trying to get a grasp of the many changes in the commit. I think I've managed to narrow down the changes into a bunch of better fitting commits. To my mind, each point could correspond to roughly one commit. I'd argue that commits shouldn't necessarily be as tiny/atomic as possible. My preferred approach is to keep each commit to one "point" or "thing" that can be concisely described in the first line of the commit, so other developers can see - at a glance - what changes have happened. When working locally with rebasing, it can also save a ton of merge headaches since git can interweave the changes with your own instead of forcing one big change into your history.

chore: update contributor email in package.json
chore: update copyright year in license
refactor: prefer ESM-style exports over CommonJS
refactor: don't implement a constructor that solely calls its base class' constructor
refactor: prefer using this over super when calling methods (less debugging if one of those methods should get overridden in future)
refactor: avoid typeof typing when direct/original type is available
feat: remove ACTRuleDecorator - its logic should be part of a constructor, not a decorator
refactor: move classes out of index.ts files into their own separate files
feat: deprecate types package (this should probably be done over several refactor commits before removing the package entirely)
feat: new package, lib
feat: locale package API changed. BREAKING CHANGE!
chore: migrate webpack configurations to TypeScript

There are bigger changes that I don't know how to document or narrow down from the single commit.
For example, when we talked, you described how you merged several packages into others because it seemed unnecessary to have a whole package for them (evaluation and dom?). I'm not sure I can pull out those changes from the single commit because I can't see specifically what that exact change encompasses when mixed with the others.
Finally, I'm not sure it's a good idea to commit developer preferences to the workspace file. Right when I opened your changeset my VSCode went from a calm dark to bright whites - had me blinded for a good few moments :D
One thing I should try and do today is upload a CONTRIBUTING.md file with instructions on writing changesets. I thought I'd already added a basic/boilerplate explanation in the README file but that's clearly not the case.

Amazing @Tellus! I think I wouldn't be able to create a summary that concise 😅
I'm glad you managed to find the time to do it, and it is easier to tackle everything separately now. I didn't/don't have much time these two weeks (the previous one, and this one) so I don't think I'll be able to contribute much... On the next one I expect to have more free time to help you with this, so just let me know how you'd like to proceed.
Regarding the VSCode preferences... My bad 😅 I didn't understand that I included those in the commit.. but I'm still a bit confused because I also don't use bright whites. I use the One Dark Pro theme 😉

Hey, João
I'm sorry for the silence. Easter came around - and then a vicious ear infection.
I'm having some trouble with redoing the one commit as the separate I suggested. The problem, I think, boils down to how Git "hunks" for files work. I was hoping that I could check out all the changes from your commit as uncommitted changes in a new branch, and then selectively just commit specific lines of changes in batches.
This works for some of the changes, but when there are several overlapping changes that should belong in different commits (for example, changes to imports at the top of a file and the immediate export of a class on the next line) can't be cleanly separated with quick Git actions. There's an interactive patch command in Git that lets you do this, but going through 304 files line by line - for each commit - is just too much work :P I couldn't find a non-interactive version that could be easily batched to do the same.
So I think we're kind of left with either merging everything as a single commit (I'm still not a fan, but as you said, you ran all relevant unit tests to ensure that code should work as expected) or re-doing all the work by hand, separated by change type. I.e. make a new branch from main, change all export statements, commit, change all type usages, commit, clean up imports, commit - and so on.
Assuming the first, we should probably still address the changes that definitely should not be committed (deleted CHANGELOG files, personal user settings in the workspace file, etc). Do you think you could amend/adjust those or should we try to speed-run the individual changes, you think?

Hey João.
Just quickly noting down what we talked about (mostly because my memory's bad :D).
We'll just pull everything in as a single PR, but with adjustments for how CI/CD works. Accounting for how the merge conflicts look right now, I think this is what we arrived at:

Create a new branch from main, then copy over all changes from this PR's commit, so they pop up as uncommitted changes.
Undo your changes to package.json files and CHANGELOG files. These portions are updated automatically in a Github action
Undo the changes to the workspace file (the user-specific additions)
Undo the changes to the lockfile, to avoid any conflicts. Do rebuild it with npm install in a separate commit afterwards (I think this should be fine).
Do change your collaborator entry in the relevant package.json files. Attribution is important :)
Since you're just checking out changes from another commit, you may have to go over the source files you intended delete again. Since we're effectively stopping the updates for some public packages, we should consider making a release that mentions their deprecation in their README files and NPM.js descriptions before a commit that fully deletes them.

Once that's done, we'll need to adjust the CI/CD pipeline to the added/deleted packages. Let's cross that bridge once the other changes are done.
Thanks for the chat and have a great weekend!

Hey @Tellus, it took me a while, but I've finished all the changes!
I had to go over a lot more files than expected because the packages were not compiling correctly. The package @qualweb/types was the culprit here because it started interfering with the new changes to the typing system. In the end, I had to get rid of it. So I'll try to summarise all the changes I made:

I've defined an order in the global package.json in which the packages should be compiled;
The new package I had created @qualweb/lib, I undid it and created a shared folder (shared) with types/classes/methods to be shared. This is not a package;

Depending on how it goes, the types may be moved to their respective module/package in the future;

The @qualweb/types is no longer needed;
Updated all other packages to stop using @qualweb/types and use the new shared folder;
Updated the tsconfig.json files to use path aliases to reference the new shared folder and data from other packages;
Updated the webpack.config.ts files to take into account the path aliases during the compilation;
Added the Window types to all packages that needed it, but each one with only the variables they use.
Some TypeScript issues fixed;
Create a new class Guideline so that in the future we abstract the rules/techniques/best-practices;

Still not sure about that name (naming is hard. Open to suggestions);
I didn't want to change even more files, so I simply created the new class but didn't move any code. We're starting to have too many abstractions and that's generally not good/needed (e.g. Guideline -> Rule -> AtomicRule -> QW_ACT_R1). To be improved in the future.

What I didn't do:

Version bumps;
Package published.

I was thinking in publishing new versions with a minor version increase and appending -alpha. This PR has a lot of changes And it would be better to test it "officially" before merging into the main branch.
Let me know if you have some time to do an overall review of these latest changes, and if you notice any red flags in this new approach, of course, let me know what you think ;)
Have a nice week!

Sorry for the silence! I was expecting Github to ping me via e-mail when you @mentioned me - nope!
I'll take a speedrun through it this evening. It's probably fine :-)

I just double checked my points from way back when.

changelogs/package.json reverted. Excellent.
the workspace file is nice and clean. My eyes are thankful :)

Pop a changeset in there to document the changes for the CI/CD to handle, and I'm all set.
Unless @carlosapaduarte has any objections I say we just merge everything and deal with the fallout if it happens :P
We should probably still think about how to signal the discontinuation of the removed packages, just so any direct consumers of them gets notice next time they try to update or run npm i in their own projects.

I've merged in the changes from the second PR.
Depending on what I missed, these would be the last TODOs. Some can probably wait until after a merge.

Finish up the changeset/changelog. NOTABLY document the changes to using @qualweb/core
Fix merge conflicts: NOTABLY the hot fixes made by Carlos since we started this refactor business.
@qualweb/act-rules: validation tests should be checked. Are the errors new or is the main version also failing those tests?
@qualweb/cli: unit tests, JSON file with options as input.
eslint config needs touching up. It runs now, which is good, but the sonarjs plugin (maybe others) insist on parsing the final files in "dist" - we're only interested in linting the raw source files.

Resolved merge conflicts between branch main and the PR branch qw-locale-improvements.
There are still a few things to iron out. API calls that haven't been updated in the interim commits, unit tests.
On it.

Only one thing left, I think. The module unit test in wcag-techniques (module.spec.ts) is failing, and I couldn't quickly figure out why. Looking into it.
I've updated this PR to merge into develop instead, so we can safely merge when happy and see how it performs via NPM.

I've fixed the tests in @qualweb/wcag-techniques (and a few other places) by exporting the WcagTechniquesModule in a separate subpath.
There's a lot of code that will try to use the window global when it's simply imported, even it's not going to be run in the browser. This causes run-time errors much higher up and is hard to diagnose.
After merging this PR it might be prudent to look into reducing use of the window global where possible. In a lot of cases, it's a use of AccessibilityUtils and DomUtils, which can just be imported directly instead of relying on a (possibly undefined) global variable.


Cherrypick: Make it work with Go 1.15

This bug is a warning of converting integer to a string of rune instead
of digits. This warning is introduced in Go 1.15. See https://blog.golang.org/go1.15-proposals
and specifically https://github.com/golang/go/issues/32479.
Tested by make test and make deploy.

Closing this experimental PR


Issue while downloading Closure_util through npm

Getting below error While Downloading closure through OpenLayers
25876 verbose stack Error<EMAIL_ADDRESS>postinstall: node ./bin/closure-util.js update
25876 verbose stack Exit status 1
25876 verbose stack at EventEmitter. (C:\Program Files\nodejs\node_modules\npm\lib\utils\lifecycle.js:255:16)
25876 verbose stack at emitTwo (events.js:106:13)
25876 verbose stack at EventEmitter.emit (events.js:191:7)
25876 verbose stack at ChildProcess. (C:\Program Files\nodejs\node_modules\npm\lib\utils\spawn.js:40:14)
25876 verbose stack at emitTwo (events.js:106:13)
25876 verbose stack at ChildProcess.emit (events.js:191:7)
25876 verbose stack at maybeClose (internal/child_process.js:886:16)
25876 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)
25877 verbose pkgid<EMAIL_ADDRESS>25878 verbose cwd D:\Work\OL4BuildKit\openlayers
25879 error Windows_NT 10.0.10586
25880 error argv "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "i" "-g" "closure-util"
25881 error node v6.10.3
25882 error npm v3.10.10
25883 error code ELIFECYCLE
25884 error<EMAIL_ADDRESS>postinstall: node ./bin/closure-util.js update
25884 error Exit status 1
25885 error Failed at the<EMAIL_ADDRESS>postinstall script 'node ./bin/closure-util.js update'.
25885 error Make sure you have the latest version of node.js and npm installed.
25885 error If you do, this is most likely a problem with the closure-util package,
25885 error not with npm itself.
25885 error Tell the author that this fails on your system:
25885 error node ./bin/closure-util.js update
25885 error You can get information on how to open an issue for this project with:
25885 error npm bugs closure-util
25885 error Or if that isn't available, you can get their info via:
25885 error npm owner ls closure-util
25885 error There is likely additional logging output above.
25886 verbose exit [ 1, true ]

duplicate of https://github.com/openlayers/closure-util/issues/336

when are we accually fixing this? love pointing too other issues, but it still isn't fixed


'data' referenced before assignment

https://github.com/Yelp/elastalert/blob/2e96c34b07bd9b5dafdde130dfe1722a1c5e99a8/elastalert/create_index.py#L77
  File "/usr/lib/python2.7/site-packages/elastalert/create_index.py", line 77, in main
    username = args.username if args.username else data.get('es_username')
UnboundLocalError: local variable 'data' referenced before assignment

Also seeing this

Please add the following in line 76 below:
        data = {}

After adding the effect is as follows:
    else:
        data = {}
        username = args.username if args.username else data.get('es_username')
        password = args.password if args.password else data.get('es_password')

For me it is working and good luck.

Looks like this occurs if you don't have a config.yaml and don't specify host/port as arguments. I'll fix this today.

Fixed in #1382


speed parameter is not implemented

I found out that you didn't call setSpeed, so I went back to lottie-web.

Hey Coolicer,
I can certainly implement this feature! I'll post on here when it's been added.

This has been added to v2.0.4! You can use:
this.$refs.anim.setSpeed(2)

Enjoy!


Please add these icons to Clarity

Hello,
Can you please add these two icons to the Clarity library?
Thank you!
Stela

Hi Stela & Jeremy, just to mention, the naming for this icon is host groups  :)
Thanks

Hi @Shijir
Please replace the current "circle" and "dot-circle" icons in the library with these:
timeline_icons_update.zip
This zip also includes a spinner icon. Please let me know if it needs any changes. Thanks!

Done in PR #3192


Fix sampling when no seed sequence given

Simple mistake that I noticed I had added a while a back. When no seed sequence was given for sampling, seed sequence became None, which would lead to AttributeError exception occurred: 'NoneType' object has no attribute 'strip'

Thanks for the fix Aku!


SBOM Packages: Can we flatten them?

Currently we can fetch the packages of an SBOM using GET /api/v1/sbom/{id}/packages and we get a paginated response similar to:

{
    "items": [
        {
            "id": "SPDXRef-29a326e0-5596-453d-aeed-aa8c5156e1dd",
            "name": "aesh",
            "version": "2.6.0.redhat-00001",
            "purl": [
                {
                    "uuid": "b5ff1d8c-70a4-56bc-b44e-d43a932ef6ad",
                    "purl": "pkg://maven/org.aesh/aesh@2.6.0.redhat-00001?repository_url=https://maven.repository.redhat.com/ga/&type=jar",
                    "base": {
                        "uuid": "fd40e5fc-5175-5937-b5e2-a7298b2b1707",
                        "purl": "pkg://maven/org.aesh/aesh"
                    },
                    "version": {
                        "uuid": "8f0db84e-2f3f-564d-b76f-7bbbee44d70b",
                        "purl"<EMAIL_ADDRESS>                        "version": "2.6.0.redhat-00001"
                    },
                    "qualifiers": {
                        "repository_url": "https://maven.repository.redhat.com/ga/",
                        "type": "jar"
                    }
                }
            ]
        },
        {
            "id": "SPDXRef-96f7c452-3dba-441c-81a4-1109b2a34689",
            "name": "apache-mime4j-dom",
            "version": "0.8.9.redhat-00001",
            "purl": [
                {
                    "uuid": "726150d9-e5c7-5eec-b9e8-6ed3926a06db",
                    "purl": "pkg://maven/org.apache.james/apache-mime4j-dom@0.8.9.redhat-00001?repository_url=https://maven.repository.redhat.com/ga/&type=jar",
                    "base": {
                        "uuid": "ea7eefce-cc98-5295-9cf0-4908146870be",
                        "purl": "pkg://maven/org.apache.james/apache-mime4j-dom"
                    },
                    "version": {
                        "uuid": "5be05e0f-e1e1-5532-97af-5a4bc2a964cd",
                        "purl"<EMAIL_ADDRESS>                        "version": "0.8.9.redhat-00001"
                    },
                    "qualifiers": {
                        "repository_url": "https://maven.repository.redhat.com/ga/",
                        "type": "jar"
                    }
                }
            ]
        }
    ],
    "total": 880
}

What are the chances of flattening the items.purl field and rather than returning the current response we return a set of purls. E.g.
{
  "items": [
    {
      "uuid": "b5ff1d8c-70a4-56bc-b44e-d43a932ef6ad",
      "purl": "pkg://maven/org.aesh/aesh@2.6.0.redhat-00001?repository_url=https://maven.repository.redhat.com/ga/&type=jar",
      "base": {
        "uuid": "fd40e5fc-5175-5937-b5e2-a7298b2b1707",
        "purl": "pkg://maven/org.aesh/aesh"
      },
      "version": {
        "uuid": "8f0db84e-2f3f-564d-b76f-7bbbee44d70b",
        "purl"<EMAIL_ADDRESS>        "version": "2.6.0.redhat-00001"
      },
      "qualifiers": {
        "repository_url": "https://maven.repository.redhat.com/ga/",
        "type": "jar"
      }
    },
    {
      "uuid": "726150d9-e5c7-5eec-b9e8-6ed3926a06db",
      "purl": "pkg://maven/org.apache.james/apache-mime4j-dom@0.8.9.redhat-00001?repository_url=https://maven.repository.redhat.com/ga/&type=jar",
      "base": {
        "uuid": "ea7eefce-cc98-5295-9cf0-4908146870be",
        "purl": "pkg://maven/org.apache.james/apache-mime4j-dom"
      },
      "version": {
        "uuid": "5be05e0f-e1e1-5532-97af-5a4bc2a964cd",
        "purl"<EMAIL_ADDRESS>        "version": "0.8.9.redhat-00001"
      },
      "qualifiers": {
        "repository_url": "https://maven.repository.redhat.com/ga/",
        "type": "jar"
      }
    }
  ],
  "total": 880
}

The only things I did (manually) is taking the original response and put items.purl under the items field
Reasons

As the filtering, pagination, sorting for GET /api/v1/sbom/{id}/packages is done in the server side, I can not do the flattening in the client side as filtering, pagination, and sorting would stop working.
Note that items.purl is an ARRAY. As a consequence I am forced to render packages of an SBOM under expanded areas

I want to render next to each package the set of vulnerabilities that affect them. And the only way of currently achieving it is fetching /api/v1/package/{uuid}. As a consequence, the only way of rendering vulnerabilities for each package is using the expanded area (image above)

Sure happy to flatten them. May put it behind a flatten query param.
Thanks for the RFE!

Ah right. I was thinking this was the purls endpoint not SBOM packages.
Ignore me.