[BUG] Duplicate records in effectivity satellites (Incremental)

Describe the bug
For records closed (end_date does not equal '9999-12-31'), when you run the dbt run -m ${model_name} in the second time, it will insert the same records into the eff_sat table.
Versions
dbt: 0.20.0
dbtvault: <IP_ADDRESS>
To Reproduce
Steps to reproduce the behavior:

Set a staging table with a record which end_date is not '9999-12-31'
Set a effectivity satellite table which source_model is the staging table set in step 1
Run dbt run -m ${model_name} twice
See duplicated records in the effectivity satellite table

Expected behavior
In the second dbt run, it shouldn't insert the same closed record again
Screenshots

Log files
If applicable, provide dbt log files which include the problem.
Additional context
I think this should be a bug in dbtvault.eff_sat, https://github.com/Datavault-UK/dbtvault/blob/master/macros/tables/eff_sat.sql#L56
latest_closed AS (
    SELECT {{ dbtvault.alias_all(source_cols, 'd') }}
    FROM latest_records AS d
    WHERE TO_DATE(d.{{ src_end_date }}) != TO_DATE('9999-12-31')
),

{# Identifying the completely new link relationships to be opened in eff sat -#}
new_open_records AS (
    SELECT DISTINCT
        {{ dbtvault.alias_all(source_cols, 'f') }}
    FROM source_data AS f
    LEFT JOIN latest_records AS lr
    ON f.{{ src_pk }} = lr.{{ src_pk }}
    WHERE lr.{{ src_pk }} IS NULL
),

{# Identifying the currently closed link relationships to be reopened in eff sat -#}
new_reopened_records AS (
    SELECT DISTINCT
        lc.{{ src_pk }},
        {{ dbtvault.alias_all(fk_cols, 'lc') }},
        lc.{{ src_start_date }} AS {{ src_start_date }},
        g.{{ src_end_date }} AS {{ src_end_date }},
        g.{{ src_eff }} AS {{ src_eff }},
        g.{{ src_ldts }},
        g.{{ src_source }}
    FROM source_data AS g
    INNER JOIN latest_closed AS lc
    ON g.{{ src_pk }} = lc.{{ src_pk }}
),

For a record which status is closed (end_date doesn't equal '9999-12-31') in eff_sat, it should appear in latest_records. While if the status of the record doesn't change in the staging table, then in new_reopened_records, it will not be filtered out and will be inserted again.
Seems like adding a where clause to filter out end_date = TO_DATE('9999-12-31') in new_reopened_records can solve the problem.

Thanks for the report. Can you tell me what materialisation you are using please?

Hi, the materialisation is view.

Thanks for the report. Can you tell me what materialisation you are using please?

Hi, the materialization is view.

Thanks for the report. Can you tell me what materialisation you are using please?

Hi, the materialisation is view.

Thanks. Raw vault structures should never be materialised as views. This will break their behaviour because they require data to be stored over time. Please try it using incremental instead and let us know if you see the same behaviour.

Thanks for the report. Can you tell me what materialisation you are using please?

Hi, the materialisation is view.

Thanks. Raw vault structures should never be materialised as views. This will break their behaviour because they require data to be stored over time. Please try it using incremental instead and let us know if you see the same behaviour.

Sorry, I checked the value by mistake. It seems like we're using incremental.

Ok that makes sense. I think this is similar to #50, in that the advised (though not well documented advice) materialisation is vault_insert_by_period and using incremental can cause some unpredictable behaviour. We need to document this better and also put some checks/safety nets in place to prevent things breaking quite so easily.

Ok that makes sense. I think this is similar to #50, in that the advised (though not well documented advice) materialisation is vault_insert_by_period and using incremental can cause some unpredictable behaviour. We need to document this better and also put some checks/safety nets in place to prevent things breaking quite so easily.

I think they're two different scenarios. In #50, the two records have different loaddate while in my case, one same record (every column is the same) will be inserted multiple times when the record is closed (end_date doesn't equal '9999-12-31') in both the staging model and the eff_sat model. I don't think using vault_insert_by_period will work.

Ok that makes sense. I think this is similar to #50, in that the advised (though not well documented advice) materialisation is vault_insert_by_period and using incremental can cause some unpredictable behaviour. We need to document this better and also put some checks/safety nets in place to prevent things breaking quite so easily.

I think the issue here is the closed record has been inserted into eff_sat twice after dbt run.
As when we
new_reopened_records AS (
    SELECT xxx FROM source_data AS g
        INNER JOIN latest_closed AS lc
)

the records from source_data are not all open, which means there would possibly be some records in new_reopened_records are actually closed, then these closed records would be inserted into eff_sat again.

Understood. we'll double check and do some experimentation internally, as have tests for this that are passing.

Effectivity Satellites have only ever been tested with vault_insert_by_period which is the recommended materialisation to use for all raw vault structures which contain a history (everything but Hubs and Links). Can you move to this materialisation and let us know if the problem is fixed?
The reason we advise the use of vault_insert_by_period instead of incremental is because vault_insert_by_period includes additional logic to ensure only the most recent (new, previously unloaded) records are being loaded into the raw vault. This is as per Data Vault 2.0 guidance; we don't want to be loading the entire history every load, but only the difference/delta since the last load. The reason duplicates come in when using incremental is because we aren't reducing the size of the stage when loading into the raw vault, dbtvault will still attempt to load the full history each time.

Some further internal discussion:
Generally we do want to avoid suggesting vault_insert_by_period, however we have found many users are trying to load the entire stage history with each load. The easiest workaround is to use vault_insert_by_period, hence the suggestion.
We have mentioned in many places in the documentation that all loads should only ever be loading new records, not the whole history. In theory if the stage data is only ever new records, the incremental materialiation should work as expected, but we have a gap in our testing for this because we decided to go down the route of recommending vault_insert_by_period for tables containing history.
Moving forward we have decided to make incremental the base case, with the strict caveat that the stage tables need to contain the delta feeds as per Data Vault 2.0 recommendation and standards. This will be quite a big overhaul of some of the macros and structures in dbtvault, so it's not something we can do overnight. For now, please use vault_insert_by_period.

Okay, we'll try vault_insert_by_period to see if that works.
Thank you.

We will ensure that the methods for loading the Raw Vault are documented more clearly. This is not a bug as such, but a mismatch between the intended implementation of Data Vault 2.0 and dbtvault.
In short: A single load/batch (i.e. dataset present in the stage layer) should contain only a delta set of data; the changes since the last load. This means each batch should only have unique PKs. We can have 10 different PKs, but we cannot have any of those 10 PKs again in the same load.
Closing in favour of #93. Thank you.


input_pills: Simplify and make uniform pill-container display.

This PR corrects regressions in pill spacing introduced in #30495 while also improving and unifying the display of pills in pill containers across the UI. Those improvements include better-centered pills in the subscribers table, as @alya requested.
CZO discussion (design)
CZO discussion (spacing regression)
Screenshots and screen captures:
Channel Subscribers

Before
After
After, 16/140

Invited Users

Before
After
After, 16/140

Mentor Pills (Pills in Profile Modal)

Before
After
After, 16/140

Invite Users Modal

Before
After
After, 16/140

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Looks great, merged, thanks @karlstolley!


Length of octet strings encoding

We currently use 8 bytes for the header/ph length (where length = # of bytes), allowing it to be up to 2^64 – 1 meaning that the header can be up to ~10^19 bytes long i.e., roughly 10000 Petabytes. This seems excessive.
Cases where even more than 32 or 64 bytes are needed can just use pre-hashing. IMO, 1 or 2 bytes (or even 3, which would allow for a header of up to 1 Mb) would be enough to encode the length of the header/ph for most applications.
8 bytes are also used for the total number of messages. I doubt anyone will need to sign 10^19 messages, however, it maybe be nice to have a practically unlimited "capacity".
Proposal

Use 8 bytes for the total number of messages/indexes is fine.
Use 2 bytes for the length of octet strings (i.e., header/ph).

I think the performance benefit here is debatable and creating an inconsistency between the number of bytes pre-appended is a higher cost.

Discussed on Wg call on the 6th of February. Since there will be no performance advantage will close to not introduce breaking changes.


Deploy of new Amplify app removed data of unrelated app

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

App Id
d1jny8zesq8m5c
AWS Region
eu-west-1
Amplify Hosting feature
Backend builds
Describe the bug
We deployed a new app in AWS Amplify.
In this deploy the backend of an unrelated app (d1nyxy0mujwrun) is overwritten and all resources in this app are deleted (DynamoDB backend tables for GraphQL API)
Expected behavior
Deploys of new apps should not modify unrelated apps
Reproduction steps

Create new app
Deploy

Build Settings
No response
Log output

# Put your logs below this line

Additional information
No response

Hi @daannijkamp 👋🏽 we are sorry to hear that backend resources were accidentally deleted. Can you provide more details around the application you deployed? Was that application using the backend environment in that separate application?  We are working to reproduce this behavior and further investigate.

We were unable to reproduce this behavior. Please open a new issue if you continue to run into this issue or if you can provide more details on how you ran into this behavior. Closing due to no response.


Project / context selection using keys in autocomplete when creating a new task

Is it an actual bug?
it is a different behavior than the previous version (Sleek 1.1.6) which reduces its ease of use.
Did you check if the bug has already been reported?
Yes.
Describe the bug
With the latest versions of Sleek, a bug related to the self-completion of projects (+) and contexts (@) has been introduced.
In detail, during the creation of a new task, by typing the + or @ symbol all the projects and contexts are proposed correctly, but their selection is now only possible using the mouse and no longer with the tab and enter keys as before.
Sometimes trying to use the tab and enter keys the selected element is actually inserted but preceded by null.
The Sleek 1.1.6 version is the latest with the correct behavior.
To Reproduce
Steps to reproduce the behavior:

Start create new task (Ctrl + N)
Write "Sometimes" and add + at the end
Press Tab key to move on the element proposed and press enter to insert
See error

Expected behavior
The tab key must move the cursor over the elements and the enter key inserts the selected item in the task.
Desktop (please complete the following information):

OS: Windows 10 Pro
Version of sleek: 1.1.8-rc.1
Source: Github

@mimmori thanks for pointing it out. I needed to rework the button a bit and missed to add the href attribute, which in fact disables the Enter function. This is going to be fixed in the next release.

@mimmori could you please check if this still happens in https://github.com/ransome1/sleek/releases/tag/v1.1.8-rc.2?
Thanks!

Problem solved with the latest version released.
As always, very fast.
Thanks!!!

I still found a condition where it is not working properly.
The problem can be observed during the self-completion phase of projects / contexts and you start writing part of the word until only the desired element remains.
In that case, pressing tab and enter the element is inserted preceded by the text null.

I can confirm this, I missed that case during testing. Thanks for checking it so precisely ❤

@mimmori this should be fixed in https://github.com/ransome1/sleek/releases/tag/v1.1.8-rc.3

confirmed. Thanks


latency in set_image function

Hi,
Thanks for the great sources. I can see the amazing performances.
When I implemented the code and tried to run the model, I could see that it takes long time at the 'set_image()' function.
I am just wondering if it is because of transformation functions is ImageEncoderViT method.
If so, is it supposed to take relatively long time?
for me, the elapsed time for each task was,
DINO model loading: 0.829
ViT encoder process: 17.912
SAM model prediction: 0.192

Thanks again,

What type of GPU are you using?

Thanks for the excellent project, I have the same problem, the set_image function takes about 17s.
os: Ubuntu 20.04
gpu: Tesla t4 16G
model type: vit_h

thanks again

Thanks for the excellent project.
I have a question about the gpu memory of set_image  function.
When i load the model to the gpu device sam.to(device=device), i find it occupies 3403MiB of the GPU using vit_h model.
But when i execute set_image, the gpu memory increased to 7573MiB.
Not sure why picture vectors take up so much gpu memory?
Thanks for any help.

Same question for me.
my device is
ubuntu22 RTX3090
my code is
s4 = time.time() input_label = np.array([1] * len(input_point), dtype=np.float32) predictor.set_image(img) print("set image time:", 1000*(time.time() - s4)) s5 = time.time() masks, scores, logits = predictor.predict(     point_coords=input_point,     point_labels=input_label,     multimask_output=True, ) print("segment time:", 1000*(time.time() - s5))
the command output is
set image time: 93.09029579162598 segment time: 15.57469367980957

@nikhilaravi,
I am using Nvidia 3080Ti

@nikhilaravi, I am using Nvidia 3080Ti

How did you achieve the VIT encoder process of 17.912 ms on the 3080ti? Inference on my 3090 takes 93.09 ms😭 my CPU is i7-9700KF

@KAWAKO-in-GAYHUB
Hi did you run with the GPU? It seems like your code is running with CPU rather than GPU.
check with the nvidia-smi during the running.

predictor.set_image(image) is the step generates image embedding

To use the ONNX model, the image must first be pre-processed using the SAM image encoder

- this is the main thread of model because it's a big backbone.
After that, we could predict much more faster with our input points, box, mask

@hungtooc
Thanks for your comment,
For me, other processes including pre-processing and transofrmation does not take that much long, and most of the time is taken at the line of,
self.features = self.model.image_encoder(input_image)

I also would like to look over onnx conversion part.
Thanks!

@KAWAKO-in-GAYHUB Hi did you run with the GPU? It seems like your code is running with CPU rather than GPU. check with the nvidia-smi during the running.

Thank you for your reply!
I'm sure my code is running on the GPU, and I wrote a demo on jupyter notebook to verify it.

I averaged 117.42 ms after running predictor.set_image(image) and predictor.predict(...) 1000 times.
In addition, I also run predictor.set_image(image) 1000 times to get the average value, which is 106.37 ms.

I don't know what's wrong in my code.

@KAWAKO-in-GAYHUB
That may be correct.
My time up there is sec, not ms.
Sorry I didn't metion above.

@hungtooc Thanks for your comment, For me, other processes including pre-processing and transofrmation does not take that much long, and most of the time is taken at the line of,
self.features = self.model.image_encoder(input_image)

that's normal. you can see it mentioned in paper

A heavyweight image encoder outputs an image embedding

@hungtooc
Got it. I missed that sentence!
I will read more details. Thanks for answering :)

@KAWAKO-in-GAYHUB That may be correct. My time up there is sec, not ms. Sorry I didn't metion above.

There shouldn't be such a big gap between the 3080ti and 3090 running code (17s and 90ms). I don't know what your code looks like.

@hungtooc Thanks for your comment, For me, other processes including pre-processing and transofrmation does not take that much long, and most of the time is taken at the line of,
self.features = self.model.image_encoder(input_image)

that's normal. you can see it mentioned in paper

A heavyweight image encoder outputs an image embedding

So my understanding is that its application scenario is more suitable for multiple inferencesof a picture, rather than real-time inference of video frames. Right?

@KAWAKO-in-GAYHUB I not sure, maybe he could help you https://github.com/facebookresearch/segment-anything/issues/107#issuecomment-1500909850

@KAWAKO-in-GAYHUB I not sure, maybe he could help you #107 (comment)

awesome, thank you!

hi, we have proposed a method for rapid 'segment anything', using just 2% of the SA-1B dataset. It achieves precision comparable to SAM in edge detection (AP, .794 vs .793) and proposal generation tasks (mask AR@1000, 49.7 vs 51.8. E32). Additionally, our model is 50 times faster than SAM-H E32. The model is very simple, primarily adopting the yolov8seg structure. We welcome everyone to try it out, github: https://github.com/CASIA-IVA-Lab/FastSAM, arxiv: https://arxiv.org/pdf/2306.12156.pdf


The code in server rendering recipe doesn't guarantee the same initial state is used to render on server and client

In https://github.com/reduxjs/redux/blob/master/docs/recipes/ServerRendering.md, server and client code are as follow:
server.js
// Compile an initial state
let preloadedState = { counter }

// Create a new Redux store instance
const store = createStore(counterApp, preloadedState)

// Render the component to a string
const html = renderToString(
<Provider store={store}>
  <App />
</Provider>
)

// Grab the initial state from our Redux store
const finalState = store.getState()

// Send the rendered page back to the client
res.send(renderFullPage(html, finalState))

client.js
// Grab the state from a global variable injected into the server-generated HTML
const preloadedState = window.__PRELOADED_STATE__

// Allow the passed state to be garbage-collected
delete window.__PRELOADED_STATE__

// Create Redux store with initial state
const store = createStore(counterApp, preloadedState)

hydrate(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
)

Note that client DOM is rendered with a different redux state than the one used to render server DOM. In few cases, this leads to DOM mismatch when hydrating in client side (I found this issue when fixing DOM mismatch caused by redux-form).
I believe the right place to get preloaded state is before createStore, so that code path between getting 'preloaded state' and hitting renderToString/hydrate keeps the same on client and server.
Few updates on those example code are made on my branch https://github.com/reduxjs/redux/compare/master...yelite:patch-1
I am wondering if there is anything wrong with my approach, because the original code snippet is in official doc for years. There might have some reason that I didn't realize.

I think you're misinterpreting what the initalState argument does. It loads up the store with an initial value for state. It does not get updated with the state of the store over time. It is discarded. Your proposed changes would lead to a __PRELOADED_STATE__ value of just the same initial {}.

@timdorr

It does not get updated with the state of the store over time.
That's the point. It doesn't get updated. __PRELOADED_STATE__ should be the same state that drives the server side rendering, in order to make hydrate work without DOM mismatch.


liferay-portal page configuration is broken after upgrading to master having previously deployed a 7.2 layout template

Step to reproduce

Create a 7.2 layout template via 9.4.3 Liferay theme generator.
Deploy to <IP_ADDRESS>-SP1 + FP3.
Start server.
Create a new widget page based on new layout template.
Shutdown server.
Upgrade DB to master.
Start master.
Go to Page administration > Click configure of the new page

Expected Results:
The configuration page should display normally.
Actual Results:
The page broken. The console will throw the following error:
2019-12-13 02:13:50.772 ERROR [http-nio-8080-exec-1][JDBCExceptionReporter:234] Table 'fp3.LayoutSEOSite' doesn't exist
2019-12-13 02:13:50.777 ERROR [http-nio-8080-exec-1][DynamicIncludeUtil:81] com.liferay.portal.kernel.exception.SystemException: com.liferay.portal.kernel.dao.orm.ORMException: org.hibernate.exception.SQLGrammarException: could not execute query
com.liferay.portal.kernel.exception.SystemException: com.liferay.portal.kernel.dao.orm.ORMException: org.hibernate.exception.SQLGrammarException: could not execute query
	at com.liferay.portal.kernel.service.persistence.impl.BasePersistenceImpl.processException(BasePersistenceImpl.java:446)

Reproduce on:
Tomcat 9.0.17 + MySQL 5.7. Portal master GIT ID: 7ce7ab20a3835fe3634c284e434a175a6dc0c95a.

We've just migrated this project to the liferay-frontend-projects monorepo in the name of consolidation. As this issue is quite old now, I'm not going to transfer it automatically. If you consider it to be still relevant, please create a fresh issue over in the new repo.


Middleware

Don't need middleware? Adds some code bloat, and it's not hard to do with the new system with ResponseWriter holding Response. (Or, the only further improvement when be running a closure inside ResponseWriter after send is called. this would be a pain to code).
So, just going to leave an example (using cors) and calling it a day.
Takes an Endpoint and returns an Endpoint. Inspired by Golang middleware.
Doesn't wrap response completely, because the user has control over the final call for sending. But is still middleware in the sense that you can automatically change request, state, and response, outside of each handler.
In some ways, this is the best middleware; even after you use middleware to make modifications, the user-provided endpoint still has the last say.

a4e119f3a9d14b2f8e66bbefb7e0db862f516055 has example with "middleware", which is just sticking a fn before the router, which can modify req and resp_wtr.


Problem: Yolov4-tiny custom object detection with one class

Hi, I'm having some troubles for the last 2 days.
I've just trained yolov4-tiny using my own images in Darknet and then converted it following this issue.
Everything works perfectly fine with .cfg and .weights trained on COCO dataset but after converting my own files, this is the final result:

Before conversion, it looks like this:

Does anyone have an idea what's wrong?
(Jetson Nano with JetPack 4.4)

I figured out that number of filters were set up to 12, instead of 18...
Sorry for the unnecessary issue and thank you for contributing this project.


Pagination does not support screen readers

Except for the "next page" and "previous page" buttons, the pagination control cannot be used by vision impaired users. There is no way to change the page size or to skip to a page without using a mouse.

Seems to work well with Chrome Vox, but not with JAWS.


feat: Support state in ionoscloud_server to set the power state

Current Provider Version

terraform {
  required_version = ">= 1.4.0"
  required_providers {
    ionoscloud = {
      source  = "ionos-cloud/ionoscloud"
      version = "6.4.1"
    }
    random = {
      source  = "hashicorp/random"
      version = "3.5.1"
    }
  }
}

Use-cases

It would be awesome to support the ionos_server_state  prob to stop severs via terraform. The ansibe-modules support a state prob to set for each server. As far as I know there are the following states in the DCD:

running
shutdown
reset
This could also be used to reboot a server without having to connect to the server.

Attempted Solutions

Currently this is not supported in this provider. You have to extract the server id form the state (or output the ids to a file) and make a extra api request in an arbitrary language
Proposal

Support the state prob in the ionoscloud_server
References

Thanks for raising this. We'll take a look at it.

Support for modifying the power state for servers through the vm_state field should be available in the next release.

Nice to hear

Fixed in https://github.com/ionos-cloud/terraform-provider-ionoscloud/releases/tag/v6.4.10

also need this feature. foremost the reboot (reset) state.
Is the reset state also supported in the new provider version ?

Reboot is not supported yet. It is harder to implement in terraform due to how the concept of state works. This is because reboot is a transient state so we can't really measure if a reboot was done or not.
I would suggest using ionosctl maybe to reboot a server: ionosctl server reboot --datacenter-id DATACENTER_ID --server-id SERVER_ID


Is there any other version of the program?

Thank you very much for sharing, I learned a lot!
Do you have the tensorflow version or the pytorch version of the program and the model?

Sorry, not yet.
We are planning to implement it using tensorflow or pytorch.

Thanks for your reply and looking forward to your tensorflow or pytorch version!


[stable/airflow] Added option to mount dag volume as read-only in web deployment

What this PR does / why we need it:
By default, webserver can write to dag volumes (and edit dags). We want to avoid this behaviour by mounting the dags volume as read-only. Compilation of dag.py to dag.pyc will be done by scheduler.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]
[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

@michieldhadamus
Would you mind to resolve the conflict file please? stable/airflow/Chart.yaml

@zanhsieh, resolved merge conflict

/ok-to-test

Messed up commit signing, will make a new PR later


Unable to import sr25519 in the node metadata example

Hi, with the minimal setup that you have defined in the tutorial:
use substrate_api_client::{node_metadata, Api};

fn main() {
    // instantiate an Api that connects to the given address
    let url = "<IP_ADDRESS>:9944";
    // if no signer is set in the whole program, we need to give to Api a specific type instead of an associated type
    // as during compilation the type needs to be defined.
    let api = Api::<sr25519::Pair>::new(format!("ws://{}", url));

    let meta = api.get_metadata();
    println!(
        "Metadata:\n {}",
        node_metadata::pretty_format(&meta).unwrap()
    );
}

and
[package]
name = "api-client-tutorial"
version = "0.1.0"
authors = ["Supercomputing Systems AG<EMAIL_ADDRESS>edition = "2018"

[dependencies]
substrate-api-client = { git = "https://github.com/scs/substrate-api-client.git" }

I am getting many errors:
➜  api-client-tutorial git:(master) ✗ cargo run
   Compiling api-client-tutorial v0.1.0 (/Users/aviralsrivastava/dev/api-client-tutorial)
error[E0433]: failed to resolve: use of undeclared type or module `sr25519`
 --> src/main.rs:8:21
  |
8 |     let api = Api::<sr25519::Pair>::new(format!("ws://{}", url));
  |                     ^^^^^^^ use of undeclared type or module `sr25519`

error[E0425]: cannot find function `pretty_format` in module `node_metadata`
  --> src/main.rs:13:24
   |
13 |         node_metadata::pretty_format(&meta).unwrap()
   |                        ^^^^^^^^^^^^^ not found in `node_metadata`

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0425, E0433.
For more information about an error, try `rustc --explain E0425`.
error: could not compile `api-client-tutorial`.

To learn more, run the command again with --verbose.

It looks like our tutorial is outdated. Please look at this example

@brenzi
I am sorry but this hasn't been helpful. You should have provided the corresponding dependencies' source as well.

For instance, I literally copied the Cargo.toml file and still, I am getting following error from the link that you referenced:
➜  api-client-tutorial git:(master) ✗ cargo run
   Compiling substrate-api-client v2.0.0 (/Users/aviralsrivastava/dev/api-client-tutorial)
error[E0433]: failed to resolve: use of undeclared type or module `substrate_api_client`
 --> src/main.rs:9:5
  |
9 | use substrate_api_client::node_metadata::Metadata;
  |     ^^^^^^^^^^^^^^^^^^^^ use of undeclared type or module `substrate_api_client`

error[E0432]: unresolved import `clap`
 --> src/main.rs:6:5
  |
6 | use clap::App;
  |     ^^^^ use of undeclared type or module `clap`

error[E0432]: unresolved import `substrate_api_client`
  --> src/main.rs:10:5
   |
10 | use substrate_api_client::Api;
   |     ^^^^^^^^^^^^^^^^^^^^ use of undeclared type or module `substrate_api_client`

error[E0433]: failed to resolve: use of undeclared type or module `Metadata`
  --> src/main.rs:20:16
   |
20 |     let meta = Metadata::try_from(api.get_metadata()).unwrap();
   |                ^^^^^^^^ use of undeclared type or module `Metadata`

error[E0433]: failed to resolve: use of undeclared type or module `Metadata`
  --> src/main.rs:28:9
   |
28 |         Metadata::pretty_format(&api.get_metadata()).unwrap_or("pretty format failed".to_string())
   |         ^^^^^^^^ use of undeclared type or module `Metadata`

warning: unused import: `std::convert::TryFrom`
 --> src/main.rs:4:5
  |
4 | use std::convert::TryFrom;
  |     ^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

error: aborting due to 5 previous errors

Some errors have detailed explanations: E0432, E0433.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `substrate-api-client`.

To learn more, run the command again with --verbose.

can you point me to your code repo so I can have a look?

Hey, thanks for reverting.
I am using the master code only. https://github.com/kebab-mai-haddi/substrate-api-client

Sorry I cannot reproduce. When I check out your repo (which is up-to-date with our master), I can do:

cd tutorials/api-client-tutorial
cargo run

and it works.
or I can go to the root directory and do:

cargo build --example example_print_metada

and it works too, what steps do you perform for it to fail?

I was at the root directory: /Users/aviralsrivastava/dev/substrate-api-client. I ran the command: cargo run --example example_get_storage. And got the following error:
     Running `target/debug/examples/example_get_storage`
Interacting with node on <IP_ADDRESS>:9944

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("Error decoding field RuntimeMetadataPrefixed.1")', /Users/aviralsrivastava/dev/substrate-api-client/src/lib.rs:143:9
stack backtrace:
   0:        0x103e0860f - backtrace::backtrace::libunwind::trace::h46cd1629179eb2bb
                               at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
   1:        0x103e0860f - backtrace::backtrace::trace_unsynchronized::he6a2c6978474c69f
                               at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66
   2:        0x103e0860f - std::sys_common::backtrace::_print_fmt::h7e4f94659b124684
                               at src/libstd/sys_common/backtrace.rs:78
   3:        0x103e0860f - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h87f791d1934b5da0
                               at src/libstd/sys_common/backtrace.rs:59
   4:        0x103e279ce - core::fmt::write::h23c8f27116676cdf
                               at src/libcore/fmt/mod.rs:1063
   5:        0x103e02367 - std::io::Write::write_fmt::h1f00d7a43839acf0
                               at src/libstd/io/mod.rs:1426
   6:        0x103e0a64a - std::sys_common::backtrace::_print::hdb601a5265ba7f34
                               at src/libstd/sys_common/backtrace.rs:62
   7:        0x103e0a64a - std::sys_common::backtrace::print::h5b8116376026eccf
                               at src/libstd/sys_common/backtrace.rs:49
   8:        0x103e0a64a - std::panicking::default_hook::{{closure}}::hf26168ecfd2fc8c1
                               at src/libstd/panicking.rs:204
   9:        0x103e0a38c - std::panicking::default_hook::hf7eb684688e3f257
                               at src/libstd/panicking.rs:224
  10:        0x103e0ad28 - std::panicking::rust_panic_with_hook::hba1377a258e49bd5
                               at src/libstd/panicking.rs:470
  11:        0x103e0a8c2 - rust_begin_unwind
                               at src/libstd/panicking.rs:378
  12:        0x103e2607f - core::panicking::panic_fmt::h0d0a3efb6be37d9e
                               at src/libcore/panicking.rs:111
  13:        0x103e25ec5 - core::option::expect_none_failed::h60a7fb6522066a05
                               at src/libcore/option.rs:1211
  14:        0x10379cd8f - core::result::Result<T,E>::unwrap::hdd8502f143ffb0a4
                               at /rustc/c20d7eecbc0928b57da8fe30b2ef8528e2bdd5be/src/libcore/result.rs:1003
  15:        0x1037b4b41 - substrate_api_client::Api<P>::_get_metadata::ha78d45a48b715fcc
                               at /Users/aviralsrivastava/dev/substrate-api-client/src/lib.rs:143
  16:        0x1037b52df - substrate_api_client::Api<P>::new::h191709ce62e4fbff
                               at /Users/aviralsrivastava/dev/substrate-api-client/src/lib.rs:102
  17:        0x1037b6ad4 - example_get_storage::main::hbbbe92adf2e40cca
                               at src/examples/example_get_storage.rs:28
  18:        0x1037b407e - std::rt::lang_start::{{closure}}::hb893d0bed7d75aad
                               at /rustc/c20d7eecbc0928b57da8fe30b2ef8528e2bdd5be/src/libstd/rt.rs:67
  19:        0x103e0a788 - std::rt::lang_start_internal::{{closure}}::h97c2f4abbac12fe2
                               at src/libstd/rt.rs:52
  20:        0x103e0a788 - std::panicking::try::do_call::hd39a46c6642b6b7f
                               at src/libstd/panicking.rs:303
  21:        0x103e0d6bb - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:86
  22:        0x103e0b12a - std::panicking::try::hd7941e20369365bb
                               at src/libstd/panicking.rs:281
  23:        0x103e0b12a - std::panic::catch_unwind::hb0089eff0d0a17f8
                               at src/libstd/panic.rs:394
  24:        0x103e0b12a - std::rt::lang_start_internal::h74a2f48667b795db
                               at src/libstd/rt.rs:51
  25:        0x1037b4061 - std::rt::lang_start::h9de3795ff5e19923
                               at /rustc/c20d7eecbc0928b57da8fe30b2ef8528e2bdd5be/src/libstd/rt.rs:67
  26:        0x1037b7622 - example_get_storage::get_node_url_from_cli::h28ef078e74cb1bea

@brenzi
And I ran the exact commands that you posted, again got the same error:
thread 'main' panicked at 'called Result::unwrap()on anErr value: Error("Error decoding field RuntimeMetadataPrefixed.1")', /Users/aviralsrivastava/dev/substrate-api-client/src/lib.rs:143:9 stack backtrace:
Btw, I am running the substrate node from the official documentation.

this is most likely due to an incompatible node.
Check that the node you are using has the same substrate revision as the substrate-api-client's

How can I do that?

got to your local substrate repo and do:
git checkout 00a400f82539e2f78e8ddbcd98aea512c87c5f3c
this is already the correct commit

In fact, when running the test node from this repo(as suggested in this repo), it shows error.
Steps:
git clone https://github.com/scs/substrate-test-nodes
cd substrate-test-nodes/
git checkout api-M1.1
cargo build --release

Error:
error[E0432]: unresolved import `hashbrown`
  --> /Users/aviralsrivastava/.cargo/registry/src/github.com-1ecc6299db9ec823/wasmi-validation-0.1.0/src/lib.rs:31:5
   |
31 | use hashbrown::HashSet;
   |     ^^^^^^^^^ use of undeclared type or module `hashbrown`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `wasmi-validation`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

warning: build failed, waiting for other jobs to finish...
error: build failed

ups, thanks for pointing this out. The readme is old ckeckout master.

Also, going into the local substrate repo:
git clone github.com/substrate-developer-hub/substrate-package
cd substrate-package
git checkout 00a400f82539e2f78e8ddbcd98aea512c87c5f3c

I got the error:
fatal: reference is not a tree: 00a400f82539e2f78e8ddbcd98aea512c87c5f3c

ups, thanks for pointing this out. The readme is old ckeckout master.

Welcome, but I didn't get this: "The readme is old ckeckout master."

Ah sorry. I did not know that you were using that repository. The substrate version they are using is too old. you would need to use https://github.com/paritytech/substrate
and regarding our test-node you need to do:
git clone https://github.com/scs/substrate-test-nodes
cd substrate-test-nodes/
cargo build --release
do not do: git checkout api-M1.1
if you already did, do: git checkout master
and then build it.
I won't be answering further questions today, I am going home. :)

@brenzi @clangenb
It worked.
Thanks guys!


Fixed incorrect comparison operator

GraphQL won't parse the request body payload for GraphQL JSON.  Additionally, it won't fetch the schema as is typically handled through common GraphQL clients.

Hey Jacob,
Actually, the current code is correct.
I think you are mixing up "getParsedBody" and "getBody". PSR-7 provides both, and there is this strange state where a request can have a "body", and no "parsed body" (because no middleware cared enough to json_decode the body). So this code is useful if no middleware added a "parsedBody" to the request (in which case we add one).
I'm closing this issue. I guess you opened this PR because you faced some kind of real problem. Don't hesitate to open a new issue if you are still facing a problem.

Hey David, makes sense.  I guess the issue here is that parsedBody is an empty array and not null in my case.  I'm pulling this value directly from the Zend\Diactoros\ServerRequest.
$serverRequestFactory = [ServerRequestFactory::class, 'fromGlobals'];
debug(($serverRequestFactory)()); //debug() is just a little function for dumping for inspection


is there a cheaper way to run GPTCelltype?

I am currently running this across a number of projects because it can save a lot of time but the API costs are becoming prohibitive. I spent 100$ in 1 day running GPTCelltype to label the results from a loop of seurat clustering... oops. Any suggestions for running this cheaper?

The cheaper alternative obviously is to use a cheaper gpt model... seems obvious.
res <- gptcelltype(marker_genes, model = 'gpt-4o-mini', topgenenumber = 10, tissuename = 'human lung cancer')
1 million cells across 134 subclusters cost 'gpt-4o-mini' only 0.07$ whereas gpt-4.0 cost 15.00$.


Two config files are published

When I run
php artisan vendor:publish --tag=iconamic-config
… the iconamic.php config file is published both in config/statamic/iconamic.php and in config/iconamic.php.

Thanks for that - you can safely remove the config/iconamic.php file - that one is not used.
I'll get a fix for this released.

An update has been released to correct this for new installs.

Sorry, it seems this creates another error:

Statamic \ Exceptions \ FieldtypeNotFoundException
Fieldtype [iconamic] not found

Rollback to v1.0.0 and manually remove the rouge config file - will get a new release up in the next day or two after tweaking the component init.

v1.0.2 has been released.
This permanently moves the config file to config/iconamic.php.
I'd suggest removing config/iconamic.php if it still exists, and then do the update - the update script will try to move the file for you. If it can't, you'll need to manually check everything is correct.
I've also done a clean install with this version and all works, so fingers crossed you're smooth sailing.

Excellent! It managed to move the file for me. All OK!

Woohoo good stuff :D


Translucent fragments

Keep old screen below the new one to be presented if the new screen's screenColor is translucent (to use like modals, for instance).
Supersedes https://github.com/airbnb/native-navigation/pull/60

c/c @gpeal @lelandrichardson

Actually, this PR won't work due to the addition of ScreenCoordinatorLayout. By controlling the drawing order there, when we keep the old view (don't .detach() it), the reverseDrawing check would be true and so the new view would be drawn below the old one.

The logic on ScreenCoordinatorLayout to reverse the order of the drawing only works if it has exactly two children. If we do not detach the fragment, we'll end up with several children, and reversing the child draw order will not have the desired effect.

@gusbicalho Yeah, reversing the last two views is probably correct for ScreenCoordinatorLayout. It has only been tested with the normal push/present case but could be modified to be more flexible.

@gpeal Our last commit seems to solve the issue we were discussing.

Thanks for your patience! By the way, do we have a schedule of when to tag releases/push to npm?


Added detection for bun/node inside typescript SDK runtime

As discussed by #6591
Changes
Tries to detect bun/node runtime through the following rules. If a detected runtime is not node or bun an error is raised.
If a package.json is present and the dagger.runtime field is set, the configured runtime is used
If a package-lock.json file is detected node is used a the runtime
if a bun.lockb file is detect bun is used as the runtime
if no runtime can be detected node is used by default

Hey! @benjaminstrasser
I'm glad you opened a PR, I'll have a look at it today 🚀

@TomChv
I just rebased and pushed all the requested changes except the one regarding the bun caching location.
I did not find a quick way to change it or debug the behavior to be certain it works the way we intended. I reran the test with the example I gave, which gives me some confidence everything is working. Maybe you have some good ideas how to best resolve this.

Created a v0.10.1 milestone, and added it to that, so we should be able to take this for then!
@benjaminstrasser I removed "Draft" from the PR title - hopefully that's ok, and this is ready to merge.
Could you also add a release note fragment following the instructions here? https://github.com/dagger/dagger/blob/main/CONTRIBUTING.md#3-add-release-notes-fragment. We haven't previously been changelogging zenith modules changes, but after v0.10.0 we will start doing so, so would be helpful to have a line in the changelog to show this off! :tada: Cheers for all your work on this! :rocket:

I tested my eslint module with all operations cached (for a fair comparison between node and bun)
# Node
time dagger call --files=src run stdout
dagger call --files=src run stdout  0.94s user 0.48s system 8% cpu 15.903 total

# Bun
➜  eslint git:(main) ✗ time dagger call --files=src run stdout
dagger call --files=src run stdout  0.63s user 0.32s system 17% cpu 5.454 total

Bun is really faster than node during the setup -> almost x3 faster after caching
I wonder how fast it could be if we use it on our repository, we could probably improve our Ts CI speeds and still be on node but with a bun runtime in it.
That's really interesting!
/cc @gerhard
I think I can test that next week by replacing the default runtime we use in the template by bun and see if it actually increase the CI speed.
Since calling init in each of our testcase and the TS one is probably one of the slower, I'm pretty sure we'll gain 1 or 2 minutes with this super small change.

:wave:  awesome contribution @benjaminstrasser! thx for sharing.
I have one more fundamental question re this PR. IIUC the DetectRuntime function will be called each time that someone tries to run a typescript function. It seems to me that running this code here: https://github.com/dagger/dagger/pull/6730/files#diff-a8b5f7f08501c3951b9991d2450b8b0a68ac764af369185bbf7044d9654ac58cR220-R236 will add a bit of overhead to each detection cycle since it quires running a Dagger container for such purpose. After skimming the __runtime_detection logic (https://github.com/dagger/dagger/pull/6730/files#diff-a8a40d72e98e14628f2eb0abf1304d14cbb3dce905058aeb72736f07c47c0944) seems to me like all that code could be written in Go directly since I couldn't spot any node/bun runtime specific handling and being performed within the TypescriptSDK runtime module instead of pulling an additional image and running a container.
Thoughts?

@helderco
Thank you for the detailed review!
I will look at it in detail tomorrow. I will give some detailed input, but at  first glance everything looks like it should be implemented/adopted.
Regarding speed I already mentioned it on discord, but did not follow up out of time constraints. Right now Runtimegets called two times and Codegen four times(2 implicit calls via Runtime and 2 explicit calls) for every dagger call.
I like the idea of just running dagger call inside a valid project and not needing any npm i prior but I am unsure about the baked in codegen.
For me and I would love some input:
Runtime: Simply provides a valid Runtime, all dependencies installed, entry-point setup and ready to call functions inside my source.
Codegen: Initialize or modify my setup in such a way that I can use dagger call.
Right now dagger call kind of does both, without writing the results from codegen to disk. If i run dagger init and delete the index.ts file and then run dagger call container-echo --string-arg yo stdout everything works since the default index.ts gets implicitly generated. This does feel counter intuitive to me. I would love some input on this. Maybe I am missing something here.

Right now dagger call kind of does both, without writing the results from codegen to disk. If i run dagger init and delete the index.ts file and then run dagger call container-echo --string-arg yo stdout everything works since the default index.ts gets implicitly generated. This does feel counter intuitive to me. I would love some input on this. Maybe I am missing something here.

If you rename index.ts to foo.ts, the file should not be replaced.

For me and I would love some input:
Runtime: Simply provides a valid Runtime, all dependencies installed, entry-point setup and ready to call functions inside my source.
Codegen: Initialize or modify my setup in such a way that I can use dagger call.

Runtime actually runs codegen because you might have external dependencies that have changed, specially when you work with multiples local multiples.
By running the codegen, we ensure your module is always ready to be executed.
It's quite hard to do one without the other, because creating new functions in your module actually updates the codegen, meaning that we must reexecute it every time.

Regarding speed I already mentioned it on discord, but did not follow up out of time constraints. Right now Runtimegets called two times and Codegen four times(2 implicit calls via Runtime and 2 explicit calls) for every dagger call.

That's true but thanks cache, it shouldn't take long because the codegen is actually reexecuted only 1 time, after that all operations are cached.

Regarding speed I already mentioned it on discord, but did not follow up out of time constraints. Right now Runtimegets called two times and Codegen four times(2 implicit calls via Runtime and 2 explicit calls) for every dagger call.
I like the idea of just running dagger call inside a valid project and not needing any npm i prior but I am unsure about the baked in codegen.
For me and I would love some input: Runtime: Simply provides a valid Runtime, all dependencies installed, entry-point setup and ready to call functions inside my source. Codegen: Initialize or modify my setup in such a way that I can use dagger call.
Right now dagger call kind of does both, without writing the results from codegen to disk. If i run dagger init and delete the index.ts file and then run dagger call container-echo --string-arg yo stdout everything works since the default index.ts gets implicitly generated. This does feel counter intuitive to me. I would love some input on this. Maybe I am missing something here.

If you're curious about some historical context, the initial purpose for the codegen function in the runtime module was just to re-generate a new client (dag) from the extended API, say by adding dependencies with dagger use. At this point you were required to run dagger develop if you made any changes and this was quite cumbersome and led to many errors because people forgot to do it or were confused by it.
The solution was to always run codegen on every call. This makes dagger develop optional actually, and is simply needed for local development, to allow the IDE or the linter to follow the code paths.
At some point later, Go moved the module's code reflection from runtime into codegen time, so codegen in Go is tied to the source coude. It generates the client from the API, but also the code to handle registration, inputs and output of function calls.
But for Python and TypeScript, the latter is still being done at runtime dynamically, through the "entrypoint". So you can set up the API codegen part in the runtime module's "codegen" in a way that its cache is not invalidated by changes in the module's source. As long as there's no changes in introspectionJson, you'll get a cached SDK after the first time.
Finally, we also ended up using the codegen step to also create initial files for the module. The initial package.json and index.ts files. In this case, I do agree that this should only happen once during dagger init --sdk or dagger develop --sdk. I'd prefer having a separate Init function that would only be called initially, which would extend the "codegen".
I'm actually experimenting on a few changes to the Python runtime module and I found myself thinking the same thing as you. I'm going to explore checking modSource, even with .Entries() if necessary, to try to detect this initial situation and only add the template files then rather than every time. Maybe that's enough instead of a separate Init function.
It makes more sense to me to return a clear error that code is missing, rather than removing your index.ts and everything running ok with the default one from the init template implicitly.

@helderco
I just implemented all proposed changes except one were I left a comment. I would love for you to look at them and give some input if needed.
Also added a missing test case.

If you're curious about some historical context, the initial purpose for the codegen function in the runtime module was just to re-generate a new client (dag) from the extended API, say by adding dependencies with dagger use. At this point you were required to run dagger develop if you made any changes and this was quite cumbersome and led to many errors because people forgot to do it or were confused by it.
The solution was to always run codegen on every call. This makes dagger develop optional actually, and is simply needed for local development, to allow the IDE or the linter to follow the code paths.
At some point later, Go moved the module's code reflection from runtime into codegen time, so codegen in Go is tied to the source coude. It generates the client from the API, but also the code to handle registration, inputs and output of function calls.
But for Python and TypeScript, the latter is still being done at runtime dynamically, through the "entrypoint". So you can set up the API codegen part in the runtime module's "codegen" in a way that its cache is not invalidated by changes in the module's source. As long as there's no changes in introspectionJson, you'll get a cached SDK after the first time.
Finally, we also ended up using the codegen step to also create initial files for the module. The initial package.json and index.ts files. In this case, I do agree that this should only happen once during dagger init --sdk or dagger develop --sdk. I'd prefer having a separate Init function that would only be called initially, which would extend the "codegen".

Thanks for the detailed description :heart: . This gave me a lot of the necessary context to understand the status quo.  I still do not understand why codegen and runtime get called twice.

I'm actually experimenting on a few changes to the Python runtime module and I found myself thinking the same thing as you. I'm going to explore checking modSource, even with .Entries() if necessary, to try to detect this initial situation and only add the template files then rather than every time. Maybe that's enough instead of a separate Init function.
It makes more sense to me to return a clear error that code is missing, rather than removing your index.ts and everything running ok with the default one from the init template implicitly.

Yeah I totally agree. I would love to do the same or help with the typescript runtime. I feel we can optimize performance and make the runtime more intuitive.

Failing test:
535
=== RUN   TestModuleTypescriptRuntimeDetection/should_detect_bun.lockb
536
    module_typescript_test.go:576:
537
        	Error Trace:	/app/core/integration/module_typescript_test.go:576
538
        	Error:      	Not equal:
539
        	            	expected: map[string]interface {}{"runtimeDetection":map[string]interface {}{"echoRuntime":"bun"}}
540
        	            	actual  : map[string]interface {}{"runtimeDetection":map[string]interface {}{"echoRuntime":"node"}}
541
        	            	Diff:
542
        	            	--- Expected
543
        	            	+++ Actual
544
        	            	@@ -2,3 +2,3 @@
545
        	            	  (string) (len=16) "runtimeDetection": (map[string]interface {}) (len=1) {
546
        	            	-  (string) (len=11) "echoRuntime": (string) (len=3) "bun"
547
        	            	+  (string) (len=11) "echoRuntime": (string) (len=4) "node"
548
        	            	  }
549
        	Test:       	TestModuleTypescriptRuntimeDetection/should_detect_bun.lockb
550
--- FAIL: TestModuleTypescriptRuntimeDetection/should_detect_bun.lockb (24.39s)

@benjaminstrasser, still need to fix the test.

@benjaminstrasser, still need to fix the test.

The test you specified should be fixed now. I had some issues where the test runs were cached, even though the cache was cleared. Still some failing tests. I'll try to have a look tomorrow and ping you when everything is done.

@benjaminstrasser, still need to fix the test.

@helderco The test you specified should be fixed now. I had some issues where the test runs were cached, even though the cache was cleared. Still some failing tests. I'll try to have a look tomorrow and ping you when everything is done.

I retriggered the test, I'm waiting for it to be green to merge the PR!


fix: Worflows permissions to run integration tests

Describe the behavior changes introduced in this PR
Allow forks to run integration tests (use repository secrets).
Linked Issues
resolves #838
Testing Instructions
Check integration tests CI job logs.

/hold
trying to understand why CI job was not triggered

I do not know why, but pull_request_target did not work.
workflow_run did not work as well, but as I read, once it is on the default branch (master in our case), it will work (and saw an example of usage). But the way I did, it takes more time to run it (upload and download zip file).
I would let the way it is (only running on push) if we can not find a way that does not downgrade the CI performance.
References:

https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
https://github.com/tiangolo/fastapi/blob/master/.github/workflows/preview-docs.yml

/unhold


Add mushroom

https://github.com/piitaya/lovelace-mushroom

Tbh, most of these cards seem to be in HA by default. So skipping this one.


Fetch with Fable 2: wrong ContentType header?

Hi,
I have been struggling to send some json data through a POST request using Fetch from a fable 2 project.
      let withProps body=
          [
              requestHeaders [ContentType "application/json"]
              RequestProperties.Mode RequestMode.Nocors
              RequestProperties.Body !!body
          ]

      let! result =
        let props = body |> withProps
        tryPostRecord url body props

or
    let withProps body=
        [
            RequestProperties.Method HttpMethod.POST
            requestHeaders
              [
                HttpRequestHeaders.ContentType "application/json"
              ]
            RequestProperties.Mode RequestMode.Nocors
            RequestProperties.Body !!body
        ]

    body
      |> withProps
      |> fetch url
      |> Promise.bind (fun res ->
        res.text())
      |> Promise.map (Decode.fromString decoder)

However, it seems that whatever the ContentType used, it will revert to text/plain;charset=UTF-8.
I never had this problem with any of my Fable 1 projects.
So maybe I'm missing something?
Thanks!

hmm
or maybe maybe... my body is considered as text and the browser is bypassing my ContentType header?

Is sendRecord set in the correct type ?

ok found (from stackoverflow).

Mode is set to no-cors.
Setting the Content-Type to application/json requires permission from CORS

Will try and tell you :)

Ok I confirm. I setup CORS on the server and everyhting is working.
Thanks!


uploading files

URL
https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-tutorial/create
Operating system
windows
More information about your system
arm64
Description
cant get my uploaded files
dotnet --info
i cant set up the files

I'm sorry it took us so long to get back to you. Are you still having this issue? Can you give us more details? There are no uploaded files on the tutorial.


Distance Expense - Inconsistency in preview between the main chat and the expense report

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.61-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4480566
Issue reported by:  Applause - Internal Team
Action Performed:
1.On an account that is an employee of a workspace (not the admin)
2.Click on FAB
3.Select "Request Money"
4.Click on the "Distance" tab
5.Click on "Start"
6.Enter as destination your current location by selecting the "Use current location" option
7.Set other 2 waypoints to places near your location to generate a "real" trip
8.Navigate to the expense details
9.Click on the generated receipt
Expected Result:
The WS chat displays an expense thumbnail with a map, when clicking it, the report preview includes a view of the map and trip
Actual Result:
The thumbnail shows no map in the main chat, the report preview generates the map and trip with a delay. The map in the preview in the main chat generates after a while
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/f833a230-1b6e-41d5-a4dd-3f540882e53f
View all open jobs on GitHub

@abekkala  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

We think that this bug might be related to #wave-collect - Release 1

handled in https://github.com/Expensify/App/pull/39243

closing as a fix for this is already being released


Probe fees not read on payment retries

Description
If we do a fee probe and send an amount that's over a wallet's balance, the API correctly returns an error message with the amount attempted including the probed fee. If the amount was over the balance and an error returned, if we retry the request with a different amount in the feeprobe and then the send method, the api no longer reads the probed fee from the payment flow repo and instead applies the max fee.
See these traces: Link

Bug: doesn't find probe when repeating the probe.
Optimisation - omit probe if we already probed for higher amount.

Optimisation - omit probe if we already probed for higher amount.

Optimisation was captured in a separate card

On re-testing with latest code deployed on staging and in dev this is no longer an issue


There are problems to writ a . or , in prices while bulk edit

When you want to change prices in bulk edit, it seems not to be possible to enter decimal number.
When you enter . or , it will be removed after a half second.
When you write other numbers fast, the signs will not be removed.

[public] Shopware automated response: This issue is linked to the internal issue: NEXT-37429
[created from NEXT-37429, comment 514394]


Support GCP Global Addresses

Hi.
Is there any limitation to why it is forcing the region to assign IP Addresses in GCP?
Because sometimes it is needed to use Global Addresses instead of Regional ones. kubeip is fetching the region from the metadata server:
"Found 0 Addresses to remove project my-project in region europe-southwest1.  Addresses []"

Sorry, VM instances can't have global IP addresses.


Release Branches Frozen For Merging | branch:maistra-2.1 branch:releases/2.2.5 branch:releases/2.3.1

While this issue remains open, tide will not merge any PR's targeting the branches mentioned in the PR title.

@yxun @jwendell
Excuse me!
Where to report issue or ask questions for this project?
Seems in the jira we can't find the Project "OpenShift Service Mesh" when trying to create issue login as a normal Redhead user.


Update documentation errors

[x] I have signed the Contributor License Agreement.
[x] This pull request is related to an issue.

Resolves #4619
Resolves #4635

Took the branch from Skanda's fork, rebased it and dropped all commits not related to documentation, then squashed all the commits related to documentation

Microsoft Reviewers: Open in CodeFlow

Thanks for making this easy!


Bug report: label says error for my package

For my package: https://cover.run/go?tag=golang-1.10&repo=github.com%2Frocketlaunchr%2Fdataframe-go
The label shows it as error but the description provided says no error.
Gocover shows no such error:
https://gocover.io/github.com/rocketlaunchr/dataframe-go

Yes

For me as well:
https://cover.run/go?repo=github.com%2Fsgreben%2Fpiecewiselinear&tag=golang-1.10

Details
ok github.com/sgreben/piecewiselinear 0.002s coverage: 94.4% of statements

It was actually working a week ago. Then magically stopped working.

The same question

Hey peoples fixed by @cloudson (very thanks man)

Perfect, thanks @cloudson & @avelino :)


