What are the contents of list.txt and meta.txt?

Thanks for your great work !
Could you provide an example or a screenshot about the contents of list.txt and meta.txt to help us better understand your code ?
data_list:
    - 'data/emore/list.txt'
data_meta:
    - 'data/emore/meta.txt'

list: file name with relative path
meta: first line: "num_image [space] num_class", eg, "5783772 85738" for emore; other lines: category labels

Hi, it is updated. Now it needs a list file with "path [space] label" in each line. No meta file anymore.


Test fcomm Makefile, make default RC=10 in fcomm

This is a straw man on how to approach #131 given #207. The test runtime should be .. interesting.

Yes, the problem with runtime how is that this will reload the rc=10 params repeatedly, and this is currently slow. This may not be practical until some of #311 is done.

Okay, it took 24 minutes:
        PASS [1447.071s] fcomm::makefile_tests test_make_fcomm_examples

This seems to raise time for ignored tests from 24 to 35 minutes (at a quick glance). Although not great, this is probably livable for now — given that we need this test.
If we want to shorten test time, we might reduce the number of examples being run in the test for now.

@porcuquine Practically speaking does it make sense to have this test as a nightly test until #311 is fixed? We should be able to pinpoint a root cause for a breakage relatively easily.

I bumped parallelism a bit. But I'm worried this test might be flaky TBH.

Hmmmm… Could run nightly until we gain confidence that it's not flakey and perf is acceptable (which it might be with the parallelism).

Sounds good. Note that the uniquely long runtime for Mac is due to a bug in sccache setup there (the cache location is incorrect on that platform in the save/restore command).


sbt 1.3 updateClassifiers does not resolve library sources

steps
sbt version: 1.3-RC2
Create any sbt projects with a library dependency. Run updateClassifiers
problem
updateClassifiers does not resolve sources of libraryDependencies when using coursier.
notes
IntelliJ expects sources to be resolved to allow source navigation by the user.

@jastice Thanks for the report. I've already reported it https://github.com/sbt/sbt/issues/4816 and fixed it in https://github.com/sbt/sbt/pull/4821


use const field instead of internal RefValue

Better for performance, avoids using internals and avoids awkward [].

I've taken a bit with this, since it didn't seem like such a "clear win" to me as the other PRs, but why not :slightly_smiling_face:
Aside: how on earth did this branch end up with this particular name?

I've taken a bit with this, since it didn't seem like such a "clear win" to me as the other PRs, but why not

To me, it is a clear win because of:

Clarity: We want the ability to mutate some fields but not others. Julia has a feature for this, const-fields. Going through the hoops of wrapping something in a container doesn't do anything better.
Legibility: Instead of having to use [] everywhere these are just used like any other field.
Performance: Instead of allocating one mutable wrapper for each field this can allocate a single one where all the mutable fields are stored.


no support for requests which parse with absoluteURI

Say you run your requests to cowboy through a proxy.  The resulting get request could look like:
GET http://proxy.server.uri/some/query/string  HTTP 1.1 ...
Then, when cowboy uses decode_packet on it, the resulting parsed request:
{http_request,'GET',{absoluteURI,http,<<"proxy.server.uri">>,undefined,<<"/some/query/string">>},{1,1}}
doesn't match any of the cowboy_http_request:request(...) functions.  In the patch below, I just added that support in the simplest way I could:
patch:
From 6646c9b0cfcab0500f8f4648811c93a1421a3003 Mon Sep 17 00:00:00 2001
From: David Kelly<EMAIL_ADDRESS>Date: Wed, 1 Feb 2012 14:08:29 -0800
Subject: [PATCH] added absoluteURI support
If requests go through a proxy, they will have the original uri in the
request, i.e. : GET http://proxy.server.uri/some/query/string  HTTP 1.1 ...
That was problematic -- cowboy_http_protocol:request didn't know what to
to with the result of decode_packet applied to this, which would be something
like:
{http_request,'GET',{absoluteURI,http,<<"proxy.server.uri">>,undefined,<<"/some/query/string">>},{1,1}}
So, I just ignore the host, grab the path and pass into
cowboy_http_protocol:request({http_request, Method, {abs_path, Path}, Version}, State)
Seems to do the trick without much effort.
src/cowboy_http_protocol.erl |    2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/cowboy_http_protocol.erl b/src/cowboy_http_protocol.erl
index baee081..f807937 100644
--- a/src/cowboy_http_protocol.erl
+++ b/src/cowboy_http_protocol.erl
@@ -113,6 +113,8 @@ wait_request(State=#state{socket=Socket, transport=Transport,
request({http_request, _Method, _URI, Version}, State)
when Version =/= {1, 0}, Version =/= {1, 1} ->
error_terminate(505, State);
+request({http_request, Method, {absoluteURI, _Scheme, _Host, _Port, Path}, Version}, State) ->

request({http_request, Method, {abs_path, Path}, Version}, State);
request({http_request, Method, {abs_path, AbsPath}, Version},
State=#state{socket=Socket, transport=Transport,
urldecode={URLDecFun, URLDecArg}=URLDec}) ->
--
<IP_ADDRESS>

Hello! Do you still receive the Host header with the request? Can I see an example of HTTP request you receive like this?

Oh yes -- I did get the Host header, and it has the original (proxy) host in it.  The request started out on my development box using curl, which went to a proxy (and a load balancer before that).  I edited the names of the hosts to make it clearer, but this is part of the tcpdump output:
/q..W...GET http:/// HTTP/1.1
Host:
User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
Accept: /
Accept-Encoding: gzip
.. more headers here with oauth stuff in them...
X-Request-Start: [proxy] t=1328127360094081,[pqueue] t=1328127360095707

Alright, then I'll merge your patch along with tomorrow's changes. Thanks!

yay!  Thanks!
-d
On Wed, Feb 1, 2012 at 3:13 PM, Loc Hoguin <
<EMAIL_ADDRESS>
wrote:

Alright, then I'll merge your patch along with tomorrow's changes. Thanks!

Reply to this email directly or view it on GitHub:
https://github.com/extend/cowboy/issues/135#issuecomment-3769266

This is in, thanks!


Count date

Description
def is_leap(current_year):
if current_year % 4 ==0:
if current_year % 100:
if current_year % 400:
return True
else:
return False
else:
return False
else:
return False
year = 0
month = 0
day = 0
add_days = 0
right_input = False
def days_month(current_month):
if current_month == 2:
if is_leap(year): return 29
else: return 28
else:
months ={1:31, 3:31, 4:30, 5:31, 6:30, 7:31, 8:31, 9:30, 10:31, 11:30, 12:31}
return months[current_month]
while not right_input:
equation_of_problem = input("Please enter the year, month, day, and the days you want to add in the form (year,month,day,add_days)")
year, month, day, add_days = equation_of_problem.split(",")
year = int(year)
month = int(month)
day = int(day)
add_days = int(add_days)
if year > 2022 or year < 1900 or month >12 or month < 1 or day > days_month(month) or day < 1 or add_days >1000:
print(" invalid input")
right_input = False
else:
right_input = True
done = False
rest_of_days = day + add_days
while not done:
if rest_of_days > days_month(month):
rest_of_days = rest_of_days - days_month(month)
if month == 12:
month = 1
year += 1
else:
month += 1
else:
day = rest_of_days
done = True
print(year, month, day)
Domain
Algorithm
Type of Contribution
No response
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of LearnCPP.

/assign


Feat/code refactory

My goal was to improve code readability as a new contributor and decrease the final bundle size.

Building in my local machine
Before refactoring

bundle type
uncompressed
brotli

es.js
11.13 KiB
3.35 KiB

umd.js
11.56 KiB
3.45 KiB

After refactoring

bundle type
uncompressed
brotli

es.js
9.62 KiB
3.12 KiB

umd.js
9.96 KiB
3.22 KiB

Decrease percentage

bundle type
uncompressed
brotli

es.js
~13,57%
~6,87%

umd.js
~13,85%
~6,67%

Nice work!
Will merge it right now...


No tag version for Symphony 2.2.5

Can't find version 1.0 of your extension!
Did i missed something?
Thank's

All tags have been pushed! Thanks!


update ValidationCode and ValidationResponse names

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

@ajayk : Thanks for your contribution to the Azure documentation! The author, @banisadr, has been notified to review your proposed change.


numerically approximate conformal maps from arbitrary domains to the unit disc using the circle packing method

Is it possible to
numerically approximate conformal maps from arbitrary domains to the unit disc using koebepy?

It should be, let me see if I can write an example script.

How do you want to input your domain? Is a polygon sufficient?

Yes. See for example : https://math.stackexchange.com/questions/1885066/is-it-possible-to-find-aproximation-of-conformal-map-from-sequences-of-complex-p


test: use sync gateway 3.0.0-beta02

Codecov Report

Merging #214 (0414943) into main (a92b9e4) will decrease coverage by 0.01%.
The diff coverage is n/a.

:exclamation: Current head 0414943 differs from pull request most recent head ccfb303. Consider uploading reports for the commit ccfb303 to get more accurate results

@@            Coverage Diff             @@
##             main     #214      +/-   ##
==========================================
- Coverage   89.81%   89.79%   -0.02%
==========================================
  Files         116      116
  Lines        7478     7478
==========================================
- Hits         6716     6715       -1
- Misses        762      763       +1

Flag
Coverage Δ

e2e.cbl
89.50% <ø> (-0.02%)
:arrow_down:

unit.cbl
2.90% <ø> (ø)

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

Impacted Files
Coverage Δ

packages/cbl_ffi/lib/src/libraries.dart
70.00% <0.00%> (-3.34%)
: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 a92b9e4...ccfb303. Read the comment docs.


Support HLS through src= on iOS

Related to #816, we will be supporting HLS through Apple's built-in HLS implementation on iOS.  This depends on the refactoring in #816, plus additional checks for Apple's built-in HLS implementation.
As in #816, using Apple's HLS implementation on iOS means most of Shaka Player's configuration will have no effect. The browser will be responsible for streaming, buffering, etc. Side-loaded captions would also fail (because we would not be streaming text, either). Shaka Player would only be able to control DRM and license requests.
But this does mean some playback on iOS with the same player you use on other browsers.

Is the support for src= on iOS substantially different than on desktop Safari?

Will there be support for Fairplay on iOS with Key System "com.apple.fps.1_0"? This is probably related to https://github.com/google/shaka-player/issues/382

