build runner does not generate .g file , but .drift.dart

Describe the bug
It was fine in few weeks ago, I have tried different Drift versions and also earlier versions of my database, no idea where is going wrong

If you want drift to emit a .g.dart file only, you can change the build.yaml to:
targets:
  $default:
    builders:
      drift_dev:
        options:
          skip_verification_code:true

You can remove the other targets and the custom definition. But note that you won't be able to use drift-generated classes as inputs to other builders (like built_value) in that case - I guess that's where your build config originally came from?
Drift will emit a .g.dart file by default, so you can revert the complex build config if that's the behavior you want.

 That will only work with drift generating separate files, so you'd have to change part statements to reference the .drift.dart files. If you don't need that, reverting the build config will make drift emit .g.dart files again.


[SDK Automation] Support generated SDK artifacts downloading in spec PR pipeline

Context
Based on the spring grove requirement, we disabled the SDK artifact downloading feature in the spec PR pipeline because it uses SAS token to download the artifacts from Azure blob.
There are still several service teams reached out us to download the generated SDK packages. They will need the SDK for Azure CLI development purpose.
Proposal
We will publish the generated SDK packages to the Azure DevOps pipeline run, and the user can browse to the corresponding pipeline run to download the SDK. In order to download the SDK, the user will need the Azure-Sdk ADO permission.

This task is completed. Refer to the document aka.ms/azsdk/sdk-automation-faq

would it be worth to move this documentation to the wiki of the repo for people to find it more easily? https://github.com/Azure/azure-rest-api-specs/wiki/About-the-Wiki
it might be good too, to add why people will want to download the artifact and what to do with it


Add Terraform setup to setup all the resources before hand and look up those resources when running tests

Description of the issue
Instead of setup all the resources during running which can cause some drawbacks:

Increase time for setup all those resources (e.g in EKS, create EKS cluster would take more than 30 minutes)
Create resources that terraform cannot destroy which cause unnecessary resources (e.g Security Group)
Share the common resources between tests (e.g IAM, SG, etc)

Description of changes

Add a common module to share all the constant variables
Add a setup module to create all the modules beforehand
Add init environment setup for nvidia
Separate ECS Fargate and ECS EC2

Note

Next step is create a PR to adhere the changes  and also run the setup once for the integration test open source account to setup all the required resources

License
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Tests
By apply this changes, I have run this on my fork
https://github.com/khanhntd/amazon-cloudwatch-agent/actions/runs/3814070927/jobs/6488169319

Is there a change needed to the integration test yaml

Is there a change needed to the integration test yaml

Yes I have stated this in the PR: Next step is create a PR to adhere the changes and also run the setup once for the integration test open source account to setup all the required resources


Multiple threads on different TPU cores

Hi Jax team!
I am trying to utilize multiple threads running on different TPU cores to scale up computation.
The code below can be run on TPUv3-8, by python run.py --num_worker x (x being the number of worker threads, each placed on one core).
The observation is quite counter-intuitive: with more workers, the total execution time is larger.

x
time (s)

1
2.67

2
3.89

3
4.88

4
5.94

Then I looked at the trace and confirmed the computation on different cores isn't really parallelized:

Such behavior was also discussed in #8281, except that in the discussion asynchronous dispatch was the topic. I feel that they might be related to the same issue under the hood?
import functools
import queue
import threading
import time

import haiku as hk
import jax
import jax.numpy as jnp
import numpy as np
from absl import app, flags

_NUM_WORKER = flags.DEFINE_integer('num_worker', 1,
                                   'The number of concurrent workers.')

DATA_SHAPE = [32, 128]

class Net(hk.Module):
    def __init__(self, name=None):
        super().__init__(name=name)

    def __call__(self, x):
        j, z = x.shape[-1], 1000
        w_init = hk.initializers.TruncatedNormal(1. / np.sqrt(j))
        w1 = hk.get_parameter("w1", shape=[j, z], dtype=x.dtype, init=w_init)
        b1 = hk.get_parameter("b1", shape=[z], dtype=x.dtype, init=jnp.zeros)
        wi = hk.get_parameter("wi", shape=[z, z], dtype=x.dtype, init=w_init)
        bi = hk.get_parameter("bi", shape=[z], dtype=x.dtype, init=jnp.zeros)
        a = jnp.dot(x, w1) + b1
        for _ in range(16):  # make the computation heavier
            a = jnp.dot(a, wi) + bi
        return jnp.mean(a)

def forward_fn(x):
    model = Net()
    return model(x)

class Worker:
    def __init__(self, input_queue: queue.SimpleQueue,
                 output_queue: queue.SimpleQueue) -> None:
        self._net = hk.transform(forward_fn)
        self._input_queue = input_queue
        self._output_queue = output_queue
        self._devices = jax.devices()
        self._x = jnp.ones(DATA_SHAPE)
        self._params = self._net.init(jax.random.PRNGKey(42), self._x)
        self._stop = False

    @functools.partial(jax.jit, static_argnums=0)
    def forward(self, params, data):
        return self._net.apply(params, None, data)

    def communicate(self, rank):
        local_device = self._devices[rank % len(self._devices)]
        local_params = jax.device_put(self._params, local_device)
        local_on_device_buffer = jax.device_put(
            jnp.zeros(self._x.shape, dtype=jnp.float32), local_device)

        print(f"Using local device {local_device}")
        while not self._stop:
            try:
                data = self._input_queue.get(timeout=0.1)
                local_on_device_buffer = jax.lax.dynamic_update_slice(
                    local_on_device_buffer, data, (0, 0))
                res = self.forward(local_params, local_on_device_buffer)
                res = jax.device_get(res)
                self._output_queue.put(res)
            except queue.Empty:
                continue

    def run(self, num=1):
        for i in range(num):
            t = threading.Thread(target=self.communicate, args=(i, ))
            t.start()

    def stop(self):
        self._stop = True

def main(argv):
    in_q = queue.SimpleQueue()
    out_q = queue.SimpleQueue()
    w = Worker(in_q, out_q)
    w.run(_NUM_WORKER.value)
    time.sleep(2)
    jax.profiler.start_trace("mt_on_slice_profile")
    start = time.perf_counter()
    for i in range(500):
        data = np.ones(DATA_SHAPE, dtype=np.float32)
        in_q.put(data)
        _ = out_q.get()
        if i == 200:
            jax.profiler.stop_trace()
    print(f"time elapsed = {time.perf_counter() - start}")
    w.stop()

if __name__ == "__main__":
    app.run(main)

Hi @zhangqiaorjc , sorry to bother, just wonder is there any updates on this issue? Still I couldn't figure out why two threads cannot utilize two separate cores in parallel..

sorry for the delay, so res = jax.device_get(res) will block the caller, I would if you could do that after you pull it out of the queue;

res = self.forward gives you a buffer future
put that future directly into the queue without device_get which blocks caller
r = out_q.get(); if you need the value, device_get after you pop it from the queue

@lkevinzc could you try this change?

Thanks @zhangqiaorjc for your advice!
Changes applied as shown below:

The time taken:

setting
elapse

a) 1 thread
2.64

b) 2 thread
3.62

c) 2 thread with device_get after popping from the queue
3.79

d) 2 thread without device_get
3.10

I feel the two threads are still blocking each other, even if we do not get the result from the device?
Looking forward to your suggestions! Thanks a lot!


cf deployment fails with bosh v266.2.0 and use-external-dbs.yml

