[✨] Allow loaders to be refetched programmatically and configure if they should refetch when an action is run

Is your feature request related to a problem?
Yes. We have a pretty complex page which requires various api calls which we use a different loader for each. Not sure if this is feasible but it would be nice to

Be able to opt in or opt out of the loader being rerun when an action is run. Some loaders we don't necessarily want to be rerun when any action is run. If there are many loaders the .json from the action can get pretty large and makes unnecessary api calls etc.
Be able to programmatically refresh a particular loader. A use case for this would be that a user performs a particular interaction on the page and we only want to rerun a single loader

Describe the solution you'd like
export const getProductData = loader$(() => {
  return {
    product: {
      name: 'Qwik City',
      price: 100,
    },
  };
}, { strategy : 'manual' });

The strategies could be 'manual' or 'automatic' or maybe something more clear. But automatic would rerun when actions are called and manual would not. Default could be 'automatic' since that's the way it currently works now.
Additionally a loader can be rerun by calling
getProductData.refresh()
I'm sure the semantics with the naming could be improved. But if these additions could be made to allow more control over the loaders that would make the qwik data fetching even more incredible
Describe alternatives you've considered
The alternative I guess is to leave it the way it is? I'm not sure if this is even feasible as I'm not super familiar with the lower level implementation of loaders and actions
Additional context
No response

I am new to Qwik and was looking for something like this to cache the loaders and not re-run them. Ideally, I prefer a similar solution to Next.js, where they parse the cache header to set this up automatically or give you a way to set up the timer on when to invalidate this cache.
Do you know if Qwik already parses the cache header for the loader$ to effectively deliver your 1st requirement?