@chrisfillmore, no, it will be much the same.  The difference is that desktop Safari has MediaSource, so desktop Safari will be able to play HLS through either mechanism.
@avelad, hopefully this simplifies FairPlay for both iOS and desktop Safari.

I'd like to offer a dissenting opinion. I invite others to chime in if they disagree, particularly if this enhancement would add value for them.
A few months ago we attempted an integration with another vendor's HTML5 player, and decided to drop it after several weeks of work. One aspect of this player which was unappealing was how it attempted to be a universal solution for all use cases. We were looking to solve a particular problem, and were burdened with solutions to problems we didn't have.
Something that is appealing about Shaka is how it is relatively lightweight. It solves the particular difficult problem of adaptive streaming. Setting video.src= is not a difficult problem to solve (in the context of streaming video). Apple even provides a demo in the FPS SDK, if you need support for Safari.

@chrisfillmore, thank you for your feedback.  I will try to solicit broader feedback from the community before proceeding.

We (happily) use Shaka player in our player and started recently to support fmp4-HLS with it. We have a complete different player for iOS using native src though, notably due to the fact that video ads work differently on iOS (e.g. src needs to be changed on each ad break). However if you can crack FPS on iOS Safari we would be more than happy to test Shaka player on that aspect.

iOS 11.3 (Safari 11.1) support EME
https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html

@chrisfillmore, I appreciate your feedback and I acknowledge your dissenting opinion on this.  I wanted to tie up one loose end now that we've started work:

If support for src= increases complexity in Shaka to the extent that it makes it more difficult to develop solutions for streaming, then IMO it seems like more of a burden than a help. I would argue that client applications should not have a hard dependency on Shaka -- whatever abstraction sits between the client and Shaka should allow the app to play via src=.

What we've found so far is that the work we've started to implement src= support is actually cleaning up a lot of the most complex and difficult to maintain parts of the Player class.  So rather than increasing the complexity of Shaka Player, I believe this work is significantly improving Shaka Player in the long run.  It's a lot of work, but it seems worthwhile.
Apps are, of course, still free to use src= for themselves, and will never be required to depend on Shaka more than they want to.

If that's the case, then great!


remove this session?

How to empty or "destroy" this session?

What is your use-case? I guess this could be added.

You have to do this first it's very important for big sites


Port Material JS to C#

Would be awesome if those components were independent of Google's Javascript.
We should investigate the feasibility of having all (or at least most of) the JS code ported to C#. It will depends on features exposed by Blazor.

What a fantastic idea! :+1:

I'm closing this issue as the work is being tracked on #7


[PROJECT PROPOSAL]

Project Request

Sarcastic Chatbot

Field
Description

About
This Project is about a Sarcastic Chatbot which can be fun for conversation purposes.

Github
RohanHBTU

Email
<EMAIL_ADDRESS>

Label
GSSOC' 23

https://github.com/RohanHBTU
Define You

[x] GSSOC Participant
[x] Contributor

Project Name

Sarcastic Chatbot
Description

This Project is about a Sarcastic Chatbot which will be capable of mocking and sarcasm.
Scope
The Chatbot will play creative and fun roles for people who usually find themselves alone. It will mark a good impression of chatbots being friendly.
Timeline

Time period
Milestone

31 July
Prototype transformer model

3 August
Chatbot interface

6 August
Integration of model into chatbot

8 August
Final testing and pushing the code to remote branch

Video Links or Support Links

Please assign me this project as soon as possible.


implement core::error::Error in no_std

after migration to Rust 1.81 it's now possible to implement Error trait in no_std

This would be blocked on thiserror merging the relevant functionality I think, since we use it in a bunch of places for deriving Error
https://github.com/dtolnay/thiserror/pull/304

thiserror 2.0 released today, and it does support no_std now!


Socket not writable

Hi,
I'm trying to implement the ftp-srv. Every time a user connects, I get the error:
{
"name":"ftp-srv",
"hostname":"5921eeb2bd3b",
"pid":1,"id":"269f39b0-1cb5-48bd-aad9-c351824e54b2",
"level":50,
"err": {
   "message":"Socket not writable",
   "name":"SocketError",
   "stack":"
      SocketError: Socket not writable
      at /app/node_modules/ftp-srv/src/connection.js:139:23
      at Promise._execute (/app/node_modules/bluebird/js/release/debuggability.js:384:9)
      at Promise._resolveFromExecutor (/app/node_modules/bluebird/js/release/promise.js:518:18)
      at new Promise (/app/node_modules/bluebird/js/release/promise.js:103:10)
      at processLetter (/app/node_modules/ftp-srv/src/connection.js:129:14)
      at /app/node_modules/ftp-srv/src/connection.js:145:14
      at tryCatcher (/app/node_modules/bluebird/js/release/util.js:16:23)
      at Object.gotValue (/app/node_modules/bluebird/js/release/reduce.js:166:18)
      at Object.gotAccum (/app/node_modules/bluebird/js/release/reduce.js:155:25)
      at Object.tryCatcher (/app/node_modules/bluebird/js/release/util.js:16:23)
      at Promise._settlePromiseFromHandler (/app/node_modules/bluebird/js/release/promise.js:547:31)
      at Promise._settlePromise (/app/node_modules/bluebird/js/release/promise.js:604:18)
      at Promise._settlePromiseCtx (/app/node_modules/bluebird/js/release/promise.js:641:10)
      at _drainQueueStep (/app/node_modules/bluebird/js/release/async.js:97:12)
      at _drainQueue (/app/node_modules/bluebird/js/release/async.js:86:9)
      at Async._drainQueues (/app/node_modules/bluebird/js/release/async.js:102:5)",
   "code":500
},
"msg":"Socket not writable",
"time":"2020-05-24T09:57:51.827Z",
"v":0
}

The error occurs on local development and production release. The Production release is a Dockerfile deployment.
Version: 4.3.1
Server Config:
 const server = new FtpSrv({
    url: process.env.FTP_URL,
    pasv_url: process.env.PASV_HOSTNAME,
    pasv_min: process.env.PASV_MIN,
    pasv_max: process.env.PASV_MAX,
    anonymous: false,
    timeout: 300
  });

Hi,
I got the same error, not for all users.

I was able to see this error when I connected via web browser to the server. The timeout would trigger (300ms is really short) but the client was incorrectly calling Socket.prototype.end instead of Socket.prototype.destroy on close.
This is fixed by https://github.com/autovance/ftp-srv/pull/208
Was this similar to how you guys ran into this issue?

Hi,
The fix solves my problem.
Additionally I missed that the pasv ports must be a number.
Previously I used the .env file with dotenv and this returns a string. Therefore it doesn't work.
Thanks for solving this issue.


MySqlValueRef methods lack parity with PgValueRef

Bug Description
The format, as_bytes and as_str for PgValueRef are exposed outside of the create.  MySqlValueRef is only exposed within the crate.
Minimal Reproduction
See:  MySql implementation vs Postgres implementation.
To be fair, I really just want some mechanism of pulling out json and/or strings in every row (Are either of those standard somewhere and I just missed them?).  I'm probably doing this wrong (below), but this was the first pass that I thought should work.
use std::collections::HashMap;

use sqlx::{
    mysql::{MySqlPoolOptions as PoolOptions, MySqlRow as DbRow},
    Column, Row, ValueRef,
};

#[tokio::main]
async fn main() -> Result<(), sqlx::Error> {
    let default_db = "mysql://tester:tester@<IP_ADDRESS>/test".to_string();
    let db = std::env::var("DB_URL").unwrap_or(default_db);
    let pool = PoolOptions::new().max_connections(5).connect(&db).await?;

    // Make a simple query to return the given parameter (use a question mark `?` instead of `$1` for MySQL)
    let rows: Vec<_> = sqlx::query("SHOW TABLES").fetch_all(&pool).await?;

    for row in rows {
        let json_data = row_to_json(row);
        println!("Row: {json_data}");
    }

    Ok(())
}

fn row_to_json(row: DbRow) -> HashMap<String, String> {
    let mut result = HashMap::new();
    for col in row.columns() {
        let value = row.try_get_raw(col.ordinal()).unwrap();
        let value = match value.is_null() {
            true => "NULL".to_string(),
            false => value.as_str().unwrap().to_string(),
        };
        result.insert(col.name().to_string(), value);
    }

    result
}

Info

SQLx version: 0.6.2
SQLx features enabled: "mysql", "runtime-tokio-rustls"
Database server and version: mysql-8.0.31
Operating system: macos (m1)
rustc --version: 1.65.0

Hi,
I am looking into this and I am running into the same problem.
Did you find a solution in the end or is this still a standing issue?

Still a standing issue.  I should also note that I've migrated some of that work into SeaORM, so I am no longer really looking at this problem.


[debt] make XML::Schema.read_memory an alias for XML::Schema.new

The method XML::Schema.read_memory is intended to be a factory method for creating a new schema from the string contents of the XSD.
But ... this is exactly what XML::Schema.new does. And under the hood, libxml2 is still calling the same parsing code, so I would be surprised if it was any faster.
This duplication introduces debt to the codebase because it's another path we need to test (note: we're not doing a good job of this already), and the fact that we've begun to have to add workarounds for libxml2 misbehavior (see #1985) and it's not clear if we need to add it to both code paths or what.
Anyway, here's what I want:

benchmark the two paths, make sure there isn't a performance reason to keep read_memory around
remove read_memory and make it an alias for XML::Schema.new

Benchmark:
#! /usr/bin/env ruby

require "nokogiri"
require "benchmark/ips"

ASSETS_DIR          = File.expand_path File.join(File.dirname(__FILE__), 'test', 'files')
PO_SCHEMA_FILE      = File.join(ASSETS_DIR, 'po.xsd')

xsd = File.read(PO_SCHEMA_FILE)

Benchmark.ips do |b|
  b.time = 10
  b.warmup = 2

  b.report("Schema.new") do
    Nokogiri::XML::Schema.new(xsd)
  end

  b.report("Schema.from_document") do
    Nokogiri::XML::Schema.from_document(Nokogiri::XML::Document.parse(xsd))
  end

  b.report("Schema.read_memory") do
    Nokogiri::XML::Schema.read_memory(xsd)
  end

  b.compare!
end

Results:
Warming up --------------------------------------
          Schema.new   928.000  i/100ms
Schema.from_document   954.000  i/100ms
  Schema.read_memory     1.002k i/100ms
Calculating -------------------------------------
          Schema.new      8.430k (± 9.8%) i/s -     84.448k in  10.118964s