Basic strategy

Implemented hit, stand, double, soft; will do split later
Added params and headers for sitdown function

waiting for split implementation


[SPARK-19366][SQL] add getNumPartitions to Dataset

What changes were proposed in this pull request?
As suggested by @cloud-fan here, adding a simple wrapper in Scala can help avoid inefficiency with non-JVM cases
How was this patch tested?
unit tests

Actually - why do we need this? I worry it can be a confusing API due to optimizer behavior.

Test build #72011 has started for PR 16708 at commit 68cb3e2.

Test build #72011 has finished for PR 16708 at commit 68cb3e2.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

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

Merged build finished. Test FAILed.

Test build #72016 has started for PR 16708 at commit 048759b.

Merged build finished. Test FAILed.

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

@rxin this was as suggested by @cloud-fan in more details in this thread here
The original concerns were around the overhead with the extra conversion needed in Python and R (to PythonRDD, RRDD) and that it would be much lighter weight to have a method in Scala for this.
Now that we have a simple workaround in R (by just calling the Scala method without conversion), I'm not feeling strongly about this so I'm ok to close this.
I do agree with the optimizer behavior but this has been a very frequently requested method and its uses as x.rdd.getNumPartitions is all over PySpark code and documentation.
Perhaps it is worthwhile to explain this is a number to expect but can be optimized out.