That is a fair point. However, it doesn't address the extra data that's going to be sent from the server back to the client even if the loader is cached on the server.  Which is about 150KB in our case, nearly all of which doesn't need to be sent again.
Just tested the caching, doesn't seem like it's supported(the loaders and actions didn't work on stackblitz):
https://stackblitz.com/edit/qwik-starter-ejmirx?file=src%2Froutes%2Findex.tsx,package.json

I was hoping that the cache header would trickle all that way so that re-fetching from the client side would only yield a no-change response. Thank you for testing it out!
It seems this is quite a missed opportunity.

I was hoping that the cache header would trickle all that way so that re-fetching from the client side would only yield a no-change response. Thank you for testing it out!
It seems this is quite a missed opportunity.

The setup of loaders and actions doesn't really work that way. Once an action is finished running a q-data.json file is sent back to the browser which contains the result of the action and a rerun of all the loaders. This is what I'm referring to in ask 1

We want to solve this problem, but remember that actions can be  submits, ie full page reloads. In this case the loaders will need to run, just like any page refresh!

We could do:

Some extra SPA only logic, could notify which loaders to run
Some server-side cache level for loaders

We will looking into both strategies! so please, keep the conversation going, i would love to understand better how you plan to use this APIs.
We will collect all this feedback and try to put it together!

That’s a good point. I guess maybe it makes more sense to configure the “strategy” of the action instead of the loader and the strategy could either be rerun all the loaders with a full reload or only return the data from the action.
The specific problem I was hoping this would solve is handling authentication state. We are currently fetching the user in a loader and storing it in a context(so we can update the context when the user logs out, all from the client), but it would be ideal to treat the loader as the single source of truth.
The other way I could do it is to run an action to log out the user, which would rerun the user loader. This suffered from the first problem of sending a lot of data(about 150kb) due to the number of loaders we have.
That said, the programmatic loaders would pretty much solve this because we could log out and then refetch only that loader. But I could see use cases where it’s unnecessary for actions to cause full reloads. So adding a strategy to actions and programmatic loader would allow the control needed to only reload what’s needed. Such as submitting a form as an action and then refetching one loader programmatically.

The ability to control when an action$ triggers some, none or all loaders would be helpful. For example, if you have a login form and the users login was successful, fire all loaders. But if the user login fails, fire none or only specific loaders.

@manucorporat I'm using a server$ function, how can I trigger a full page reload with it?

This issue has become quite a bottleneck for my app. Submitting a form in a nested route causes all routeLoaders in the parent layout files to run which in turn makes the response of my actions really slow.

Bundled some duplicates. Generally speaking, the desired caching behavior seems to mostly be "forever". So if a routeloader ran once, cache it and never run it again while navigating.
Maybe this can be achieved in the serviceworker, adding SSR'd routerloaders into the browser cache?

@wmertens It's true if the routeLoader$ is only for loading static resources, but I think the life time of the cache must be same to the resource if it is dynamic.

Since I have read about the routeLoader$ and loadClientData to fix some issues, I came up with a way to enforce refetching programmatically.
I you want enforce refetching a route loader when SPA navigate to the page the loader related with, you can put a cache buster parameter to the href of the  component.
This makes change the cache key of the client data, then you can always refetch the brand new q-data.json at the SPA navigation.

If the route loader is a pure function, the cache buster parameter can be inferred from the arguments of the function.
To append JSON.stringify(args) is a simple solution.
I think it is great if the loadClientData can treat it automatically.
Even for cases the loader is not pure function, the optimizer may be possible to extract the implicit dependencies as well as QRLs do.

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.


[HOPS-1154] Clean code for block hash undo in file append and update …

…pipe line RPCs
Make sure there is no duplicate PR for this issue

Please check if the PR fulfills these requirements

[ ] Tests for the changes have been added and passed (for bug fixes / features)
[x] HOPS JIRA issue has been opened for this PR
[x] All commits have been squashed down to a single commit
[x] The commit message has the following format: [HOPS-XXX] message

Post a link to the associated JIRA issue
https://hopshadoop.atlassian.net/browse/HOPS-1154

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
code more readable and it is closer to the algorithm publish in the paper

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:

Can one of the admins verify this patch?

Jenkins test this please.

Can you put a proper description in the jira?

fxied

Jenkins test this please.


[RFC]: add REPL text lint rule for catching semicolon omission in examples

Description
This RFC proposes adding tooling support for warning when semicolons are omitted from examples in REPL text help files. For reference, semicolons are used to silence/suppress the display of return values in the REPL. As an example,
> function foo() { return 'bar'; }
> foo()
'bar'

The above should trigger a warning (or perhaps more strongly an error) to indicate that the function declaration should not be displayed as return output. Instead, the above should be
> function foo() { return 'bar'; };
> foo()
'bar'

Discussion of return value suppression can be found in the REPL developer guide: https://github.com/stdlib-js/stdlib/blob/481690174833259628032a259dbe7d26bbde807d/docs/repl_text.md#examples.
Related Issues
n/a
Questions
No.
Other
No.
Checklist

[X] I have read and understood the Code of Conduct.
[X] Searched for existing issues and pull requests.
[X] The issue name begins with RFC:.

The need for this RFC arose in https://github.com/stdlib-js/stdlib/pull/2421 where, during PR review, it can be easy to overlook inadvertent omission of semicolons.

Would just updating this file with a complementary check do the trick?

@Snehil-Shah Yes, it seems we can simply update the existing lint rule and update the rule description accordingly.

It works. Should I push this? (with any changes?)

@Snehil-Shah That looks reasonable. You'll also want to update the lint rule description, I believe, in the package.json to something more general.


Bump local auth basic auth version

$subject

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.sadil seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Weird display when Git has a remote host ID warning

Type: Bug
If a Git remote host's key changes, and there is a key error, the warning message is something like:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.

However, the Git error message box just shows the ampersands, and cuts off the rest of the message, which is pretty exciting at first until you figure out what's going on.
To reproduce, you could purposefully break your Github fingerprint in ~/.ssh/known_hosts, which would give you the error.
VS Code version: Code 1.76.2 (ee2b180d582a7f601fa6ecfdad8d9fd269ab1884, 2023-03-14T17:53:46.528Z)
OS version: Darwin arm64 21.6.0

This is what the modal looks like:

Closing as duplicate of https://github.com/microsoft/vscode/issues/178235


feature: cta example sections

Connects to #516
CTA section examples.

theres an issue with p text not being centered when Text-center is used (bc of paragraph max-width) but Laura has a fix for that in her branch.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Bug: Viewing Related Work Items Throws Exceptions

When clicking on 'Related planner item' in the Work Item Linking bar, an exception is thrown. The UI still displays the linking input option.
When I try to click on another item in the Work Item List, the URL changes (http://demo.almighty.io/work-item-list/detail/47 becomes http://demo.almighty.io/work-item-list/detail/256), but the UI does not show me the proper Work Item Detail information or highlighted row.

Note - I have to refresh my screen in order for the exception to clear and continue to navigate through the work item list.

This was fixed in #403 and #405


Add tr() descriptors for Taproot output scripts

Implements tr() descriptors

Thanks for the changes in 6539d6c4967f74fa2a2bcc022067d3c9dd3cb9c2. I still think more test vectors would be useful here.

Core doesn't really have any test vectors that we can use.

Core doesn't really have any test vectors that we can use.

Feel free to use the test vectors from:

https://github.com/satoshilabs/slips/blob/master/slip-0014.md#bitcoin-taproot--p2tr--bip86
https://github.com/satoshilabs/slips/blob/master/slip-0014.md#bitcoin-testnet-taproot--p2tr--bip86

utACK d2d360c4cc7db84afea41c56497cf33f0726b136


PXPay requires currency to be specified.

Currently, the currency is the transaction is not being specified by default, though it's a required variable.
http://i.imgur.com/hIzV2fm.png

You need to specify which current you wish to use in your parameters,
$gateway = Omnipay::create("PaymentExpress_PxPay");
$gateway->initialize(array('username' => 'username', 'password => 'password'));
$gateway->purchase(array(
    'currency' => 'NZD',
    'amount' => '10.00',
    'returnUrl' => 'https://www.example.com/return',
))->send();


Service test: Servo

attempt at servo tests

@tballmsft we need a way to assign a value to a register and observe the changes.

we have assign(register, expression) - everything is a function call right now.

Crashes UI

oh, that's interesting... let me take a look.

Fixed.


Added changes to handle timestamp and score

Fork that adds fix for bug where timestamps and scores got link-ified as potential phone numbers

where are the tests? what problem are you solving?

It's not possible to test this feature directly through glipdown. The function that runs a final check on potential phone numbers is a dependency not directly included. The function 'is_valid_pstn()' is initially set to false and changes if a Client object exists. This means that all numbers marked by the 'potential_phone_regex' are not link-ified by glipdown on its own. Therefore no tests can be done to prove that the numbers treated as exceptions are being marked or not.

And to answer what problem is being solved: Timestamps and Scores are being marked as potential phone numbers and occasionally pass through the link-ify step when they should not. This prevents time stamps that follow a standard form and small scores (i.e in the form of XX-XX) are treated as exceptions and are prevented from being linkified.


Ext overrides3 storage headless migrate

Description of changes

(fix) auto-migrate on headless s3 storage api
(fix) storage unit-tests for prompter function change
(fix) s3 cli-ux loop until permission selected

Issue #, if available

Description of how you validated changes
Checklist

[ ] PR description included
[ ] yarn test passes
[ ] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #8696 (67ce21a) into extOverrides3 (fdbab02) will increase coverage by 0.15%.
The diff coverage is 30.57%.

@@                Coverage Diff                @@
##           extOverrides3    #8696      +/-   ##
=================================================
+ Coverage          56.17%   56.32%   +0.15%
=================================================
  Files                841      834       -7
  Lines              47325    47118     -207
  Branches            9453     9439      -14
=================================================
- Hits               26583    26540      -43
+ Misses             19924    19760     -164
  Partials             818      818

Impacted Files
Coverage Δ

...egory-api/src/provider-utils/supported-services.ts
100.00% <ø> (ø)

...ls/awscloudformation/handlers/resource-handlers.ts
14.56% <ø> (ø)

packages/amplify-cli-core/src/index.ts
100.00% <ø> (ø)

...amplify-cli-core/src/state-manager/stateManager.ts
39.77% <ø> (+0.32%)
:arrow_up:

...ormation/service-walkthroughs/apigw-walkthrough.ts
7.73% <7.00%> (-0.79%)
:arrow_down:

...ory-api/src/commands/api/add-graphql-datasource.ts
22.01% <9.45%> (-1.62%)
:arrow_down:

...egory-interfaces/category-base-schema-generator.ts
11.42% <14.28%> (-1.08%)
:arrow_down:

...mation/service-walkthroughs/appSync-walkthrough.ts
14.46% <29.54%> (-0.49%)
:arrow_down:

...ls/awscloudformation/utils/synthesize-resources.ts
17.77% <30.95%> (-0.14%)
:arrow_down:

...scloudformation/utils/transform-user-pool-group.js
20.00% <33.33%> (ø)

... and 23 more

Continue to review full report at Codecov.

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


Move events group name to component params (#61)

Q
A

Is bugfix?
❌

New feature?
✔

Breaks BC?
❌

Fixed issues
#61

For the first consideration

What's wrong with rector?

What's wrong with rector?

Rector workflow don't work in PR from forks. So far we have not able to solve this problem. May be has idea how fix it?

Thanks 👍

What's wrong with rector?

Rector workflow don't work in PR from forks. So far we have not able to solve this problem. May be has idea how fix it?

maybe helps
https://github.com/actions/checkout/issues/455


Add an entry for ISO Word styling on NOTEs and EXAMPLEs

Add explanation for correct formatting of ISO documents in Word for NOTEs and EXAMPLEs.
From ISO Editor:

When documents are processed at ISO, NOTEs and EXAMPLEs are so styled that they would appear in a font one-size smaller than the normal body text. Other than that, there’s no hard rule on how the EXAMPLEs/NOTEs are formatted.
If an EXAMPLE/NOTE contains multiple paragraphs, the usual practice is to follow the indentation in the submissions. It is possible to put the content in borderless tables, or other formats, to get the indentation right. But if there’s no special indentation in the submitted text, there would be no indentation in the rendered PDF.
For the EXAMPLEs in DP2, I suppose the special format (“EXAMPLE 2” on its own line; the frame around the text) was used for ease of understanding; after all, “EXAMPLE 2” provides examples for EXAMPLEs in documents, it could cause confusion if they all use the same format (it’s already quite convoluted putting them in this sentence).

Better yet this could be a blog post with screenshots on how NOTEs and EXAMPLEs can be encoded (i.e. source code + rendered look). Will be very useful for authors.

I am going to make it very clear, once again, that there is no way I am going to rewrite the documentation of Metanorma for a FOURTH time: I will never do this, and if you want this done, you hire someone else. It also goes without saying that this will make metanorma documentation more unnavigable, not less.
I actually see nothing to document here at all for metanorma.com. We don't document rendering, we never have, and there is no reason to. And the lack of navigability of metanorma.com will not be addressed with more random content.
Therefore I will not generalise this task past a desultory blog post. There will be no cartoons.

This task is to document our decisions for the user. This does not seem to require extra work.

Which part of this makes this sound like a “rewrite”?


Init the credentials with the access token if no service account file is available

@loicmathieu Hi Loic, here is the draft PR to support the injected access tokens, but only if the security account file is not available. I just need to make sure that when quarkus-oidc is on the classpath, then, with both IdTokenCredential and AccessTokenCredential being produced, it is the latter which is injected into TokenCredential...
Maybe going forward a map of credentials can be introduced, for example, when more than one service is used and one can only work with the service account (PubSub), the other one like BigQuery should use access token, etc...but this simple PR should do for now.
quarkus-security is a very light dependency and it should be OK linking these services with it as it also has other types of credentials which might become useful in time

Hi thanks for contributing!
If I understand it, the authentication flow will be: service account file -> token credential -> default (which will rely on the service account env variable, or the gcloud auth configuration).
Service account is server to server authentiation whereas token credential is final user authentication, so we may still be able to override the user authentication if needed. It's good for me.
Maybe we need to be able to disable this kind of authentication in case someone want to use this inside a GCP Function or AppEngine where the default authentication works out of the box, this will allow the user to rely on the default authentication for accessing google services (that will be a service account) and still use user authentication for other part of the application.

HI @loicmathieu
First of all, I updated it a bit to use Securityidentity instead - it is more flexible (ID token can be picked up if needed), and in fact it will work even with your OAuth2 extension :-), in principle, AFAIK, Google access tokens are binary tokens, though indeed, the primary case for using this access token is with the OpenId Connect Authorization code flow. I can work on a Qute + BigQuery + quarkus-oidc demo as well later on.

Maybe we need to be able to disable this kind of authentication in case someone want to use this inside a GCP Function or AppEngine where the default authentication works out of the box, this will allow the user to rely on the default authentication for accessing google services (that will be a service account) and still use user authentication for other part of the application.

Good point. Maybe:
   /**
     * Enable Google Cloud access token authentication (
     * For example, the access token which is returned as part of OpenId Connect Authorization Code Flow
     * may be used to access Google Cloud services on behalf of the authenticated user.
     *
     * Note that if a service account location is configured then the access token will be ignored even if this property is enabled.
     *
     * Disable this property if the default Google Cloud authentication is required.
     */
    @ConfigItem(defaultValue=true)
    public boolean accessTokenEnabled = true;

Or something similar ? thanks

@sberyozkin the proposed configuration item is good for me, the documentation part is really great by the way ;)
There is no automated test so I would need to test this manually, and I don't know how to test the oidc flow.

@loicmathieu Thanks, let me update the PR then (we can also disable the property by default - can be easily tweaked).

There is no automated test so I would need to test this manually, and I don't know how to test the oidc flow.

You can authenticate against Google as shown here. Just remove .tenant-b. part and make it a default configuration:
quarkus.oidc.auth-server-url=https://accounts.google.com
quarkus.oidc.application-type=web-app
quarkus.oidc.client-id={GOOGLE_CLIENT_ID}
quarkus.oidc.credentials.secret={GOOGLE_CLIENT_SECRET}
quarkus.oidc.token.issuer=https://accounts.google.com
quarkus.oidc.authentication.scopes=email,profile,openid

and add the quarkus-oidc dependency. So the basic test can just involve, without even the cloud services, injecting the ID token and returning your name to the browser.
Once this is done, you can then try check if the access token returned alongside ID token can be used to access some of these services, here is the instructions I added awhile back in the other project in a BigQuery demo (how to make this access token capable of accessing it on behalf of the user), it may be a bit outdated, but should be also applicable to any other Google service:

First, create a Big Query project as described in
https://cloud.google.com/bigquery/sign-up

1. OAuth2 Authorization Code flow.

Create a client id and secret as described in
https://cloud.google.com/bigquery/authorization#clientsecrets.

Set Redirect URI to
https://localhost:8080/bigquery
(You'd have JAX-RS `@GET` here, with `@Authenticated`)

Then start a browser and go to

https://localhost:8080/bigquery

and after you login in to Google you should land to this JAX-RS resource which will call BigQuery (or some other service)
Give it a try please when you get some time :-)

@loicmathieu thanks, I've updated the PR with the boolean property check, would you like me to open it for Review ?

@sberyozkin open it for review when you're done but I will not have time to review it untill mid of next week as I wanted to test it so it may take me some time.

@loicmathieu Sure, will do, definitely, it does not have to be rushed, so yeah, lets test it etc first :-)

Could we detect whether Quarkus is running inside of a managed GCP environment by checking for availability of the  metadata server? I imagine it would always be preferable to utilize this if possible and would reduce the need for a configuration property to control where the access (and possibly ID) tokens are fetched from.

@kostacasa when running inside a managed GCP environment, you won't need to setup the serciceAccount, the call to GoogleCredentials.getApplicationDefault(); will return the default credential so it should be OK.
Your note on getting the project ID from the managed environment is a good remark, can you open an issue for that ?

I successfully tested it thanks to your detailed information !
As soon as you document it, I'll merge it.

Hi @loicmathieu

I successfully tested it thanks to your detailed information !

Cool, thanks for spending the time on it

As soon as you document it, I'll merge it.

Sure, I suppose I will add a section not specifically about BigQuery but about linking the user acces tokesn with all (or most) of these services. Then later on there will be an integration test, and may be we can have a joint demo too :-)

Hi Loic @loicmathieu I've updated README, I can update it further if you'd like, no problems, thanks

@sberyozkin the current documentation is OK for me, when publishing guides for the Quarkus website (or whatever will store the Quarkiverse guides) we could have a more complete example.
As soon as you fix the code formatting (yes, code style on Quarkiverse is the same as on Quarkus ; ) I'll merge it.

@loicmathieu I had use Instance<SecurityIdentity> as it may not always be available; I can tweak the verification code there a bit if you'd like

@sberyozkin goods for me.

@all-contributors please add @sberyozkin for code


Clarification of documentation

Documentation "Prototypes and Prolog objects" lists two JavaScript prototypes:

Var (variables)
Term (compounds and atoms)

The code seems to also have Num, which seems to be for numbers but is not documented.
I am currently designing API for JS and SWI-Prolog (wasm build) interoperability and was looking how other JS-Prolog libraries do it.

Hello @rla . The English version of the docs is not fully translated yet. The Spanish docs are more matured, but they are not up to date either. We'll update them both as soon as we can!

Hello again @rla. The "Prototypes and Prolog objects" page has been updated.


Sensu Checks not working

Hi,
I am new to sensu. I have installed Sensu server, API & Uchiwa in one machine and RabbitMQ & Redis in another machine in redundant mode.
Sensu clients and checks are visible in Uchiwa dashboard, but the issue is, checks are not getting refreshed. Seems checks are not working.
Below is our memory check config.
{
"checks": {
"memory": {
"command": "/etc/sensu/plugins/check-memory.sh -w 956 -c 928 -p",
"interval": 10,
"subscribers": [ "Linux" ],
"refresh": 60,
"handler": "default"
}
}
}
Subscription "Linux" is configured in client machines in client.json file and also in the dashboard memory check is visible for the client machines with old check status.
I have restarted sensu server, api from sensu server. Sensu client from client machines. When I restart or re-initiate the checks, the checks getting updated, after that no updates in the checks.
Please let me know what is wrong and  if any one faced such issues.
Thanks,
Muhammed Udhuman

It is always good to start looking in the server and client logs.

This is more question than sensu issue. I would try stackoverflow instead...

@Udhuman there's not enough information here to suggest there is an issue with Sensu itself, so we're going to close this issue as "won't fix". If you need help learning Sensu, please consider signing up for Sensu Training, here: https://sensuapp.org/training
Alternatively, have you tried visiting the #sensu channel on Freenode? There are usually lots of Sensu users there who can help resolve issues like this.


[FRS-17] Provide more frequently used tools in container image

What is the purpose of the change
This pull request fix #17, provide more frequently used tools in container image
Brief change log

using openjdk:8-jdk-slim as base image to support more command like jps
Install some utilities like ps

Verifying this change
This change is already covered by existing tests in github action*.

Thanks @reswqa . I will help to merge it.

Merged.


Reversing an animated lua sprite

Describe your problem here.
Is there a way to reverse the animation of an animated lua sprite
Basically make it start at the end and end at the beginning.
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No response

addAnimationByIndices and do it backwards


Ignoring network definitions

Currently we ignore networks definition in services , but looks like we don't properly parse and ignore global networks definitions.
version: '2'

services:
...
networks:
  foobar:
  barfoo:

kompose seems to fail if these networks are defined. We need to successfully parse but give a warning.

I think it's not really an issue as the networks definition above seems not to be enough, then libcompose's parsing giving a panic.
I'm maybe wrong but it seems compose v2 requires at least one of these configs in network top-level definition: driver, driver_opts, ipam or external
If I try this below compose, it works:
$ cat networks.yml
version: "2"

services:
  redis:
    image: redis
    command: redis-server
    ports:
      - "6379"
    volumes:
      - /opt/redis:/redis
    networks:
      - foo

networks:
  foo:
    external: true

$ kompose --file networks.yml convert --out abc.txt
WARN[0000] Unsupported network configuration of compose v2 - ignoring
WARN[0000] Unsupported key networks - ignoring
WARN[0000] Volume mount on the host "/opt/redis" isn't supported - ignoring path on the host

I'm maybe wrong but it seems compose v2 requires at least one of these configs in network top-level definition: driver, driver_opts, ipam or external

I'm not sure about that, I'm usually writing compose v2 files where only top-level definition is version and services.

I'm not sure about that, I'm usually writing compose v2 files where only top-level definition is version and services.

To be exact, it's a libcompose bug. If I only declare networks name without any parameter like below, docker-compose still works but libcompose doesn't.
version: "2"

services:
  redis:
    image: redis
    command: redis-server
    ports:
      - "6379"
    volumes:
      - /opt/redis:/redis
    networks:
      - foo

networks:
  foo:

@ngtuna exactly. so do we need to add external:true for it to work.
We should file a bug upstream with lib compose.

Double checked. Libcompose solved it at HEAD. We should somehow update libcompose ref.


InstantiationService might create two service instances

have descriptors not service instances
create child instantiation service
from there request an instance
from the parent request an instance
⚡ two instances of the same service...

Closing with the option to revisit the fix

@Tyriar Pls verify


[Question]: Handle context window overflow?

What is your question?
Hi, as a gopher, really looking forward to the new go version :)
Does this library intend to handle context window overflow? As an example if I pass an input of 8000 tokens and the LLM it’s hitting has a context window of 4000, what happens? There are some solutions that handle context overflow by seeking summarization and including past summarizations in a loop. Thinking of MemGPT. I think Plandex also does this.
Just curious.
Thanks!