Schema.from_document      8.040k (±13.1%) i/s -     79.182k in  10.055691s
  Schema.read_memory      9.334k (±17.4%) i/s -     90.180k in  10.051572s

Comparison:
  Schema.read_memory:     9333.8 i/s
          Schema.new:     8429.7 i/s - same-ish: difference falls within error
Schema.from_document:     8040.4 i/s - same-ish: difference falls within error

Generally, read_memory is modestly faster though shows greater variation in performance. I don't think the modest performance justifies the presence of a second implementation. @tenderlove WDYT?

I'll also add that https://github.com/sparklemotion/nokogiri/issues/2115 documents that read_memory doesn't work (and has probably not worked for a long time) in JRuby.


[FR] Is it possible to use impersonated service account?

Is your feature request related to a problem? Please describe.
maybe related to #1703
I think It is not natural for the client to always have the service account json file, and I want to access the firebase admin through impersonate service account generated by gcloud auth application-default login --impersonate-service-account= which the service account has permission for generating custom token.
However, when I use the service account which now stored in ADC, firebase admin throws an error message: 'Refresh token must contain a "client_id" property.'.
In fact, the impersonate service account does not have a client_id itself, but it is contained in source_credentials like:
{
  "delegates": [],
  "service_account_impersonation_url": "",
  "source_credentials": {
    "client_id": "",
    "client_secret": "",
    "refresh_token": "",
    "type": "authorized_user"
  },
  "type": "impersonated_service_account"
}

Describe the solution you'd like
When checking ADC's service account, if type is impersonated_service_account, then check source_credentials.
Describe alternatives you've considered
I can manually get my service account from ADC and use 'source_credentials'. But is it really the only solution for checking impersonated service account?
Additional context
No additional context

@lahirumaramba any update?

This is fixed in #1862 and now included in the v11.5.0 release.
Thanks folks for your patience on this! Try out the new feature if you get a chance and let us know what you think.
If you encounter any issues, please open a new issue on Github. Thank you!

Hi @blue-hope ! Thanks for working on this! Could you let me know what your initializeApp function looks like?
I'm initializing firebase like this:
initializeApp({
        credential: applicationDefault()
    })

But I get the following error:
Error: //cloud.google.com/docs/authentication/. If you are getting this error with curl or similar tools, you may need to specify 'X-Goog-User-Project' HTTP header for quota and billing purposes. For more information regarding 'X-Goog-User-Project' header, please check https://cloud.google.com/apis/docs/system-parameters. Raw server response: "{"error":{"code":403,"message":"Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the identitytoolkit.googleapis.com. We recommend configuring the billing/quota_project setting in gcloud or using a service account through the auth/impersonate_service_account setting. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/. If you are getting this error with curl or similar tools, you may need to specify 'X-Goog-User-Project' HTTP header for quota and billing purposes. For more information regarding 'X-Goog-User-Project' header, please check https://cloud.google.com/apis/docs/system-parameters.","errors":[{"message":"Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the identitytoolkit.googleapis.com. We recommend configuring the billing/quota_project setting in gcloud or using a service account through the auth/impersonate_service_account setting. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/. If you are getting this error with curl or similar tools, you may need to specify 'X-Goog-User-Project' HTTP header for quota and billing purposes. For more information regarding 'X-Goog-User-Project' header, please check https://cloud.google.com/apis/docs/system-parameters.","domain":"usageLimits","reason":"accessNotConfigured","extendedHelp":"https://console.developers.google.com"}],"status":"PERMISSION_DENIED","details":[{"@type":"type.googleapis.com/google.rpc.ErrorInfo","reason":"SERVICE_DISABLED","domain":"googleapis.com","metadata":{"consumer":"projects/764086051850","service":"identitytoolkit.googleapis.com"}}]}}"

Hi @blue-hope ! Thanks for working on this! Could you let me know what your initializeApp function looks like?
I'm initializing firebase like this:
initializeApp({
        credential: applicationDefault()
    })

But I get the following error:
Error: //cloud.google.com/docs/authentication/. If you are getting this error with curl or similar tools, you may need to specify 'X-Goog-User-Project' HTTP header for quota and billing purposes. For more information regarding 'X-Goog-User-Project' header, please check https://cloud.google.com/apis/docs/system-parameters. Raw server response: "{"error":{"code":403,"message":"Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the identitytoolkit.googleapis.com. We recommend configuring the billing/quota_project setting in gcloud or using a service account through the auth/impersonate_service_account setting. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/. If you are getting this error with curl or similar tools, you may need to specify 'X-Goog-User-Project' HTTP header for quota and billing purposes. For more information regarding 'X-Goog-User-Project' header, please check https://cloud.google.com/apis/docs/system-parameters.","errors":[{"message":"Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the identitytoolkit.googleapis.com. We recommend configuring the billing/quota_project setting in gcloud or using a service account through the auth/impersonate_service_account setting. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/. If you are getting this error with curl or similar tools, you may need to specify 'X-Goog-User-Project' HTTP header for quota and billing purposes. For more information regarding 'X-Goog-User-Project' header, please check https://cloud.google.com/apis/docs/system-parameters.","domain":"usageLimits","reason":"accessNotConfigured","extendedHelp":"https://console.developers.google.com"}],"status":"PERMISSION_DENIED","details":[{"@type":"type.googleapis.com/google.rpc.ErrorInfo","reason":"SERVICE_DISABLED","domain":"googleapis.com","metadata":{"consumer":"projects/764086051850","service":"identitytoolkit.googleapis.com"}}]}}"

+1

Hello, you need to authenticate as a service account, not a end-user.
gcloud auth application-default login --impersonate-service-account<EMAIL_ADDRESS>

Hey @Klaitos , that's what i have been doing but without luck. I'm impersonating the firebase service account that has the following permissions:

And as for the end user, my account has Owner permissions so i should be good.
Is there anything else I could be doing wrong?

Hum yes you're right, it does not simply work on my local computer either.
I figured it out how to make it works but it requires a lot of changes in the class ImpersonatedServiceAccountCredential, i can try to make a pull request but i don't know many things on oauth2 scopes.

@blue-hope i think we might need your help on this one. I tried some code on my laptop, it works when we tweak the function getAccessToken of class ImpersonatedServiceAccountCredential  with something like

  const auth = new GoogleAuth({
    scopes: 'https://www.googleapis.com/auth/cloud-platform',
  });
  const client = await auth.getClient();
  const json = await client.getAccessToken()

  if (!json.token || !json.res?.data.expireTime) {
    throw new FirebaseAppError(
      AppErrorCodes.INVALID_CREDENTIAL,
      `Unexpected response while fetching impersonated access token: ${JSON.stringify(json)}`,
    );
  }

  return {
    access_token: json.token,
    expires_in: new Date(json.res.data.expireTime).valueOf() - new Date().valueOf()
  }

but i'm not aware of unexpected consequences

It looks like we are not handling the token creation for impersonated accounts correctly here: https://github.com/firebase/firebase-admin-node/blob/49251a82b8fd1e30e09a82ca3797623d8691f4d0/src/app/credential-internal.ts#L399
Looking at the implementation in google-auth-library-nodejs this needs a bit more work. We need to send the token request to iamcredentials.googleapis.com instead of using the REFRESH_TOKEN_HOST. We also need to include the required scopes for admin sdk and add support for delegates in impersonated credentials. See: https://github.com/googleapis/google-auth-library-nodejs/blob/bdc6339014ae13945bbf82576f7ff71534851ab1/src/auth/impersonated.ts#L132
The proper fix for this is to migrate Admin SDK credentials handling logic to use google-auth-library-nodejs. This migration prevents us from having to maintain a separate codebase to perform the same actions that google-auth-library-nodejs handles better.
This is part of the reason for @Klaitos's workaround above to work, as it creates a new GoogleAuth client using ADC (and the client is smart enough to detect impersonated service account credentials from your environment).
We are currently doing the initial planning for credentials migration to google-auth-library-nodejs and part of that work is also related to #1377

Sorry for my naive approach for getting access token.
Don't we have to hot-fix REFRESH_TOKEN_HOST to iamcredentials.googleapis.com before implementing google-auth-library-nodejs? @lahirumaramba
And if I can get a chance, I would like to participate the migration task.

It's not that simple because you need to call the route iamcredentials.googleapis.com with an access token from the source user in order to get the access token for the service account and we do not have a simple way to get the first one i think

Folks, is there an open issue tracking this? It seems like a huge problem that firebase doesn't work out of the box with Google's Recommended Security Practices for Service Accounts.

Can we re-open this please?

I implemented a workaround to do service account impersonation in https://gist.github.com/lox/8bff5607c3e713c92a03a631796ab3f3.

Hey @velocd we have made some changes internally to migrate credentials handling to use google-auth-library. Check out https://github.com/firebase/firebase-admin-node/issues/1377#issuecomment-1971607584 for a custom build if you have some time to test it out and share any early feedback. Thanks!


Stop the logging in loop after 3 unsuccesful attempts, prevents the infinite loop

File: logger.js
Possible Solution: A global counter that prevents login after 3 attempts

I'd like to claim this issue if it's not taken. Proposal submitted already


style: simplify some statements for readability

We can improve readability and code maintainability by replacing lines like
help: The correct format looks like #[diesel({})]",
SQLITE_TYPE_NOTE

with
help: The correct format looks like #[diesel({SQLITE_TYPE_NOTE})]"

There is a clippy lint for that too if we choose to accept that
https://rust-lang.github.io/rust-clippy/master/index.html#/inline format


Improve UpdateCLI workflow

Proposed Changes

Improve UpdateCLI workflow to delete leftover branches before the automation is executed. This should help fix (or at least reduced) the amount of failed pipelines - https://github.com/k3s-io/k3s/actions/workflows/updatecli.yaml.
Types of Changes

Verification

Testing

Linked Issues

User-Facing Change

N/A

Further Comments

CC @matttrach


Add equals/hashCode/toString

Required for all messages and all mappers.

Makes no sense to do this now. It may be useful to do ti later.


Corrected the exception class used and removed unnecessary strtolower in MethodScanner::setVisibility

Exception - which is used as exception class within setVisibility - is not a class but a (sub)namespace. InvalidArgumentException likely is the intended exception class here.
This is my first submission. Wanted to get my feet wet with the submission workflow. :)

@fhein patch looks fine, but a test case verifying the expected thrown exception type is needed. See https://github.com/zendframework/zend-code/blob/6b1059db5b368db769e4392c6cb6cc139e56640d/test/Scanner/MethodScannerTest.php
You can push to your current branch to update this PR :+1:

Done. Plus a bit. :) Anything left to do?

Looking good!

:) . This was very helpful to setup and test my environment. Thanks.
After a short review of Roave/BetterReflection I think it is better to stop fiddling around with the scanner stuff here. I've got some spare time I could spent helping out. If you like and if there's demand, feel free to give me a try and direct me to somewhere where help is needed.

Thanks, @fhein!


Reconnect devstack peers to avoid flakes

Improve test reliability by getting nodes within a devstack to reconnect to each other rather than assuming they connect and stay connected. Also reduce the dial timeout time to only a second rather than the default of 60 seconds.

See run attempts - https://app.circleci.com/pipelines/github/bacalhau-project/bacalhau/4406


fix(kube): Fixes missing API versions

In several of the job checks and other conversions we were using legacyscheme.
I don't know why it was working before, but I am guessing something changed
between k8s 1.15 and 1.16 with which types were registered. To fix I changed the references to use the default scheme in client-go
Closes #6894

I am going to see if anyone on the issue can double check this works as well.
I tested this with a handful of different charts to make sure it didn't break something else and I tested charts with batch/v1

I am going to leave the PR open until my morning so people across timezones can give the PR a whirl as well. Really trying to avoid any other regressions from hidden schema stuff

In several of the job checks and other conversions we were using legacyscheme.
I don't know why it was working before, but I am guessing something changed
between k8s 1.15 and 1.16 with which types were registered. To fix I changed the references to use the default scheme in client-go
Closes #6894
This issue also occurs on Kubernetes 1.13 on GKE but your fix solves it. Thanks.

$ k version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.11", GitCommit:"25074a190ef2a07d8b0ed38734f2cb373edfb868", GitTreeState:"clean", BuildDate:"2019-09-18T14:41:46Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.11-gke.9", GitCommit:"6c1e92d07f5717440f751666d4aad6943015d3cb", GitTreeState:"clean", BuildDate:"2019-10-11T23:14:17Z", GoVersion:"go1.11.13b4", Compiler:"gc", Platform:"linux/amd64"}

moving to 2.16.2; looks like this didn't make it into 2.16.1


WMS: 11287 Quarterly QA Update

Add here your WMS ID
General requirements

Information in the workshop is adequate and updated
Code is correct and working
Links are correct
Make sure you enter the help email link in your manifest.json
Please make sure WMS URLs are updated as needed after your PR is approved

Checklist - Refer to the QA document for the complete list
Please confirm that the following is completed before submitting your PR