Basically I want to push back against exposing this as a public API ...

@rxin you think this will be confusing as the results might change over time ?

Yes.

Isnt the dataset immutable ? i.e. the optimizer is called once when the RDD is materialized and the RDD doesn't change after that ?

@shivaram yea, once the Dataset is materialized, the partition number won't change. I think rxin's concern is, when people trying to get the partition number, the result is unpredictable as too many factors can affect it.


Rbenv directory search order with brew

The bug is that as-written, rbenv (if installed by brew) always uses the brew prefix directory and the RBENV_ROOT. But the default desired behavior of rbenv is to use the $HOME/.rbenv to store installed rubies. As a result, you get the system ruby only.
My change builds upon the #3275 pull request from @mbologna and reverses the order of the search directories for rbenv to put the brew prefix last.
Since this bug only occurs for brew users, non-OSX users will not be affected.

Hi, and thanks for contributing.
You will have to git rebase -i @~2 in order to get rid of the empty merge commit.
Then please find a few people to test and +1 this.

+1
I haven't tested this but I have encountered the same problem on OSX and brew installed rbenv. Traced the issue with the brew directory rather than $HOME directories for rubies.

Is the bug still present? @mmorga @mcornella

I have no idea... @gchan ?

Yes. I just enabled the rbenv plugin and this still happens.
$ zsh --version
zsh 5.0.5 (x86_64-apple-darwin14.0)