I guess there is another way too… maybe vectorizing and crawl/query over it


css intellisense

when a style tag is in the HTML the css doesn't get intellisense. This is a key feature for custom elements.
VS code - Version 1.34.0 (1.34.0)
component version - 1.8.8

I am happy to submit a PR, I am just not familiar with the development process for VSCode. I am looking through some of the documentation.

Hi
I'm sorry, but it's currently impossible at the current moment
It's just syntax highlighting plugin. For code folding and autocomplete features this plugin should be implemented as a custom language plugin.


Codecov Report

Merging #119 (c78a9ee) into develop (35e420a) will increase coverage by 0.28%.
The diff coverage is 84.10%.

@@             Coverage Diff             @@
##           develop     #119      +/-   ##
===========================================
+ Coverage    68.08%   68.36%   +0.28%
===========================================
  Files           52       54       +2
  Lines         8064     8365     +301
===========================================
+ Hits          5490     5719     +229
- Misses        2574     2646      +72

Impacted Files
Coverage Δ

src/coins/accounts.rs
0.00% <0.00%> (ø)

src/plugins/signer.rs
0.00% <ø> (ø)

src/coins/ops/mul.rs
39.62% <5.00%> (+6.28%)
:arrow_up:

src/coins/staking/validator.rs
77.77% <77.77%> (ø)

src/coins/pool.rs
82.90% <82.24%> (-8.16%)
:arrow_down:

src/coins/staking/delegator.rs
91.66% <91.66%> (ø)

src/coins/staking/mod.rs
76.42% <93.88%> (ø)

src/coins/decimal.rs
55.76% <100.00%> (+2.70%)
:arrow_up:

src/state/mod.rs
49.10% <100.00%> (+2.37%)
:arrow_up:

src/coins/share.rs
62.00% <0.00%> (-8.00%)
:arrow_down:

... and 10 more

Continue to review full report at Codecov.

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

Would have been nice to fix the clippy lints


Changing file name of uploaded files

I'm new to FilePond - and GitHub - so if this isn't the proper channel to ask for help, please let me know what is.  :-)
I want to change the name of files uploaded through FilePond. I've figured out how to manipulate this with the php boilerplate files you have provided. However, I want to be able to pass a php variable from the page FilePond is on to the Item.class.php file to add to the file name but I can't get a variable to go through so it can be used in the class.
I was wondering if there was an easier way to handle file naming through the setOptions/configuration of FilePond instead. If there is, I can't figure it out from the docs, so that's why I'm asking for your help.
Specifically, the page I am using FilePond on has an ID number for the project, stored in a php variable. I'd like any files uploaded through FilePond to be renamed using this ID (say, "12345"), so I can easily associate them with the project later on. So, when uploading my_file.jpg, I'd like it to change to 12345-my_file.jpg when stored on the server.
Thanks for making a cool product and putting it out there!
Matt

Hi Matt, excellent first post!
If you're uploading the files async then you could add the file id when posting the form. You can then modify the submit.php file and loop over the $items array after the temp files have been loaded. The Item class has a rename(), getFilename() and getName() function which you can use to rename the file.

Thanks for the quick response. I really appreciate it.
I've spent some time messing around with it again tonight based on your suggestions. I think I'm closer but I'm still struggling to figure out what I need to change to make it work.
In the submit.php file, I've got a loop going over the $items array, prepending the ID to each item. This ID comes from a hidden $POST value I added to the form.
...
// Get submitted field data items, pass input field name along
$items = FilePond\RequestHandler::loadFilesByField('filepond');

function prepend_ticket($x) {
    $ticket = $_POST['ticket'] . '_';
    return($ticket . $x);
}
$items = array_map("prepend_ticket",$items);

// Items will always be an array as multiple files could be submitted
FilePond\RequestHandler::save($items, 'uploads');