[ ] All filenames are lower case (including folders, images, files, etc.)
[ ] Filenames are descriptive
[ ] Your workshop folder structure should be similar to the one used in the sample workshop (https://github.com/oracle-livelabs/common/tree/main/sample-livelabs-templates/sample-workshop)
[ ] Are you using multiple versions (desktop/, sandbox/, tenancy/)? Make sure that each of them contains a manifest.json and an index.html
[ ] Image references in markdown contain an alternate text

Hi,
I just updated the introduction format and pushed the changes. Let me know if anything else needs to be updated.
Thanks,
Miles
From: ramumg @.>
Date: Friday, April 28, 2023 at 3:34 PM
To: oracle-livelabs/database @.>
Cc: Miles Novotny @.>, Mention @.>
Subject: [External] : Re: [oracle-livelabs/database] WMS: 11287 Quarterly QA Update (PR #248)
@ramumg requested changes on this pull request.
Hi @milesnovhttps://urldefense.com/v3/__https:/github.com/milesnov__;!!ACWV5N9M2RV99hQ!Pt3jorZ5Dylilv4-_Ixxnjap7oChBtltlEMUBioBSbFA7HETd6JOxgQ39KnLIHzUwk30htYO22xkoN453K6Aztdgx0ww$,
Please make sure that you go over the QA document.
QA (6).docxhttps://urldefense.com/v3/__https:/github.com/oracle-livelabs/database/files/11357130/QA.6.docx__;!!ACWV5N9M2RV99hQ!Pt3jorZ5Dylilv4-_Ixxnjap7oChBtltlEMUBioBSbFA7HETd6JOxgQ39KnLIHzUwk30htYO22xkoN453K6Azog1p7xo$
The introduction page doesn't follow the livelabs format.
Let me know if you have any question.
Thank you,
Ramu
—
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/oracle-livelabs/database/pull/248*pullrequestreview-1406573058__;Iw!!ACWV5N9M2RV99hQ!Pt3jorZ5Dylilv4-_Ixxnjap7oChBtltlEMUBioBSbFA7HETd6JOxgQ39KnLIHzUwk30htYO22xkoN453K6AzmKTz1Zu$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/A2B6UGRSGGO5MNOS3E2W73LXDQSUDANCNFSM6AAAAAAXPRFJSU__;!!ACWV5N9M2RV99hQ!Pt3jorZ5Dylilv4-_Ixxnjap7oChBtltlEMUBioBSbFA7HETd6JOxgQ39KnLIHzUwk30htYO22xkoN453K6AzoXPtHN_$.
You are receiving this because you were mentioned.Message ID: @.***>


Hide state and temp tiddlers in nodejs wiki

Fixes #20

Tiddlers starts with $:/ won't show up in the disk when using nodejs wiki, and won't cause data leak if we use fileSystemPath to put the tiddler in a different folder.
Currently, the state tiddler of SE will go into different folder than the original tiddler, because it have different tags than the original tiddler, so won't be recognized by fileSystemPath to automatically move it.

Reopen one.


What's the plan for online (background) garbage collection

Hello - we've been reading the documentation for the new garbage collection in docker registry.
 In future registry versions the intention is that garbage collection will be an automated background action and this manual process will no longer apply.

"Stop the world" garbage collection will not work for us. The SLA we have with our customers precludes the amount of downtime required.
Could you please advise what the current plan is for automated background GC? i.e. any design documents available, and whether there is a release target in mind.

@jhart1685 : there is not much I can tell you.   We have started some internal discussions but i don't have a release date

@RichardScothern has there been any updates on this?

@RichardScothern Is there any progress on this? We attempted to use the GC feature as-is, but we have enough developers and overnight processes that there is no time of day when the downtime to restart in readonly mode is acceptable for us.

It's been a full year now, has there been any more discussions you can share with us @RichardScothern ?

Next year passed and there is no progress...
In our setup we have reached a point where GC takes many hours and we can not keep registry RO for so long.
GC has poor computational complexity accessing storage, but I have no time and knowledge to address this, so I thought of simpler solution.
The idea is to leave mark-and sweep proces as it is, but refrain from deleting "young" blobs. By selecting sufficiently far time boundary we can assure that no newly created blobs will be deleted. This will leave some garbage, but it will be collected eventually in some future pass.
There is also a possibility that we delete some long-unused layer which happened to be used by newly (during GC process) pushed image. I think that probability of such event is very low.
Do you consider this as a viable solution? We could make this an option for "you know what you are doing" scenarios.

@bartebor that sounds like a really simple approach that would work well. Have you implemented it all anywhere?

@chino I have not implemented it yet. We switched storage backend from swift to nfs gaining huge speed improvements so GC performance is not a serious issue for us now. Having said that, we are still interested in not having to stop registry while GCing, just priorities changed. Too bad project maintainers do not seem to show any interest in this topic. This is a little bit discouraging to say the least.


catalyst ingest-exchange -x poloniex -i btc_usdt --show-progress fails with a Http 403 error

Operating System: MAC OSX HighSierra 10.13.4
Python Version: 3.6.2
Python Bitness: 64
How did you install Catalyst: pip
Python packages: catalyst, ipython, jupyter

I'm seeing an error on running the command above. I think this is failing because there seems to be an intermediary captcha page which turns up when we try to hit the public APIs.
This is the error message thrown up by python
ccxt.base.errors.ExchangeNotAvailable: poloniex https://poloniex.com/public?command=returnTicker GET 403 Client Error: Forbidden for url: https://poloniex.com/public?command=returnTicker <!DOCTYPE html>

Could you suggest a workaround for this?

This is a known issue with Poloniex exchange. There is nothing we can do. This happens when you retrieve data from the exchange from certain geographies (mostly from outside the US).
Our only recommendation is that you connect to the exchange via a VPN, simulating you are inside the US.


Formly/Angular-Material Select Multiple - selectAll should not select disabled mat-option.

Hi, I find formly to be a great tool to create reactive forms and easier the process of handling models.
Description
I am using formly with angular material. When an option is disabled, selectAllOption must not select the disabled mat-option!
Demo
I created a demo, which can be seen here-
https://stackblitz.com/edit/ngx-formly-ui-material-wdcvcg?file=src/app/app.component.ts
PS- I am new to formly and if this was designed to be like this intentionally & was not an issue, I request you to pardon me in that case.

This issue has been fixed and released as part of v5.10.6 release.
Please let us know, in case you are still encountering a similar issue/problem.
Thank you!


Fix #573. Ensure we don't write 0 bytes to pty

On macOS, pasting 0 bytes from the clipboard hangs the terminal.
I.e. pbcopy </dev/null followed by ctrl-v. This ensures
we never send 0 bytes.

If this is macOS specific, I think the fix should be in copypasta/src/macos.rs.

Alright. It doesn't seem to hang on Linux, but I figured the writing of 0 bytes was ok for both, but I'm happy to move the fix.

Actually no.
It's not the copy/pasting that is the problem. It's the sending of 0 bytes which also currently happens on dead keys.

You're right. Just tested it with xclip < /dev/null on Linux and pasted in alacritty. Terminal hangs.
OTOH you could reword the comment, because it happens on other platforms as well.

Thanks for checking on Linux. Comment fixed.

Done

Thanks @algesten!


Do not require IDs (allow empty string IDs)

fix(index): allow empty string as id
test(post-deploy): make sure empty id does not bomb anymore
chore(debug): add some meta-logging
chore: more console.log debugging
refactor(logger): wait for import to complete
ci(circleci): reduce wait time

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

v2.1.1
v2.1.1
GitHub release

Your semantic-release bot :package::rocket:


No pre-filled fields after creating or updating item.

Hi everyone!
When i update / create:

... everything is ok in my table.

But on the updated page, fields are not pre-filled.

Any ideas?
Thanks! <3
Multiselect::make('Categories', 'categories')
                ->asyncResource(\App\Nova\Category::class)
                ->nullable(true)
                ->saveAsJSON(true)
                 ->hideFromIndex()  ,

            Multiselect::make('Produits', 'products')
                ->asyncResource(\App\Nova\Product::class)
                ->nullable(true)
                ->saveAsJSON(true)
                ->hideFromIndex() ,

Vincent

Nobody ?

I'm unable to reproduce this issue. I think you have to debug it on your side or create a reproducible example for me. :(


Error message details dialog

Includes and supersedes #22
Sorry for the drive by commits :)

Some minor changes.
It feels uncommon to see a warning above the textfield and the login-button.
The visual flow seems to be disturbed. Can the message be between the button and a possible list of other usernames?

I played with various positions and this one felt the least worst. Placing it between the button and the list or between the logo and the form field felt even more disturbing. You can easily play with this by moving the ErrorMessage widget to different positions within the Column widget.
By the way looking at this, I guess I forgot to populate the error details parameter on the RPC bus with a formatted full trace for the iOS side of things. Do you want to take a look at that?

Yep. I'll take a look.


Deprecated parameters warning

The channel, chan_creds, and updater_proc parameters will be removed on 2017/09/08

Which gem?

Sorry, google-cloud-speech

Thanks. I'll release an update to stop triggering the warning. Thanks for opening the issue!

So apparently the version of the googleapis-common-protos gem that was released this week is raising that deprecation warning. We probably need to address this for all gems that use Google::Longrunning::OperationsClient.

Right now it looks like Spanner and Speech are the only gems affected.

Today all google-cloud-* gems were refreshed and released, and I've ensured that none of the gems raise warnings during their normal usage. Closing this issue as fixed. If you continue to see warnings, please open a new issue. Thank you for your contribution!


-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null  will crash app

Hi,
In the project Building Setting --> Other Linker Flags, Debug and Release, add -Wl,-sectcreate,__RESTRICT,__restrict,/dev/null. than will crash app.
-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null could stop dylib hooking in my app.
It will be a great pleasure for me if you could solve this problem.
Thanks a lot!

I have tried some methods, for example, Dynamic Framework, CocoaPods, Static Framework. App crashed also.
If i clean the Other Linker Flags statement, it launch successfully.

Other Linker Flags:

-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null function:

When you say that this change will "will crash app", what exactly do you mean? If your application is crashing, can you share the crash log and backtrace from the crash? Can you share why you believe this to be an issue with Realm?

I have found a reason that maybe not exactly. My project include Realm and some swift files at the same time, it will crash and log some information such as libswiftAVFoundation, libswiftCore and other libswiftxxx not loaded.
However, If I delete all swift files, App lunch successfully.

I set the Embedded Content Contains Swift Code in Building Settings to 'YES' when I get the crashed log. And then clean the project and run again, crashed as before.

I think it may be a linker mechanism problem , such as Dynamic and Static.

Your recent comments still mention that it is crashing, but you've not yet provided a crash log. Can you please share one?

I have found the reason. After CocoaPods updated and Pods.debug.xcconfig file add inherited flag to OTHER_LDFLAGS. Removed the inherited flag, everything is OK.

@bdash, I did not do proper research on this issue before. It's my mistake. Thank you very much.


Consider alternate mechanisms to define specialized qualifiers in Statement profiles

The current core-im-source draft from Larry and Alex uses a plural label qualifiers but takes a single object as its type:

I assume this plural name is used because of how you implement statement-specific qualifiers in profiles like the Variant Pathogenicity Statement - where the qualifiers field takes a single "untyped" object within which several specific 'qualifying' properties are defined:

I would like to propose alternatives to the naming and nesting of properties in undefined objects as a way to specify profiled qualifier representations.

Alternative 1 (preferred): Directly specialize the core-im Statement.qualifier property in a given Profile schema to define specific qualifier-type properties.  So for Variant Pathogenicity, where we want to specify three possible types of qualifiers (penetrance, moi, gene context) - the VariantPathStatement profile would include the following three properties on the VarPAthStatement object that all extend a core-im qualifier property:

VariantPathogenicityStatement:
  maturity: draft
  type: object
  inherits: va.core:Statement
  properties:
    . . .
    penetranceQualifier:
      extends: qualifier
      type: string
      enum:
        - high
        - low
        - risk allele
      description: >-
        The extent to which the variant impact is expressed by individuals …

    modeOfInheritanceQualifier:
      extends: qualifier
      type: string
      enum:
        - autosomal dominant
        - autosomal recessive
        - X-linked dominant
        - X-linked recessive
        - mitochondrial
      description: >-
        The pattern of inheritance expected for the pathogenic effects …

    geneContextQualifier:
      extends: qualifier
      $refCurie: gks.genes:Gene
      description: >-
          A gene context that qualifies the Statement.

This is to me a clear, simple, and direct implementation of how I have envisioned qualifier specialization working.  At its core is the simple pattern where a profile holds several distinct qualifier properties that are direct properties of the Statement, and not nested in some untyped object.  But not sure if there is a technical or application-specific reason this won’t work?
Alternative 2 below was not considered / approved on the 5-29 call, so next step is to wait for Alex' team to draft an implementation of their approach to encoding Alternative 1 in a way the metaschema tooling can handle.
Or, might we consider refining the metaschema code to allow for multiple specializations of a single property - so we could directly adopt Alternative 1 above?  If it is just a technical impediment that is preventing this useful feature, perhaps we could change it?

Alternative 2: Another approach that is closer to the current way things are specified, but explicit declares object types, would involve a VariantPathogenicityQualifierSet class in the VarPath profile schema.  In this class, we could define the three qualifier properties defined in the current schema within a nested untyped object. This class would extend a generic QualifierSet class we would want to add to the core-im. Then the existing VarPathStatement.qualifiers` property would then simply reference this class as its type, e.g.:
In the core-im, we add:
"Statement":
  heritableProperties:
    "qualifierSet":
       "type": "#/$defs/ QualifierSet"

"QualifierSet":
   "heritableProperties":
      "qualifiers":
         "type": "array"
         "items": Qualifier

TO DO: finish getting this right

In the VarPathStatement class:
  qualifierSet:
      $ref: "#/$defs/ VariantPathogenicityQualifierSet"

Definition of the VariantPathogenicityQualifierSet class in the varpath profile:
VariantPathogenicityQualifierSet:
  maturity: draft
  type: object
  inherits: va.core:QualifierSet
  description: >-
    Additional, optional properties that qualify a VariantPathogenicity Statement.
  properties:
    penetranceQualifier:
        extends: qualifier
        type: string
        enum:
           - high
           - low
           - risk allele
        description: >-
           The extent to which the variant impact is expressed by individuals …

    modeOfInheritanceQualifier:
        extends: qualifier
        type: string
        enum:
           - autosomal dominant
           - autosomal recessive
           - X-linked dominant
           - X-linked recessive
           - mitochondrial
        description: >-
           The pattern of inheritance expected for the pathogenic effects …

    geneContextQualifier:
        extends: qualifier
          $refCurie: gks.genes:Gene
          description: >-
              A gene context that qualifies the Statement.

While this is not as simple and clean as the first alternative, it is at least IMO a more clear and explicit way to implement the current approach – in that avoids it what I find to be a confusing use of nested properties and  untyped objects.  However, it does require defining and profiling an additional core im class (QualifierSet)  in order to define a  VarPathStatement profile. But again, if we go with Alternative 1 above, which I prefer – we avoid all of this.

I'm in favor of moving forward with Alternative 2 in lieu of the effort and time needed for Alternative 1. Alternative 2 resolves the main concerns of being able to both tag which qualifiers are required vs optional as well as being able to explicitly define the types and subtypes of qualifiers.

Looking closer at the Alt 2 proposal - I actually think we run into the same problem here as for Alternative 1 - as we would need to extend a QualifierSet.qualifier core IM property three different times to define the three VarPath qualifiers needed in that profile. We can see this clearly in the example above - where penetranceQualifier, modeOfInheritanceQualifier, and geneContextQualifier all extend the same QualifierSet.qualifiers property.  (Recall, prolfiling does not allow for defining abritrary new named properties in a profiled class. All named properties in a profile need to be inherited from or extend a core-im property.)
Given this, perhaps we wait for Alex to draft his proposal for implementing Alternative 1 and see if we like that.  He liked the spirit of that alternative, and said that it could be done using existing metaschama functionality.

I know I am jumping the gun here given that we haven't seen Alex' propsoal for implementing Alternative 1 - but is it crazy to consider extending the metashchema functionality to allow for what we need to implement Alternative 1 directly?  i.e. the ability to specialize one core im property into three different profile properties? Just like a class or a property in an ontology can have multiple subtypes? This would directly support implementing Alternative 1 as above, and seems like generally useful functionality for metaschema tooling to support.
I am not really qualified to propose such things, but naively it seems like this would just require a new keyword to use instead of extends that would support this functionality - maybe call it multiplies?  The metaschema code could be updated to know that when it sees this multiplies keyword, it will be deriving multiple new properties in a profile that all inherit the characteristics of their parent core-im property, but overwrite these with any new constraints defined in the 'multiplied' property. A profile schema based on this approach would look something like:
VariantPathogenicityStatement:
  maturity: draft
  type: object
  inherits: va.core:Statement
  properties:
    subject: ...
    predicate: ...
    object: ...
    . . .
    penetranceQualifier:
      multiplies: qualifier
      type: string
      enum:
        - high
        - low
        - risk allele
      description: >-
        The extent to which the variant impact is expressed by individuals …

    modeOfInheritanceQualifier:
      multiplies: qualifier
      type: string
      enum:
        - autosomal dominant
        - autosomal recessive
        - X-linked dominant
        - X-linked recessive
        - mitochondrial
      description: >-
        The pattern of inheritance expected for the pathogenic effects …

    geneContextQualifier:
      multiplies: qualifier
      $refCurie: gks.genes:Gene
      description: >-
          A gene context that qualifies the Statement.

Of course, this 'multiplies' functionality could also be used to implement Alterntive2 if we like that approach better.  As noted above, this alternative woudl also need to specialize one core im property into three profile properties.

UPDATES:
On the 5-29-24 call, Alex and Javi approved of the simplicity/directness of Alternative 1 - including the idea that all qualifier properties would be captured at the same level as the core s-p-o properties that together express the Statements core proposition.  But Alex clarified that the metaschama 'extends'  functionality cannot implement Alternative 1 exactly as shown above - as it cannot 'override' a single core-im property (e.g. qualifier) multiple times to create several derived/specialized qualifier properties in a Profile (e.g. penetranceQualifier, geneContextQualifier, etc).  However, he did indicate that they could implement the spirit of this proposal in a different way.  His team will explore / demonstrate how this could work.
Another consideration that favors Alternative 1 is that there are some qualifiers that are required and critical components of a given statement type (e.g. the disease qualifier for a therapeutic-response statement), and others that are not required but can optionally provide additional detail or context to a statement (e.g. the alleleOrigin qualifier for a therapeutic-response statement).  I get the sense that Alex would like the essential qualifiers to not be shown at the same level as the core s-p-o properties (which is achieved by Alternative 1), and not nested down a level in a Qualifiers object (which would happen in Alternative 2).
One the 6-12-24 call, Larry seemed to support Alternative 1 as the best long term solution, but pushed for short term implementation of Alternative 2 as a concrete improvement that would require minimal change/effort - given that Alternative 1 may require some developer time.
Matt still factors Alternative 1, but agrees Alternative 2 is a simpel short term improvement if that is all that we can do right now. He reiterated the fact that defining qualifier specializations in yaml files is something that community modelers will need to be able to understand and do for themselves. So it needs to remain clear and simple to understand and implement. This conceptual clarity and ease of implementation was one of the main drivers for Alternative 1 proposed above. As was the clarity of the connection between the profiled qualifiers and the core-im qualifier property.  Whatever solution Alex's team comes up with to implement this approach should be clear and simple to implement, and not obscure the connection between the core-im and profiled qualifiers.

Larry - can you explain further what you mean by “ find a way to show a Concept Attribute called Qualifier in its place. ”?

After more discussion we are going to make changes to the metaschema processor to support approach 1.

@larrybabb and @mbrush is there a recording that documents why we will be investing the effort to make this change in the near-term?

@ahwagner I don't think the discussion was recorded, but I will summarize here. To be clear, the solution that Larry and I decided we prefer was implementing Alternative 1 by extending the metaschema code with a new keyword and functionality that allows for specializing a core-im property into multiple sub-properties when profiling.  Details and benefits are described in the comment above. If I recall you liked the spirit of this proposal, and main objection was that the current metaschema processor doesn't have a function to support specializing one core property into several sub-properties in a profile. Larry and I say lets just add this (seemingly straightforward) functionality, rather than try to define work arounds.
Our rationale:

we generally agree that this new functionality would it make qualifier specialization clean, clear, and easy for profile developers to define in the yaml (see yaml example above), then   if we can add it without too much effort - so lets just do it now rather than spending time defining and implementing a short term fix that is not ideal.
We noted that the utility of this functionality is not limited Statement qualifiers, as there are analogous use cases for wanting to specialize a single core-im property into many sub-properties (e.g. the need to multiply the core-im `StudyResult.dataItems' property into several data type specific properties in the caf profile here). This too becomes very concise, clear, and easy to define in the yaml with a 1:many specialization capability.
One of the challenges to selling our approach will be ensuring profile developers and users can understand and easily create yaml profile definitions - so anything we can do to make metaschema-based specification of these more straightforward is a win.

Of course this is all dependent on your approval willingness to devote developer time to making this enhancement. Larry estimated adding code to handle 1:m specialization would be ~a days work, but obviously you would know better here.

Sorry about the delay in a response here, I'm really bogged down in grant submissions and travel at the moment.
FWIW, the limitation here isn't technical; it would be easy enough to implement. The limitation is about breaking conventions. Extends has roughly meant "replaces the parent property with an extended version". It is not specific to VA-spec or the VA-spec core IM, it is a generic operation that works across products. This operation is different than "inherits from an abstract property", which is the behavior being described in this thread. I'm opposed to changing the definition and behavior of extends (or any keyword) to suit a specific use case, and not sufficiently motivated by the argument that it is easier for implementers to reuse extends in the same way as done for the subject and object properties of some core IM classes.
What I was going to propose was simply creating a Qualifier class and using the JSON Schema allOf keyword, that is used to address this specific type of situation, e.g.:
VariantPathogenicityStatement:
  maturity: draft
  type: object
  inherits: va.core:Statement
  properties:
    penetrance:
      description: >-
        The extent to which the variant impact is expressed by individuals …
      allOf:
       - $refCurie: va.core:Qualifier
       - type: string
          enum:
            - high
            - low
            - risk allele
    . . .

An alternative approach is to add functionality for another another keyword (@mbrush suggested multiples), and I think inherits (at the property level) would make sense here. But my preference would be to use the JSON Schema allOf approach first, since it would require no further development work and leverage standard patterns in JSON Schema.

@ahwagner - no worries, I know you are busy!  To be clear, we are not proposing to change the definition or behavior of the extends keyword - per the first part of your response.   'Extends' stays as is, and is used for 1:1 property extension/replacement.
Our proposal is what you reference briefly at the very end of your response - to create an new keyword that is used specifically when a profiler wants to do 1:m extension/replacement of a property. For example, specialize the Statement.qualifiers property into modeOfInheritance and geneContext.  Or specialize the StudyResult.dataItem property into focusAlleleCount and locusAlleleCount.  Glad to hear that this approach makes good sense to you, and would be technically simple to implement!
I get the rationale behind your proposal as well - but was hoping you could flesh it out a bit by illustrating what this 'Qualifier' class-based proposal looks like in both the core-im yaml as well as a derived profile?  I tried working this up myself but wasn't sure what you had in mind.

I also wanted to note one potential issue with your proposal concerning its creation of a new de novo property in the VarPath profile (penetrance) that does  'extend' an existing core-im property.  This violates our established Profiling rules - which require any 'new' property added to a profile to specialize/extend an existing core-im property (if it does not, it needs to be created using the Extension mechanism).   Of course, in your example you could declare penetrance to 'extend' the core-im Statement.qyualifier property - but there are other qualifier properties in this profile that would also need to extend qualifier - which as you say is not allowed.  This is of course where the 'multiplies' keyword would help.

Finally, I wanted to make sure it was clear that the qualifier example is not the only use case for wanting to perform 1:m property specialization/extension.  For example, I think it would also come into play to support specific data type properties created in StudyResult profiles (e.g. focusAlleleCount  and locusAlleleCount in the CAF profile).  So there is more general utility to adopting a 'multiplies' like functionality.

Our proposal is what you reference briefly at the very end of your response - to create an new keyword that is used specifically when a profiler wants to do 1:m extension/replacement of a property.

Hey @mbrush; just to clarify, this is not what I meant. Yes, a new keyword is possible (though again, I would prefer to use existing JSON Schema conventions); and no, this is not a proposal for a 1:m replacement of a property. To my knowledge, 1:m property replacement is not a pattern that is used in JSON Schema, pydantic, Active Model, or any other framework we use for modeling data in VICC resources. It might help me understand the importance of this pattern to see it applied in other data modeling languages. I am not aware of a 1:m property/slot replacement mechanism in LinkML, either; from what I understand (having spent very little time with this particular language), what I am proposing is most similar to the LinkML slot_URI property.

@mbrush I'd like to review the following statement with you...

I also wanted to note one potential issue with your proposal concerning its creation of a new de novo property in the VarPath profile (penetrance) that does 'extend' an existing core-im property. This violates our established Profiling rules - which require any 'new' property added to a profile to specialize/extend an existing core-im property (if it does not, it needs to be created using the Extension mechanism).

With @ahwagner's solution we would only be adding new attributes to the Standard Profiles not implementation specific profiles. I think we may be raising the bar much too high to say that no attributes beyond what are in the core-im classes can be added. I think by allowing the standard profiles to add the Qualifiers and DataItems needed for specific standard profile types we are finding the appropriate compromise and not contriving a special mechanism.
Frankly, if implementers choose to add attributes we cannot stop them anyway. But, with this compromise we can still relegate the standard qualifier attributes and dataitems for statements and studyresults as needed. If implementers go off course, that is the choice they have to make. We will clarify the risks for doing so, but it is not our job to be overly restrictive. We want to allow implementers to experiment and succeed and fail at their own behest.

@mbrush I'd like to propose we try @ahwagner's approach so we can see it in action. I will apply it to the CohortAlleleFrequency and VariantPathogenicity standard and implementer subprofiles. We can always improve upon it later. This way we can all clearly see the impact before we try to make the final-final decision.
I will proceed with this and continue watching for any comments from you.

More to say on this next week - but for now @ahwagner can you add to your the partial example above what the Qualifier class would look like in the core-im yaml - to help me appreciate how the profiled qualifiers in your example above relate to the core-im model?  The example above only shows what your proposal looks like in a Profile.
Also, I didn’t follow how what you are proposing is "most similar to the LinkML slot_URI property". If you think it is important that I do - can you explain in more detail? Thanks!

@mbrush again deferring to @ahwagner for the final word to your request immediately above..
My best guess is that the Qualifier class would resemble the DataItem class. You had pointed out the similar pattern between needing to treat DataItems off of StudyResults the same way Qualifiers should be treated off of Statements. Ideally we have a similar solution and design pattern.

@mbrush and @ahwagner ... I played around with various options for several hours/days to find a good jumping off point so that we can move forward.  Here's where I currently have landed (and all of this is in the newly refactored schemas as of Jul 2, 2024).

We should NOT be creating a qualifiers array property at the abstract Statement level since we do not want a qualifiers array in the profile subclasses.
Since we DO want explicit xxxQualifier properties on profiles, we should simply define these explicitly in the standard profiles themselves.  (Yes, Matt, I think it is necessary to be able to add new attributes off of core-im classes, especially those that are abstract. The standard concrete profiles is the place where everything comes together.)
I went back and forth creating a Qualifier class in the va.core namespace and decided it created unnecessary complexity with little to no benefit.  (I left a commented out version of this class in va.core's core-im-source.yaml at the top).
I landed on simplicity and simply named the qualifier properties on the various standard profiles using the convention xxxQualifier where xxx was the original name we proposed for each qualifier property.  I do not think we need to by typed or made into objects unless needed by the type of the data itself.  (result: simple data type qualifiers like integer qualifiers can be very straightforward).

I hope this is a good next step an allows us to move forward with more implementation work.
Please review, comment and close this out if possible.

accidentally closed this. sorry

To follow up on something Alex said earlier:

"To my knowledge, 1:m property replacement is not a pattern that is used in JSON Schema, pydantic, Active Model, or any other framework we use for modeling data in VICC resources. . . . I am not aware of a 1:m property/slot replacement mechanism in LinkML, either"

I don't think of what is happening with qualifiers in terms of a formal 1:m property "replacement" pattern. Conceptually, I just want to be able to indicate that we are defining multiple sub-properties of the core-im Statement.qualifier property in a Statement Profile - and using these sub-properties to collect different types of qualifying information.  It is this type of 1:m property specialization that I am saying is common practice in many modeling frameworks (e.g. you can find many examples of a property having >1 subproperty in LinkML models such as Biolink, and in OBO ontologies used to generate Linked Open Data).
If JSON schema language or tools don’t formally support the idea of 1:m property specialization, that is fine. This parent/child property link doesn’t need to be formally specified/implemented in the final json schema profiles that are generated by metaschema.
I just want to be able to indicate in the yaml-based specification of a profile  (and the derived documentation) that this property specialization relationship exists - so it is clear in the profiling process that modelers are not creating a truly 'new' property when they define qualifiers in a Standard Profile. Having a metaschema keyword to explicitly indicate this will ensure that modelers consider the "no new properties" rule, and that we can validate that this rule is followed (by checking that all properties in a profile have an extends or multiplies keyword).
IMO the proposed multiplies keyword lets us do this in the most direct and simple way.  I just want a flag in the yaml to say "property specialization is happening here, we are following the rules!". There need not be any processor functionality associated with it if 1:m specialization/replacement violates json schema conventions.

I don't think of what is happening with qualifiers in terms of a formal 1:m property "replacement" pattern. Conceptually, I just want to be able to indicate that we are defining multiple sub-properties of the core-im Statement.qualifier property in a Statement Profile - and using these sub-properties to collect different types of qualifying information. It is this type of 1:m property specialization that I am saying is common practice in many modeling frameworks (e.g. you can find many examples of a property having >1 subproperty in LinkML models such as Biolink, and in OBO ontologies used to generate Linked Open Data).

Would you kindly link some of these examples here, so I can gain some context on what patterns from these other frameworks you are looking to replicate? I was unable to find an example of a multiples or analogous pattern in LinkML when I looked, so could use your help to find that and anchor this discussion.

Hi Alex. Apologies if the text above wasn't clear about this - I am not saying that the linkML or OBO ontology frameworks come with code that supports a 'multiplies'-like function for transforming models when defining profiles (although linkML is interested in developing direct support for a profiling paradigm like the one we are implementing in VA, which will likely include such a function).
I am saying that the underlying notion of a property having >1 sub-property  ('1:m property specialization') is a pattern found in these and other modeling paradigms.  e.g. we see cases in the Biolink Model (the founding LinkML data model) where a slots (aka property) has > 1 sub-property specializations (see slot inheritance hierarchies for the slots here and here).
The ability to specify 1:m property specialization is IMO a foundational requirement for the VA/SEPIO profiling approach. I would like our framework and tooling to explicitly support this idea as a part of the profiling process - where a given property (e.g. 'qualifier' in the core-im) can have >1 specialized sub-properties defined in a profile that replace the abstract parent.   The most simple and direct way I envision doing this is a flag or keyword we can use in the yaml to indicate where this type of  property specialization happens (and to trigger code that simply removes the abstract parent property from profiles  (e.g. remove 'qualifier' in profiles where specializations of this property are defined). Analogous to what you have already implemented with 'extends', but for 1:m specialization instead of 1:1 extension.
Hopefully that helps, and the rest of my rationale for this above is clear.

Okay, I'm getting it. The LinkML specializations linked above are property-level inheritance, implemented with is_a; this is a different pattern than what is being proposed with multiples, but with these links I understand what you are looking to emulate. I think the most productive next step would be to draft up a schema that uses existing patterns in JSON Schema and Metaschema processor that meets the goals of the profiling approach.

@ahwagner what would help me to understand and assess your proposal for qualifier specification would be an end-to-end view of what the various modeling artifacts would look like (the core-im yaml, a derived VarPathStatement profile yaml, and final the json-schema generated by the processer).  This will let us fully appreciate/assess how it addresses criteria that are important to us (adherence to VA profiling rules, adherence to traditional modeling paradigms, clarity/ease of profile authoring for modelers, etc).
re:

I disagree that a syntax and translation function for 1:m specialization is a foundational requirement for VA-spec. What I want from VA-Spec is the evidence->evidence line->assertion model; if I can realize this without such a function, how is that a foundational requirement?

1:m property specialization is core to how the SPOQ model in the core-im is specialized into the SPOQ model for a profile like the VariantPathogenicityStatement profile - which has 3 qualifier properties.  Specialization of the core-im qualifier property into three subproperties (geneContextQualifier, modeOfInheritanceQualifier, and 'penetranceQualifier`)  happens in this profiling process.
I don't know that we definitively need a formal "syntax and translation function" - but IMO a foundational requirement of the support we provide for profile modelers is the ability to declare in their yaml that this kind of specialization is happening - to facilitate adherence to Profiling Rules that say any 'new' properties defined in a standard profile must be specializations/extensions of existing properties in the core-im.
If there are ways to achieve this using 'traditional' modeling paradigms', that also make it easy for modelers to understand and draft yaml-based profile documents, I would be happy to go this route.  Just need to understand how this would look in practice.

@mbrush if i may interject. I get that geneContextQualifier, modeOfInheritanceQualifier and penetranceQualifier are all subtypes of qualifier. I don't think that is so much of an issue (but I could be wrong). The real challenge is when a property is assigned to an abstract class only that property may be specialized.
When I look at some of the LinkML examples of property inheritance like association it has many concrete subtypes.  But it's only the subtypes that get applied to a given class. I don't see anywhere in the LinkML Association domain where the qualifier abstract property gets placed as a property within another class (abstract or not).
So, if this is what is needed we would need to find a different mechanism in our approach and tooling to building profiles which didn't create a scenarios that had us place an abstract property like qualifier in an abstract class like Statement.
I'm not sure if we should explore defining a way to define abstract property types (slots?) and stick with the approach that all (including LinkML) use to only apply the concrete property types to the appropriate class that will designate that that property will always be available in that class and all of it's descendants.
I don't think we can support property inheritance to a property that has already been assigned to a class. In those situations we can simply extend and constrain it further but not expand or change it fundamentally.  FHIR is a good example of this, although I don't think FHIR has the notion of property inheritance (but I haven't reviewed it lately).

@ahwagner what would help me to understand and assess your proposal for qualifier specification would be an end-to-end view of what the various modeling artifacts would look like (the core-im yaml, a derived VarPathStatement profile yaml, and final the json-schema generated by the processer). This will let us fully appreciate/assess how it addresses criteria that are important to us (adherence to VA profiling rules, adherence to traditional modeling paradigms, clarity/ease of profile authoring for modelers, etc).

Understood. I put together a draft PR (#171) to illustrate what I think captures what you are looking for while preserving typical inheritance patterns. It injects slot definitions and the is_a form in a format compatible with LinkML, which will make that transition easier if/when we pursue that.

Per discussions held on 8/6 and 8/7 with @mbrush and @larrybabb, we will not be incorporating LinkML features (e.g. slot inheritance) at this time, as this represents a substantial risk to target timelines for VA-Spec deliverables. We will incorporate SPOQ semantics as part of variable names as a compromise, in recognition of the SEPIO conceptual model. Continued work on the SEPIO conceptual design and domain-agnostic framework will be disentangled from VA Spec and maintained in a separate repository by the SEPIO developers.
Closing this issue for now. @mbrush or @larrybabb please reopen if this is still required for VA Spec 1.0.


add cbd functionality to cache parameter group

what

This PR gives you the option to generate the Elasticache Parameter Group using a create before destroy lifecycle

why

When you try to upgrade/change the engine version of the instance you're required to change the family of the parameter group to match the engine version. The terraform apply fails because the name of the parameter group is the same and is still in use.

+1 it makes my life harder when upgrading to redis 7

@goruha @kayla-haku any chance to push forward it? I can help with any further required changes.


Broken link in PyTorch serving doc

On this page:
https://www.kubeflow.org/docs/components/pytorchserving/
The Seldon link is broken:
https://github.com/SeldonIO/seldon-core/blob/master/docs/wrappers/python.md

/assign @isaacmg

/close


pipelines-control-service: release a new version

A new release, that includes Swagger UI path changes.
version.txt and CHANGELOG.md updated accordingly
Testing Done: need to sync if anything else worth including in
CHANGELOG, that will also get released

@ttsvetko @mivanov1988 do you recall anything else for CHANGELOG.md addition?

thanks for the review; do we need to add changes description to CHANGELOG.md?
Is there any New features/Improvements/Bux fixes after latest made modification:
1.3 - 20.12.2021
----
* **Improvement**
  * Add tracking and automatic release of locks on service shutdown<br>
    This will prevent delays in the K8s watching functionality on service restart/redeploy.


[normalize] Null Safety

I've published *-nullsafety.1 versions of most gql packages,  so it is now safe to migrate normalize to null safety: https://github.com/gql-dart/gql/pull/194
Should be fairly straightforward using dart migrate

@micimize awesome, thanks for doing that.
I'll try to work on this later this week.

Hello @smkhalsa
Did you have time to release a new version of normalize lib?

@b-jan  done


Codable support, array in completion,

1. Add Codable Support

extension User: Codable {     public enum CodingKeys: String, CodingKey {         case name     } }

2. Pass simple array in completion in replacement of ListResponse

func fetchNumbers(completion: @escaping (APIResult<[Number]>) -> Void)

@vaibhav-nickelfox @ravindrasoni

Adding open func requestForceJSONParseable to force parse object as JSONParseable.
Reason:
In functions like:
static func verify(otp: String, countryCode: String, number: String, completion: @escaping APICompletion<String>)
Here we try to parse a single string, and String confirms to both Codable and JSONParseable.
When we try to parse only one string, it by default try to parse it as Codable, and Codable is not able to parse a single string because it is not in JSON/Dictionary format.


[Question] Duplicate "Bearer" String on Auth Method Chaining

Insomnia Version: <IP_ADDRESS>5
Operating System: MacOS 10.13

Details
When Chaining Authentication Requests and using the Bearer Auth Method, Chained Request will contain "Bearer" string twice:
Chain Example:

First Request: will return Authorization in Response Header in format "Bearer "
Second Request: Uses Bearer Auth Method with Value of Previous Request's Authorization Header

The Second Request will have Bearer string twice since One will be added by Auth Method and the second one already exists in Authorization Response header.
I've tried setting Second Request's to {% filter replace("Bearer ", "") %}{% response 'header', 'req_81f8f8cb2aa147ef96ff3f88c593b322', 'Authorization' %}{% endfilter %} with no luck.
The only workaround I've found is that do not use built-in Auth Method(Set to No Authentication) and try setting the Header in Header Panel Manually.

Hmm, I tried that as well and it didn't work. However it did work with `{% filter replace('Bearer ', '') %}Bearer 12345{% endfilter %} so I'm not sure what the problem is (I'll look into it).
I'm not sure if this will work for you, but a common way to do this sort of thing is to nest environment variables. If you set an environment variable to "variable": "{% response 'header', 'req_81f8f8cb2aa147ef96ff3f88c593b322', 'Authorization' %}" you can use it with regular variable syntax like {{ my_variable | replace('Bearer ', '') }}

Tnx for the quick & helpful response, I'll try using env variables, tnx.

@gschier
It works well, Thank you very much

You're welcome 😄


[MINOR][PYTHON][DOCS] Fix broken link in legacy Apache Arrow in PySpark page

What changes were proposed in this pull request?
This PR proposes to fix the broken link in the legacy page. Currently it links to:

It should link to:

Why are the changes needed?
For users to easily navigate from legacy page to newer page.
Does this PR introduce any user-facing change?
Yes, it fixes a bug in documentation.
How was this patch tested?
Manually built the side and checked the link

Test build #144874 has started for PR 34475 at commit 60048da.

Test build #144874 has finished for PR 34475 at commit 60048da.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49344/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/144874/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49344/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/49344/

Merged to master and branch-3.2.


1st image replaced when running createReport() second time

Environments: Node v16.13.1, Windows 10, Mac 12.0.1, docker from node:13.12.0-alpine
I have found a bug where if you run the createReport() function on a file which you have already run createReport() on and inserted images, then the 1st image of the file will be replaced by the new image that is added.
looking at the docx as a zip it seems the issue is that the 1st name is reused on the second run so there are 2 relations to the same image name. but on the second run the 1st image is overwritten so they both point to the image inserted in the second run.
This is what i find in word/_rels/document.xml.rels at the end of the 2 runs of the function.
  <Relationship Id="img37" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="media/template_document.xml_image1.png" />
  <Relationship Id="img38" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="media/template_document.xml_image1.png" />

this issue doesn't occur after opening, making a small change and saving the file after the first pass.
however changing the line in main.js from
const imgName = `template_${documentComponent}_image${i + 1}${extension}`;

to
imgName = `template_${documentComponent}_image${(i + 1)}${new Date().getTime().toString()}${extension}`;

also resolves this issue.
Would it be possible to get a small bugfix to change this line of code so the image file names were more certainly unique each time

Good find. When implementing this I did not foresee this use case. Thanks for proposing a fix, looks simple enough. I'd like to cover your use case in the test suite too.

The library is used to create a document which would usually contain images. Then the document goes through a review process then a signature is inserted once accepted. the review process might introduce changes to the document before the signature is inserted in which case the error doesn't occur. but if the document isn't changed then the second run of the function should create the bug

Working on this... Adding the current datetime in the image string will introduce some non-determinism in createReport, making testing and reasoning about the document's contents more difficult. I'm now prototyping a different solution that is based on enumerating all existing image rels before injecting new ones.

Released in https://github.com/guigrpa/docx-templates/releases/tag/v4.9.1. Should be on NPM shortly.


Slightly updated installation instructions

Readme.md has been slightly updated to provide links for installing stack, which seems to be the easiest thing we can provide for someone who does not already have familiarity with the Haskell toolchain - seeing as it manages that automatically. Also, some typos corrected.

Also, whoever merges this - please squash or rebase to keep the number of commits down. 😸

Woo! You can also enable "Merge and Squash" on GitHub, to allow GitHub to
do this automatically 😀

Your biggest fan

On Wed, 21 Dec 2016 at 13:24 Oskar Abrahamsson<EMAIL_ADDRESS>wrote:
Also, whoever merges this - please squash or rebase to keep the number of
commits down. 😸
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/GRACeFUL-project/GenericLibrary/pull/8#issuecomment-268510531,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABlw1yLSj1stYmPM41at9ed2PsnXGooRks5rKRpqgaJpZM4LS5BB
.
--
Matthías Páll Gissurarson


Telco churn 1.1.0 fails to start with Failed building wheel for numpy

Actual behavior
Instance logs attached, error during pip install trying to build wheel for numpy
41319fdb-8436-47e4-802a-aa8c9cf93404.txt
Steps to reproduce:
Import bundle and start new instance
Affected Versions:
Telco Churn Risk 1.1.0
OS, browser, other environment details and versions:
Tested on MC-24.02.1 https://7342184.dedicated.h2o.ai/apps/996a3028-49ef-4a9e-bc35-3ebd86a896c6

cc @VijithaEkanayake


Test timeouts are causing the legacy daily build to fail on x64_debug

https://github.com/Microsoft/ChakraCore/wiki/Build-Status#legacy-builds
It seems specific to x64_debug.
While we investigate why they are timing out after 60s (despite running individually in under 10s), we will disable these tests in this configuration.

Sounds like this might be a bug in the way rl.exe does its timeout.  I believe I have a consistent repro on my laptop fortunately.

Turns out my consistent repro was a legitimate timeout.  On my laptop and actually my desktop, our internal unit test Debugger\promise_deferNestedAttach.js takes almost two minutes to run to completion for x64debug.  I'm not sure why it doesn't time out on the internal CI machines.  Perhaps they are faster CPUs.
@satheeshravi had a repro where a test that was timing out did allegedly run way under 60 perhaps.  I'll work with him to do more investigation.

In my case, they were Date\parseISO.js and typedarray\samethread.js. Both timed out under rl.exe.

@satheeshravi and I took a look and it turned out that the Date\parseISO.js test took longer than 60 seconds on his machine and so it legitimately timed out.  The typedarray\samethread.js test appeared to take around 25-30 seconds, so my suspicion is that it occasionally gets stalled off the CPU and trips over the 60 second threshold.
I'll look at the Jenkins failure to see if that test might also just be a longer runner that gets tripped up.
rl.exe uses wall clock time for the timeout which of course means that if the test process gets stalled it might timeout.  I'm not sure if we can do better since 1) rl.exe runs ch.exe via cmd.exe so rl.exe does not have direct access to the ch.exe process for querying cpu time and 2) in general a test might be a batch script that starts and waits for numerous processes.  Thus we'd have to query the cpu time of the tree of processes spawned by the test and Windows does not provide APIs afaik for easily getting this information or even the handles of the descendant processes.
I think the solution we need to go for here is to mark these particular tests as slow and increase their timeout threshold.
Our original criteria for moving tests to the slow group was if they run longer than 5 seconds on our dev machines, so these tests are clearly failing that and should be moved.

Added a list of tests I've seen affected by this issue so far (I haven't checked in about a week, but that's from my notes).

@ianwjhalliday Sounds good about moving them to slow tests. Still, we might try decreasing the number of CPUs used by rl.exe on those test machines first and see if that helps with any potential hypervisor-related CPU reclamation or stalling out.

Just observed another file timing out:
d:\j\workspace\Private\Microsoft_ChakraCore_daily_x64_debug\test\bailout\bailout-args.js

This build has been green for a few days. But since we didn't intentionally fix it I want to leave this issue open to track it until we figure out why the problem seems to be gone (or in case in comes back).
FYI @ianwjhalliday

Information on the first build where the issue went away:
http://dotnet-ci.cloudapp.net/job/Microsoft_ChakraCore/job/daily_dev12_x64_debug/44
http://dotnet-ci.cloudapp.net/job/Microsoft_ChakraCore/job/daily_dev12_x64_debug/44/changes#detail8

@dilijev do we think this issue has gone away now that it has been a few months?

@ianwjhalliday Yeah I haven't seen the issue in a while. We can reopen this bug if it comes back.


Unsolicited advice on alternate span dispatchers

I noticed a start towards non-scribe span dispatchers (reporters in zipkin lingo). The most important one to have for new people is http, as that is the easiest to setup the backend for.
When looking at messaging like kafka or rabbit, prefer sending TBinaryProtocol lists as the message body (as opposed to emulating scribe's base64 stuff). This will allow a future zipkin rabbitmq collector to consume the messages. Note: this encoding is also supported on kafka and http.
Hope this helps.
Thrift
The message's binary data includes a list header followed by N spans serialized in TBinaryProtocol
Codec.THRIFT.writeSpans(spans) encodes spans in the following fashion:
write_byte(12) // type of the list elements: 12 == struct
write_i32(count) // count of spans that will follow
for (int i = 0; i < count; i++) {
  writeTBinaryProtocol(spans(i))
}

https://github.com/openzipkin/zipkin/tree/master/zipkin-collector/kafka#thrift

Makes sense. I'll keep this in mind


nits

Stack from ghstack (oldest at bottom):

#1173
#1172
#1171
#1170
-> #1169
#1168
#1167
#1166
#1165
#1164
#1163
#1162

Codecov Report

Merging #1169 (26a06b3) into gh/anuragprat1k/21/base (090f503) will decrease coverage by 0.02%.
The diff coverage is n/a.

:exclamation: Current head 26a06b3 differs from pull request most recent head f672403. Consider uploading reports for the commit f672403 to get more accurate results

@@                     Coverage Diff                     @@
##           gh/anuragprat1k/21/base    #1169      +/-   ##
===========================================================
- Coverage                    34.00%   33.98%   -0.03%
===========================================================
  Files                          345      345
  Lines                        34174    34174
===========================================================
- Hits                         11622    11615       -7
- Misses                       22552    22559       +7

Impacted Files
Coverage Δ

lowlevel/minecraft/pyworld/physical_interfaces.py
88.18% <0.00%> (-2.37%)
:arrow_down:

lowlevel/minecraft/pyworld/fake_mobs.py
87.28% <0.00%> (-1.70%)
:arrow_down:

interpreter/craftassist/tasks.py
76.12% <0.00%> (-0.36%)
:arrow_down:


Blood Fury

I see its not being track, would it be a possible addition?

Yes, likely will add this when/if they give a 1 minimum hit as currently you can't differentiate between hitting a 0 which would use a charge and missing which also shows a 0 but doesn't use a charge and I'm not wanting to calculate maxhit and use probability as it's too much work. It will be much easier to add correctly in the future.

This can be added now with the successful accuracy rolls always showing a distinguishable 1+ damage hit now. That said it can be done either via xp drops (check for abscence of same tick range/mage xp on defensive, 200m xp use fake xp drops, cannon xp drop + defensive xp drop same tick consideration) or melee attack anims (huge list of possible animations), both of which aren't very simple to do.
If someone wants to tackle this feel free