Probably this is why I opened #3275

Yes @mbologna, the code changes in #3275 are very similar to this PR.
Unsure about the reason for line 12 (https://github.com/robbyrussell/oh-my-zsh/pull/3808/files#diff-22fdd1fcfb5b98380f344442393e1f6fL12) however.

@gchan @mcornella @mmorga please check with #4384 if it solves your problem

@mbologna I don't think that would fix for me, since I have no bin directory in ~/.rbenv/.
I'm getting a bit lost between these PRs...
my edit would just be like the one in your https://github.com/robbyrussell/oh-my-zsh/pull/3275, specifically this line.

@caesarsol #4384 does not infer anything from ~/.rbenv/bin. Please check the diff.

I'm sorry, isn't the diff only deleting lines 7~10?
I still see $rbenvdir/bin in the file...

Nope. See https://github.com/mbologna/oh-my-zsh/commit/f3e357d71253a8255f1a1ccece9426f37da47d00#diff-22fdd1fcfb5b98380f344442393e1f6fL7-10

I'd reopen https://github.com/robbyrussell/oh-my-zsh/pull/3275/files, that's the issue I'm having.
This PR doesn't solve the problem.

@mbologna sorry for the misunderstanding, what I'm saying is:
this PR doesn't solve the issue for me.
I didn't realize you were splitting two different issues.

@caesarsol this PR is closed, see above.

Thank for the fix!
Although in my case I had to make both changes (one by @caesarsol and the other one by @mbologna) to make it work. Whenever I revert to implementing only one of the changes, it all breaks down again.


init codeql plugin

Taking into account that there are two stages and commands accordingly I don't know at the moment how we will support this issue for CodeQL - where a user will be able to redefine a command.

Taking into account that there are two stages and commands accordingly I don't know at the moment how we will support this issue for CodeQL - where a user will be able to redefine a command.
I think in the case of two or more commands in any plugin the user will have to execute commands manually.

@shikari-ac
Yeah, hard to tackle this issue straight away. There is no solution for now. Probably it's better to leave it as is, and return when this feature request will appear.


Use monotonically increasing time

There are a lot of calls to Time.now which is known to be affected by changes to system time (e.g. NTP updates). It is better to use Process.clock_gettime(Process::CLOCK_MONOTONIC). For more information see: https://blog.dnsimple.com/2018/03/elapsed-time-with-ruby-the-right-way/

Hi, @sdemjanenko - thank you for your suggestion! We have brought this up with our Product Manager, who will determine whether it will be added to our roadmap, and if so, what its priority will be.

Additional benefits for this change - Process.clock_gettime(Process::CLOCK_MONOTONIC) returns a float which can be used directly by most of the duration-calculating code. This means the agent can stop constructing Time.now all over the place. In my case that's ~1000 new Time objects on each request just from the tracing which uses Time.now.to_f to calculate duration.

@viraptor thanks for the additional use-case where switching can be highly beneficial.  We definitely want to do this, but felt it was best to deprecate support for Ruby 2.0 (which is happening with our upcoming 7.0 release) before tackling this issue.

With Ruby 2.0 and 2.1 deprecated for 7.0.0 release, this issue should be prioritized for inclusion an upcoming release.
Using either Process.clock_realtime (good enough and fastest) or more pedantically correct Process.clock_monotonic would improve all our duration calculations by as much as 2.7 times over Time.now
Allocations -------------------------------------
            Time.now       1/1  alloc/ret        0/0  strings/ret
Process.clock_realtime
                           0/0  alloc/ret        0/0  strings/ret
Process.clock_monotonic
                           0/0  alloc/ret        0/0  strings/ret
Warming up --------------------------------------
            Time.now    28.525k i/100ms
Process.clock_realtime
                        41.243k i/100ms
Process.clock_monotonic
                        41.683k i/100ms
Calculating -------------------------------------
            Time.now    512.386k (± 3.8%) i/s -      2.567M
Process.clock_realtime
                          1.413M (± 4.3%) i/s -      7.053M
Process.clock_monotonic
                          1.340M (± 4.1%) i/s -      6.711M

Comparison:
Process.clock_realtime:  1412578.4 i/s
Process.clock_monotonic:  1340018.5 i/s - same-ish: difference falls within error
            Time.now:   512385.8 i/s - 2.76x slower

Benchmark code for above results:

While pairing with @amhuntsman on this today, we determined Process.clock_gettime(Process::CLOCK_MONOTONIC) is our preferred value to replace Time.now when used as a float. Its purpose as defined by POSIX seems more appropriate than CLOCK_REALTIME for calculating the durations commonly recorded by the agent.


Refactors, new features, etc.

Added new border types, refactored that code a bit, a few extra methods and options, and moved some of the text converting/stripping into functions, so I can use them in the CLI app I'm working on.
I'm confused by Scrollbox, btw.  It uses this._clines in many places, but _clines is only set in parseContent, which is only run on screens (because detached is only true for screens (?)).  I'll look into it more, but maybe you can smoke screen that for sanity.
Thanks for blessed, it's friggin' awesome.

Just closing up old PRs.  Still love blessed.  I've wondered what


Java dev container template has an ineffective cleanup step

I don't think this cleanup step in the Dockerfile for the java-11 dev container (probably the other versions too) is doing what it is intended to do:
https://github.com/microsoft/vscode-dev-containers/blob/dfda2f5e04c41c7902216b149d4abce1f6f54e23/containers/java-11/.devcontainer/Dockerfile#L53-L56
Removing files and/or packages in a separate RUN instruction will simply render them invisible in the final flattened container FS, but they will still be part of the image layer stack i.e. they will take up disk space. If the intent is simply to make them invisible this is of course perfectly fine, but if the intention is to make the image smaller, I believe this is not an effective strategy.
This is mitigated a bit by the fact that for a while now already, basically all Debian-derivative Docker images have had APT hooks in place that remove any downloaded package files after each run, therefore apt-get clean in this context doesn't really do anything. Package lists would still need to be removed if one wants to save the space that they take up.

//cc: @testforstephen @akaroml - Some feedback on the dev container for Java.

@Chuxel Looks like this is not a Java specific issue, i see other dev container such as go is using the similar logic. It's better to have someone to fix this systematically.
https://github.com/microsoft/vscode-dev-containers/blob/dfda2f5e04c41c7902216b149d4abce1f6f54e23/containers/go/.devcontainer/Dockerfile#L65-L68

@testforstephen The issue here is that it's in a different RUN which is not the case in other places.  Each RUN is a separate layer, so if the previous layer doesn't have the cleanup step in it, the contents are effectively in the image.  The Go definition you reference does not have this problem.


how to store in room database

i want to store option in room database and also edit the qr code  from  history

This is out of scope for this library. You can make a custom serializer for it using kotlinx.serialization or organize the options into different serializable structure


Add SASL-SCRAM ability to Kafka connection

This PR adds the ability to connect to Kafka via SASL-SCRAM 256 or 512
It adds an entry in the SASL Profile configuration called
key=mechanism
value type=string
required=no
default value=(empty)
Which accepts either values SCRAM-SHA-256, SCRAM-SHA-512
Partially addresses #526

This patch worked for my setup, SCRAM + SASL + TLS, thank you @rjh-yext

Thanks for your work on this PR @rjh-yext. Are you planning to make it ready to be merged into master or can somebody help you with that?

I could provide a path to fix the linting and merge conflicts, but I'm not sure how to go about that

Thanks for contributing! Shipped with https://github.com/linkedin/Burrow/pull/627.


[CT-2225] [Bug] Suddenly getting ModuleNotFoundError: No module named 'pytz'

Is this a new bug in dbt-core?

[X] I believe this is a new bug in dbt-core
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
I am installing dbt-bigquery with meltano (which installs it in a isolated venv).
Today when invoking dbt deps using meltano invoke dbt-bigquery:deps I am getting a stacktrace with
ModuleNotFoundError: No module named 'pytz'

Expected Behavior
pytz should be found. I have noted that it is not included in the requirements. So while it's strange that it suddenly started failing, maybe it was more of an accident that it ever worked in the first place?
Steps To Reproduce
With versions specified as
dbt-core~=1.3.0
dbt-bigquery~=1.3.0

invoking dbt deps should not throw a ModuleNotFoundError
Relevant log output
Traceback (most recent call last):
  File "/workspaces/elt/.meltano/transformers/dbt-bigquery/venv/bin/dbt", line 5, in <module>
    from dbt.main import main
  File "/workspaces/elt/.meltano/transformers/dbt-bigquery/venv/lib/python3.9/site-packages/dbt/main.py", line 24, in <module>
    import dbt.task.build as build_task
  File "/workspaces/elt/.meltano/transformers/dbt-bigquery/venv/lib/python3.9/site-packages/dbt/task/build.py", line 1, in <module>
    from .run import RunTask, ModelRunner as run_model_runner
  File "/workspaces/elt/.meltano/transformers/dbt-bigquery/venv/lib/python3.9/site-packages/dbt/task/run.py", line 8, in <module>
    from .compile import CompileRunner, CompileTask
  File "/workspaces/elt/.meltano/transformers/dbt-bigquery/venv/lib/python3.9/site-packages/dbt/task/compile.py", line 4, in <module>
    from .runnable import GraphRunnableTask
  File "/workspaces/elt/.meltano/transformers/dbt-bigquery/venv/lib/python3.9/site-packages/dbt/task/runnable.py", line 11, in <module>
    from .printer import (
  File "/workspaces/elt/.meltano/transformers/dbt-bigquery/venv/lib/python3.9/site-packages/dbt/task/printer.py", line 22, in <module>
    from dbt.tracking import InvocationProcessor
  File "/workspaces/elt/.meltano/transformers/dbt-bigquery/venv/lib/python3.9/site-packages/dbt/tracking.py", line 25, in <module>
    import pytz
ModuleNotFoundError: No module named 'pytz'

Environment
- OS: Linux (fresh docker container inside virtual environment)
- Python: 3.9
- dbt: 1.3.1 (~=1.3.0)

Which database adapter are you using with dbt?
other (mention it in "Additional Context")
Additional Context
No response

Workaround I've found is to specify pytz explicitly in the meltano config as so:
  transformers:
    - name: dbt-bigquery
      variant: dbt-labs
      pip_url: dbt-core~=1.3.0 dbt-bigquery~=1.3.0 pytz==2021.1

but ideally dbt should define it's dependencies properly

Facing this as well went with the same fix.

If I see correctly it's because of the Babel package (included indirectly by agate). They've just released version 2.12 which incudes pytz only if you have python < 3.9.
https://github.com/python-babel/babel/tree/v2.12.0
# Python 3.9 and later include zoneinfo which replaces pytz
'pytz>=2015.7; python_version<"3.9"',

I think if dbt uses pytz directly it should specify explicitly in reqs.
Pinning Babel to ver 2.11.0 should also work.

Thanks for the report, all. It sounds like the fix here is to add pytz as an explicit dependency to setup.py. We'll need to fix this and backport it to all currently supported versions.
Separately, we should look into whether we ought to replace pytz with zoneinfo for Python 3.9+.

Don't suppose you could also backport to 1.0?

@WittierDinosaur we provide critical fixes for minor versions of Core for 1 year from their release date, and v1.0 came out in December 2021 so is no longer covered: https://docs.getdbt.com/docs/dbt-versions/core

I also had this bug too when trying to install DBT using the Docker file from the DBT site and docker-compose. I found a way to fix it for the moment but I think the bug comes from the Dockerfile.
First, you need to use docker with the build kit like this  ‘DOCKER_BUILDKIT=1 docker build .’ Then alter the Dockerfile with a simple run command ‘RUN python -m pip install dbt-core’ or any other pip install that you need.


bugfix issue #105

If lyrics are missing from the page but are requested with the --embed-lyrics option, then lyrics tag will contain 'lyrics unavailable' string.

Hm, not sure about this, its not quite a bug with the lyrics grabbing feature and more that I should not have left the option available in its current state (It does nothing)
I found the original fetching and embedding unreliable, we were getting duplicate lyrics tag or lyrics were coming up null even if they existed (Sometimes its not in the album data)
I later found out where to get the lyrics reliably but haven't added it back in yet.

The underlying issue was bigger, fixed now.


How to implement a standard behaviour for a widget

I want to address the following scenario:
A screen/widget is being displayed (pushed).
This screen needs to:

perform a perform a long task (a request) the first time when it is created
show a loading while it is performing the task(reqeusting)
display an error dialog if required (failed request)
update the list accordingly when the task finishes
have an outside trigger to update and restart the long task (request the data again + loading and alerts included)

——————————————————————————
I have reached a conclusion that you cannot have this behaviour without:

a delay mechanism to display the error dialog (addPostFrameCallback or Future.delayed)
a state mechanism for handling the component behaviour (initial/loading/non loading/finished). This state mechanism implies a stream for state or calling setState at key moments and reacting to current status.

have you tried using this
https://docs.flutter.io/flutter/widgets/FutureBuilder-class.html

@superciccio Yes. Here (https://stackoverflow.com/questions/55631289/how-to-implement-a-standard-behaviour-for-a-widget)  is a more detailed description of the situation:

Hi @durduman
I believe opening your question on SO has being the right decision.
Please see https://flutter.dev/community for resources for asking questions like this.
Closing, as this isn't an issue with Flutter itself,
if you disagree please write in the comments and I will reopen it
Thank you


Gap between node tray and resize bar

Current Behavior
Watching this video from Prescient on YouTube, at 0:46, I noticed a weird gap between the exec node tray and its resize bar.
Screenshot from the video.

I was able to reproduce it here, but I still can't pinpoint exactly what causes it. Sometimes it's there, and sometimes it's not.
Expected Behavior
No response
Steps To Reproduce
No response
Example flow
paste your flow here

Environment

Node-RED version: 3.0.2
Node.js version: v16.16.0
npm version: 8.11.0
Platform/OS: macOS
Browser: Chrome and Safari

It seems this only happens when you zoom in on the browser. Depending on the zoom level, the gap is there.

The .red-ui-tray-resize-handle is being rendered with border-box: content-box.  It is set to 7 pixels w/ a border on the left so it's 8 pixels wide but being offset to the left by 9 pixels.
.red-ui-tray-resize-handle {
    position: absolute;
    top: 0px;
    bottom: 0px;
    width: 7px;
    left: -9px;
    background-color: var(--red-ui-primary-background);
    cursor: col-resize;
    border-left: 1px solid var(--red-ui-primary-border-color);
    box-shadow: -1px 0 6px var(--red-ui-shadow);
}

At certain zoom levels this seems to be working OK because it shares a border w/ the red-ui-tray underneath it but at some zoom levels you can see the gap.  I think a possible fix is to add a right-border so that the handle is 9 pixels wide and being offset by 9 pixels (no gap)
e.g.
    border-right: 1px solid var(--red-ui-primary-border-color);

Before/After
Image

Before

After

Side node: The original shared border uses the secondary-border-color var var(--red-ui-secondary-border-color) but because the handle is adding a box shadow that darkens the border I think using primary-border-color looks closer to the color at 100% zoom.


Trying to install a component since I didn't install the whole npm package but I keep getting this error .

What RMWC Version are you using [major.minor.patch]:

Name your build system [Webpack, Rollup...]:

Describe the bug with as much detail as possible:

What happened, and what was supposed to happen:

npm i @rmwc/select --save
: npm ERR! code Z_BUF_ERROR
npm ERR! errno -5
npm ERR! zlib: unexpected end of file
npm ERR!      C:\Users\Chokor solomon\AppData\Roaming\npm-cache_logs\2020-04-07T06_33_23_927Z-debug.log
I don't there is something wrong with my version of npm because i tried installing other random packages
i needed and it worked just rmwc packages


Implement driver for FDO2 sensor

This PR:

Adds the stateless and stateful driver code for the FDO2 sensor which will be used to measure FiO2.
Integrates the FDO2 sensor (which produces pO2 measurements) with the simulator (which simulates FiO2 measurements).
Implements support for a subset of the commands made available by the FDO2 sensor.
Performs a version check and starts the sensor in broadcast mode as the setup routine, but does it in a blocking manner (which may take up to 100 ms).
Does not do error-checking in some places.
Really needs refactoring.

This PR is in the critical path of development, passes clang-tidy and clang-format checks, is needed for me to make progress on the milestone 8 (v0.5), is of at least comparable (probably slightly lower) quality to the rest of the firmware codebase, and probably would not be able to find someone to review it very quickly. We will need to go back and review everything in this PR and refactor it. I will merge in this PR now.
For records-keeping:

This project is licensed under Apache License v2.0 for any software, and Solderpad Hardware License v2.1 for any hardware - do you agree that your contributions to this project will be under these licenses, too? Yes
Were any of these contributions also part of work you did for an employer or a client? No
Does this work include, or is it based on, any third-party work which you did not create? No


Add a .py.typed file

This lets type checkers know that the package contains inline types, meaning that they won't generate annoying errors about using an untyped library if a user imports a function from the package (see PEP 561 for more details).
Closes #5

Thanks!

Thank you!


Unable to configure using kotlin

I'm attempting to use this plugin using the kotlin DSL. Has anyone had any luck?

http {
    config {
        request.uri.set("${gHostUriType}://${gHost}:${gRestPort}")
    }
}

yields

  Line 33:         request.uri.set("${gHostUriType}://${gHost}:${gRestPort}")
                   ^ Unresolved reference: request

Leave it to banging your head against a wall for a long time to figure something out.
http {
    config{
        it.request.setUri("${gHostUriType}://${gHost}:${gRestPort}")
    }
}


Quick Sort Implementation

Thank you for contributing to @AllAlgorithms, your pr got merged! ✨ Make sure that you ⭐ the project 🤓, and continue helping us!

This pull request will be closed as Quick sort is already implemented in #12 #20


Demo with usage of EV

This version needs to use v.1.0.1 of home-energy-managment package which will be released after merging EV simulator into main branch

I left two more comments. Apart from that lgtm :)

Please:

squash commits before you merge
add new reference to HEM in requirements.txt
test if everything works


Fixed extensions/locations confusion in error extraction.

When the Fusion execution encounters an error from a subgraph, it tries to extract information such as the location and the errors. Due to a small mixup in JSON parsing, it currently throws
System.InvalidOperationException: The requested operation requires an element of type 'Array', but the target element has type 'Object'.

Thanks for your help!
The build is running:
https://github.com/ChilliCream/graphql-platform/releases/tag/14.0.0-preview.11.2


Support for S3 caching

Cody supports local cache, but I've found it quite pointless as the cache hits are extremely conditional on a number of factors.
https://stackoverflow.com/a/59070807/4131237
Not from any public source, but these are some observations:

The cache will only be available if the build time is more than 5 minutes.

* Cache can be used if the new build is successfully placed on the same build host.

* Cache can be used if the new build is being run within 5-15 minutes of the last build. Cache may stay available based on the last build time with a max of 15 minutes.

* Despite builds exceeding 5 minutes, the cache may not always work probably due to build being placed on different build host.

* Additionally, in the case where the cache speeds up the new build to below 5 minutes, that build will not be cached resulting in subsequent miss.

It'd be great to allow configuring S3 cache with Cody by specifying the bucket name.

Believe that Cody already allow using s3 as a cache by using the cache method and setting the properties directly. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-codebuild-project-projectcache.html
A s3_cache convenience method would be nice though. Will consider PRs. No sweat either way though, will get to it in time.


card border flicker on theme switch

Switching themes on your blog has a minor "flicker" on cards borders due to CSS transitions which don't seem to be applied on borders, just making it transparent seems to fix it and it can't be removed entirely because of hovers
Sorry for nit picking, just some ocd. And thanks for your amazing work for the community!

you're right, thank you so much for the fix ❤


Cocoapods

Hi,
Cocoapods not work .
pod 'BlackRaccoon', :git => 'https://github.com/lloydsargent/BlackRaccoon'
Thank you

I do not use Cocoapods. Anyone have a solution?


@types - AuthCallback: Incorrect definition

https://github.com/verdaccio/monorepo/blob/9.x/core/types/index.d.ts defines
type AuthAccessCallback = (error: string | null, access: boolean) => void;

interface IPluginAuth<T> extends IPlugin<T> {
  authenticate(user: string, password: string, cb: AuthCallback): void;
  adduser?(user: string, password: string, cb: AuthCallback): void;
  changePassword?(user: string, password: string, newPassword: string, cb: AuthCallback): void;
  allow_publish?(user: RemoteUser, pkg: T & PackageAccess, cb: AuthAccessCallback): void;
  allow_access?(user: RemoteUser, pkg: T & PackageAccess, cb: AuthAccessCallback): void;
  allow_unpublish?(user: RemoteUser, pkg: T & PackageAccess, cb: AuthAccessCallback): void;
  allow_publish?(user: RemoteUser, pkg: AllowAccess & PackageAccess, cb: AuthAccessCallback): void;
  allow_access?(user: RemoteUser, pkg: AllowAccess & PackageAccess, cb: AuthAccessCallback): void;
  allow_unpublish?(user: RemoteUser, pkg: AllowAccess & PackageAccess, cb: AuthAccessCallback): void;
  apiJWTmiddleware?(helpers: any): Function;
}

However, the server seems to be expecting an object when there is an error for the callback, not a string.
When I try to pass an error: string the server throws an error, it seems to be expecting an object.  I have to pass null to prevent the server from throwing an error.
Example Code
public authenticate(username: string, password: string, cb: AuthCallback): void {

  // fetch the user and set validPassword

  return validPassword ? cb(null, fetchedUser.groups) : cb('user not found', false);
}

Output from server
npm ERR! Unexpected token u in JSON at position 0 while parsing near 'user not found'

I checked this in https://github.com/verdaccio/verdaccio/tree/5.x and found to be fixed? Is there any work left on this? Or need to do replicate it in master?
Code in 5.x
type AuthError = HttpError & { code: number };
  type AuthAccessCallback = (error: AuthError | null, access: boolean) => void;
  type AuthCallback = (error: AuthError | null, groups: string[] | false) => void;

  interface IPluginAuth<T> extends IPlugin<T> {
    authenticate(user: string, password: string, cb: AuthCallback): void;
    adduser?(user: string, password: string, cb: AuthCallback): void;
    changePassword?(user: string, password: string, newPassword: string, cb: AuthCallback): void;
    allow_publish?(user: RemoteUser, pkg: T & PackageAccess, cb: AuthAccessCallback): void;
    allow_access?(user: RemoteUser, pkg: T & PackageAccess, cb: AuthAccessCallback): void;

@dnafication there is no progress on this yet, I decided to move first all plugins and modules to 5.x so change types is way easier, that step was already done. So the next step would be this one.

I would like to take this up @juanpicado

@haquezameer awesome, my comment from 2020, back then the master branch did not have the current structure. In master branch you can find all the modules and this file https://github.com/verdaccio/monorepo/blob/9.x/core/types/index.d.ts is located here
https://github.com/verdaccio/verdaccio/tree/master/packages/types so you have all required pieces on this repo.
Feel free to ask me all you need to know to move this on.


add .github files

Most of files copied from killbill/killbill-commons repository, except for ci.yml: It's copied from killbill-oss-parent

PR from my account failed because:
org.apache.maven.wagon.authorization.AuthorizationException: authentication failed for
  https://oss.sonatype.org/content/repositories/snapshots/org/kill-bill/testing/testing-mysql-server/8.0.31-1-37662a8-SNAPSHOT/testing-mysql-server-8.0.31-1-37662a8-20221031.212728-1.jar,
  status: 401 Unauthorized

Let's close this one and use PR from this repo branch.


Crawler stopping too soon

I'm trying to run the crawler to extract links from a simple page using the following command:
phantomjs --ssl-protocol=any --ignore-ssl-errors=true --proxy=<IP_ADDRESS>:8080 --proxy-type=http render.js http://<IP_ADDRESS>:8899/pages/11.php

11.php is part of wivet, a web crawler test application. The response generated when browsing to 11.php is:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

		<meta http-equiv="content-type" content="text/html; charset=windows-1250">
		<link type="text/css" rel="stylesheet" href="/style.css" />

      click me
      click me 2

I see this in the browser I'm running in <IP_ADDRESS>:8080 (see proxy param in the phantomjs call). I also see the jquery.js page being requested.
The output seen in stdout when running the command is:
{"response":{"headers":{"Date":["Thu, 02 Feb 2017 21:14:30 GMT"],"Server":["Apache/2.4.10 (Debian) PHP/5.6.11"],"X-Powered-By":["PHP/5.6.11"],"Set-Cookie":["PHPSESSID=2a81288b4a514a017c4d79bd89de6c51; path=/"],"Expires":["Thu, 19 Nov 1981 08:52:00 GMT"],"Cache-Control":["no-store, no-cache, must-revalidate, post-check=0, pre-check=0"],"Pragma":["no-cache"],"Vary":["Accept-Encoding"],"Content-Length":["726"],"Connection":["close"],"Content-Type":["text/html; charset=UTF-8"]},"contentType":"text/html; charset=UTF-8","status":200,"url":"http://<IP_ADDRESS>:8899/pages/11.php","body":"\n\t\t<meta http-equiv=\"content-type\" content=\"text/html; charset=windows-1250\">\n\t\t<link type=\"text/css\" rel=\"stylesheet\" href=\"/style.css\">\n  \n  \n\t\n\t\n    \n      click me\n      click me 2\n    \n\t\n\n","details":{"links":[{"text":"click me","url":"http://<IP_ADDRESS>:8899/innerpages/11_1f2e4.php"}],"forms":[],"jsLinkFeedback":true}},"elasped":531,"ok":1,"msgType":"domSteady","signature":"==lXlKfYWch7H9VdJgPCmJ=="}

{"action":"element.triggered","events":["click"],"keyChain":["root","body/center[1]/a[2]"],"childFrames":[{"headers":[{"name":"Accept","value":"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"},{"name":"Referer","value":"http://<IP_ADDRESS>:8899/pages/11.php"},{"name":"User-Agent","value":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/538.1 (KHTML, like Gecko) PhantomJS/2.1.1 Safari/538.1"}],"id":1,"method":"GET","time":"2017-02-02T21:14:30.560Z","url":"http://<IP_ADDRESS>:8899/innerpages/11_2d3ff.php","fromMainFrame":true,"navigationType":"Other"}],"msgType":"domChanged","signature":"==lXlKfYWch7H9VdJgPCmJ=="}

The first one is the response for the initial GET request. The second one seems to be a click on one of the links:
      click me
      click me 2

My questions are:

Did you guys run gryffin against WIVET? Any results you can share?
Why is only one of the links clicked?
Why am I not seeing the HTTP request to 11_2d3ff.php in my proxy?
In the JSON printed in stdout I see:

"details":{"links":[{"text":"click me","url":"http://<IP_ADDRESS>:8899/innerpages/11_1f2e4.php"}]

If the crawler did not click on the second link, how was that URL extracted?
Is there something I'm doing wrong? I'm using phantomjs 2.1.1

The project is being archived.


Add The Witelon State University of Applied Sciences in Legnica

Please add The Witelon State University of Applied Sciences in Legnica.
Website: http://www.pwsz.legnica.edu.pl/
E-mail pattern<EMAIL_ADDRESS>

@MK-PL Pull request merged. Thank you!

Thank you!


some codes modified for pandas >= 1.0

modified list:
df.to_dense -> df.sparse.to_dense
df.ix[index] -> df.iloc[index]
df.ix[:, 'features'] -> df['features']
If you modify the above, you will be compatible for pandas >= 1.0.

Thanks—will just merge this, as this repo is no longer maintained/supported.

Thanks—will just merge this, as this repo is no longer maintained/supported.