Summary
Job locket in instance group diego-api specifies consumers in this ops file but the locket job does not define any consumers in the release spec.
Expected Result
Deploy cf succeeds.
Actual Result
Deploy cf fails.
Context
Bosh v266.2.0 is deploying cf including diego-release v2.8.0.
Tested on AWS, but should be relevant to all infrastructures.
Steps to Reproduce
Bosh v266.2.0 deploys cf using the diego-release v2.8.0 and cf-deployment/operations/use-external-dbs.yml.
Possible Causes or Fixes (optional)
Consume section (see https://bosh.io/docs/links/) of the locket job spec is missing.
Additional Text Output or Screenshots (optional)
Bosh task output when deploying cf:
Task 27611 | 09:27:10 | Preparing deployment: Preparing deployment (00:00:03)
                     L Error: Job 'locket' in instance group 'diego-api' specifies consumers in the manifest but the job does not define any consumers in the release specUpdating deployment:
  Expected task '27611' to succeed but state is 'error'
Exit code 1

Hi, @ansd,
Thanks for pointing out this issue. It is already resolved via https://github.com/cloudfoundry/cf-deployment/pull/525, which should be in the next final version of cf-deployment.
Best,
Eric, CF Diego PM


Add warning in case using Undeclared Variables

This rule can help to locate potential ReferenceErrors resulting from misspellings of variable and parameter names. See more about no-undef rule

Lot of eslint errors appears after these changes:
'require' is not defined
'module' is not defined
To solve it you must make changes:
Global config: .eslintrc
{
  "extends": "eslint-config-opuscapita",
  "env": {
    "node": true
  }
}

Or you can add to specific file:
/*eslint-env node*/


Run field validation without updating flags

Description:
It will be great if we could get the validation result, without flagging the fields as invalid.
This is necessary for a UX where the Form's Save/Send button is disabled until the form becomes valid. However, I do not want to mark any inputs that the user has not yet focused as invalid, thus cannot use validate/validateAll.
My current implementation of the computed property for the save button is iterating over the this.$validator.fields.items and using the private method this.$validator._validate to check if any field is invalid without triggering any field flag updates.

You could trigger validation on change or blur instead, wouldn't that be appropriate for your use case?
Or are you talking about the silent validation that is run always when the field is attached? so valid/invalid flags are always set.

The change and blur only occur when the user focuses an input then type in it or directly focus other input.
I will try to better explain my case:
[1---------]
[2---------]
[3---------]
(Save)
The 3 inputs do not have an initial validation, so no red markers around the fields.
When the user focuses field1 and triggers the change or blur event the red markers and hints are shown to field1 and not on the other fields.
When the user has entered a valid text to field1 and goes to field2, there will be no red markers shown until a field2's change or blur event occurs. (field3 remains without red markers)
All this works fine with vee-validate, until the (Save) button.
The (Save) button is disabled initially and will become enabled after all 3 field's validations are valid.
This is why the (Save) button needs a silent way to verify whether the 3 fields have passed their validations, without marking any field as invalid.

I see, I guess this is a valid enhancement. But I can't think of anything viable for an API. Feel free to suggest how you would like to use such a feature and I will see what can I do.
I think you can achieve what you need by taking the validated flag into account, since its only set once the input has been validated by user interaction. Again feel free to suggest any improvements.

The validated flag won't work in the scenario where the field is not required but has validation. Then it may be not be validated yet, but the (Save) should be enabled as it is not required.
As for an API here is a sample PR: https://github.com/baianat/vee-validate/pull/1245
You would need to call validateAll(null, null, true) in order to run silent validation for all fields. It will be better if there is a support for arguments to be passed as an object, what do you think?

Sure, but that will be a breaking change, for now, I will accept this PR since it wouldn't break anything.


Roadmap/Priorities

This is an issue to get suggestions to update the Servo roadmap and identify the main priorities for the project in the coming months. Please share your ideas and then we could review and decide the final list in order to update the roadmap page on the Servo wiki.
There might be many different angles and people can have different priorities. One important aspect to decide what we can work on is to clarify what people commit to work on, as it doesn't make sense if we pick topics/ideas that nobody is going to be working on.
We could try to organize things per areas, though it might be a bit tricky as we could think in many different options: WPT pass-rate, popular websites, popular frameworks, missing HTML&CSS features, performance, embedding API, binary size, modularity, tooling, etc.
So initially let's collect ideas here, and after a couple of weeks we can try to identify the main ones, select a few and update our roadmap for 2025.
Proposals format:

Topic: XXX
Area: (if you can identify it somehow)
Description: (1-2 sentences description if needed)
Commitment: (if you have plans to work on that in the coming months)

Topic: Improving the Embedding API
Area: N/A?
Description: There's already been some renewed talk about it in Zulip, but in general making the process of actually embedding Servo clearer and more well documented could be helpful in getting more people interested in using Servo.
Commitment: I started working on my own (currently) toy browser Moto recently and already have identified some areas that could be improved for the embedder, which I'd be happy to keep exploring.

Topic: Implementing the Media Source API
Area: DOM/Media
Description: The Media Source API is used in most major video streaming sites, including YouTube. Right now I believe Servo's video playback is limited to contexts where the entire video file is downloaded at once. I think that getting this working would help expand potential use cases for Servo, particularly for embedders that want to be able to interact with streaming video. It would also make for some nice press (worth noting Ladybird also does not support this API yet) and could help stir up more interest in the project.
Commitment: I do have a personal interest in seeing this come to fruition, but given the complexity of the API and my lack of experience with GStreamer I don't know if I'd be up to the task on my own without serious time investment.

Topic: Layout performance
Area: Performance
Description: The new layout engine hasn't been optimized in most cases, it'd be useful to investigate performance and check if we can implement optimizations. One key feature that we're missing is usually known as incremental layout, that prevents having to relayout the whole website when there are changes in a particular part of it; this is a very important feature if we want to have a proper comparison with other engines after the initial layout.
Commitment: Igalia has plans to work on this feature in 2025.

Topic: Supported embedding exemplar projects
Area: Embedding
Description: we should choose 2-3 use cases for embedding Servo beyond a general purpose browser. Once these are selected, we can build representative examples of these use cases, which will help focus our API design and make Servo a more attractive option for Rust projects that match them.
Commitment*: I would be interested in building the examples once we have identified we the use cases.

Topic: Interactivity
Area: Layout
Description: There are many things that are still missing int he new layout engine in Servo, one of them are some things like editing a text input (you can do it know but there's no caret or anything), editing more complex form fields, being able to interact properly with a form, selection, etc. Some of these things might be too big or complex, but in general it seems worth to improve the current status of affairs in this area to make Servo more usable.
Commitment: Igalia is interested on working on this feature in 2025, but we don't know yet if we'll have availability to do this kind of work.

Topic: Implement Shadow DOM
Area: DOM/Layout
Description: One of the most common errors when browsing real world sites/web apps is that attatchShadow is not implemented. This will help close the gap in expected web compatibility when testing Servo against existing web content.
Commitment: I would like to break down the work into tasks that can be implemented by other people.

Topic: Improve CI (build/lint/test) times
Area: Infrastructure
Description: CI iterations times affect and slow down everyone working on Servo. This may be particular painful for new contributors who are not used to waiting 1 hour for CI checks, but also affects the productivity of regular contributors.
Commitment: I am able to work on some of these tasks which can be done purely in the repository, but others which require access to things like Github settings or build infrastructure would require someone with access to those things to work on them.

See also: https://servo.zulipchat.com/#narrow/channel/263398-general/topic/CI.20performance

Topic: Onboarding new contributors and maintainers
Area: Governance / Outreach
Description: Servo currently struggles to maintain the amount of code it owns with the number of contributors/maintainers that it has. I therefore think it ought to be an explicit priority to onboard new contributors, with an emphasis on onboarding senior contributors with Rust and/or browser development experience where possible. And additionally to uplift (new or existing) contributors to maintainer status where they (collectively) have the ability to independently review/approve/publish code in their area.
Commitment: I am willing to work on this. I could make posts for the Servo blog, Reddit, etc advertising that Servo is actively seeking contributors. However, it is important that any new arrivals have a good experience: questions are answered, their contribution is actively encouraged and supported, their code is reviewed in a timely manner, etc. And I feel like this will require a wider commitment from existing Servo community members.

Topic: CSS Grid support
Area: Layout
Description: CSS Grid is an important modern layout method which Servo should support.
Commitment: I already have an active PR open for basic support. I intend to commit more time to WPT test score improvements once that lands.

Topic: Layout performance
One key feature that we're missing is usually known as incremental layout, that prevents having to relayout the whole website when there are changes in a particular part of it; this is a very important feature if we want to have a proper comparison with other engines after the initial layout.

I would add that for Flexbox/CSS Grid this is important for performance even within a single frame, as these algorithms are exponential with respect to the depth of the tree. I believe Servo has some basic caching support now. But it should be tested as layout can easily end 100x or 1000x too slow if it isn't working properly.

Topic: Interactivity
There are many things that are still missing int he new layout engine in Servo, one of them are some things like editing a text input (you can do it know but there's no caret or anything), editing more complex form fields, being able to interact properly with a form, selection, etc

I definitely agree that text inputs in particular are one of the most conspicuous weaknesses of Servo atm (if I try to use it for "real world" browsing tasks such as performing a search (google, wikipedia, etc) or using Reddit / Hacker News). I think we ought to consider using a 3rd-party library such as parley for text input. They have a lot of the hard bits (selection, and soon IME) figured out, and it would allow Servo to share code with the wider Rust ecosystem going forwards.

After the discussion the Roadmap has been updated at: https://github.com/servo/servo/wiki/Roadmap
We have left a couple of tasks identified as things for the future as we didn't have people available to work on them.
I'll close this issue but for future updates of the roadmap people can use https://github.com/servo/project/issues/114


Pull points from Core using .soqlpack when possible

Informal tests show .soqlpack-based requests from Core use less than 1/10th the memory of .geojson requests and are 2-3x faster.
Tests don't pass yet
.soqlpack only used when only the point column is selected;  $select=xxx results in .geojson being used as a fallback

tileserver #125 FAILURE
Looks like there's a problem with this pull request

tileserver #126 FAILURE
Looks like there's a problem with this pull request

tileserver #128 FAILURE
Looks like there's a problem with this pull request

tileserver #129 SUCCESS
This pull request looks good

tileserver #131 SUCCESS
This pull request looks good

tileserver #132 SUCCESS
This pull request looks good

LGTM up to e90d041

tileserver #134 SUCCESS
This pull request looks good

tileserver #135 SUCCESS
This pull request looks good

Merging now, Kaida and I have been pairing on this.


[Bug] [Action] --catalog_conf is invalid in CompactAction

Search before asking

[X] I searched in the issues and found nothing similar.

Paimon version
0.7.0
Compute Engine
flink
Minimal reproduce step
run compact action use args compact --warehouse s3://paimon/ --database default--table T --catalog_conf s3.endpoint=http://<IP_ADDRESS>:32308 --catalog_conf s3.access-key=BNA9YT5dm2asa2MRFfnc --catalog_conf s3.secret-key=g0AWWthulyMA3qsnwFypNB01iq1wtiQe74vmKxEv
What doesn't meet your expectations?
--catalog_conf
Anything else?
The document uses --catalog_conf to specify parameters, and the code uses catalog-conf to cause --catalog_conf to not take effect

Are you willing to submit a PR?

[X] I'm willing to submit a PR!

It has been fixed, the code is not updated


Fix bound range in dynamicuniformbuffer sample

Untested fix for #872 -- I only checked the code builds.

Confirmed this fixes the validation layer error and rendering output looks good. Tested using Vulkan SDK <IP_ADDRESS> and VK_LAYER_KHRONOS_validation only.

Thanks for your PR. Very much appreciated.


[SPARK-22895] [SQL] Push down the deterministic predicates that are after the first non-deterministic

What changes were proposed in this pull request?
Currently, we do not guarantee an order evaluation of conjuncts in either Filter or Join operator. This is also true to the mainstream RDBMS vendors like DB2 and MS SQL Server. Thus, we should also push down the deterministic predicates that are after the first non-deterministic, if possible.
How was this patch tested?
Updated the existing test cases.

Test build #85355 has started for PR 20069 at commit ad6607c.

Test build #85355 has finished for PR 20069 at commit ad6607c.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

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/85355/
Test FAILed.

retest this please

Test build #85356 has started for PR 20069 at commit ad6607c.

Test build #85356 has finished for PR 20069 at commit ad6607c.

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

Merged build finished. Test PASSed.

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

Test build #85508 has started for PR 20069 at commit ac8a801.

Test build #85508 has finished for PR 20069 at commit ac8a801.

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

Merged build finished. Test PASSed.

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

cc @cloud-fan @rxin @sameeragarwal @gengliangwang @jiangxb1987 @marmbrus

Test build #85550 has started for PR 20069 at commit fdef44a.

Test build #85550 has finished for PR 20069 at commit fdef44a.

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

Merged build finished. Test PASSed.

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

Thanks! Merged to master.


No intellisense on OSX

Hi!
I'm facing trouble after mono reinstallation on OSX 10.11.5, intellisense just stopped to work after mono update. Ionide-sharp version is 1.7.0, vscode version is 1.1.1
Mono & fsharpi are in path:
Daniils-iMac:~ danslapman$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
Daniils-iMac:~ danslapman$ which fsharpi
/usr/local/bin/fsharpi
Daniils-iMac:~ danslapman$ which mono
/usr/local/bin/mono
I also tried to reinstall both the extension in vscode two times, it didn't help.
How to figure out the root of the issue?

Should be fixed in 1.8.2

It worked for some time after Ionide update, now all the same


[Clang importer] Remove @asyncHandler inference for Objective-C methods

The rule was inconsistent and required a lot of auditing, and could
cause surprises. We can consider bringing it back at another time.

@swift-ci please smoke test and merge

@swift-ci please smoke test

@swift-ci please smoke test


Make the ControllerConfiguration annotation optional

With workflows being moved to their own annotation, it might often happen that the ControllerConfiguration ends up being empty. It would be nice if it could be made optional.
Originally posted by @csviri in https://github.com/operator-framework/java-operator-sdk/issues/2274#issuecomment-1989056835

Note that, if I recall properly, we already looked at making it optional at some point but ran into some issues (though I don't remember which ones).
Note also that the annotation is already optional when you use the Quarkus extension because the processing is based on whether or not a class implements the Reconciler interface there.


Put Followed filter in sidebar

From Slack.
We should make 'Followed' a sidebar item, it pairs well with My Predictions and My Questions. Hot-Movers-New are a set of user-agnostic shortcuts and Followed doesn't belong there.
Also when Followed is active and I click through different topics, the filter persists and I get no results most of the time. It should behave like how My Predictions behaves, where the filter resets when I switch to different topics.
We can use the :mag_right: emoji and call it "Following" in the sidebar.

Ready for testing on dev

lgtm!


use solveargs in newton, minimize

Coverage increased (+0.1%) to 87.51% when pulling ab01b5bbe610c2d7fd23286eb207e7c4ea4c5b85 on gertjanvanzwieten:solverargs into 50fcfb65b4657972f0702c298bdc5df53a5b7a87 on nutils:master.


Migrate to new slash syntax

Since sbt 1.5 the in syntax has been deprecated and should be updated to the newer slash syntax. I'm currently getting the following warnings when using sbt 1.7.1:
       [warn] /app/.sbt_home/plugins/HerokuBuildpackPlugin.scala:6:20: method in in trait ScopingSetting is deprecated (since 1.5.0): `in` is deprecated; migrate to slash syntax - https://www.scala-sbt.org/1.x/docs/Migrating-from-sbt-013x.html#slash
       [warn]     sources in doc in Compile := List(),
       [warn]                    ^
       [warn] /app/.sbt_home/plugins/HerokuBuildpackPlugin.scala:6:13: method in in trait ScopingSetting is deprecated (since 1.5.0): `in` is deprecated; migrate to slash syntax - https://www.scala-sbt.org/1.x/docs/Migrating-from-sbt-013x.html#slash
       [warn]     sources in doc in Compile := List(),
       [warn]             ^
       [warn] /app/.sbt_home/plugins/HerokuBuildpackPlugin.scala:7:21: method in in trait ScopingSetting is deprecated (since 1.5.0): `in` is deprecated; migrate to slash syntax - https://www.scala-sbt.org/1.x/docs/Migrating-from-sbt-013x.html#slash
       [warn]     publishArtifact in packageDoc := false,
       [warn]                     ^
       [warn] /app/.sbt_home/plugins/HerokuBuildpackPlugin.scala:8:21: method in in trait ScopingSetting is deprecated (since 1.5.0): `in` is deprecated; migrate to slash syntax - https://www.scala-sbt.org/1.x/docs/Migrating-from-sbt-013x.html#slash
       [warn]     publishArtifact in packageSrc := false

Hi @hagerf!
Thanks for the report! We'll get this fixed!

I see that the issue was fixed already in October. Any idea of an ETA? Thanks :)

Hi @hagerf sorry for the long delay of the release and thanks for pinging! I just merged the fix and cut a release. The next build of your app will no longer have the annoying warnings in the build log! :)

Awesome and thanks! @Malax


fix: use relative paths in sources for transformed source maps

Description
This refines the fix from https://github.com/vitejs/vite/pull/4985 to
turn absolute paths into relative paths for the sources array in
source maps for transformer outputs (and thereby completely avoids the
Windows drive letter problem). In order to minimize unintended negative
side effects, we perform this step only when the source file name is
absolute.
This addresses the issue that source files show up with an absolute path
prefix in case of Vue^1.

Additional context
Bug: https://crbug.com/1411596
Ref: https://github.com/vitejs/vite/issues/4964
Ref: https://github.com/vitejs/vite/issues/4912

What is the purpose of this pull request?

[X] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

cc @jecfish

Let's make sure to run this PR against the ecosystem CI once the Vite tests are passing

/ecosystem-ci run

About ecosystem-ci: the Qwik fail should be unrelated, and the vite-plugin-vue fail is due to outdated snapshots.

The @fs, components, hmr and context prefixes, are these artifacts of the playground setup? @bluwy mentioned that at least @fs is prepended due to the file: dependency in the package.json.

No, I don't think these are artifacts of the playground setup. I guess sources field of the sourcemap of components/Dummy.jsx has C:/Users/green/foobar and Chrome resolves that as components/C:/Users/green/foobar.

No, I don't think these are artifacts of the playground setup. I guess sources field of the sourcemap of components/Dummy.jsx has C:/Users/green/foobar and Chrome resolves that as components/C:/Users/green/foobar.

Ooohhhh, you're right. It never occurred to me that we also need to pay special attention to potential Windows paths in sourcemaps. I'll dig into that (https://crbug.com/1417564).

No, I don't think these are artifacts of the playground setup. I guess sources field of the sourcemap of components/Dummy.jsx has C:/Users/green/foobar and Chrome resolves that as components/C:/Users/green/foobar.

Ooohhhh, you're right. It never occurred to me that we also need to pay special attention to potential Windows paths in sourcemaps. I'll dig into that (https://crbug.com/1417564).

Quick follow up here: After some discussion with the team, there's nothing we can do about this in DevTools, since c: is a valid URL path component (and a valid Unix folder name), so resolving it relative as done here is the correct behavior for DevTools.
The correct fix here is to avoid putting absolute (Windows) paths into source maps in the first place.

I have a fix for the vite-plugin-vue in here. It basically does the same as this PR, cleaning up the sources after the compiler ran.

I was just discussing this with @danielroe and we might need to move this a layer up. Please don't merge this yet.

Based on the session earlier with @danielroe, I now changed the patch to hook into the choke-point after the transformer is called, which seems to completely fix it for Vue and React!

/ecosystem-ci run

Apparently I'm not allowed to run the ecosystem CI :laughing: Maybe someone else can run kick it off. @dominikg I wonder if we could loosen permissions to allow anyone with triage rights on GitHub to run it?

/ecosystem-ci run

Apparently I'm not allowed to run the ecosystem CI laughing Maybe someone else can run kick it off. @dominikg I wonder if we could loosen permissions to allow anyone with triage rights on GitHub to run it?

unfortunately not that simple, to trigger a run you need write access to ecosystem-ci repo (until the generic version is in place that can offer this via custom run triggers - or someone upgrades vite org to enterprise where you have more finegrained permission controls)

Thanks for triggering the ecosystem CI. Looks like the MagicString source map type changes still need to be updated across all the various plugins.

I just sent a PR to vite-plugin-vue, which should fix most of the CI fails: https://github.com/vitejs/vite-plugin-vue/pull/114

Any idea what's up with the Windows bot?

/ecosystem-ci run
re-running after @bluwy's PR to to plugin-vue

/ecosystem-ci run

/ecosystem-ci run

ecosystem-ci looks good now, fails are the same as current ones against main and vite-plugin-vue needs to update the snapshots

Apparently I'm not allowed to run the ecosystem CI laughing Maybe someone else can run kick it off. @dominikg I wonder if we could loosen permissions to allow anyone with triage rights on GitHub to run it?

unfortunately not that simple, to trigger a run you need write access to ecosystem-ci repo (until the generic version is in place that can offer this via custom run triggers - or someone upgrades vite org to enterprise where you have more finegrained permission controls)

Because we trigger the CI by app, I guess just adding the username here might work.
https://github.com/vitejs/vite/blob/3d3788d5518350dd989659548ce0610134781851/.github/workflows/ecosystem-ci-trigger.yml#L18-L31

Alright, thanks folks. So this is ready to land then?

Yes, let's merge it so we can test it during the 4.2 beta period

This broke Vitest's typechecking feature (it relies on mapConsumer.generatedPositionFor, which depends on the source path). I am not sure why this wasn't caught by the ecosystem-ci since we have a test for it. Is it possible to add an option to keep sources as an absolute path?

@sheremet-va That doesn't sound reliable. Couldn't vitest simply resolve relative entries in sources according to the source map spec? Just like the debuggers and other tools do?

@sheremet-va That doesn't sound reliable. Couldn't vitest simply resolve relative entries in sources according to the source map spec? Just like the debuggers and other tools do?

I am not sure what you mean by "other tools". esbuild, for example, returns absolute paths.

I am not sure what you mean by "other tools". esbuild, for example, returns absolute paths.

And it doesn't seem like Vite returns "sourceRoot" that can be used to identify the actual path.

This is not about source map generators; for those it's perfectly valid to put relative paths (or just file names) into the sources.
This is about source map consumers, and vitest is one of those consumers, just like debuggers (i.e. browser devtools) and other tools like bundlers or post-mortem stack processors; for consumers the Source Map Revision 3 Proposal states how to resolve sources entries:

If the sources are not absolute URLs after prepending of the “sourceRoot”, the sources are resolved relative to the SourceMap (like resolving script src in a html document).

sourceRoot is only a prefix that's prepended to all sources, but that's not where the producers should put absolute paths either. The consuming tools need to resolve the sources (after prepending sourceRoot) relative to the source map. In case of vite, let's say you have an output file /Users/foo/project/file.js which references input.ts. Then the consumer resolves this to /Users/foo/project/input.ts.

In case of vite, let's say you have an output file /Users/foo/project/file.js which references input.ts. Then the consumer resolves this to /Users/foo/project/input.ts.

Vite's transformRequest doesn't return ID's absolute path, so it is impossible to determine the filesystem path for sources. It can also return virtual modules that don't have actual paths. Currently, Vitest tries to guess the path based on root and base, but it is not reliable. I can call transformRequest with an alias and it will return the processed result, but we cannot "reliably" consume the map if entries are relative.
Another thing is that transformRequest sometimes returns a map with entries relative to root, if ssr: true flag is present, so we cannot reliably get fs path even if we knew the absolute path of the module.

In the end, Vitest modifies all maps to have absolute sources because this is how other tools consume it in Node.js environment, as far as I can see (e.g., source-map-support)

Without having the specific context of vitest, my reading of this would be that vite should supply the necessary information for tools to properly resolve sources entries.

If the sources are not absolute URLs after prepending of the “sourceRoot”, the sources are resolved relative to the SourceMap (like resolving script src in a html document).

Also, as far as I understood this doesn't rule out the fact that source map's "sources" can be absolute paths. If there is no sourceRoot:
const sourceMapUrl = '/absolute`
const map = {
  sourceRoot: '',
  sources: ['entry.js']
  ...
}

resolve(sourceMapUrl, map.sources[0]) === '/absolute/entry.js'

const sourceMapUrl = '/absolute`
const map = {
  sourceRoot: '',
  sources: ['/absolute/entry.js']
  ...
}

resolve(sourceMapUrl, map.sources[0]) === '/absolute/entry.js'

The current specification does not rule that out, yes.
I also don't want to block fixing the vitest feature. It's of course up to @patak-dev to decide whether having a different mode for sources when running with vitest is acceptable. My hunch is that it'd be better / more maintainable long-term to consistently use filenames (or worst case relative paths) in sources through all of vite to reduce the number of edge cases.


How to obtain TokenCloudCredentials inside a webapi?

I have a portal where a user logs in using WAAD. After logging he/she can call some webapi's (inside the same MVC project). Inside that webapi I need to call some functions from the Azure Management Libraries. The question is: how can I obtain TokenCloudCredentails inside that webapi for the current user? (who logged in with valid credentials).
Obviously, I don't want people to login again calling AcquireToken since they already are logged in with valid WAAD credentials.

Though I don't have a specific code example handy to demonstrate this functionality, I showed off how to do multi-tenant auth from within a web application for this specific purpose - knowing how to pull the token out and re-use it - during my MAML presentation at TechEd Europe last year.
The talk is recorded an available on Channel 9 here: http://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B316
The Multi-tenant demo begins at around 55:00, so just jump to that part of the talk and you'll see a walk-through, with code, on doing precisely what you're after.
Hope this helps! For now I'm going to close this issue. If you need any further guidance please reach out to me directly via twitter (@bradygaster) and we'll work it out from there.


How do I sign a transaction?

The examples are not very clear. How do I use the wallet to

prompt the user for password/acceptance, then
use password to decrypt passwordDerivedKey, and finally
sign transaction?

The keystore is great, I just need some help implementing this into a real wallet where a user is actually prompted for a password before signing the transaction, similar to how metamask prompts to accept/reject the transaction.

Hi,
You can see the txutils in README.md
Before you sign transaction, you need to create RLP encoded raw unsigned transactions .
For example
valueTx:
var valueTx = lightwallet.txutils.valueTx({to: 'to address', value: 'value', nonce: 'nonce', gasPrice: 'gas price'})
contractTx:
var funcTx = lightwallet.txutils.functionTx(abi, 'name', ['args'], {to: 'contract address', value: 'value', nonce: 'nonce', gasPrice: 'gas price'})
signedTx:
var signedTx = lightwallet.txutils.signTx(keystore, pwDerivedKey, 'your RLP encoded raw unsigned transactions', address).toString('hex')
Finally use sendRawTransaction in web3Js.

Thanks, i get
var txutils = lightwallet.txutils;
var signedTx = txutils.signTx(keystore, _privateKey, valueTx, toAddr).toString('hex');

//error
Uncaught (in promise) TypeError: txutils.signTx is not a function

@IAMtheIAM signTx is in the signing lib, not txutils
https://github.com/ConsenSys/eth-lightwallet#signing-function-definitions

@tzapu It's signing lib, thx!
Before send the transaction, you should add hex prefix.


[BUG] Heroku is deprecating free dynos, need to migrate to somewhere else...

Move away from heroku to some other hosting platform...

You just need to install docker/docker-compose and run the container, then forward the port somewhere to access.
I will be sorting new hosting soon (prob in the next two weeks). If you could wait two weeks, then it'd be back!

Update, just made a semi-permanant hosting solution. More details in README (just change the domain to vbr.wocr.tk instead).
@nosvagor


Documentation on experimental flag

@istarkov What's the status on the experimental flag? It's been 4 months since that update, is it ok to use in production?
Rendering large amounts of markers has performance issues when the marker events are triggered

I Still have no opinion about, it works good mostly for dev builds, and even I see some performance gains at Release builds, can't say that I will prefer this flag over standart way.
So it can be removed.

Locally I have versions with grouping support, there markers split on groups, so updates is propagated just for group, and not for all, BTW api is so bad now so I cant release it.

@istarkov we see a big jump in performance if this is used when there is many SVG markers on the map

@istarkov It looks like the only thing the experimental flag is doing is enabling a shouldComponentUpdate on google_map_markers. Is there a reason you wouldn't want to have a shouldComponentUpdate method running?
It looks to me like there's no reason for the flag at the moment.

This part is the difference
https://github.com/istarkov/google-map-react/blob/7ae63cb3d733b91ef14332ed52dd38b5886459f5/src/google_map_markers.js#L62-L65
Having that flag is experimental let's don't think about it's nature and
other things ;-)
On Mon, Nov 14, 2016 at 2:10 AM, alex-e-leon<EMAIL_ADDRESS>wrote:

@istarkov https://github.com/istarkov It looks like the only thing the
experimental flag is doing is enabling a shouldComponentUpdate on
google_map_markers. Is there a reason you wouldn't want to have a
shouldComponentUpdate method running?
It looks to me like there's no reason for the flag at the moment.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istarkov/google-map-react/issues/277#issuecomment-260220276,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE14MjOXeVrs51o762Rd0EtNhL_PwTSMks5q95jcgaJpZM4Kvbzf
.

I must have been half asleep when I was reading the code last time, I totally missed the other return value.
That said, here's an example of the performance benefits we're seeing with the flag turned on vs off:
Note that with the experimental flag turned on there are no react updates called on hover.

@alex-e-leon Is there something I can help here? I am closing the issue as for now as it seems you could make it work, but please re-open if you need further help Alex!

@itsmichaeldiego It looks like the experimental flag is still available and undocumented. I ended up successfully using it to increase performance in my application, so there's no work required from me, but I think that it could be useful for other consumers to know about the flag, or for the experiment to be finished up and turned into default behaviour so that the performance improvements are made available to everyone.

That sounds good @alex-e-leon, it seems that you know more about the experimental flag than me, would you mind adding simple documentation in DOC.md?

Unfortunately @itsmichaeldiego I don't really remember too much about this ticket/flag, so I probably won't be of much help.


Adds new statistics for tracking connections created and closed

We add several new statistics fields for tracking the following:

connections_created: How many connections have been created
connections_broken_closed: How many connections were closed due to a broken state
connections_invalid_closed: How many connections were closed due to be considered invalid.
connections_max_lifetime_closed: How many connections were closed due to reaching the max lifetime.
connections_max_idle_timeout_closed: How many connections were closed due to reaching the idle timeout.

We have added also a new statistic called get_waited_time_micro which provides the accumulated time in micros that all calls to the get method had to wait for a new connection.

@djc this one is ready for a second review.


Tell if number is Even or Odd.

Ask user for a number,print whether the  number is even or odd
example:
input=number=9
output=number is odd.

@ananahyeah I'm interested in working on this issue. Would you please assign it to me?

yes I have assigned it to you !


Fixing Possible Error during build

I encountered build error using<EMAIL_ADDRESS>Error Message:
FAILURE: Build failed with an exception.

* Where:
Build file '/Users/richardng/Projects/whoisspy/node_modules/react-native-share/android/build.gradle' line: 53

* What went wrong:
A problem occurred evaluating project ':react-native-share'.
> Could not find method compileOnly() for arguments [com.facebook.react:react-native:+] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

Enable to solve by:
compileOnly -> provided
implementation -> compile
in the dependencies section of build.gradle

https://github.com/react-native-community/react-native-share/pull/335#pullrequestreview-145393760


Add support for kubernetes 1.6

Kubernetes 1.6 is just out. Can u update the plugin to support the latest release

I've added the 1.6 API definitions to the plugin. Once you update it should be used as the default for completion unless you've changed the version in the settings page.
Please let me know if you encounter any issues with the new definitions.

Sorry for the delay responding. I have tested with the latest version of plugin.
Though the latest apiVersion for StatefulSet is apps/v1beta1, the plugin sets this value to apps/v1alpha1
Please verify

Thanks, yes I see that too. It looks like for some reason the Swagger specs define the StatefulSet under both apps/v1alpha1 and apps/v1beta1 (https://github.com/kubernetes/kubernetes/blob/release-1.6/api/swagger-spec/apps_v1alpha1.json and https://github.com/kubernetes/kubernetes/blob/release-1.6/api/swagger-spec/apps_v1beta1.json) and the plugin just picks the first one when suggesting the apiVersion initially.
I'll open up a new issue to address this. Thanks for reporting.


Lock mechanism can stick in infinite loop

Hello. I have code like :
client = etcd.Client(host='etcd', protocol='http', port=2379)
lock = etcd.Lock(client, 'lock_key')
print 'Try to acquire Lock'
lock.acquire(blocking=blocking, lock_ttl=lock_ttl, timeout=timeout)

And sometimes it just freezes on lock.acquire(...). Logs indicate what etcd.client tries to read value over and over:

...
161 Try to acquire Lock
162 2016-06-09 14:19:53,213 - etcd.client - DEBUG - Issuing read for key /_locks/lock_key with args {'recursive': True}
163 2016-06-09 14:19:53,241 - urllib3.connectionpool - DEBUG - "GET /v2/keys/_locks/lock_key?recursive=true HTTP/1.1" 200 109
164 2016-06-09 14:19:53,242 - etcd.lock - DEBUG - Lock not found, writing it to /_locks/lock_key
165 2016-06-09 14:19:53,243 - etcd.client - DEBUG - Writing 7e932ac6c2ae428aae0bcac0aa73017b to key /_locks/lock_key ttl=1 dir=False append=True
166 2016-06-09 14:19:53,441 - urllib3.connectionpool - DEBUG - "POST /v2/keys/_locks/lock_key HTTP/1.1" 201 210
167 2016-06-09 14:19:53,468 - etcd.lock - DEBUG - Lock key /_locks/lock_key/35619 written, sequence is 35619
168 2016-06-09 14:19:53,471 - etcd.client - DEBUG - Issuing read for key /_locks/lock_key with args {'recursive': True}
169 2016-06-09 14:19:53,477 - urllib3.connectionpool - DEBUG - "GET /v2/keys/_locks/lock_key?recursive=true HTTP/1.1" 200 485
170 2016-06-09 14:19:53,478 - etcd.lock - DEBUG - Lock keys found: [u'/_locks/lock_key/35618', u'/_locks/lock_key/35619']
171 2016-06-09 14:19:53,560 - etcd.lock - DEBUG - Locker: /_locks/lock_key/35618, key to watch: /_locks/lock_key/35618
172 2016-06-09 14:19:53,560 - etcd.lock - DEBUG - Lock not acquired, now watching /_locks/lock_key/35618
173 2016-06-09 14:19:53,561 - etcd.client - DEBUG - About to wait on key /_locks/lock_key/35618, index None
174 2016-06-09 14:19:53,566 - etcd.client - DEBUG - Issuing read for key /_locks/lock_key/35618 with args {'recursive': None, 'timeout': 1, 'wait': True}
175 2016-06-09 14:19:53,569 - urllib3.connectionpool - DEBUG - "GET /v2/keys/_locks/lock_key/35618?wait=true HTTP/1.1" 200 None
176 2016-06-09 14:19:54,468 - etcd.lock - DEBUG - Detected variation for /_locks/lock_key/35618: expire
177 2016-06-09 14:19:54,469 - etcd.client - DEBUG - Issuing read for key /_locks/lock_key with args {'recursive': True}
178 2016-06-09 14:19:54,471 - urllib3.connectionpool - DEBUG - "GET /v2/keys/_locks/lock_key?recursive=true HTTP/1.1" 200 109
179 2016-06-09 14:19:54,472 - etcd.lock - DEBUG - Lock keys found: [u'/_locks/lock_key']
180 2016-06-09 14:19:54,472 - etcd.client - DEBUG - About to wait on key /_locks/lock_key/35618, index None
181 2016-06-09 14:19:54,472 - etcd.client - DEBUG - Issuing read for key /_locks/lock_key/35618 with args {'recursive': None, 'timeout': 1, 'wait': True}
182 2016-06-09 14:19:54,474 - urllib3.connectionpool - DEBUG - "GET /v2/keys/_locks/lock_key/35618?wait=true HTTP/1.1" 200 None
183 2016-06-09 14:19:55,476 - etcd.client - DEBUG - Watch timed out.
184 2016-06-09 14:19:55,477 - etcd.client - DEBUG - About to wait on key /_locks/lock_key/35618, index None
185 2016-06-09 14:19:55,477 - etcd.client - DEBUG - Issuing read for key /_locks/lock_key/35618 with args {'recursive': None, 'timeout': 1, 'wait': True}
186 2016-06-09 14:19:55,477 - urllib3.connectionpool - INFO - Resetting dropped connection: etcd
187 2016-06-09 14:19:55,625 - urllib3.connectionpool - DEBUG - "GET /v2/keys/_locks/lock_key/35618?wait=true HTTP/1.1" 200 None
188 2016-06-09 14:19:56,628 - etcd.client - DEBUG - Watch timed out.
189 2016-06-09 14:19:56,628 - etcd.client - DEBUG - About to wait on key /_locks/lock_key/35618, index None
190 2016-06-09 14:19:56,628 - etcd.client - DEBUG - Issuing read for key /_locks/lock_key/35618 with args {'recursive': None, 'timeout': 1, 'wait': True}
191 2016-06-09 14:19:56,629 - urllib3.connectionpool - INFO - Resetting dropped connection: etcd
192 2016-06-09 14:19:56,646 - urllib3.connectionpool - DEBUG - "GET /v2/keys/_locks/lock_key/35618?wait=true HTTP/1.1" 200 None
193 2016-06-09 14:19:57,648 - etcd.client - DEBUG - Watch timed out.
194 2016-06-09 14:19:57,683 - etcd.client - DEBUG - About to wait on key /_locks/lock_key/35618, index None
195 2016-06-09 14:19:57,683 - etcd.client - DEBUG - Issuing read for key /_locks/lock_key/35618 with args {'recursive': None, 'timeout': 1, 'wait': True}
...

I beleave it can happen because of https://github.com/jplana/python-etcd/blob/master/src/etcd/lock.py#L127

         while True:
            try:
                r = self.client.watch(watch_key, timeout=t)
                _log.debug("Detected variation for %s: %s", r.key, r.action)
                return self._acquired(blocking=True, timeout=timeout)
            except etcd.EtcdKeyNotFound:
                _log.debug("Key %s not present anymore, moving on", watch_key)
                return self._acquired(blocking=True, timeout=timeout)
            except etcd.EtcdException:
                # TODO: log something...
                pass

At first I think it is unlikely because I miss second log entry from _get_locker() method but it can be what _get_locker will fail with exception,  "except etcd.EtcdException" part will catch exception and start watch method again and again and then code will fail into infinite loop. May be it is normal behavior but I specify timeout and want result or error after timeout. There are two problems:

Someone ignores exception. You can log anything You like but please log something. It will be much easier to understand and debug
Someone ignores timeout. I wrap execution and add timeout for now.

The lock code is awful and I think it should be removed. Here is a trivial situation that will reliably cause deadlock:
From one python shell (call it A), run:
client = etcd.Client()
lock = etcd.Lock(client, lock_name='foo')
lock.acquire(blocking=True, lock_ttl=10)
time.sleep(10)
lock.release()

Immediately after starting the above, from another python shell (call it B) run:
client = etcd.Client()
lock = etcd.Lock(client, lock_name='foo')
lock.acquire(blocking=True, lock_ttl=5)

Note that the second lock call has a TTL of 5, while the first has a TTL of 10. The following set of events happen, in order:

A successfully acquires the lock with a TTL of 10 seconds
B doesn't manage to acquire a lock, but gets the next key in the sequence, with a TTL of 5 seconds
B starts to watch A's key for changes
B's key expires, but B doesn't see that because it's only watching A's key
A's key expires, A exits
from this point all execution is on B: B sees A's key expire and reads the list of keys; since there are no keys under the lock, the lock itself is a leaf and is returned: [u'/_locks/foo']
the l.index(self.lock_key) call doesn't find the lock key, causing a ValueError which is then reraised as an EtcdLockExpired error
this error is caught in the except EtcdException: pass block and simply causes a retry of the watch on A's key
since A's key doesn't exist, the watch never returns because there will never be any changes on the key -- deadlock.

We hit problems with key removal actually. Looks like this:

1st thread create lock record 1
1st thread does some stuff
2nd thread looks at locks list and find record 1. Tries to create record 2
1st thread complete task and removes record 1
2nd thread starts to wait record 1 in infinite loop because record does not exits.

Actually we fix problem with little sed script:
    sed -i -e 's/except ValueError:/except ValueError as val_err:/g' /usr/lib/python2.7/site-packages/python_etcd-0.4.3-py2.7.egg/etcd/lock.py && \     sed -i -e 's/raise etcd.EtcdLockExpired(u"Lock not found")/_log.error(val_err)\n            raise etcd.EtcdLockExpired(u"Lock not found")/g'  /usr/lib/python2.7/site-packages/python_etcd-0.4.3-py2.7.egg/etcd/lock.py && \     sed -i -e 's/return (l\[0\], l\[i-1\])/return (l\[0\], next(x for x in results if x.key == l\[i-1\]))/g' /usr/lib/python2.7/site-packages/python_etcd-0.4.3-py2.7.egg/etcd/lock.py && \     sed -i -e 's/watch_key = nearest/watch_key = nearest.key/g' /usr/lib/python2.7/site-packages/python_etcd-0.4.3-py2.7.egg/etcd/lock.py && \     sed -i -e 's/r = self.client.watch(watch_key, timeout=t)/r = self.client.watch(watch_key, timeout=t, index=nearest.modifiedIndex + 1)/g' /usr/lib/python2.7/site-packages/python_etcd-0.4.3-py2.7.egg/etcd/lock.py && \     cat /usr/lib/python2.7/site-packages/python_etcd-0.4.3-py2.7.egg/etcd/lock.py && \     rm -rf /usr/lib/python2.7/site-packages/python_etcd-0.4.3-py2.7.egg/etcd/lock.pyc
So main change is what we watch record 1 from last point we see it so if cluster has changes after this point (deletion in our case) it will return result instead of timeout.

I solution provided above is correct I can create pull request with it.

I believe your solution is correct for the problem you pointed out, but does not solve the problem I pointed out. Would you mind testing the scenario I constructed and seeing if it still deadlocks?

could anyone fixed it  or has any other method ?

Scenario suggested by @obi1kenobi leads to stuck. My solution does not cover it but 2 lines can solve it. To reproduce @obi1kenobi  scenario execute
import time
import etcd
import threading

def run_long_lock():
    client = etcd.Client()
    lock = etcd.Lock(client, lock_name='foo')

    print '[{}] Try to acquire long Lock'.format(time.time())
    lock.acquire(blocking=True, lock_ttl=10)
    print '[{}] Long Lock acquired'.format(time.time())

    time.sleep(10)

    print '[{}] Try to release long Lock'.format(time.time())
    lock.release()
    print '[{}] Long Lock released'.format(time.time())

def run_short_lock():
    client = etcd.Client()
    lock = etcd.Lock(client, lock_name='foo')
    print '[{}] Try to acquire short Lock'.format(time.time())
    lock.acquire(blocking=True, lock_ttl=5)
    print '[{}] Short Lock acquired'.format(time.time())
    lock.release()

long_thread = threading.Thread(target=run_long_lock)
long_thread.start()

# to make sure if long lock is ready
time.sleep(1)

short_thread = threading.Thread(target=run_short_lock)
short_thread.start()
short_thread.join()

I have created pull request https://github.com/jplana/python-etcd/pull/206

Forgot to post test case for error with lock race. It's simple but anyway. I start etcd docker container like this:
export HostIP="<IP_ADDRESS>"
docker run -d -p 4001:4001 -p 2380:2380 -p 2379:2379 \
  --name etcd \
  quay.io/coreos/etcd \
  /usr/local/bin/etcd \
  -advertise-client-urls http://${HostIP}:2379,http://${HostIP}:4001 \
  -listen-client-urls http://<IP_ADDRESS>:2379,http://<IP_ADDRESS>:4001

And then start python script:
import threading
import time
import etcd

client = etcd.Client(host='localhost', protocol='http', port=2379)

def run_lock_getter(name="Thread1"):
    while True:
        lock = etcd.Lock(client, 'lock_key')
        print '[{}:{}] Try to acquire Lock'.format(name, time.time())
        lock.acquire()
        print '[{}:{}] Try to release Lock'.format(name, time.time())
        lock.release()

first_thread = threading.Thread(target=run_lock_getter, args=("Thread1", ))
first_thread.start()

second_thread = threading.Thread(target=run_lock_getter, args=("Thread2", ))
second_thread.start()
second_thread.join()

It will acquire/release lock in 2 loops and will stuck after several seconds. Issue remains until I applied fix above.

After a few tests, I see the problems that both @obi1kenobi and @ainlolcat describe here, and the seem to be fixed by @ainlolcat PR #206. Probably locking is not completely fixed by this, but at least this deadlock is fixed.

BTW, thank you both for the great description of the problem!


[Records] No error when a const Set / Map has an element with non primitive ==

co19/LanguageFeatures/Records/primitive_equality_A02_t01
co19/LanguageFeatures/Records/primitive_equality_A02_t02

https://dart-review.googlesource.com/c/sdk/+/262127


Unable to update VirtualMachineProfile Extension Public Setting (Scale Set)

Fluent API, v1.1.1
Repo.VirtualMachineScaleSets.GetById(ID);
Set.Update().UpdateExtension("OctopusDeploy").WithPublicSetting("RandomSetting", "Value").Parent().Apply();

Updates are missing in the request to Azure. Adding private setting etc works without any issues.

@pppchris just to clarify, are you saying you could UPDATE the private settings of this extension but unable to update the public settings?

@anuchandy - yes correct, private work.. public does not.
Fiddler tracers are not showing any public setting changes in the API request.

@pppchris thank you!. Submitted fix for this issue.

looks like the fix made it into v1.2


Add container link to OBS project

A pcw container is now being build in the QAC project. This commit
updates the README to point to the container in the openSUSE registry
and the setup instructions are also updated accordingly.

Good work!


What is the parameters of plugin callback function?

Documentation Is:

[x] Missing or needed
[ ] Confusing
[ ] Not Sure?

Please Explain in Detail...
The document reads that a callback function can bu used in the plugin config. And the callback function take two parameters one of which is the current chart, but what is the other one options: any, is the options of the chart or some thing else?

Your Proposal for Changes
Example

The options will return the options specified for the plugin, see example: https://codepen.io/leelenaleee/pen/oNzGrez
Seems like from what I saw that options should be defined as type object since if you give it a string, array or number it returns an empty object. If you feed it a object with settings it returns it correctly

After looking in the type docs it should be an object and not any
https://github.com/chartjs/Chart.js/blob/3ffcd93d10a08d926fe2bd43d2b2b6d01297e755/types/index.esm.d.ts#L818

Docs updated in #8230


Alternative compression methods

Is your feature request related to a problem? Please describe.
I'm using Keyv to wrap connection with Redis and I would like to compress the content cached in Redis. This caching process is time-sensitive, so it should favour speed over compression rate. Thus why I'm atm using separate wrapper using snappy as the compression algorithm. I did performance tests and it turned out that Brotli in BROTLI_MIN_QUALITY mode is almost 2x slower than snappy!
So, the real problem for me is that Brotli is the built-in compression mechanism that cannot be easily changed for anything else.
Describe the solution you'd like
I would like to have some options if it goes to choosing the compression method that can be used with Keyv.
Describe alternatives you've considered
Atm I'm using custom kdybicz/apollo-server-snappy-cache-wrapper wrapped for Keyv.
Additional context
Scotty, We Need More Power!

@kdybicz  - Thanks for sending this over and we are also looking to make the compression engine more modular for Keyv moving forward. This would make it so that we can be more browser friendly (https://github.com/jaredwray/keyv/issues/252). Some thoughts on this is to create a generic interface for these modules that would interact more like this:
const Keyv = require('Keyv');
const KeyvBrotli = require ('KeyvBrotli')

const keyvBrotli = new KeyvBrotli();

const keyv = new Keyv({ compression: keyvBrotli });

This would make it more flexible to add in other libraries and could be supported via a standard interface. Would like your thoughts on this.

Yep. much more scalable solution. We hope to have those changes out in the next 30 days or so then will get back to making it browser compatible.

@jaredwray I really like that idea. Such approach would also make the configuration of the compression more clear, as it would be delegated to a dedicated module, one with a clear (I hope) interface :)

@alfaproject and @kdybicz - we will begin this work in August and plan to release the change in September 2022. Will post a description of the plan in this issue.

@alfaproject and @kdybicz we have merged in the changes and will be planning a release this week. Also, will add in support for snappy as a compression provider and most likely gzip.

@jaredwray snappy integration is something you can probably ignore for now, as it might be tricky to manage due to native libraries use by it and is not really needed by me anymore. It was way faster, but it turned out I need bigger compression ration that it was providing. So I've created my own compression wrapper for brotli which for some reason happens to be way faster than one that was built-in - no idea why though, maybe I messed up the configuration. So atm I'm using brotli and would be happy to switch to keyv dedicated solution, rather using custom one. At the same time adding gzip might make sense.
Some time ago I've found this compression methods benchmark, not sure if you will find it helpful https://quixdb.github.io/squash-benchmark/

@kdybicz - great will focus on the gzip version next using most likely as we want to support at least two. Will get that going and most likely release all of this update this upcoming weekend.

Le lun. 29 août 2022, 01:56, Jared Wray @.***> a écrit :

@alfaproject https://github.com/alfaproject and @kdybicz
https://github.com/kdybicz we have merged in the changes and will be
planning a release this week. Also, will add in support for snappy as a
compression provider and most likely gzip.
—
Reply to this email directly, view it on GitHub
https://github.com/jaredwray/keyv/issues/407#issuecomment-1229586246,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A2I25MNZFV4IBMNPRLTKGFTV3P4EBANCNFSM53RLPE3A
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@jaredwray looks like you might need to secure the project bit better 👆🏼

@jaredwray looks like you might need to secure the project bit better 👆🏼 (edit: the rouge comment that was sent via email has vanished as the account of the :trollface: was deleted)

Crazy that this happened. Wonder what it was. There have been no pull requests done or code submitted so I think the project is ok.

@jaredwray looks like you might need to secure the project bit better 👆🏼 (edit: the rouge comment that was sent via email has vanished as the account of the :trollface: was deleted)

Crazy that this happened. Wonder what it was. There have been no pull requests done or code submitted so I think the project is ok.

He mailed-in that comment and I though there is a setting in project configuration to enable/disable that functionality, but I cannot find anything in my projects o.O

We have now brought in support for gzip with this PR https://github.com/jaredwray/keyv/pull/457
Plan will be to do the breaking update.

Closing this issue as we have now published the compression changes. https://github.com/jaredwray/keyv/releases/tag/2022-09-02


unicode_literals import isn't detected if part of a multiline import statement

Thanks for this helpful tool! We're excited to incorporate it into our workflow. I found one very slightly inconvenient bug when futurizing a particular file added the following from __future__ imports:
from __future__ import print_function
from __future__ import division
from __future__ import absolute_import
from __future__ import unicode_literals

Subsequently running isort reduces this to:
from __future__ import (absolute_import, division, print_function,
                        unicode_literals)

Now, errors about native string literals appear where they otherwise would not, assumedly because this check only checks for the presence of unicode_literals on the same line only.
Happy to take a whack at a PR.

A PR would be appreciated!


Import Python 3 related decisions from sprint repo into docs

For porting Werkzeug to Python 3, we had a sprint. The werkzeug.rst in the linked repository contains crucial information on which string types should be chosen for representing headers, URIs, IRIs etc. Maybe it's just me, but even now i sometimes take a look back into that repo when working on werkzeug.urls.
Therefore i think we should import at least parts of werkzeug.rst into the documentation. The current location is too isolated for such design decisions.

I'm not sure where this would go in the docs, and I think it's somewhat moot at this point given the maturity of compat as well as the pending EOL for Python 2.


added myself

hey, I am Rohan Kumar this my first time I create a pull request.
and I loved it.
please add my pull.

please review my pull request


Cubit not registering on GetIt

When a new project created:
Cubit file created but cubit registration not added to DI file (GetIt)

fixed


Existing BUG: Ratings are not being stored to DB

Resolved in: https://github.com/Surya-06/XpensAuditor---Group-11/pull/17


Rename planckunit submodule folder to planck-unit

All includes, CMake code, and paths have been updated accordingly.

 Rename planckunit submodule folder to planck-unit. Be careful for includes and CMake code!


extend the grammar with negctrl gate modifier

The paper https://arxiv.org/abs/2104.14722 introduces negctrl for open controlled gates that the grammar currently does not support. The OpenQASM3 grammar needs to be extended with negctrl.

See https://github.com/Qiskit/openqasm/pull/203.

closing as duplicated with #203


Fix broken instructions

@mccbryan3, I just realized that changes in #8 require us to change every the instructions as well and possibly all occurences of it.

Right.. I intend to walk through the repos this week and update the instrucitions.


Support python 3.12

changes made

run CI on Python 3.12.
run torch~=1.11 only on python 3.8.
pin new supported version in setup.py.
update documentation.

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

@julien-c indeed, a stable version of python 3.13.0 was released last week https://www.python.org/downloads/release/python-3130/ but tensorflow and torch are not supporting python 3.13 yet

Ahah true, I missed last year release :smile:

The CI is green for python 3.12, let's bump the version to 3.13 and support it as well!

issues with gradio support for python 3.13 (gradio/issues/9696) :(  we will only support python 3.12 for now and then bump to 3.13 once the issue is fixed.


Callbacks inside templates

The simplest way I could find is:
<% @site.posts.limit(5).each (post) => if 1: %>
  <%- @someHelper post.title %>
<% end %>

Is there anything better?

It should work without if 1
<% @site.posts.limit(5).each (post) => : %>
  <%- @someHelper post.title %>
<% end %>

It will run without errors, but not work. It works only for sync functions. You still can't query the cache or database (which seems the case in the original comment).

Yes, ect not support async calls, because it synchronous. For template engine purposes synchronous way gets more speed then asynchronous. But all data need to be prepared before we send it to template engine.

But still the idea to have a callbacks-based (or event better, promises-based) templates is so tempting that I subscribed for this issue just to see if someone comes up with a clever solution for it without hurting performance :)
It possibly can give some throughput improvements too, say while you querying the DB the rest of template which doesn't need it is being rendered.


Create 作业名.py

Hey @YaoWang666
Thank you for opening a PR
This is not the correct repository for this pull request.
Maybe this is the correct one?
https://github.com/badou-Michael/badouai-ai-special-2024
Have a great day 😊


example: added "root secure" deployment yaml

Allows deploying in clusters with PodSecurityPolicy enforcing
runAsNonRoot without getting the following error:
“Error: container has runAsNonRoot and image has non-numeric
user (etcd-operator), cannot verify user is non-root”
Please read https://github.com/coreos/etcd-operator/blob/master/CONTRIBUTING.md#contribution-flow

lgtm @qvicksilver thanks!


Synchronize and Align Viewer With Caret

I find the option to synchronize the NppMarkdownPanel's viewer with Npp's caret useful, but it would be more useful if the viewer maintained vertical alignment with the caret. Currently the caret's associated text is always positioned at the top of the viewer. Is it possible to actually synchronize the viewer with the caret, including vertical alignment? If not, perhaps you could position the caret's associated text from 35% to 50% below the top of the viewer, so it can be seen in context with other nearby text.

Better yet, how about synchronizing the scrolling itself, so that top of the rendered content starts with the same line that's at the top of the editor's text view?

There is a new feature in version 0.7.1 which addresses this issue.
The Option is called "https://github.com/mohzy83/NppMarkdownPanel/releases/tag/0.7.1"


flash loader fails on STM32L0xx

This is a resurgence of issue https://github.com/texane/stlink/issues/356, which is closed and locked (why?).
Using Nucleo L073RZ.
It does not happen with any other chips I tried.
ST_link firmware is V2J29M18, st-flash version 1.4
Mass erase, as suggested in the README is slow, goes through fine, but doesn't resolve anything.
$ st-flash write build/bees.bin 0x8000000
st-flash 1.4.0
2017-11-16T10:09:01 INFO src/common.c: Loading device parameters....
2017-11-16T10:09:01 INFO src/common.c: Device connected is: L0x Category 5 device, id 0x20086447
2017-11-16T10:09:01 INFO src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x30000 bytes (192 KiB) in pages of 128 bytes
2017-11-16T10:09:01 INFO src/common.c: Ignoring 96 bytes of 0x00 at end of file
2017-11-16T10:09:01 INFO src/common.c: Attempting to write 31904 (0x7ca0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08007c80 erased
2017-11-16T10:09:03 INFO src/common.c: Finished erasing 250 pages of 128 (0x80) bytes
2017-11-16T10:09:03 INFO src/common.c: Starting Half page flash write for STM32L core id
2017-11-16T10:09:03 INFO src/flash_loader.c: Successfully loaded flash loader in sram
2017-11-16T10:09:06 ERROR src/flash_loader.c: flash loader run error
2017-11-16T10:09:06 WARN src/common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2017-11-16T10:09:06 WARN src/common.c:
write_half_pages failed == -1
248/249 pages written
2017-11-16T10:09:36 INFO src/common.c: Starting verification of write complete
2017-11-16T10:09:36 ERROR src/common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

The flashing is extremely slow, but despite the errors shown, after a board reset with the hardware button the uploaded firmware seems to be working correctly.

Ah, I see there's a couple old isues with this exact error, closed as "will be fixed in 1.2" or so - alas...

I'm having similar problems
st-flash 1.4.0
2018-02-01T18:02:36 INFO src/common.c: Loading device parameters....
2018-02-01T18:02:36 INFO src/common.c: Device connected is: L011 device, id 0x10086457
2018-02-01T18:02:36 INFO src/common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x4000 bytes (16 KiB) in pages of 128 bytes
2018-02-01T18:02:36 INFO src/common.c: Attempting to write 12508 (0x30dc) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003080 erased
2018-02-01T18:02:37 INFO src/common.c: Finished erasing 98 pages of 128 (0x80) bytes
2018-02-01T18:02:37 INFO src/common.c: Starting Half page flash write for STM32L core id
2018-02-01T18:02:37 ERROR src/flash_loader.c: unknown coreid, not sure what flash loader to use, aborting! coreid: bc11477, chipid: 457
2018-02-01T18:02:37 WARN src/flash_loader.c: Failed to write flash loader to sram!
2018-02-01T18:02:37 WARN src/common.c: stlink_flash_loader_init() == -1
2018-02-01T18:02:37 WARN src/common.c:
write_half_pages failed == -1
 96/ 97 pages written
2018-02-01T18:02:48 INFO src/common.c: Starting verification of write complete
2018-02-01T18:02:48 INFO src/common.c: Flash written and verified! jolly good!


Character rendering incorrectly

Using latest version: 1.1.357
On Chrome 44.0.2403.125 m
PDF file:  http://seth.redirectme.net/med/pdf/55a3e76831f73.pdf
Renders correctly in adobe acrobat, but displays '!' symbol instead of '<' in pdf.js (see images)
Interestingly, when I copy the character to the clipboard from adobe acrobat it pastes as '!'.

I can confirm this using Windows 10 Pro x64, Firefox 39.0 and the latest PDF.js development version.

Closing as fixed by #6715.


Bump Brewfile llvm@9 -> llvm@11

Followup to #10217

test_alpine fails with (unrelated):
Invalid memory access (signal 11) at address 0x7f966eb01da8
  [0x55b5a9c35c66] *Exception::CallStack::print_backtrace:(Int32 | Nil) +118
  [0x55b5a99fe82c] __crystal_sigfault_handler +316
  [0x55b5aae434ee] sigfault_handler +40
  [0x7f967d7b4c4b] ???

make: *** [Makefile:93: compiler_spec] Error 11

test_alpine fails with (unrelated):
Invalid memory access (signal 11) at address 0x7f966eb01da8
  [0x55b5a9c35c66] *Exception::CallStack::print_backtrace:(Int32 | Nil) +118
  [0x55b5a99fe82c] __crystal_sigfault_handler +316
  [0x55b5aae434ee] sigfault_handler +40
  [0x7f967d7b4c4b] ???

make: *** [Makefile:93: compiler_spec] Error 11


Using "\W*" doesn't compile

While both \w* and \B* work, using ctre::search<R"(\W*)"> fails to compile with the last error being
ctre.hpp:4355:9: error: array subscript value ‘3’ is outside the bounds of array type ‘ctre::point_set<2>::point [3]’
 4355 |         if constexpr (!collides(calculate_first(Content{}...), calculate_first(Tail{}...))) {
      |         ^~

The other quantifiers (+, ?) don't seem to be supported with \W neither.
But replacing \W with [^_[:alnum:]], which should be synonymous, does work.

@hanickadot this appears to be the bug I ran into ages ago that I fixed by increasing the capacity of the buffer by one. Not sure, but it seems like negative sets need an additional bit of space?

Duplicate of #175 ?

@danlark1 looks like, not exactly clear where the bug occurs my best guess is that negating a character class requires additional space I'm thinking like: [a] vs [^a] the first one requires only space for one range where the second needs space for two. Somewhere at compile time there's not enough room to work with.

In playing around with first.hpp I found that if I use my other commits it's when I change this section:
https://github.com/hanickadot/compile-time-regular-expressions/blob/eeada602518d1cb7838f14d899e0c1acb39d613b/include/ctre/first.hpp#L423
The error does go away, but that's not the interesting bit, if I add a check to test to see if we're inserting to a point_set which is already filled and instead return nullptr suddenly I can compile. However I suspect that the check will break things, but it does seem to indicate there's an additional insertion into the character class which creates a compile time error.

I have found the issue @hanickadot you'll want to add a test for:
static_assert(calculate_size_of_first(ctll::list<ctre::negative_set<ctre::word_chars>>{}) ==
	calculate_size_of_first(ctll::list<ctre::negative_set<ctre::char_range<'A', 'Z'>, ctre::char_range<'a', 'z'>, ctre::char_range<'0', '9'>, ctre::char_range<'_', '_'>>>{}));
	```
	I'm getting the error for other issues, but the problem appears to be when embedding a set inside a negated set.

static_assert(calculate_size_of_first(ctll::list<ctre::negative_set<ctre::char_range<'A', 'Z'>, ctre::char_range<'a', 'z'>, ctre::char_range<'0', '9'>, ctre::char_range<'', ''>>>{}) == 5);
static_assert(calculate_size_of_first(ctll::list<ctre::negative_setctre::word_chars>{}) == 2);
You'll find that this passes*, hence the issue with indexing past the end, 2 is definitely not sufficient to handle a point set which requires 5.

// calculate mutual exclusivity
template <typename... Content> constexpr size_t calculate_size_of_first(ctre::negative_set<Content...>) {
	return 1 + 1 * sizeof...(Content);
}

The error's here*, sizeof...(Conent) should be:
// calculate mutual exclusivity
template <typename... Content> constexpr size_t calculate_size_of_first(ctre::negative_set<Content...>) {
	return 1 + calculate_size_of_first(ctre::set<Content...>{});
}

@Andersama can you please add the test as part of PR? I'm not currently near computer and for a few more days I won't be.

Oh, shoot I thought I did, whoops*.

Oh right I added mine under msvc because that's what I'm testing with that's why I didn't commit it it wouldn't be specific to msvc. Where should I add it in?


works with redux logger?

First thank you for sharing this package and making it easier and less verbose to implement state management. I wonder if it's possible to use redux-logger with repatch? I've tried to add redux-logger as middleware without success.
import Store, { thunk } from 'repatch';
import { logger } from 'redux-logger';

export default new Store({
  counter: 0,
})
  .addMiddleware(thunk)
  .addMiddleware(logger);

Am I doing something wrong or is repatch not compatible with redux-logger?
If it's not compatible, is there anyway I can access the name of the called action in the middleware?

It is not compatible. Redux works a quite differently then repatch. For example redux middlewares take actions as second argument, but in repatch there are no actions.
I linked the related section in the api reference, where I implemented a very simple logger:
https://github.com/jaystack/repatch/blob/master/docs/store.md#addmiddlewaremiddlewares
Some enhancement could be that we take the deep difference between the previous and current state, like in redux-devtools.
As soon as possible I would like to provide a useful logger middleware in this package, but it is not difficult to implement yourself ;)


Add requirement for more comprehensive testing

Fix https://github.com/shuddle/rails-api/issues/5528

LGMT


Implement date_part() function

Example:
DATE_PART('day', CAST(s.expect_arrival_date AS TIMESTAMP) -
                        CAST(s.delivery_time AS TIMESTAMP))

Do we want to support date_part(text, timestamp) or also date_part(text, interval) (see PSQL docs).

The example above is actually requesting the latter, since TIMESTAMP - TIMESTAMP results in interval.
date_part should share the implementation with extract, or rewritten as extract + cast if performance is not a concern.
Our extract implementation is also missing support for many fields, as shown in the regress test:
https://github.com/risingwavelabs/risingwave/blob/d06346151ce13176856ffe0e173aeff60973fe45/src/tests/regress/data/sql/date.sql#L224


verify -> confirm

small patch for a missed string
https://github.com/celo-org/wallet/pull/76#issuecomment-805806776
fixes #166

Thanks @isabellewei
Because we're now using Crowdin, this change needs to be done in there, otherwise it will be overwritten next time Crowdin syncs with this repo.
@aleksey-nov or Denisse will handle this.
See more details about our translation process

Done in #165


[Compile] Fix hyberscan not found Fix boost found problem

run starrocks_be_unittest

it need rebase to resolve conflict.


K8s yaml manifest decompiler

Fixes https://github.com/Azure/bicep-extensibility/issues/25
Microsoft Reviewers: Open in CodeFlow

Closing this as the functionality was implemented with #7812


Maven release

Hi,
I'm happy to have found this project. Kudos!
I'd like to use it as an in-process, repl-driven tool. It's how I happen to run most of my tools, and also a particularly good fit for my use case (grepping the classpath. A repl always knows the accurate classpath it's running on, with no overhead to compute it).
For that to happen, I'd need a Maven artifact. Would you be so kind to start releasing those?
Thanks - V

Hi, thanks for the interest.
What should be included into this maven artifact? Only grepping? Or also things like glob pattern matching? Or also multithreaded processing?

Hi, after a long delay, I've finally refactored out a library out of lmgrep: https://github.com/dainiusjocas/lucene-monitor
Check it out, and let me know what can be added.

Thanks!
I cannot promise to immediately take a look at it, however this (the use case described in OP) would sound like a nice thing that cider-nrepl could do.
I'll add an issue there to not forget.


Question: Why look like bounded(0) not block using dbg!?

I try to emulate a streaming protocol using channels instead of iterators (so get a way to do pseou-coroutines):
use crossbeam::crossbeam_channel::unbounded;

fn main() {
    let (s, r) = bounded(0);

    thread::spawn(move || {
        dbg!("s1");
        s.send(1).unwrap();
        dbg!("s2");
        s.send(2).unwrap();
        dbg!("s3");
        s.send(3).unwrap();
        dbg!("end");
        drop(s); // Disconnect the channel.
    });
    for x in r.iter() {
        dbg!(x);
    }
}

I expect to see in order:

s1, 1, s2, 2, etc...

but the output is different, like:
[src/main.rs:59] "s1" = "s1"
[src/main.rs:69] x = 1
[src/main.rs:61] "s2" = "s2"
[src/main.rs:63] "s3" = "s3"
[src/main.rs:69] x = 2
[src/main.rs:69] x = 3
[src/main.rs:65] "end" = "end"

You have a race condition: there's no synchronization between when you send/receive a value and make the call to dbg!(). In your case, here's the sequence of events (pseudocode):
Thread 1: dbg!("s1")
Thread 1: s.send(1).unwrap()
Thread 2: let x = r.recv();
Thread 2: dbg!(x); // 1
Thread 1: dbg!("s2");
Thread 1: s.send(2).unwrap();
Thread 2: let x = r.recv();
Thread 1: dbg!("s3");  // Problem starts here: no order guaranteed between operations in threads!
Thread 2: dbg!(x); // 2
Thread 1: s.send(3);
Thread 2: let x = r.recv();
Thread 2: dbg!(x); // 3
...

So the problem is not an issue with crossbeam's channels.

Ok, so how I can do a streaming of data? Or is crossbeam not the tool for it?

Well, everything should still work as expected, except that side effects won't be noticed in a defined order. If you want to have a thread sending data and another processing it, that will work fine as long as you don't have the sender relying on updates made by the receiver.


refactor: improve dependency location

Summary

Alternatively, we could place the Sourcemap into the Dependency and use range.to_loc(self.sourcemap) for location transformation.

Your suggestion sounds promising. Would you please give it a try?
Originally posted by @h-a-n-a in https://github.com/web-infra-dev/rspack/issues/7892#issuecomment-2358021494
In the past, I had attempted to implement this but encountered some issues.
I've been thinking about how to ensure low memory usage, and recently, I came up with some ideas. I eventually aligned my approach with webpack and extracted RealDependencyLocation from DependencyRange.
Checklist

[ ] Tests updated (or not required).
[ ] Documentation updated (or not required).

What is the relationship between DependencyLocation, DependencyLocation now?

Would you please resolve the conflict? I think it's good to merge ;-). Thanks

Would you please resolve the conflict? I think it's good to merge ;-). Thanks

done


Redis metadata report support database properties.

What is the purpose of the change
Redis metadata supports setting database properties.
Brief changelog
Redis metadata supports setting database properties.
Verifying this change
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

I triggered the CI again, will merge after CI pass.

Codecov Report

Merging #4476 into master will increase coverage by 0.59%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #4476      +/-   ##
============================================
+ Coverage     62.34%   62.94%   +0.59%
  Complexity      450      450
============================================
  Files           791      770      -21
  Lines         34852    33006    -1846
  Branches       5457     5216     -241
============================================
- Hits          21730    20774     -956
+ Misses        10624     9837     -787
+ Partials       2498     2395     -103

Impacted Files
Coverage Δ
Complexity Δ

...ubbo/metadata/store/redis/RedisMetadataReport.java
54.28% <100%> (+1.34%)
6 <0> (ø)
:arrow_down:

.../apache/dubbo/qos/protocol/QosProtocolWrapper.java
64.1% <0%> (-17.95%)
0% <0%> (ø)

.../apache/dubbo/remoting/transport/AbstractPeer.java
58.69% <0%> (-13.05%)
0% <0%> (ø)

.../apache/dubbo/rpc/protocol/AsyncToSyncInvoker.java
79.16% <0%> (-8.34%)
0% <0%> (ø)

...ng/exchange/support/header/HeartbeatTimerTask.java
73.68% <0%> (-5.27%)
0% <0%> (ø)

...bo/rpc/cluster/support/FailbackClusterInvoker.java
67.21% <0%> (-3.28%)
0% <0%> (ø)

...a/org/apache/dubbo/monitor/dubbo/DubboMonitor.java
87.85% <0%> (-1.87%)
16% <0%> (ø)

...a/org/apache/dubbo/common/json/ParseException.java

...o/rpc/protocol/thrift/DubboClassNameGenerator.java

.../java/org/apache/dubbo/common/json/JSONObject.java

... and 21 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 4c4b931...a6a1bbe. Read the comment docs.


thread 'main' panicked at 'called `Result::unwrap()

I am getting this error intermittently, not sure where to debug this.
The code(taken from examples) is here:
https://github.com/SachinMaharana/ceph-op
cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/ceph-op`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Utf8Error { valid_up_to: 10, error_len: Some(1) }', /home/centos/.cargo/registry/src/github.com-1ecc6299db9ec823/ceph-3.0.0/src/ceph.rs:1988:46
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It's a bug with this piece of code: https://github.com/ceph/ceph-rust/blob/v3.0.0/src/ceph.rs#L1988. That unwrap should be a checked ? instead. It appears that the string being returned is not valid utf8.

Would you like to try forking the repo, changing those unwraps and seeing if that helps?

@cholcombe973 sure. I will get on this.


Deprecate unsafe and useless Option functions

Long overdue...

You can check the patch-package-set task in this job to see which packages in the package-set would now have deprecation warnings (the base library is one of them ;))

@kritzcreek Cool feature!
I fixed the errors that I saw in this repo, an extended branch/PR here: #275
Is the general fix to write an explicit switch and then assert false for null?  That's what I assumed.
I would say that this is somewhat longer than writing the "useless" unwrap function, but that the assertion is closer to the code whose invariants guard against it running, so that's better for understanding the assertion failures, when they happen (but they shouldn't).

FWIW, with "useless" I was referring to the other two functions. :)


Drop preview tag for 15.7 release

Internal bug: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/605756

@dotnet-bot test Ubuntu16.04 Build for CoreCLR please

We're running out of 15.7 window. Merging this to prep VS insertion for escrow approval and to ensure no downstream (CLI) issues.


Add SeKey.app 0.1

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if adding a new cask:

[x] Named the cask according to the token reference.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.
[x] Checked there are no open pull requests for the same cask.
[x] Checked the cask was not already refused in closed issues.
[x] Checked the cask is submitted to the correct repo.

I was unable to test the app itself as my own Mac doesn’t have Sierra, or High Sierra, or a Touch Bar.
@caskroom/maintainers Anyone with a Touch Bar, care to review please?

i have some issues running it, its because the permission on the log folder. the path is created as root .
I don't know how to fix this from the cask. maybe using the set_ownership?

I'm not overly keen on including the plist in the Cask. AFAIK we don't with any other Casks and we have refused requests to do so.
Recent issues: https://github.com/caskroom/homebrew-cask/issues/40931 and https://github.com/caskroom/homebrew-cask/issues/40325

@commitay Thanks for the heads up; I wasn’t aware we didn’t like here-plists in Casks.
@ntrippar For future binary releases, would you be willing to ship your plist in the zip file? (If you do, frel free to use or ignore the additions I have made to the plist.)

According to the developer, the next release is going to ship with the plist.
Putting this PR on hold until then.

i created a pkg and the cask script. (i currently dont have my macbook, but i tested and everything worked perfect, the install and uninstall). the cask is on a fork that i created
https://github.com/ntrippar/homebrew-cask/tree/sekey
I didn't have direct access to push to this pull request. so lets wait @claui  to push it. (in the guidelines says that i shouldn't create a new pull if there is one already).

@ntrippar Thanks, we'll pull that in.
You should also update uninstall, if possible. See https://github.com/caskroom/homebrew-cask/blob/master/doc/cask_language_reference/stanzas/uninstall.md#uninstall-key-pkgutil

uninstall launchctl seems to work correctly for the CI (10.12)
>>> brew cask uninstall --verbose Casks/sekey.rb
==> Uninstalling Cask sekey
==> Running uninstall process for sekey; your password may be necessary
==> Removing launchctl service com.ntrippar.sekey
==> Uninstalling packages:
com.ntrippar.sekey
==> Unlinking Binary '/usr/local/bin/sekey'.
==> Purging files for version 0.1 of Cask sekey


LUN-514: Change colors of articles

This pull request belongs to an issue on our bugtracker.
You can find it there by looking for an issue with the key which is mentioned in the title of this pull request.
It starts with the keyword LUN.


Batch sign/verify

The current sign/ verify function take in a signer object with a sign function. This works great for a custom signer signing a single credential however many HSMs support batch signing, it would be great if the library can support something to the effect of
issueCredentials([unsignedCreds]) where the suite with the signer object takes in an array of these unsigned credentials and signs them.

@mkhraisha,
It sounds like the goal above is not to simply do something like this:
const vcs = await Promise.all(credentials.map(c => issue(c, ...)));

But to, instead, capture the bytes from each credential that is ultimately to be signed (i.e., usually some concatenated hashes) in a queue so it can be sent in a single request to an HSM for batch processing. Have I understood correctly?
If so, then this implies, to me, that a signer implementation that is passed in the creation of a suite (for example) could do this queuing internally without any changes here or elsewhere in the stack. The signer could then be used in one or more suites that are passed in multiple, concurrent issuance calls (e.g., like in the above code).
Such a signer.sign() implementation could do internal batching in a similar way that database drivers do today with N requests sent over M pooled connections -- without exposing those details at higher layers. What do you think?

The goal is to send a single request to an HSM that states please sign X credentials.
const vcs = await Promise.all(credentials.map(c => issue(c, ...)));

I think your comment is on the right track, and it definitely belongs to the  Signer.sign() function.
I see that the sign function has an id field is that correlated to the credential in any way or is it an arbitrary id that can be used for anything?
I guess what I'm trying to wrap my head around is assuming two requests to sign 5 credentials come in, and we want to send them all in one call to the HSM. It is trivial to set up a basic batching on the signer.sign function that says "wait for X credentials before submitting or a timeout of X before sending out the request". What I'm struggling with is what would the signer.sign function return from the sign call, and how can it associate it to each credential?

@mkhraisha,

I see that the sign function has an id field is that correlated to the credential in any way or is it an arbitrary id that can be used for anything?

The id field is for identifying the verification method / key ID. So this would be the same only when used with the same key.

What I'm struggling with is what would the signer.sign function return from the sign call, and how can it associate it to each credential?

It would still return the same thing it does now -- the batching would all be handled internally. Some quick back of the napkin (do not use for real, of course) pseudo code:
batchSigner = wrapSigner(someSimpleSigner);

function wrapSigner(signer) {
  // really, just use something from:
  // https://www.npmjs.com/package/promise-fun
  let queue = [];

  return {
    id: signer.id,
    async sign(x) {
      return scheduleSign(x);
    }
  };

  async function scheduleSign(x) {
    let resolve;
    promise = new Promise(r => resolve = r);
    queue.push({x, resolve});

    if(timeToSend) {
      sendBatch();
    } else {
      setTimeout(() => sendBatch(), waitTime);
    }

    return promise;
  }

  async function sendBatch() {
    // clear queue for next batch
    const batch = queue;
    queue = [];

    /* send batch to HSM, it returns results in order */
    const allX = batch.map(({x}) => x);
    const results = await doHsmBatchSign(allX);
    batch.forEach(({resolve}, i) => resolve(results[i]));
  }
}

That makes a ton of sense, it probably should be cleaned up and added somewhere to the readme? I feel like many people would be looking to batch sign and a starting point would help them out quite a bit.
Thanks!