If I do a var_dump on $items at the end of the last line, I get the ID I want prepended to the item but the item being returned is the name of the temp folder being generated during the initial upload/drop of the file, rather than the file name.
array(1) { [0]=> string(32) "myID#_9ce44f05523308b03b454b84c0432535" }
I can't figure out how to use the rename function in the Item class to actually rename the files after hitting the submit button. I feel like I'm close but just don't know enough about PHP to put the right pieces in the right places. Any further help you can offer would be greatly appreciated!  :-)
-Matt
PS- It would be awesome to somehow offer some sort of file renaming (prepending, appending or complete rename) as part of the setOptions when configuring the FilePond script on the page. I don't know if that's possible or not, but if there is a way to have the file renamed right from the user dropping it on a FilePond instance that would save having to muck about with PHP, making this much more approachable for us mere mortals. :-)

No problem Matt!
A file rename plugin is on the roadmap but I am currently not working on it so it's still some time away.
I had to update the PHP boilerplate to make this work correctly, indeed the $items were id's instead of actual Item instances.
After getting the latest files, this should work:

// Get submitted field data items, pass input field name along
$items = FilePond\RequestHandler::loadFilesByField('filepond');

foreach($items as $item) {
    $item->rename('foo_' . $item->getNameWithoutExtension());
}

// Items will always be an array as multiple files could be submitted
FilePond\RequestHandler::save($items, 'uploads');

Hi! Just published the File Rename plugin to rename files on the client, I would still advice to prepend id's on the server but who knows, it might be useful.

For demo purposes, the default path is currently relative to the API location, as that makes it visually clear where the files end up. You can override the location either in code or by setting the static property.
I've updated the file-rename plugin docs with a quick example:
https://pqina.nl/filepond/docs/patterns/plugins/file-rename/#usage

Will close this for now as the original issue has been resolved.


Variable-length IDs

When trace-ids or span-ids are merely opaque strings (i.e., they're not used for arithmetic or substring manipulation, just for uniqueness), I don't see why this standard needs to specify their length. As such, I'm proposing that they become variable-length.
(Note that I would also welcome generic baggage support in this tracecontext format, but that's an orthogonal issue and thus not part of this PR)
Curious what other people think. (@bogdandrutu encouraged a pull request to discuss proposals like this)

I'm not sure how the number one could ever be a legitimate trace ID. Isn't this a bit too loose?

I guess it could be a legitimate trace ID once :P

I'm not sure how the number one could ever be a legitimate trace ID. Isn't this a bit too loose?

Yes, I included that just to emphasize the boundaries of the format... agreed that it's hard to imagine any uses outside of tests. The thinking here is just to be general when there's no good reason not to be. /shrug

"there's no good reason not to be" hmm I bet you can think of some reasons to have constraints, right? There must be some sort of impact

@bhs is the motivation here to support longer (or shorter) ids or make them an opaque strings?
If first - for longer strings proposal should enable more scenarios. I've been talking to the team in MS that wants span-id be 128bit (basically a GUID) for their internal purposes. From an example I see on aws it looks they use longer span-id as well.
Shorter strings may cause a problem as mistakenly sent GUID may be accepted as a valid string and the first part will be treated as a trace-id. Also uniqueness may become a problem as @adriancole mentioned.
If the proposal to support any string - I'd ask why hex vs base64 charset? Allowing trace-id be an opaque string may enable base64-encoded values. This may be beneficial if you want shorter string with the same 128bit uniqueness.
@bhs what is the scenario you trying to support?

oh, second qq already in discussion: https://github.com/TraceContext/tracecontext-spec/issues/16

Couple of questions/comments here:

Who needs longer trace-ids?
What is the limit of the trace-ids (probably we should have a limited size)?
Have you tried to benchmark this encoding? Please consider to do so, I think it is important for products with high qps to have a cheap encoding/decoding (like envoy).

@SergeyKanzhelev

is the motivation here to support longer (or shorter) ids or make them an opaque strings?

Good question. Much more the latter than the former, and I only kept the base16 thing because I wanted to literally minimize the diff in this proposal. I do not have strong feelings about it (either way). If it was literally up to me (clearly not), I would vote for arbitrary string data, base64-encoded or otherwise.
@bogdandrutu

Who needs longer trace-ids?

... or shorter. I was actually thinking about 8-byte trace-ids, not 32-byte trace-ids when I proposed this. Though IIRC the AWS folks used 24-byte trace-ids? (Trying to remember what Abhishek said IRL in Berlin – I could be wrong for sure)
My thinking here is definitely more that the ids should literally be used for identification (and not much more) in v1 of this spec.

What is the limit of the trace-ids (probably we should have a limited size)?

I'm happy to include sanity-checks on either (lower/upper) end if it makes this go through. Since we're dealing with HTTP headers, the upper bound is annoying inasmuch as it's inconsistent across implementations. What I would like to avoid is a requirement that all tracecontext-spec impls use precisely the same bitwidth for ids.

Have you tried to benchmark this encoding? Please consider to do so, I think it is important for products with high qps to have a cheap encoding/decoding (like envoy).

I have not tried, though given that we're only dealing with this when there's also a bunch of I/O / syscalls, it's really hard to believe that parsing a variable-length string (with no additional syscalls) is  going to make a difference in a real-world benchmark.
If we can agree about the encoding stuff, I'm happy to create a test demonstrating the difference (and the RPS numbers needed to observe a performance impact, if any). If that's a "discussion requirement" for spec changes like this, let me know.

@bhs

Good question. Much more the latter than the former, and I only kept the base16 thing because I wanted to literally minimize the diff in this proposal. I do not have strong feelings about it (either way). If it was literally up to me (clearly not), I would vote for arbitrary string data, base64-encoded or otherwise.

I thing this was discussed, and if I remember you kind of confirmed that this is better for production engineer (SREs). Happy to use base64 (a bit slower than base16 for small strings like this but probably not significantly). I would keep base16 for the moment and we can benchmark the encoding for 8/16/24 byte arrays and decide.

I'm happy to include sanity-checks on either (lower/upper) end if it makes this go through. Since we're dealing with HTTP headers, the upper bound is annoying inasmuch as it's inconsistent across implementations. What I would like to avoid is a requirement that all tracecontext-spec impls use precisely the same bitwidth for ids.

Do you think a limited size of 128 byte arrays is not enough for each of the ids?

I have not tried, though given that we're only dealing with this when there's also a bunch of I/O / syscalls, it's really hard to believe that parsing a variable-length string (with no additional syscalls) is going to make a difference in a real-world benchmark.

There are multiple possible options that we have here if we want to support variable sizes:

Rely on a delimiter "-" to determine the size.
Include the size in the header base16(size)base16(trace_id) that may improve performance.
Don't support variable sizes and pick a reasonable size 24 and always force 24 bytes. (against this PR, but I am adding as an option).

Good question. Much more the latter than the former, and I only kept the base16 thing because I wanted to literally minimize the diff in this proposal. I do not have strong feelings about it (either way). If it was literally up to me (clearly not), I would vote for arbitrary string data, base64-encoded or otherwise.
I thing this was discussed, and if I remember you kind of confirmed that this is better for production engineer (SREs). Happy to use base64 (a bit slower than base16 for small strings like this but probably not significantly). I would keep base16 for the moment and we can benchmark the encoding for 8/16/24 byte arrays and decide.

I think I was arguing that there be a human-friendly delimiter (- as we have at master is 👍 on that front, and compatible / non-overlapping with both base16 and base64 encodings). I only bring up the base64 thing since it's a safe and non-fancy (if admittedly suboptimal) way of encoding arbitrary string data per @SergeyKanzhelev's suggestion.

I'm happy to include sanity-checks on either (lower/upper) end if it makes this go through. Since we're dealing with HTTP headers, the upper bound is annoying inasmuch as it's inconsistent across implementations. What I would like to avoid is a requirement that all tracecontext-spec impls use precisely the same bitwidth for ids.
Do you think a limited size of 128 byte arrays is not enough for each of the ids?

I think 128 bytes is more than enough if you want to set that as a max... or, at least, I have little sympathy for anyone using a 129-byte identifier. :)

I have not tried, though given that we're only dealing with this when there's also a bunch of I/O / syscalls, it's really hard to believe that parsing a variable-length string (with no additional syscalls) is going to make a difference in a real-world benchmark.
There are multiple possible options that we have here if we want to support variable sizes:

Rely on a delimiter "-" to determine the size.
Include the size in the header base16(size)base16(trace_id) that may improve performance.
Don't support variable sizes and pick a reasonable size 24 and always force 24 bytes. (against this PR, but I am adding as an option).

I don't feel super strongly about this, but I am running under the assumption that none of this matters at all in terms of real-world performance, and thus we should choose the thing that's easiest for human beings. If we can agree about the rest of the changes here I'm again glad to write some simple benchmarks to measure overhead relative to an HTTP request.

:+1: for longer trace IDs, we use 40-byte trace IDs in TraceView.

@cce are you embedding metadata into the ID, or is it just super long?

What's the status of this?

What's the status of this?

@SergeyKanzhelev I am not sure too. Skywalking IDs are Variable-length.

@SergeyKanzhelev I am waiting for someone to either LGTM or tell me what needs to change :)
It seems like this would be stalled behind many of the open issues in this repo... many stimulating discussions, but lots of questions in the air about various things.

@bhs Variable-length is good for skywalking, but we still need an extra valid char: . . After all, id is very different for different implementations.

@wu-sheng what is this separator for? In some MS teams we are using hierarchical identifiers. The idea was to keep span-id as it is and attach hierarchy as a tail section of the trace-context.

@wu-sheng @SergeyKanzhelev I am fine with substantially broadening the set of allowable characters (I might even be enthusiastic)... we could also reuse (or, ugh, define) some sort of simple escaping mechanism to effectively represent any ascii char. Curious about thoughts on this front.

As I mentioned in https://github.com/TraceContext/tracecontext-spec/issues/16#issuecomment-332070303, I do not believe that the allowed alphabet is particularly important, what's important is that we simply cannot assign any semantic meaning to the blob that represents a trace ID (whether it's hexadecimal or richer alphabet), since the receiving tracer has no guarantee where that blob has come from - it could've come from a tracer that generated the blob completely randomly but the resulting representation just happened to look like it's a "hierarchical ID" or whichever semantics the receiving tracer might want to infer.

I referenced this in a proposed plan for v0.1.0 in #31 as I think this is the only big issue blocking us from a first release. Please let me know on that issue if you think this is a good or bad process.
Regarding fixed vs. variable-length IDs, I don't have a strong opinion, and from reading the replies above it looks like most people are leaning towards variable length (?). I'm curious to hear what @jkowall, @abhiksingh, and @CodingFabian think.

I am all for treating it as opaque. It would allow to preserve the value without meaning. But more importantly it helps us agreeing on it. In the and its a (hopefully) unique blob of bits.
On the topic of encoding, I would like to point out that we transmit our ids as numeric values on many non http formats for efficiency. Its interesting to see how hard it is to use a 64bit long for that.
We probably would stick to 8+8byte.
Now the big question for me is: what to do with the trace ids we are discussing here. When they are vendor specific, we cannot preserve them. So at maximum we could use the as reference to other segments of a trace.
Declaring a specific header as opaque would solve only one issue: mangling it.
If we would specify an encoding and value range, that would help processing the id, but still neither the tracer, nor the end user would know where to retrieve the spans from

We should know the tradeoff when we do something and opening the range..

seems to support some longer ids (ex Solarwinds, SkyWalking and MS hierarchical form)
interferes with interop of tracing systems that can currently interop "without looking" (dapper-based systems with 64 or 128-bit trace IDs).
doesn't alone enable multi-part IDs, ones that have IDs coupling across multiple fields, ex. AWS (timestamp+random although you can concat these)

In so far as it loosens the data that can be passed around, it doesn't solve the problems it creates. For example, before dapper-like systems could use the format directly. Now, we are saying anything goes, which means sequential or path-based data gets crammed into the field with no semantic clarification of what to do.. and with not enough data to say what to do next (next being when to devise another id).
Long story short, we are removing the ability for dapper-based systems to interop without prior knowledge (those systems can and do interop today, without the change proposed here). We also don't mention how practically these "open ids" can be shared. My guess is that the goal is to pass data and we'll just figure out later what to do with it?

For the moment, I assume this pull request is only focused on size and that any movement if any from base16 will happen on #16 as opened by @yurishkuro a while back.
Here are some concrete suggestions for text to add, should we decide to go with no minimum or maximum length of trace ID. If folks like @bogdandrutu @CodingFabian @jkowall @abhiksingh @christian-schwarzbauer are ok with this, I am. Please bear in mind, many are busy and scheduled time to be on-site Nov 1,2 to discuss this.
Anyway.. here are some notes I think should go into the spec or some usage related section if we remove all length constraints.

Some systems may send padded data and others not. It is not guaranteed the case that the trace ID 00aabcd is the same as aabcd.
This specification allows unbounded trace IDs. For example, some systems may not be able to store a 4KiB identifier. The next hop might restart a trace they cannot store.

The latter point is possible even with the existing system. We don't have an issue to track how to handle an incoming ID that you cannot process. Most systems restart traces if they cannot continue a trace for any reason. However, we might add an issue to explore other options, such as moving the "original ID" to a correlation header.

unless all vendors will agree on an ID format (which I consider unlikely) the interop issue always remains.
if the goal of the spec is to enable interop (e.g. bring together a complete trace from two sources) then more work needs to be done (e.g. explaining from which api the trace can be retrieved given the incoming headers)
Just preserving headers a tracer cannot understand is neither feasible nor helpful.
the likely outcome is that in the current proposal interop is not possible: Tracers will see an incoming Id which doesn't match the format of the tracer. Because it cannot be handled in data-structures of the tracer it will be dropped.
Variable length specifies this as accepted solution. Which could be good to get the spec started off, but I doubt will be actually useful.

During workshop everybody was OK with the fixed length. We can revisit it later again.

@SergeyKanzhelev I will still need to argue about our variable length trace id and parent span id,  and non base64 ID.
flying to beijing, today. keep in touch.

I will start  a new issue .


Support for Models in App folder in Laravel 11?

Laravel Version
11.0.7
PHP Version
8.2.16
Database Driver & Version
No response
Description
I'm a old skool Laravel developer who wanted Models to remain in the App root and was always grateful that Laravel 8+ still supported this. I've just installed Laravel 11 with Laravel Breeze (Blade/Alpine) and this seems to work fine as before... except when I run php artisan test.
I haven't quite deduced what's going on, but 19 of the 25 tests fail with the same error:

include(/Users/home/Eleven/vendor/composer/../../app/Models/User.php): Failed to open stream: No such file or directory
at vendor/laravel/framework/src/Illuminate/Database/Eloquent/Factories/Factory.php:789
785▕             $factoryBasename = Str::replaceLast('Factory', '', class_basename($factory));
786▕
787▕             $appNamespace = static::appNamespace();
788▕
➜ 789▕             return class_exists($appNamespace.'Models\'.$namespacedFactoryBasename)
790▕                         ? $appNamespace.'Models\'.$namespacedFactoryBasename
791▕                         : $appNamespace.$factoryBasename;
792▕         };

Steps To Reproduce

Install new Laravel 11 application with Laravel Breeze (Blade/Alpine) and SQLite
Move User model to App root (follow these steps: https://stackoverflow.com/a/77046263/199700 )
Run php artisan make:model Test to ensure everything is working correctly
Run php artisan test

Hi @driesvints, I don't think you read the report correctly. I know you're busy, but please take another look.

@JohnnyWalkerDigital ah sorry I indeed misread that.
What's going on is probably that your User factory doesn't points to your User any more. Try either updating the model property of your factory and/or add a dedicated newFactory method to your User model
https://github.com/laravel/laravel/blob/11.x/database/factories/UserFactory.php

Yes, I thought it might be the UserFactory no pointing to the right folder, but alas it's not that:
<?php

namespace Database\Factories;

use App\User;
use Illuminate\Database\Eloquent\Factories\Factory;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Str;

/**
 * @extends Factory<User>
 */
class UserFactory extends Factory

Does this mean that Laravel 11 doesn't support the root folder anymore?

It should. But since you moved it manually you'll need to figure out a bit what it takes on getting that test to pass. It's best to try a support channel for that:

Laracasts Forums
Laravel.io Forums
StackOverflow
Discord
Larachat
IRC

@driesvints Sorry, not sure I follow. If you could explain further I'd really appreciate it. As far as I know there is no other way than the manual editing of the config/auth.php to change the models folder. Is there another supported way?
I'd love to discover this is something I've done wrong, but I've used this technique on many projects through Laravel 8, 9 and 10. It's only with 11 that I'm getting this strange issue... but maybe I've made a misstep somewhere. I will keep prodding and probing to see if I can discover the root, but if there's anything else you could add, I would appreciate it.
Thanks.
Here's my config/auth.php:
'providers' => [
       'users' => [
           'driver' => 'eloquent',
           'model' => env('AUTH_MODEL', App\User::class),
       ],

       // 'users' => [
       //     'driver' => 'database',
       //     'table' => 'users',
       // ],
   ],

@driesvints Bah! It was fixed with composer dump-autoload. All is fine. Thanks for your time.

@JohnnyWalkerDigital all good! Glad you figured that one out 👍


test_default_cluster_spinup_time using too many instances for too long

Single CI run is spinning up this many instances for this test:

These instances have been running for about 10 minutes now.

As of 9:45 (my time, matching times in image) what are all these instances doing still running / just starting to shut down now?

test_default_cluster_spinup_time-bdcea260 details was one of the cluster up way too long, it was terminated from 20 minute idle timeout.
I'm guessing that when a previous CI run is canceled, there's no cleanup. Can that be fixed?
If not, can we at least set fairly short idle-timeout? Or would you expect multiple minutes of idleness on a cluster between tests?

These instances have been running for about 10 minutes now.

Hrm, that's not expected (or good) behavior. This test is meant to monitor how long it takes to spin up a vanilla Coiled cluster
https://github.com/coiled/coiled-runtime/blob/595c449f9a8c55ffe23d64c639314c46a4db1540/tests/runtime/test_cluster_creation.py#L6-L20
I would expect it to take ~3 minutes (at least the rough time I have in my head about how long cluster creation takes) and then shut things down. That roughly what I see when looking at one of the benchmark plots

I'm guessing that when a previous CI run is canceled, there's no cleanup. Can that be fixed?

I would expect the cluster to be closed when the Python session is shutdown from the CI job cancellation. Do you have a link to the CI run where we hit the 20 minute timeout?

I would expect the cluster to be closed when the Python session is shutdown from the CI job cancellation. Do you have a link to the CI run where we hit the 20 minute timeout?

https://github.com/coiled/coiled-runtime/actions/runs/3251088970
In the MR I'm testing currently I added AWS resource tags with information about the CI run :-)

Is this issue resolved?
@jrbourbeau can we close this one?

is this resolved? Can we close this one?

I have no reason to think it's resolved, has anyone done anything or looked into this?

Took a quick look at the database and it's still happening (not most of the time, but sometimes).
For last month:
109755	test_default_cluster_spinup_time-2a5285d2	2022-11-11 03:33:30.61228+00	{"minutes":21,"seconds":46,"milliseconds":858.322}	All instances stopped
109757	test_default_cluster_spinup_time-2d64768c	2022-11-11 03:33:54.046914+00	{"minutes":21,"seconds":41,"milliseconds":453.336}	All instances stopped
113081	test_default_cluster_spinup_time-80ae0a5c	2022-11-17 00:48:09.404028+00	{"minutes":11,"seconds":14,"milliseconds":855.942}	Scheduler Stopped -> Process never phoned home
113083	test_default_cluster_spinup_time-83d92c77	2022-11-17 00:48:45.173515+00	{"minutes":10,"seconds":36,"milliseconds":613.41}	Workers all had error -> Process never phoned home
113084	test_default_cluster_spinup_time-606dcfbc	2022-11-17 00:49:05.334872+00	{"minutes":10,"seconds":23,"milliseconds":461.523}	Scheduler Stopped -> Process never phoned home
113087	test_default_cluster_spinup_time-cb9bd55a	2022-11-17 00:51:38.292775+00	{"minutes":10,"seconds":19,"milliseconds":116.58}	Scheduler Stopped -> Process never phoned home
112882	test_default_cluster_spinup_time-8cebd667	2022-11-16 22:13:45.147772+00	{"minutes":21,"seconds":48,"milliseconds":313.03}	All instances stopped
114135	test_default_cluster_spinup_time-82ad517a	2022-11-18 18:07:28.182544+00	{"minutes":22,"seconds":7,"milliseconds":974.746}	All instances stopped

For example, this cluster was up for ~20 minutes so probably had idle timeout: https://cloud.coiled.io/dask-engineering/clusters/109757/details

Here are different test clusters that from what I see did nothing and got idle timeout:
121028	test_shuffle-7b8a5b1a	2022-12-01 22:40:43.151424+00	{"minutes":21,"seconds":40,"milliseconds":690.376}	All instances stopped
121025	test_futures-3783e012	2022-12-01 22:40:37.217465+00	{"minutes":21,"seconds":30,"milliseconds":604.092}	All instances stopped
121024	test_futures-3048a2cf	2022-12-01 22:40:26.837846+00	{"minutes":21,"seconds":41,"milliseconds":28.294}	All instances stopped
121023	test_futures-6ef73eef	2022-12-01 22:40:26.76738+00	{"minutes":21,"seconds":41,"milliseconds":123.947}	All instances stopped
121021	test_join-4b03394e	2022-12-01 22:40:20.114842+00	{"minutes":21,"seconds":30,"milliseconds":673.948}	All instances stopped
121019	test_shuffle-eb7178e8	2022-12-01 22:38:56.886475+00	{"minutes":21,"seconds":43,"milliseconds":810.413}	All instances stopped
121017	test_custom-ab39af6f	2022-12-01 22:38:43.31958+00	{"minutes":21,"seconds":48,"milliseconds":454.944}	All instances stopped
121016	test_csv-f20a6f86	2022-12-01 22:38:43.276364+00	{"minutes":21,"seconds":48,"milliseconds":523.522}	All instances stopped
121014	test_dataframe-ad3a30c4	2022-12-01 22:38:42.82349+00	{"minutes":21,"seconds":49,"milliseconds":26.782}	All instances stopped
121013	test_shuffle-8fd97395	2022-12-01 22:38:35.175994+00	{"minutes":21,"seconds":45,"milliseconds":528.141}	All instances stopped
121010	test_shuffle-62f72938	2022-12-01 22:38:19.315201+00	{"minutes":22,"seconds":1,"milliseconds":441.852}	All instances stopped
120992	test_shuffle-ad273ca3	2022-12-01 22:37:59.248902+00	{"minutes":22,"seconds":4,"milliseconds":641.336}	All instances stopped
120991	test_shuffle-857332f2	2022-12-01 22:37:58.204368+00	{"minutes":22,"seconds":5,"milliseconds":714.79}	All instances stopped
120977	test_csv-30ad9101	2022-12-01 22:37:52.933941+00	{"minutes":21,"seconds":49,"milliseconds":111.007}	All instances stopped
120976	test_dataframe-8219c181	2022-12-01 22:37:52.70418+00	{"minutes":22,"seconds":6,"milliseconds":71.806}	All instances stopped
120975	test_dataframe-64d1cea8	2022-12-01 22:37:52.686156+00	{"minutes":22,"seconds":5,"milliseconds":46.687}	All instances stopped
120972	test_custom-e3d12839	2022-12-01 22:37:52.039349+00	{"minutes":22,"seconds":6,"milliseconds":761.883}	All instances stopped
120971	test_custom-ded2de82	2022-12-01 22:37:52.01883+00	{"minutes":21,"seconds":50,"milliseconds":54.652}	All instances stopped
120970	test_csv-d72133b0	2022-12-01 22:37:51.014115+00	{"minutes":21,"seconds":51,"milliseconds":90.314}	All instances stopped
120969	test_shuffle-cfc157a2	2022-12-01 22:37:43.107083+00	{"minutes":21,"seconds":43,"milliseconds":546.317}	All instances stopped
120964	test_shuffle-63f55cf0	2022-12-01 22:37:36.839246+00	{"minutes":21,"seconds":38,"milliseconds":818.196}	All instances stopped
120962	test_shuffle-8abe8f00	2022-12-01 22:37:32.589235+00	{"minutes":21,"seconds":32,"milliseconds":23.267}	All instances stopped
119769	testing19712	2022-11-30 22:11:17.656741+00	{"minutes":22,"seconds":17,"milliseconds":59.082}	All instances stopped
119356	test-naty-2w-q4	2022-11-30 16:44:32.554919+00	{"minutes":23,"seconds":1,"milliseconds":766.76}	All instances stopped
119138	test_work_stealing-4145e2e8	2022-11-30 15:28:39.765247+00	{"minutes":21,"seconds":34,"milliseconds":683.075}	All instances stopped
119136	test_futures-f5f13eb2	2022-11-30 15:28:29.585383+00	{"minutes":21,"seconds":30,"milliseconds":850.959}	All instances stopped
119134	test_join-68f7501f	2022-11-30 15:28:27.430934+00	{"minutes":21,"seconds":37,"milliseconds":997.103}	All instances stopped
119131	test_futures-974d17a9	2022-11-30 15:27:53.851213+00	{"minutes":21,"seconds":34,"milliseconds":566.519}	All instances stopped
119130	test_join-0eec5748	2022-11-30 15:27:52.345579+00	{"minutes":21,"seconds":36,"milliseconds":95.528}	All instances stopped
119125	test_futures-c468fb12	2022-11-30 15:27:21.509733+00	{"minutes":21,"seconds":31,"milliseconds":834.211}	All instances stopped
119124	test_dataframe-74b80034	2022-11-30 15:27:17.921918+00	{"minutes":21,"seconds":31,"milliseconds":489.676}	All instances stopped

select id, name, created, updated - created cluster_lifetime, reason
from declarative_clustermodel
where
name like 'test_%' and name not like 'test_array%'
and created > now() - interval '1 month'
and updated - created > interval '20 minutes' and updated - created < interval '25 minutes'
order by id desc
limit 100

@jrbourbeau just checking, did you ever take a look at this or do you know where the issue might be coming from?
@ntabris how problematic is this? Is this something that should be prioritized?

how problematic is this? Is this something that should be prioritized?

not a huge deal, feels worth spending a little time looking into, but no idea what else is in the queue for y'all.
for reference, typical CI run costs ~$4:

run that left workers sitting around idle (GITHUB_RUN_ID<PHONE_NUMBER>) was ~$11:


README Example #4, Sending an Email: Not Captured by a Stream

I've created a node server that uses the EWS Streaming API, via this library, to track Created and Modified events in a user's inbox, sentitems, and calendar folders. I'm writing unit/integration tests and running into a snag. I send an email programmatically (using the example from the README) and then I make sure its creation in the sentitems folder is tracked/captured by the stream. Unfortunately, this email creation isn't reported by the stream, although it shows up in the sentitems folder in an email client. Strangely, once I manually send an email through the email client, the stream reports the prior emails I sent programmatically, along with the new one just sent manually. Any ideas on what's going on? Is there a bug in the example code?

Just for clarification, are you using the EWS Streaming or Push? We have an example of the Push listener but nothing for the EWS Streaming as that was breaking due to multiple envelopes being submitted from the server during the open streaming session (see #48). If you've got that working then I'd be curious how.
As for the EWS CreateItem not triggering an update, Node-EWS is just a wrapper for Node-SOAP which makes/receives SOAP messages with your EWS server. As such if you aren't seen a response from the server for the event then the problem is most likely on the server side or has something to do with the options in either the CreateItem or GetStreamingEvents requests.
I suggest you try using something like EWSEditor (https://ewseditor.codeplex.com/) to do some testing/debugging. With that you should be able use the "EWS Post" tool (under the "Tools" menu) to test out the raw SOAP calls and see the server responses. What I've done in the past is to open two instances of the "EWS Post" tool, initiate the streaming subscription request followed by the GetStreamingEvents (https://msdn.microsoft.com/en-us/library/office/gg236898(v=exchg.140).aspx) for all events in one instance to track the activity. (Note: After submitting the GetStreamingEvents call, you will need to wait the duration specified in the request before seeing all of the server responses in that window.) Then send the CreateItem call in the second instance and see what the server responds with. If the problem is duplicated outside of Node-EWS then it isn't a bug within Node-EWS but something to do with the EWS itself. But if the same SOAP requests work outside of Node-EWS then we can start to work the problem backwards from the server and figure out what's going on.
Hope this helps!

I'm using EWS Streaming. I thought #48 revolved around being able to access the streaming requests as they come in as opposed to accessing after the stream closes? I've gotten it to work through the GetStreamingEvents function. It throws an exception once the stream finishes, but I catch the exception and parse out the envelopes with the streamed notifications.
It might be an issue with the options in CreateItem, but I won't be able to know for sure until I test it with EWSEditor. I wasn't able to get it to run on my computer so I filed an issue on its repo. I can report more once I get it to work.
Thanks for the thorough response!

Very clever! Why hadn't I thought to try that? LoL! Though ultimately with #48 I'm wanting to set up a streaming service with the max 30 minute open session and capture and process the server responses in real time.

A compiled version of EWSEditor can be found here: https://ewseditor.codeplex.com/

Thanks for pointing me to the executable! I've tried using the EWS Editor to execute the flow of events that you outlined above. I can successfully initiate the streaming subscription to get a subscription ID, but whenever I try to make a GetStreamingEvents request it ends up failing and reporting an error (screenshot attached).

Any ideas why it might not be working? I've targeted Exchange 2010 SP1 and cloud-hosted Exchange on Office 365, but they both yield the same error.


Fix test calling directly _chkbx_changed

https://github.com/mne-tools/mne-qt-browser/pull/160 is changing the signature of this private method, thus this test is failing.

Closing for now, as this is not needed in the end.


switch tile

Hi,
I'm trying to use both SwitchTile and SwitchSliderTile.
But how do I detect the state of the switch button ?
I've tried using both :
switchTile.setOnSwitchPressed(e -> System.out.println(switchTile.getCurrentValue());
and
switchTile.setOnSwitchPressed(e -> System.out.println(switchTile.isActive());
to print out the state or the value of the toggle switch but nothing shows up in the stack trace.
My goal is that if I toggle off the switch in SwitchSliderTile,  the whole slider bar should have the value of zero.
Thanks for any insight and keep up the good work!
-mokun

You are right, it doesn't work anymore, will fix it. In the meantime you can simply listen for changes on the activeProperty() in your switchTile. This property will indicate the change, the following code works for me:
Tile switchTile = TileBuilder.create().skinType(SkinType.SWITCH)
                                             .prefSize(400, 400)
                                             .build();
switchTile.activeProperty().addListener(o -> System.out.println(switchTile.isActive()));

Fixed with commit: ecd9fb97e15327f2a20bd804dea4b8d6cbb4f087
Now the following code should work:
Tile switchTile = TileBuilder.create().skinType(SkinType.SWITCH_SLIDER)
                                      .prefSize(400, 400)
                                      .build();
switchTile.activeProperty().addListener(o -> System.out.println("Switch.isActive: " + switchTile.isActive()));

EventHandler<SwitchEvent> pressedHandler = e -> System.out.println("PRESSED: " + switchTile.isActive());
switchTile.setOnSwitchPressed(pressedHandler);

EventHandler<SwitchEvent> releasedHandler = e -> System.out.println("RELEASED: " + switchTile.isActive());
switchTile.setOnSwitchReleased(releasedHandler);


Abandoned library?

I see that no commits have been made over the past 6 months. Has the author abandoned the library? If so, I'm going to look into forking it, but wanted to ask first.

It's a very useful library, we can all help maintain it @egeersoz

has a fork been created ?

This issue is stale because it has been open for 60 days with no activity.

This issue was closed because it has been inactive for 7 days since being marked as stale.


feat: Stack

Feature Request
Describe the Feature Request
Implement a Stack data structure in Cairo 1.0

Describe Preferred Solution
The stack should be implemented through an array.
The stack should expose three "main" methods to the user : new, pop and push. On top of that, we can implement utility functions such as len, peek and is_empty.

Describe Alternatives

Related Code

struct Stack<T> {
    elements: Array::<T>,
}

trait StackTrait<T> {
    fn new() -> Stack::<T>;
    fn push(ref self: Stack::<T>, value: T);
    fn pop(ref self: Stack::<T>) -> Option::<T>;
    fn peek(ref self: Stack::<T>) -> Option::<T>;
    fn len(ref self: Stack::<T>) -> usize;
    fn is_empty(ref self: Stack::<T>) -> bool;
}

Additional Context
While the Stack implementation seems pretty trivial, I have given a try at it and encountered two major issues that should be solved with the next release of Cairo 1.

Variable was previously moved
Here's a snippet of code illustrating the problem

// Variable was previously moved
fn peek(ref self: Stack::<T>) -> Option::<T> {
        let mut elements = self.elements;
        let mut last_index = elements.len() - 1_usize;
        let last = elements.get(last_index);
        self = Stack { elements };
        last
}

Hypothesis: the borrow checker complains here because I took ownership of self in the operation elements.len() - 1_usize. Therefore, I can't reuse it later in the code. This would require generic type T to implement the Dup trait (explanation from @spapinistarkware) which is a feature that will soon be implemented.

Variable not dropped.
A variable that is declared and not returned at the end of a function generates the error Variable not dropped. I guess the comment above for the Dup trait stands for the Drop trait as well.

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

[x] Yes
[ ] No

Implementating a stack using an Array is impossible, so good thing the compiler stopped you:)
We can only append to the end of the array, or pop from the front. So a queue is ok, a stack isn't. This has to do with Cairo's immutable memory model.
A stack could be implemented on top of a dictionary though

And yes, something like peek would require Dup or snapshots (an upcoming feature), so I'll probably add a message here when it's done

We can only append to the end of the array, or pop from the front

I was thinking about duplicating the array in another memory segment without its last element

Yeah, that could work. It would restrict you to use inly Dup T's, while the dict impl doesn't, but peek would give you a snapshot (similar to rust reference).
I think dict makes more sense

@msaug @spapinistarkware  I just opened a PR of the Dict implementation of  Stack(still need to fix some compilation errors, which wasnt present when I was trying in another repo).
But I as its still WIP, I wanted to make 2 questions around Cairo V1:

In Cairo V1 do we still need the "start_word_dict"?
https://github.com/danilowhk/quaireaux/blob/37580e6291ee267eb8d7fb40e303f9b27521db45/src/data_structures/stack.cairo#L26

In CairoV1 , lets say we use uint256 or any other struct(that uses more than 1 felt) as "value". In this case, when "updating len" do we have to go up by 2(in case of uin256) and N(in case of another struct that needs N felts in memory)? Or is this part abstracted and we just up 1 by 1?

https://github.com/danilowhk/quaireaux/blob/37580e6291ee267eb8d7fb40e303f9b27521db45/src/data_structures/stack.cairo#L59
These are the 2 questions that came to mind when trying to implement Stack in Dict. Also please let me know if there is any part of the code that could be done more efficiently, as I believe we are aiming for the most "efficient" code for
quaireaux I guess.

@msaug for reference implementation in cairo 0.x using dicts, see https://github.com/sayajin-labs/kakarot/blob/main/src/kakarot/stack.cairo

@danilowhk regarding 1. I believe we don't need to keep track of start_dict and end_dict in Cairo 1, the dictionary can be created and modified like this:
    let mut d = DictFeltToTrait::new();
    d.insert('First', 1);
    let a = d.get('First');
    d.squash();

For 2. since we're indexing a dictionary by felt we just need to increment/decrement length by one


Strong typing

Fixes #4
This is a rewrite of the library to provide strong types.
r? @Ralith

@msiglreith please have a look at the new rotation types.
After a bit of investigation, I agree that the choice if cgmath-rs in unconventional, and I believe mint should strike for established conventions instead (both of them...).

Looks nice! 👍
As the library is focused on compute graphics I wondering which coordinate system to apply. Most applications probably will focus on realtime rendering, where usually Y is specified as the up direction in contrast to Z.


<EMAIL_ADDRESS>

@devmotion any idea whether there's anything in particular that needs to change in order to upgrade this package to the latest version of Makie?

I don't know what the breaking changes are. Seems Github disabled Compathelper, I'll run it manually and then we'll see if anything has to be fixed.

What went wrong in #35 that meant it neeed reverting? Tests seem to pass when I run locally.

The main and in fact only way to inspect if everything works is building the documentation. But in the PR it was not built with Makie 0.16 (and there was no version bump), so it was not clear if everything works as desired. I'll open a new PR with an updated Manifest when I'm back at my computer later this afternoon.


v2: Change license to MIT

For v2, switch to the MIT license.
CC-BY is currently recommending against using it for software projects.
See #28

Done


Change Object to has byte[] with(Objects... objects) method instead of extends Bytes

Let's change Object to has byte[] with(Objects... objects) method instead of extends Bytes. This change will change all API.

Closed by 31dc531.


Replace deprecated .Page.UniqueID variable

Fix #76.
As stated in https://github.com/hugo-apero/hugo-apero/issues/76#issuecomment-1059045295, the syntax of getting ID of a page changes from Page.UniqueID to Page.File.UniqueID after Hugo v0.69 (https://github.com/gohugoio/hugo/commit/89044b8f8795f17c36396c67823183a20fc88139).

Thank you so much!!


Changeover dates

Is your feature request related to a problem? Please describe.
To be able to use Litepicker for the booking of apartments, I would like to request to add "changeover" dates to the calendar. The changeover days allow the user to select only specific dates for check-in or check-out.
I'm currently using the options "lockDays" and "disallowLockDaysInRange" to prevent any collisions with bookings so I can't use this to lock certain days for the user to select.
Changeover days should be locked for selecting but could be in a certain daterange.
Describe the solution you'd like
I would like to have a similar solution to the "lockDays", just a second alternative I can use without the "disallowLocakDaysInRange".
Describe alternatives you've considered
At the moment I'm highlighting the changeover days so users know what days they can select. Validation is done after the users submits a request. I would like to let the user know before the submit a request.
Additional context
There's a jsfiddle for the example with highlighted changeover days;
https://jsfiddle.net/mga5d2yL/
P.s. I've read the following issue; https://github.com/wakirin/Litepicker/issues/173 but I didn't want to contaminate the issue.
If there's anything I can do to help, let me know.
With best regards,
Kevin

I see your example is using v1.4.7
In v2 I added new option lockDaysFilter.
You can do something like that:  https://jsfiddle.net/1o0c6gkp/

Sorry for the late response but thank you very much!


Add p4perf4ce.me to webring index

Sawasdee krub.
Webring icon is located at the footer of the page krub.
Icon (Desktop)

Icon (Mobile)

Thank you very much.

@p4perf4ce
Thanks, and welcome to the webring!


glfwGetProcAddress is not ABI-compatible with wglGetProcAddress

Problem
WGL defines wglGetProcAddress to be WINAPI, i.e. __stdcall, and return PROC, i.e. intptr_t (__stdcall *)(void). GLFW defines glfwGetProcAddress to be a plain C function and return GLFWglproc, i.e. void (*)(void).
#define WINAPI __stdcall /* minwindef.h */
typedef INT_PTR (WINAPI *PROC)(void); /* minwindef.h */
PROC WINAPI wglGetProcAddress(LPCSTR lpszProc); /* GL/wgl.h */
#define GLFWAPI __declspec(dllimport) /* GLFW/glfw3.h */
typedef void (*GLFWglproc)(void); /* GLFW/glfw3.h */
GLFWAPI GLFWglproc glfwGetProcAddress(const char* procname); /* GLFW/glfw3.h */

This makes it impossible to have a loader API to set a GetProcAddress function for the platform that can accept both &wglGetProcAddress and &glfwGetProcAddress, with or without a cast.
Discussion
The return type mismatch is not pretty, but probably not serious; why in the world does Windows define PROC to have an intptr_t return type, I have no idea. The only reason I mention it is because I think it would be cleaner and more logical for GLFWglproc to be APIENTRY, but this would be an API break.
The calling convention incompatibility is a real problem and, on the surface, appears to require an ABI break to fix it. But (call me mad, but) it actually does not. The thing is, __stdcall and __cdecl function names are mangled differently: an __stdcall function has @N appended to the end of its name, where N is the combined size of the argument in bytes, while a __cdecl function does not. Thus it is perfectly possible for a GLFW build to define both versions of glfwGetProcAddress, and the client code will pick up the one with the calling convention it saw the declaration for. Switching the GLFW headers to the __stdcall version by default would still be an API break.
While I believe it would be cleaner for glfwGetProcAddress to be APIENTRY by default, there does exist client code that depends on it not being so, gladLoadGLLoader in @dav1dde’s glad being one unfortunate example (supposedly noöne ever tried to pass wglGetProcAddress to it?). Still, providing an APIENTRY version behind a #define in 3.x would be an option.
Obviously the client code can always define its own  APIENTRY version that calls the C one, but I think this is a GLFW wart that should be fixed in GLFW.

An additional data point is that SDL’s SDL_GL_GetProcAddress is also not __stdcall by default: in theory it is SDLCALL, but that means the default C convention everywhere except (for some reason) on OS/2 (where it means _System, a close relative of __cdecl). I don’t know whether to take it to mean that GLFW is right and I am wrong or that SDL is also wrong and I am still right.
SDL_GL_GetProcAddress also returns void *, even though C does not guarantee that function pointers are able to be cast to data pointers and back losslessly, but then so does POSIX dlsym(3) (and thus requires that they be). That, strictly speaking, still does not mean that a void *(*)(const char *) function pointer (like &SDL_GL_GetProcAddress) is compatible with a void (*(*)(const char *))(void) function pointer (like &glfwGetProcAddress), but I think that this is true on all platforms that SDL actually runs on.

An additional data point is that SDL’s SDL_GL_GetProcAddress is also not __stdcall by default: in theory it is SDLCALL, but that means the default C convention everywhere except (for some reason) on OS/2 (where it means _System, a close relative of __cdecl). I don’t know whether to take it to mean that GLFW is right and I am wrong or that SDL is also wrong and I am still right.
SDL_GL_GetProcAddress also returns void *, even though C does not guarantee that function pointers are able to be cast to data pointers and back losslessly, but then so does POSIX dlsym(3) (and thus requires that they be). That, strictly speaking, still does not mean that a void *(*)(const char *) function pointer (like &SDL_GL_GetProcAddress) is compatible with a void (*(*)(const char *))(void) function pointer (like &glfwGetProcAddress), but I think that this is true on all platforms that SDL actually runs on.


Add support for the python formatter ruff

Thanks! LGTM.
Please add ruff (with a link to its home page) to README.md as well.

Would you like me to squash into one commit?

Aside: Just for my own education do you happen to know what the "-" argument represents? I included it as the last argument because I've seen it here and elsewhere (e.g. The docstring for python-flymake-command when it  describes how to use flake8 instead of pyflakes though it this case these are linters and not formatters but I think the argument is serving the same purpose) but I'm not entirely sure what is for and if it is necessary in all cases.

Thanks!

Would you like me to squash into one commit?

No need. I can do a "squash and merge" from GitHub's UI.

Just for my own education do you happen to know what the "-" argument represents?

When - is used instead of a filename, it generally means the program should read from standard input, or write to standard output, instead of using an input or output file. This convention is very common among all kinds of Unix programs.

The docstring for python-flymake-command when it describes how to use flake8 instead of pyflakes though it this case these are linters and not formatters but I think the argument is serving the same purpose)

It almost certainly has the same purpose, yes.

When - is used instead of a filename, it generally means the program should read from standard input, or write to standard output, instead of using an input or output file. This convention is very common among all kinds of Unix programs.

I see. Thanks for taking the time to explain. Perhaps then it or --stdin-filename=stdin is unnecessary then in that case.

Removing the "-" and it still works but it seems --stdin-filename=stdin is necessary and the value must be stdin.

Removing the "-" and it still works

That makes sense. It often works.

but it seems --stdin-filename=stdin is necessary and the value must be stdin.

That's weird. The value of --stdin-filename shouldn't matter.


Starhawking python version check

Adding a python version check to use  ssl._create_unverified_context() for an insecure connection as per https://docs.python.org/2/library/httplib.html

Fixed in separate commit to maintain PEP8 compliance


Initial Commit for CRC32_vpmsum integration and WeakHash Failure

Changelog category (leave one):

Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
fixing Weakhash unit. test failure on POWER

Information about CI checks: https://clickhouse.com/docs/en/development/continuous-integration/

I've merged this one into https://github.com/ClibMouse/ClickHouse/pull/118, so we can close this.


Implement TorCtrl

Closes #348
This is a partial implementation. Some TorCmd still need to be finalized. It is enough to get moving along with building out TorRuntime

Node.js is a nightmare.... hopefully this is the final issue as it relates to Windows Node.js issues.

Last try. Will disable JS for windows CI and add an issue ticket to fix later if this does not resolve it here


disable autoscroll

This PR automatically disables autoscrolling if physics are NeverScrollableScrollPhysics. It also allows the developer to override this automatic behavior using the autoScroll argument on ReorderableGrid, SliverReorderableGrid, and ReorderableGridView
Issues
Resolves https://github.com/casvanluijtelaar/reorderable_grid/issues/10
Code
return ReorderableGrid(
  gridDelegate: SliverGridDelegateWithFixedCrossAxisCount(
    crossAxisCount: widget.layout.crossAxisCount,
    childAspectRatio: widget.layout.childAspect,
    mainAxisSpacing: widget.layout.gap,
    crossAxisSpacing: widget.layout.gap,
  ),
  itemCount: 9,
  physics: const NeverScrollableScrollPhysics(), ///////////////////////
  itemBuilder: (context, i) {
    return ReorderableGridDragStartListener(
      key: ValueKey(i),
      index: i,
      child: Container(
        color: Colors.red,
        child: Text(i.toString()),
      ),
    );
  },
  onReorder: (i, j) {
    print('from $i to $j');
  },
);

Before
https://user-images.githubusercontent.com/666539/172380122-a644ae1d-fda1-426f-8040-5c8e7a591591.mov
After
https://user-images.githubusercontent.com/666539/172380210-e59b1d5b-7c03-4c71-9639-b2b396e6a97b.mov

is there a thought process why autoScroll wasn't added to all gridview constructors?

I intended to, which did I miss? (There was a follow up commit to try to capture them all)


Support for scheduling containers with multi AZ High Availability

I have 6 instances running on AWS with 2 instances on each availability zone, so I have 6 hosts in my rancher Dashboard, with labels:
az:us-west-2a(key:value) - 2 instances
az:us-west-ab(key:value) - 2 instances
az:us-west-2c(key:value) - 2 instances
My use case is, I am running a service with 3 containers and I want to schedule it in such a way that at least one container should run on each availability zone i.e.
one container should run on one of the instance having label az:us-west-2a(key:value)
one container should run on one of the instance having label az:us-west-2b(key:value)
one container should run on one of the instance having label az:us-west-2c(key:value)

As discussed in the forums, this is an enhancement request to our scheduler.
https://forums.rancher.com/t/how-to-schedule-containers-with-multi-az-high-availability/2670

+1 This would be of great value in a hybrid environment as well.

I went to the rancher forums to ask this specific question and found that a multi AZ approach wasn't yet feasible. Unfortunately, being able to do this is such a critical requirement for us, that it's absence may end up being a deal breaker. Is there any workaround? Even a manual one we can implement until such time as an automated approach is feasible?

Maybe you could create an environment for each az?  We at least did that for our two private data centers.

You could create host labels that describe availablity zones, for example AZ=west-1 AZ=west-2 etc. At some point in the future, Rancher could then provide AZ info as an automatically applied host label.
Then use scheduling labels to distribute the containers as you see fit. This is a hack, but a good step towards realizing a reusable pattern...

Or maybe you can have one container on each i srance set up till the time we have this resolved by rancher. I know its not ideal, but only possible solution as of now which i can think of.

+1

Ya, if we have such mechanism in place it would be of great value.

maybe this will help: https://github.com/rancher/rancher/issues/7253

Using #7253 to track this as we are looking to implement this soon.