Double escaping of ssrNode in style attribute values

Version
2.6.11
Reproduction link
https://github.com/kamilic/vue/tree/style-attr-escaped
Steps to reproduce
You can add this unit test at ./test/ssr/ssr-string.spec.js in Vue project.
it('should not double escape style attribute values', done => {
    renderVmWithOptions({
      template: `

      `
    }, result => {
      expect(result).toContain(`<div style="background: url(https://foo.bar/foo.png) no-repeat center center;background-size: cover;"></div>`)
      done()
    })
  });

or
clone the library and checkout to style-attr-escaped branch and run.
npm run test:ssr

result:

What is expected?
No double escaping of ssrNode in style attribute values
What is actually happening?
style attribute will be escaped.

This issues may be related to #7224;
https://github.com/vuejs/vue/pull/7224

I tried to change this line (https://github.com/vuejs/vue/blob/dev/src/server/optimizing-compiler/modules.js#L109) to
    return [{ type: RAW, value: ` style=${JSON.stringify(staticStyle.replace(/\n/g, ''))}` }];

It works, but I don't know it whether match expected behavior.

any reply?????

any news?

any reply??


No module named gprofiler

Hello,
We are running Gprofiler as an executable. We ran the code below.
wget https://github.com/Granulate/gprofiler/releases/latest/download/gprofiler_$(uname -m) -O gprofiler
sudo chmod +x gprofiler
sudo sh -c "setsid ./gprofiler -cu --token  --service-name  [options] > /dev/null 2>&1 &"
sleep 1
pgrep gprofiler # make sure gprofiler has started
We checked that Gprofiler started (pgrep gprofiler).
We tried to profile a test.py file with the code below:
python3 -m gprofiler -cu -token  --service-name  python test.py
The result is :
/usr/bin/python3: No module named gprofiler
Could you provide us a solution to this issue?
Best,
George

Hi @geokas7 !
You don't need to start your profiled script with python -m gprofiler ... python myscript.py. Upon being started, gProfiler automatically profiles all Python code running on your system. So you can just run python test.py, and it will be profiled by gProfiler that was started earlier.

I'm closing this ticket as the question was answered. If you have any additional questions, feel free to open a new one (or reopen this oen with subsequent questions on this topic).


Getting "ActiveMocker.safe_methods is unable to find methods: missing_class_macros" error for ruby 2.5.5

I am getting ActiveMocker.safe_methods is unable to find methods: __missing_class_macros__ error when try to run rake task rake active_mocker:build with ruby version 2.5.5
It's working fine with old version of ruby (2.4.5)

I checked if I am testing that version of Ruby in travis and I am. Could you @mahigawas28 provide a little more info maybe a backtrace or an example project so I can debug the issue faster.

@zeisler I am getting this error in lenny project of renewfiancial, please find below error log details
AvmDbProperty has the following errors: ActiveMocker.safe_methods is unable to find methods: __missing_class_macros__ error ActiveMocker.safe_methods is unable to find methods: __missing_class_macros__ /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/mock_creator/defined_methods.rb:30:in create_method'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/mock_creator/defined_methods.rb:20:in block in class_methods' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/mock_creator/defined_methods.rb:20:in map'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/mock_creator/defined_methods.rb:20:in class_methods' (erb):7:in block in partials'
/Users/mgavas/.rvm/rubies/ruby-2.5.5/lib/ruby/2.5.0/erb.rb:876:in eval' /Users/mgavas/.rvm/rubies/ruby-2.5.5/lib/ruby/2.5.0/erb.rb:876:in result'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/mock_creator.rb:121:in block in partials' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/mock_creator.rb:117:in each'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/mock_creator.rb:117:in each_with_object' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/mock_creator.rb:117:in partials'
(erb):5:in template_creator_default' /Users/mgavas/.rvm/rubies/ruby-2.5.5/lib/ruby/2.5.0/erb.rb:876:in eval'
/Users/mgavas/.rvm/rubies/ruby-2.5.5/lib/ruby/2.5.0/erb.rb:876:in result' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/template_creator.rb:15:in render'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/mock_creator.rb:49:in render' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/mock_creator.rb:44:in create'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/file_writer.rb:72:in create_mock' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/file_writer.rb:21:in process!'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/file_writer.rb:15:in block in write!' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/file_writer.rb:33:in block in safe_write'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/file_writer.rb:31:in open' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/file_writer.rb:31:in safe_write'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/file_writer.rb:15:in write!' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/generate.rb:58:in write_file'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/generate.rb:21:in block in call' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/generate.rb:20:in each'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/generate.rb:20:in call' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/active_mocker-2.6.1.beta2/lib/active_mocker/public_methods.rb:31:in create_mocks'
/Users/mgavas/projects/lenny/tasks/active_mocker.rake:21:in block (2 levels) in <top (required)>' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/task.rb:250:in block in execute'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/task.rb:250:in each' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/task.rb:250:in execute'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/task.rb:194:in block in invoke_with_call_chain' /Users/mgavas/.rvm/rubies/ruby-2.5.5/lib/ruby/2.5.0/monitor.rb:226:in mon_synchronize'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/task.rb:187:in invoke_with_call_chain' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/task.rb:180:in invoke'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/application.rb:152:in invoke_task' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/application.rb:108:in block (2 levels) in top_level'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/application.rb:108:in each' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/application.rb:108:in block in top_level'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/application.rb:117:in run_with_threads' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/application.rb:102:in top_level'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/application.rb:80:in block in run' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/application.rb:178:in standard_exception_handling'
/Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/lib/rake/application.rb:77:in run' /Users/mgavas/.rvm/gems/ruby-2.5.5/gems/rake-12.0.0/exe/rake:27:in <top (required)>'
/Users/mgavas/.rvm/gems/ruby-2.5.5/bin/rake:23:in load' /Users/mgavas/.rvm/gems/ruby-2.5.5/bin/rake:23:in '
/Users/mgavas/.rvm/gems/ruby-2.5.5/bin/ruby_executable_hooks:24:in eval' /Users/mgavas/.rvm/gems/ruby-2.5.5/bin/ruby_executable_hooks:24:in '
RuntimeError`
Sample model code
`require_relative "application_record"
module ReportParser
module UnderwritingData
# ActiveMocker.all_methods_safe
class AvmDbProperty < ::ReportParser::UnderwritingData::ApplicationRecord
self.table_name = "avm_db_properties"
has_many :avm_db_property_mortgages, class_name: "ReportParser::UnderwritingData::AvmDbPropertyMortgage"
  module PropertyValueLabels
    def property_value_label
      "ez_value"
    end

    def property_attribute_name
      if self.try(:property_state) == "FL"
        "avm_high"
      else
        "high_low_avg_avm"
      end
    end
  end
  include PropertyValueLabels
  extend PropertyValueLabels

  def property_value
    return avm_valuehigh if property_state == "FL"
    avm_value_amount
  end

  def confidence_score
    avm_confidence_score
  end

  def valuation_date
    black_knight_avm_updated_at
  end

  def table_name
    self.class.table_name
  end
end

end
end
`

@mahigawas28 can you try using the latest version and see if your issue persists?

Thanks for that extra information. I can try to dig into this sometime this week.

@mahigawas28 I have been trying to reproduce this error and have been unable, but I could have a solution although I am unable to test it.
Add the following monkey patch to config/initializers/active_mocker.rb
module ActiveMocker
  class MockCreator
    module DefinedMethods
      def class_methods
        class_introspector
          .get_class
          .methods(false)
          .reject {|m|  [:__missing_class_macros__].include?(m.to_sym)}
          .sort
          .map { |m| create_method(m, :method) }
      end
    end
  end
end

If you find that there are more methods like __missing_class_macros__ showing up add it to the array.
I know this is only a hack, but the only way I could possible find a way to fix this is for you to give me a minimal repo that reproduces the error.


Add placeholder :1 and $1

Solution for other placeholders

Thanks for this! Very useful :+1:
It might make sense to merge the original question mark Literal::Placeholder with the new Literal::OtherPlaceholder, since (at least in the SQLite grammar), question marks can also be followed by parameter numbers. Likewise, SQLite also supports @ as a placeholder, and we might add that as well.
So, I'm thinking to turn Literal::Placeholder into Literal::Placeholder(ItemPlaceholder), and extend ItemPlaceholder with QuestionMark and AtSign variants.
What do you think?

Sorry, I still can not find time to finalize.

Implemented in #58, so closing this. Thanks!


Give hfrost admin permissions in H2

Hannah needs to be able to see everything.

Amy indicated that Hannah is already a member of the admin group, so the problem here is that Hannah is not seeing the "All Collections" table.  This is only show to members of that group, so it's likely that the groups are not being set correctly for Hannah.  We may need a developer to add some logging around this code and see what is going on:
https://github.com/sul-dlss/happy-heron/blob/5ddeb9434aeb8eadf4c8ad1c53e68d6af5e6f408/app/controllers/application_controller.rb#L35-L48

solved with a logout/login


Regression (?) with resolver=2, cargo build -p, and workspaces

Problem
Let's say you have a workspace that contains a library (library) and some tooling (tool). Something like this. You want the library to support no_std, but the tooling does not. (In general, this isn't specific to tooling, perhaps a subset of your workspace supports no_std)
One would expect that building library for a baremetal target would work (and build serde with no_std), and building the entire workspace or tool for a baremetal target would not. Furthermore, it's common to use cargo build -p serde to just build serde; and it's useful if it builds the serde that-would-be-built-by-running-cargo build-in-the-same-folder, because it helps for things like incrementally getting dependencies to work with no_std.
This is indeed how it works on resolver = "1", note that cargo check and cargo check -p serde both succeed from the library folder, but not the root folder:

[10:09:15] मanishearth@manishearth-glaptop ~/sand/workspace-test/library ^_^
$ cargo check --target thumbv7m-none-eabi
(succeeds)
[10:09:22] मanishearth@manishearth-glaptop ~/sand/workspace-test/library ^_^
$ cargo check --target thumbv7m-none-eabi -p serde
(succeeds)
[10:09:27] मanishearth@manishearth-glaptop ~/sand/workspace-test/library ^_^
$ cd ..
[10:09:29] मanishearth@manishearth-glaptop ~/sand/workspace-test ^_^
$ cargo check --target thumbv7m-none-eabi
(fails)
[10:09:33] मanishearth@manishearth-glaptop ~/sand/workspace-test O_o
$ cargo check --target thumbv7m-none-eabi  -p serde
(fails)

However, with resolver = "2", cargo check succeeds in the library folder, but not cargo check -p serde:

[10:45:55] मanishearth@manishearth-glaptop ~/sand/workspace-test/library ^_^
$ cargo check --target thumbv7m-none-eabi
(succeeds)
[10:45:58] मanishearth@manishearth-glaptop ~/sand/workspace-test/library ^_^
$ cargo check --target thumbv7m-none-eabi  -p serde
(fails)
[10:46:02] मanishearth@manishearth-glaptop ~/sand/workspace-test/library ^_^
$ cd ..
[10:46:03] मanishearth@manishearth-glaptop ~/sand/workspace-test ^_^
$ cargo check --target thumbv7m-none-eabi
(fails)
[10:46:05] मanishearth@manishearth-glaptop ~/sand/workspace-test O_o
$ cargo check --target thumbv7m-none-eabi  -p serde
(fails)

This seems a bit counterintuitive to me: the new resolver is intended to reduce this kind of problem. It would be nice if the old behavior still worked here, and this seems like a regression to me.
Steps

Check out https://github.com/Manishearth/cargo-resolver-bug
Uncomment the resolver = "2" line in Cargo.toml
Install some no_std target (I'm using thumbv7m-none-eabi). You can alternatively use -v in the build commands to check if serde is built with std enabled
cd library && cargo check --target thumbv7m-none-eabi  -p serde

Notes
Output of cargo version:
$ cargo version
cargo 1.55.0-nightly (9233aa06c 2021-06-22)

This was an intentional change as part of making it less magical as to changing behavior based on the "current" directory (part of package-features in #5364, RFC #2957).

it's common to use cargo build -p serde to just build serde

I'm a bit surprised to hear this is "common", as I haven't really seen that done before.  Is there some reason you can't just run cargo check to see how the dependencies would build?  Why would you need to build a specific one?

I'm a bit surprised to hear this is "common", as I haven't really seen that done before. Is there some reason you can't just run cargo check to see how the dependencies would build? Why would you need to build a specific one?

It's super common in large codebases when doing a major refactor -- sometimes you wish to focus on a specific dependency, and it's not necessarily clear if a compile failure comes from:

A different dependency building first
Your dependency being "fixed" (now you can move on)
Your attempts at fixing one thing breaking something else earlier in the pipeline

You can get this clarity by using -v and checking which crates get built, and also by knowing the dep graph, but for large codebases this is still annoying.
For example, right now I'm moving a codebase over to no_std and it's important to be able to do this crate by crate, especially for external dependencies like serde (need to be able to make sure it's being built with the correct features, etc)
I think this is a pretty important use case tbh, it makes such work much much harder. Perhaps there could be a different flag, but I don't think this is that uncommon for large codebases.


Set default Windows charset to UTF-8

As reported on Reddit: https://www.reddit.com/r/java/comments/jxllez/java_development_on_windows_request_for/gcxhwo5/

For reference: https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/


return an error when Write is called on a closed stream

Codecov Report

Merging #773 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #773      +/-   ##
==========================================
+ Coverage   91.33%   91.34%   +<.01%
==========================================
  Files          79       79
  Lines        5724     5726       +2
==========================================
+ Hits         5228     5230       +2
  Misses        311      311
  Partials      185      185

Impacted Files
Coverage Δ

stream.go
97.81% <100%> (+0.02%)
:arrow_up:

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 3e012f7...77d4573. Read the comment docs.


chore: release 1.2.0

:robot: I have created a release *beep* *boop*
1.2.0 (2019-08-20)
Bug Fixes

deps: update dependency yargs to v14 (e3e5872)

Features

introduce v1p2beta1 client (#181) (675ae04)

This PR was generated with Release Please.

Release is at https://github.com/googleapis/nodejs-asset/releases/tag/v1.2.0

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


Write a PromQL Parser

Should be able to parse incomplete queries.

Hint from Federic via slack:
it's probably outdated at this point but this is the yacc definition before it got removed https://github.com/prometheus/prometheus/blob/5602328c7ce724d9d0fb395147771f4fedabcb2f/rules/parser.y

No longer necessary since the plan is to use the upstream parser.


Question about exporting Mamba models to GGUF format for Ollama deployment

I am interested in deploying mamba within the Ollama framework. I was wondering if thers's a way to export Mamba models to GGUF format, or if there are any recommended methods for doing so.
Thanks a lot!

I'm not familiar with the GGUF format but perhaps others might be able to help.

https://github.com/ollama/ollama/issues/3023

ollama/ollama#3023

Thanks a lot


Import wallet from coldcard made paperwallet

Hi, how do i import wallet from paperwallet made with coldcard?
i have WIF

Unfortunately, this is not yet implemented. Given the many documented issues with paper wallets, I'm not sure it's worth implementing, especially since these keys are not deterministic, or follow BIP32.

how about just watch only, its useful to have for following transactions to
paperwallet/ opendime?
tir. 6. apr. 2021, 08:28 skrev craigraw @.***>:

Unfortunately, this is not yet implemented. Given the many documented
issues with paper wallets, I'm not sure it's worth implementing, especially
since these keys are not deterministic, or follow BIP32.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/sparrowwallet/sparrow/issues/91#issuecomment-813859715,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATRMIL3GIQVWFBBXEJ4MQQTTHKSW7ANCNFSM42MZE6LQ
.

Unfortunately that's not really any easier to implement. I'd like to support this, but it's a lot of work for a relatively niche use case.

Outstanding Action: Implement WIF import (paper wallet)
Proposed Priority: V. Low / NACK

Agree, closing this off.


Update main.py

The code above contained an error on line 138, where the sys.platform() method was called as if it were a function. However, sys.platform is a string that represents the platform on which the script is being executed, and not a function that can be called.

Thanks 😄


500 encountered from metaflow service

@russellbrooks reported the following issue
Metaflow service error:
Metadata request (/flows/TuningXGB/runs/572/steps/start/tasks/1821/metadata) failed (code 500): {"message":"Internal server error"}

For context, this was encountered as part of a hyperparameter tuning framework (each flow run is a model training evaluation) after ~6hrs with 125 runs successfully completed. Everything is executed on Batch with 12 variants being trained in parallel, then feeding those results back to a bayesian optimizer to generate the next.
The cloudwatch logs from Batch indicate that the step completed successfully, and the Metaflow service error was encountered on a separate on-demand EC2 instance that's running the optimizer and executes the flows using asyncio.create_subprocess_shell. Looking at API Gateway, the request rates seemed reasonable and its configured without throttling. RDS showed plenty of CPU credits and barely seemed phased throughout the workload. Each run was executed with --retry but this error seems to have short-circuited that logic and resulted in a hard-stop.

@russellbrooks can you try using the provided python client for the metadata service to access the task for your run you reported issues with?
Something like
from metaflow import namespace, Run
namespace(None)
run = Run('TuningXGB/572')

for step in run:
    print(step)

Hey @ferras appreciate the help!
Running:
from metaflow import namespace, Run
namespace(None)
run = Run('TuningXGB/572')

for step in run:
    print(step)

gives the start step as expected Step('TuningXGB/572/start'). The flow terminated with the 500 service error before starting the next (end) step.
For what it's worth – I'm able to load all of the task artifacts from within step.task.data.
from metaflow import namespace, Run
namespace(None)
run = Run('TuningXGB/572')

for step in run:
    print(step)

    # Just testing that we can actually load the artifacts from S3.
    for artifact in step.task.data._artifacts:
        print(f"{artifact}: {step.task.data.__getattr__(artifact)}")

can you access the metadata associated with the task?

The task metadata is accessible:
from metaflow import Step
Step('TuningXGB/572/start').task.metadata

[Metadata(name='attempt', value='0', created_at=1581380003965, type='attempt', task=Task('TuningXGB/572/start/1821')),
 Metadata(name='attempt-done', value='0', created_at=1581380003965, type='attempt-done', task=Task('TuningXGB/572/start/1821')),
 Metadata(name='code-package', value='{"ds_type": "s3", "sha": "9efdd934eb15e79f0da12b1f1e116df0fa5c7fc9", "location": "s3://......./TuningXGB/data/9e/9efdd934eb15e79f0da12b1f1e116df0fa5c7fc9"}', created_at=1581380003965, type='code-package', task=Task('TuningXGB/572/start/1821')),
 Metadata(name='log_location_stderr', value='{"ds_type": "s3", "location": "s3://......./TuningXGB/572/start/1821/0.stderr.log", "attempt": 0}', created_at=1581380003965, type='log_path', task=Task('TuningXGB/572/start/1821')),
 Metadata(name='log_location_stdout', value='{"ds_type": "s3", "location": "s3://......./TuningXGB/572/start/1821/0.stdout.log", "attempt": 0}', created_at=1581380003965, type='log_path', task=Task('TuningXGB/572/start/1821')),
 Metadata(name='origin-run-id', value='None', created_at=1581380003965, type='origin-run-id', task=Task('TuningXGB/572/start/1821'))]

The task stdout/stderr seems to point towards the culprit:
Step('TuningXGB/572/start').task.stdout
[KILLED BY ORCHESTRATOR]

Step('TuningXGB/572/start').task.stderr
[19da02fe-4dd6-4f72-88fe-460f61f1d217] Task is starting (status RUNNABLE)...
[19da02fe-4dd6-4f72-88fe-460f61f1d217] Task is starting (status STARTING)...
[19da02fe-4dd6-4f72-88fe-460f61f1d217] Task is starting (status RUNNING)...
[19da02fe-4dd6-4f72-88fe-460f61f1d217] Setting up task environment.
[19da02fe-4dd6-4f72-88fe-460f61f1d217] Downloading code package.
[19da02fe-4dd6-4f72-88fe-460f61f1d217] Code package downloaded.
[19da02fe-4dd6-4f72-88fe-460f61f1d217] Task is starting.
[19da02fe-4dd6-4f72-88fe-460f61f1d217] Using default logging configs, no overrides found.
... normal logs ...
[19da02fe-4dd6-4f72-88fe-460f61f1d217] Task finished with exit code 0.
[KILLED BY ORCHESTRATOR]

Looking at the Batch job, it shows successful completion on the first attempt without getting kicked off its spot instance (managed, spot compute environment).

so [KILLED BY ORCHESTRATOR] implies that you lost connection while your job was running. So doesn't seem like the failure was a result of the metadata service. I would suggest re-running your flow using resume
https://docs.metaflow.org/metaflow/debugging#how-to-use-the-resume-command

Interesting since it seems like it had already finished the Batch job for the first task and died while starting the next task.
Re-running the flow using resume --origin-run-id 572 does work as expected.
I do think you're right that this is more likely related to either metaflow's runtime or potentially how these flows are being executed as subprocesses in asyncio.
Another interesting observation after repeating the process, this time getting through 244 flow runs in ~12hrs before an error occurred  – the end step was submitted and finished successfully on Batch but the runtime bombed after starting it.
From cloudwatch logs, captured stdout from the subprocess flow execution:
2020-02-11 07:02:01.889 Workflow starting (run-id 877):
2020-02-11 07:02:02.045 [877/start/3028 (pid 15173)] Task is starting.
2020-02-11 07:02:03.473 [877/start/3028 (pid 15173)] [d2820876-216b-4005-81f8-c7bfd452fb8a] Task is starting (status SUBMITTED)...
... first task logs ...
2020-02-11 07:03:14.694 [877/start/3028 (pid 15173)] [d2820876-216b-4005-81f8-c7bfd452fb8a] Task finished with exit code 0.
2020-02-11 07:03:15.456 [877/start/3028 (pid 15173)] Task finished successfully.
2020-02-11 07:03:15.797 [877/end/3031 (pid 15236)] Task is starting.
2020-02-11 07:03:17.366 [877/end/3031 (pid 15236)] list index out of range
2020-02-11 07:03:17.548 [877/end/3031 (pid 15236)] Task failed.
2020-02-11 07:03:17.548 This failed task will not be retried.

From cloudwatch logs, captured stderr from the subprocess flow execution:
Internal error:
The end step was not successful by the end of flow.

For comparison, here's stdout from metaflow for the step Step('TuningXGB/877/end').task.stdout):
list index out of range

stderr from metaflow for Step('TuningXGB/877/end').task.stderr) is empty.
What's really odd is that the Batch job for the end step was successfully submitted without showing up in the captured stdout logs and ran till completion. That's what is making me think something is going awry with metaflow runtime (maybe due to being executed via asyncio.create_subprocess_shell 🤷♂ ).
Curious what your all's thoughts are and again, really appreciate the help.

@russellbrooks do you see the same behavior when not running on batch?
@savingoyal do you see any potential problems on the batch side?

@ferras I have yet to see the behavior outside of running on batch.
Right now I have a couple tests running to try to narrow things a bit more:

(everything local) Trimmed the flow's steps to have just sleep(randint()). The bayesian optimizer still runs when any of the flows finish, but I'm just giving it a random number to simulate similar number crunching that occurs synchronously. The asyncio scheduler maintains 10 concurrent flow executions. Currently 652 flow runs in.
(everything local) Same as (1), but removing the optimizer completely and just using await asyncio.sleep(100) between making the new flow executions to simulate a somewhat short-running, synchronous process (FWIW it's typically <30s). Currently 108 flow runs in.
(flow runs on batch, optimizer + asyncio scheduler local): How it's been run previously, just giving it another go. Currently 147 flow runs in.

I've got all three of these running overnight and will follow up soon.

Hey guys, still been digging into this on my end and here's what I've found so far after letting these run for awhile:
When not using batch (with or without the mocked optimizer) and just running sleep statements, it works without errors for thousands of runs. FWIW this still uses S3 as a datastore and the metadata service.
When using batch for the task executions (still just sleep statements), it eventually hits:
list index out of range
The error seems to eventually occur as part of starting the end task from within the flow execution.
2020-02-13 07:25:19.045 [4346/start/14142 (pid 26351)] Task is starting.
2020-02-13 07:25:19.633 [4346/start/14142 (pid 26351)] [faf09017-46c7-45b3-bce3-4f5b656c05b6] Task is starting (status RUNNABLE)...
2020-02-13 07:25:23.803 [4346/start/14142 (pid 26351)] [faf09017-46c7-45b3-bce3-4f5b656c05b6] Task is starting (status STARTING)...
2020-02-13 07:25:26.935 [4346/start/14142 (pid 26351)] [faf09017-46c7-45b3-bce3-4f5b656c05b6] Task is starting (status RUNNING)...
2020-02-13 07:25:33.279 [4346/start/14142 (pid 26351)] [faf09017-46c7-45b3-bce3-4f5b656c05b6] Setting up task environment.
2020-02-13 07:25:36.493 [4346/start/14142 (pid 26351)] [faf09017-46c7-45b3-bce3-4f5b656c05b6] Downloading code package.
2020-02-13 07:25:36.493 [4346/start/14142 (pid 26351)] [faf09017-46c7-45b3-bce3-4f5b656c05b6] Code package downloaded.
2020-02-13 07:25:47.057 [4346/start/14142 (pid 26351)] [faf09017-46c7-45b3-bce3-4f5b656c05b6] Task is starting.
2020-02-13 07:25:47.057 [4346/start/14142 (pid 26351)] [faf09017-46c7-45b3-bce3-4f5b656c05b6] Sleeping for 8 sec.
2020-02-13 07:25:47.057 [4346/start/14142 (pid 26351)] [faf09017-46c7-45b3-bce3-4f5b656c05b6] Task finished with exit code 0.
2020-02-13 07:25:47.535 [4346/start/14142 (pid 26351)] Task finished successfully.
2020-02-13 07:25:47.726 [4346/end/14146 (pid 26445)] Task is starting.
2020-02-13 07:25:48.199 [4346/end/14146 (pid 26445)] list index out of range
2020-02-13 07:25:48.475 [4346/end/14146 (pid 26445)] Task failed.
2020-02-13 07:25:48.475 This failed task will not be retried.

Like before, it does actually kick off the batch job and it finishes successfully despite the flow execution tanking.
Misc
While doing these tests I also managed to hit the default service limit of CloudWatch Logs' GetLogEvents (10 req/s) from executing tons of these parallel flow executions on batch 😅
stdout
2020-02-13 06:47:26.538 [3911/end/12842 (pid 1470)] ClientError('An error occurred (ThrottlingException) when calling the GetLogEvents operation (reached max retries: 4): Rate exceeded')    Batch error:
2020-02-13 06:47:26.538 [3911/end/12842 (pid 1470)] Task failed!
2020-02-13 06:47:26.851 [3911/end/12842 (pid 1470)]
2020-02-13 06:47:27.038 [3911/end/12842 (pid 1470)] Task failed.
2020-02-13 06:47:27.038 Workflow failed.

stderr
Step failure:
    Step end (task-id 12842) failed.

All of that seems fine though and within the batch job/task it'll retry 5 times, independent of boto's retrying, before failing the task (still allowing batch retries on top from the flow's --with retry).

Thanks @russellbrooks. I have a few ideas that I will try out over the next few days to isolate the issue. This is indeed very helpful.

@savingoyal This appears to be a similar error to what I am experiencing on AWS Batch and which I communicated recently on the following Gitter thread:
https://gitter.im/metaflow_org/community?at=6088af4bda3e853b33d9096b
The main difference is that this issue is reporting the list index out of range error at the end step rather than in the middle of a 'fan-out' step (which is where I am experiencing the problem).

This issue also arises when running many concurrent foreach branches in batch. We didn't used to get this error with --max-workers=100, but for last couple of months we have and so we reduced to --max-workers=20 which "resolves" our situation for now (but I would really prefer to run --max-workers=100 😄 )

@jaklinger Thanks for commenting on this issue. That is exactly where I am experiencing the issuse... concurrent foreach branches being run on AWS Batch. I also didn't use to see it previously. In my case, I'm just running 16 workers at a time but I'm probably running about 60 total within a foreach fan-out.
@savingoyal This issue appeared again for me last night. It's happening about once every three or four days now.
Below was the status update shortly after the list index appeared in the logs:
2021-05-04 23:58:31.723 16 tasks are running: e.g. ....
2021-05-04 23:58:31.723 11 tasks are waiting in the queue.
2021-05-04 23:58:31.723 0 steps are pending: e.g. ....

Thanks for the extra data points. I am actively looking into this issue.

@dpatschke Can you help me out with the version of Metaflow (and service) that you are using? Also, does this happen always with AWS Batch only? If so, it could be an issue with AWS Batch calls and not the service itself.

@dpatschke @jaklinger Do you run into the same issue when you use METAFLOW_DEFAULT_DATASTORE=local python flow.py run --with batch? I have a few canaries bombarding the metaflow service and AWS Batch since last evening and I am yet to run into the issue 😞 Would you mind sharing what your Batch compute environment looks like and if you have any non-standard AWS API call limits in place?

I created the above issue https://github.com/Netflix/metaflow/issues/507 to provide wider visibility to this issue.

Hi @savingoyal - thanks for looking into this, much appreciated!
My compute environment is (I believe) the standard prescribed by metaflow via Cloudwatch:

Provisioning model: EC2
Minimum vCPUs: 0
Desired vCPUs: 0
Maximum vCPUs: 64
Spot fleet role: --
EC2 keypair: ***
Instance types m4.large, m4.xlarge, m4.2xlarge, m4.4xlarge, r5d.4xlarge
Instance role arn:aws:iam::******:instance-profile/nesta-metaflow-ECSInstanceProfile-LS7YJ38EBANG
Maximum % on-demand price: --
Allocation strategy: --

Regarding running METAFLOW_DEFAULT_DATASTORE=local python flow.py run --with batch: I've found that it produces the same outcode for max-workers=100.
Extra info on my tasks
My batch tasks produce very little output, and will run for up to 8 minutes. According to these lines in batch_client producing zero output will lead to persistent polling of CloudWatch logs. Split over my 100 max-workers will lead to 100 polls per seconds which is probably causing the GetLogEvents rate limit error - but I would assume that this issue wouldn't surface as quickly for tasks which are a) shorter and b) more verbose.
One solution would be to avoid clashes between unique instance calls of batch_client.BatchLogs.get_events, ensuring that max_workers / _sleep_on_no_data ~< 10 (10 reqs/s being the global log requests limit), or otherwise to dynamically set the polling time _sleep_on_no_data to ensure the limit is respected (i.e. _sleep_on_no_data = max_workers/10 + random_jitter()). This could lead to fairly long polling time (e.g. every 10 seconds) but in this case it's unavoidable due to AWS's hard limit. Other quick/static alternatives could be to increase the default _sleep_on_no_data from 1 to 10 (or more), or to impose a maximum max_workers when using batch?

I worked with @dpatschke to triage this issue (Many thanks!). Looks like AWS Batch refuses to send the correct response to the describe_jobs API call we make to ascertain job status for some requests (the response code is still 200). Upgrading to Metaflow 2.3.0 should address this issue https://github.com/Netflix/metaflow/pull/543.


error building version 23.1

Brand new Ubuntu 23.1 Server Build, Toshiba Satellite C855D, getting the following error when trying to build the package with sudo dpkg -i lcarsde-app-menu_23.1_amd64.deb:
dpkg: dependency problems prevent configuration of lcarsde-app-menu:
 lcarsde-app-menu depends on python3-posix-ipc; however:
  Package python3-posix-ipc is not installed.

installed posix-ipc with sudo pip3 install posix-ipc as doing without sudo causes install errors..

creating a new virtual environment solved the issue

I just got the same python3-posix-ips is not installed error and cant find a way to install it.  tried to install using apt, also with pip3 as noted above.  found .deb of it but that has an error preventing install.


Add aws-full command and refactor to remove workspaces

Execute pl002, pl003, pl004 and pl005 to execute all test.

I am currently testing, it seems there are some problems when executing multiple tasks with the same "workspace" like https://tekton.giantswarm.io/#/namespaces/test-workloads/pipelineruns/15c6597f-fb42-11eb-959d-fa3ca8521a07?pipelineTask=test-aws-pl002&step=run-tests
I will try to make this sequential and see if it works.

@MarcelMue do you have an idea why do I get this on the new pipeline I created:
https://tekton.giantswarm.io/#/namespaces/test-workloads/pipelineruns/1f6df920-fb54-11eb-bb04-b613c42b326b?pipelineTask=test-aws-pl002&step=run-tests&view=logs
panic: {"kind":"unknown","annotation":"unknown flag: --output","stack":[{"file":"/root/project/main.go","line":78}]}

goroutine 1 [running]:
main.main()
	/root/project/main.go:28 +0x2cf

towards: https://github.com/giantswarm/roadmap/issues/376


New Release?

There are currently 22 commits since the last release in December. Any chance we can get 1.5.1 released?

https://github.com/composer/installers/releases/tag/v1.6.0


Maps

I want to showcase a map showing user location
That would be much more descriptive view of weather.
Pls assign me

Go ahead! Contribute well🚀


On Heroku, SERVER_NAME should equal $DYNO

https://devcenter.heroku.com/articles/dynos#local-environment-variables
Maybe if $DYNO is present, we can just hook that up automatically. I wonder what a sane way to detect if we're on Heroku would be? Look for env variables with HEROKU in them? Look for a .heroku folder? Or is the presence of DYNO fine?

Although probably a "private API" in a sense, we could check for the presence of /etc/heroku, which we already do to get the release.


[SR-11625] SyntaxRewriter crashes when called from a thread other than main

Previous ID
SR-11625

Radar
None

Original Reporter
benpious (JIRA User)

Type
Bug

Environment
SwiftSyntax 0.50100.0, Xcode 11.1. Made a simple SwiftPM project, used generate-xcodeproj to make a project to open (double-clicking the Package.swift file did not produce a buildable project).

Additional Detail from JIRA

Votes
0

Component/s
SwiftSyntax

Labels
Bug

Assignee
None

Priority
Medium

md5: 9e3f668e7cbc4a6d8fd8813e5c6f08ad

Issue Description:
I'm trying to create and use a SyntaxRewriter subclass from a thread other than main. I'm not sharing between threads, so it seems like it should be fine. However, I get an EXEC_BAD_ACCESS inside of SwiftSyntax. Here's some sample code that demonstrates the problem, which is adapted from the SwiftSyntax README's sample code:
let string = """

protocol P {
    var x: Int? { get set }
}

"""

let queue = DispatchQueue.global()
let sourceFile = try! SyntaxParser.parse(source: string)
let semaphore = DispatchSemaphore(value: 0)
queue.async {
    _ = Renamer().visit(sourceFile)
    semaphore.signal()
}
semaphore.wait()
print("done")

It crashes with an EXEC_BAD_ACCESS, typically in `SyntaxRewriter.visitChildren()`. Trying to print any variables in the debugger outputs "Trying to put the stack in unreadable memory at <some memory address>".
I can't reproduce this in an optimized build.

I Guess the issue should be marked as resolved? Because in corresponding issues in JIRA all issues seems to be resolved

Dupe of https://github.com/apple/swift-format/issues/357


Rename internal search filters (with deprecation warnings)

From https://github.com/FlexMeasures/flexmeasures/pull/451#discussion_r952887454:
The distinction between the timing of beliefs and the timing of events is critical to our data model, and we welcome tweaks to make it more understandable. I expect we'll have to deal with some deprecation warnings in various plugins, though. Filters I'm considering renaming:

beliefs_before -> beliefs_formed_before
beliefs_after -> beliefs_formed_after
event_starts_after -> events_occurring_after or events_happening_after (in timely-beliefs, this should become event_ends_after)
event_ends_before -> events_occurring_before or events_happening_before (in timely-beliefs, this should become event_starts_before)

Relevant timely-beliefs PR: https://github.com/SeitaBV/timely-beliefs/pull/120


Added secure gRPC server option

Merging in finished tests

What this PR does / why we need it:
This PR gives KServe the ability to use gRPC's built-in support for ssl/tls to both authenticate requests & encrypt data.
Which issue(s) this PR fixes:
N/A
Type of changes:
New feature (non-breaking change which adds functionality)
Feature/Issue validation/testing:

Added tests for parse_grpc_server_credentials function to test_creds_utils.py.  4 unit tests testing 1) a valid file path, 2) an invalid file path, 3) a valid byte string, and 4) an invalid type.
Added test_server_grpc.py file to test the gRPC server using both secure and insecure option.  4 unit tests testing 1) an insecure gRPC server with an insecure gRPC request resulting in success, 2) a secure gRPC server with a secure gRPC request resulting in success, 3) a secure gRPC server with an insecure gRPC request resulting in failure, and 4) an insecure gRPC server with a secure gRPC request resulting in failure.

Existing test suite runs unchanged, as desired (as the option for secure gRPC should not impact existing - insecure - gRPC channels).
Special notes for your reviewer: N/A
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
Checklist:

[x]  Have you added unit/e2e tests that prove your fix is effective or that this feature works? - yes
[x]  Has code been commented, particularly in hard-to-understand areas? - yes
[ ]  Have you made corresponding changes to the documentation? - I have not updated any README docs, as the gRPC functionality is not noted in any docs as it currently exists

Release note:
Added option for gRPC requests to KServe to use gRPC's built-in dual authentication/encryption functionality that leverages SSL/TLS.  This release adds the option (which is excluded by default) to use this by passing a flag that the secure option is desired as well as the required certs to the ModelServer class via either the command line or constructor when it is started.  Note that the existing corresponding InferenceServerClient class already supports passing SSL/TLS certs to make authenticated & encrypted requests, so this update to the server class is sufficient to enable fully authenticated & encrypted channels.

@cbalbera-imaige Can you update the title and help sign off the commit ?

@cbalbera-imaige Can you update the title and help sign off the commit ?

Done - added signed commit & updated title, let me know if there's anything else!

@cbalbera-imaige Can you update the title and help sign off the commit ?

Done - added signed commit & updated title, let me know if there's anything else!

Thanks ! It looks like the DCO is not happy. Some commits missing signs https://github.com/kserve/kserve/pull/3752/checks?check_run_id=27575451511

@cbalbera-imaige can you help sign off the commits and resolve the conflicts ?

Hi Dan - working with Siva to get this wrapped, currently running into some testing questions. Will likely be in a different/clean PR to minimize conflicts as there has been a new major version release since this one was created.


[Feature] : Add Release Details Inside Components

Issue Description:
To enhance user experience by providing detailed information about the changes in each release, including new components or updates, directly inside the component or in the sidebar.
Proposal:
In every latest release, we should include small, informative details inside each component, clearly indicating whether it has been updated or is a new addition. This will help users quickly identify changes without having to refer to a separate release note.
Something Like this :

Hi @darkweb19,
Thank you for your valuable suggestion! We appreciate your feedback and totally agree that providing clear details about updates within each component is a fantastic idea.
We're planning to implement this in our next release or update. Additionally, we're considering a blog post to summarize all the updates and improvements, ensuring users have easy access to comprehensive information.
Your input is invaluable, and we're committed to enhancing the user experience. Stay tuned for the exciting updates, and thanks again for being part of the Keep React community!
Best regards,
Md Ariful Islam


Unable to debug Python tests (duplicate entries in "env")

Python: 3.7.5
VSCode: 1.43.2
Pytest: 5.4.1
Using virtual env.
Whenever I press "Debug All Tests" button I get the message: Invalid message: Duplicate entries in "env".

My launch.json file:
{
"version": "0.2.0",
"configurations": [
{
"name": "Python: Current File",
"type": "python",
"request": "launch",
"program": "${file}",
"console": "integratedTerminal"
}
]
}
The same thing happens if I try to debug any particular failed test.
Looking forward to your help!

Dupe of #10722
Try with this:
{
"name": "Python: Current File",
"type": "python",
"request": "test",  // <----- this is for tests
"console": "integratedTerminal"
}


Increased max thang-name-length to 60 characters

👍 Given that the tests pass, I think this is good to go.


Please merge 6bddb6c112d7f8c220397652f92f4263daf5ca12 and 57e11e3d55a12805324d17cc72555307eed032ee into dev channel

commit(s) to merge: 6bddb6c112d7f8c220397652f92f4263daf5ca12 and 57e11e3d55a12805324d17cc72555307eed032ee (original fix + status file patch)
merge instructions: clean merge
reason: Fixes issues with async debugging described in flutter/flutter#18877 which are also present in standalone Dart.
/cc @dgrove @kevmoo @mit-mit @whesse @athomas

Is this critical for GA? Could this land in our first patch release? CC @vsmenon

@a-siva - what do you think?  do we need this in 2.0?

If anyone is debugging and steps over an awaited Future with a closure
defined within the same asynchronous method, the debugger falls right
through all other breakpoints in the program. This is extremely confusing
and frustrating to run into, so I'd argue that from a dev-exp perspective
this is a big enough issue to warrant a fix being patched in for the 2.0
release.
On Thu, Jul 26, 2018 at 4:35 PM vsmenon<EMAIL_ADDRESS>wrote:

@a-siva https://github.com/a-siva - what do you think? do we need this
in 2.0?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dart-lang/sdk/issues/33996#issuecomment-408266850,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXFs4FMjVfdN7eyam-ody_v2OBnpxNl1ks5uKlJRgaJpZM4VirRJ
.

Is this a recent regression for Flutter? I think we're at the point now where we REALLY want to be picky about bugs we merge in.
We can get a dev release out with this the same week as stable – but we'd really like to keep the bar high for 2.00 GA

No, I believe this has been an issue since we moved to Dart 2 in general,
but it was only reported when Dan Tup ran into it during VsCode work. I
personally think this is a pretty major debugger regression, but if there's
going to be another release in the near future I guess it can wait.
On Thu, Jul 26, 2018, 5:01 PM Kevin Moore<EMAIL_ADDRESS>wrote:

Is this a recent regression for Flutter? I think we're at the point now
where we REALLY want to be picky about bugs we merge in.
We can get a dev release out with this the same week as stable – but we'd
really like to keep the bar high for 2.00 GA
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dart-lang/sdk/issues/33996#issuecomment-408270968,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXFs4Hpuc0ABrk8MVAG_B4QvsxWDuLygks5uKlhYgaJpZM4VirRJ
.

Merged in 2.0.0-dev.69.4


docs(tools): fix and update instructions for the Kakoune editor

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Use different config per queuing

Now we use queue as follows:
MathJax.Hub.Queue(['Typeset', MathJax.Hub, target, callback]);

But looks like Mathjax can't use individual configs per queuing like the following code:
MathJax.Hub.Queue(['Typeset', MathJax.Hub.override({}), target, callback]);

Can you support this usage?

Not all configuration options can be changed on the fly (e.g., which extensions are loaded, what font to use, etc.).  But some be, and for that, you can do
MathJax.Hub.Queue(
  ['Typeset', MathJax.Hub, target, callback],
  ['Config', MathJax.Hub, { ... (your configuration options) ... }],
  ['Typeset', MathJax.Hub, target, callback]
);

Or you could do them in individual queue calls:
MathJax.Hub.Queue(['Typeset', MathJax.Hub, target, callback]);
MathJax.Hub.Queue(['Config', MathJax.Hub, { ... (your configuration options) ... }]);
MathJax.Hub.Queue(['Typeset', MathJax.Hub, target, callback]);

if you prefer.

PS, remember that any following typeset operations use the last configuration that was set.

Thanks for the answer. I want to set the config temporarily because I want to use Mathjax in and from individual libraries. Can you support this usage in the future?

We are currently in beta test for MathJax v3, which is a complete rewrite of MathJax.  Configuration is handled very differently there, and so is the typesetting call itself, so these ideas don't really apply any longer.  It is unlikely that we will be extending the v2 interface at this point.

You can, of course, do something like
MathJax.Hub.Queue(['Config', MathJax.Hub, { ... (your configuration options) ... }]);
MathJax.Hub.Queue(['Typeset', MathJax.Hub, target, callback]);
MathJax.Hub.Queue(['Config', MathJax.Hub, { ... (your original options) ... }]);

to get temporary changes.
You may also find mathjax-node useful if you are doing server-side processing.  (Not sure what "in and from individual libraries" means.)

How can I revert the config correctly? Can you add the revert command as follows?
MathJax.Hub.Queue(['Config', MathJax.Hub, 'Revert']);

or
MathJax.Hub.Queue(['Config', MathJax.Hub, MathJax.Hub.Revert]);

MathJax.Hub.Queue waits for the completions of the each processing. Then if a queued process is an async process, another process can change the config and we can't revert the config to the last config. Seems like your code can't resolve that point. Is there any solutions?

As long as you are queuing your changes to the queue (as I have done above), then it won't change during another queued asynchronous process.  One should not be calling MathJax.Hub.Config() directly once MathJax has been started.  For example, if someone calls MathJax.Hub.Config() in a pause during your queued typeset operation, it is not clear what a "reset" of the configuration should be.  Should it be to the state of the configuration before your queued typeset?  (This would completely lose the changes that were made, which probably isn't the right behavior.)  Should it be to reset the values that you changed (which is what my code would do)?  (This could lose some of the changes made during the typeset operation.)  I don't think there is a correct answer; the problem is that the intermediate configuration change should not be performed.  The only rational way to handle it is to queue it like the other changes to guarantee that the oder of operations is preserved.
I would point out that your suggested API changes suffer from the same issue.  If a configuration change occurs while the typeset is occurring, it is not clear what the configuration should be set back to at the end.

Then supporting individual configs per queue is the only way to resolve the issue. https://github.com/mathjax/MathJax/issues/2061#issuecomment-428709095 is imperfect.

Is it impossible to request that feature?

Then supporting individual configs per queued items is the only way to resolve the issue.

As I pointed out, it doesn't.

Is it impossible to request that feature?

I've marked this issue as a feature request, but there are no current plans to implement it.

I see, thanks.


Remove Gemfile.lock

In general, gems should not include a Gemfile.lock, as this can restrict the ability of applications using the gem to use different (but compatible) versions of dependencies.
see, e.g. http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
thanks for the helpful gem!

Thanks! Released a new gem version:
https://rubygems.org/gems/google_url_shortener/versions/1.0.2


ISSUE-372 # fix random number generation

PR branch : https://github.com/sparrowV/zerocode
Fixed the issue of generating random numbers.

CI is green now.
https://travis-ci.org/github/authorjapps/zerocode/builds/681902206
But there is a sync issue from Travis... wierd!


Feature Request: Add a release pipeline with zip / tar files

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description
Is your feature request related to a problem?

In order to gain some usage stats, we can't use the default release zip / tar files since there are no download stats available from the GitHub API for them.
Describe the solution you'd like

If we create some artefacts for each release, we can then target them from the PowerShell module and get some stats. There will be no functionality or content changes, just a different file name.

There aren't any known alternatives outside of adding telemetry to the code, which is overkill at this time.
Additional context

Completed and released


List of classifiers is hardcoded in "Inductive Miner"

I have taken a log that has several classifiers and instead:

Hi, already make the classifiers include more items. Thanks for your advice.


Simple file cache for calendars, avoid repeating expensive fabrication

Annoyed by long runtimes of creating large calendars, I've introduced a simple file cache. Write fabricated calendars to users` cache; then search cache for matches before ~searching the dict~ fabricating (edit: that didn't make sense).
If cached calendar older than 24 hours then it is ignored & eventually overwritten. Stops cached calendars never updating.
Uses appdirs module to get user cache folder path, so should be cross-platform. Specifically: user_cache_dir() - their README provides actual path for each platform: https://pypi.org/project/appdirs
Benchmark
My use case is creating full calendars across multiple exchanges. Was ~10 seconds, now 0.4 seconds (once cache initialised).
import exchange_calendars as xcal
from time import perf_counter

exchanges = ["XNYS", "XTSE", "XLON", "XAMS", "XTAE", "XASX", "XNZE"]

t1 = perf_counter()
for e in exchanges:
	cal = xcal.get_calendar(e, start=1950, cache=True)
t = perf_counter()-t1
if t < 2:
	print("loading from file cache: {:.2f}s".format(t))
else:
	print("creating from scratch: {:.2f}s".format(t))

t1 = perf_counter()
for e in exchanges:
	cal = xcal.get_calendar(e, start=1950, cache=True)
print("loading from dict cache: {:.2f}s".format(perf_counter()-t1))

Output:

first pass

creating from scratch: 11.22s
loading from dict cache: 0.00s

second pass

loading from file cache: 0.42s
loading from dict cache: 0.00s

Cache contents after run:

ls ~/.cache/py-exchange_calendars
calendar-XAMS.pkl  calendar-XLON.pkl  calendar-XNZE.pkl  calendar-XTSE.pkl
calendar-XASX.pkl  calendar-XNYS.pkl  calendar-XTAE.pkl

There used to be an automatic cache that we dropped. I like the idea of an optional one.
This PR would need tests added to it.

I removed appdirs dependency by copying code into appdirs_clone.py. Not sure it's better because I now can't guarantee   it'll work on Windows or Mac - different codepaths.
All but 1 flake8 'unused variable' errors relate to appdirs code, which upon close investigation are false postiives. E.g.
            try:
                if PY3:
                    import winreg as _winreg
                else:
                    import _winreg
            except ImportError:
                _get_win_folder = _get_win_folder_from_environ
            else:
                _get_win_folder = _get_win_folder_from_registry

The other flake8 error in test_exchange_calendar.py refers to code that doesn't exist, no idea what's going on.

Adding a personal ToDo: embed module version into cached calendars, so they expire when new version installed. Easy to implement.

Module version now embedded in the cached calendars

@maread99 Is there anything else outstanding before this can merge?

Hi @ValueRaider, implementing a permanent cache would be @gerrymanoim's call.
The tests would need to pass. Couple of options might be:

use appsdir but make it an optional dependency so that the requirements are no heavier than needs be.
limit caching to a temporary in-memory cache (which is what was there before) and leave it to clients to implement anything more permanent.

@gerrymanoim, if you decide to implement this perhaps you'd give me an opportunity to have a look through before you merge. Cheers.

exchange_calendars already has an in-memory cache.
I've just found a package that solved this problem cleanly without appdirs, so can port in a fix for tests.

The port here seems to be copying the file with appdirs with the copyright? But maybe I'm missing something.
Does picking the calendar yourself and loading it as needed in your own processing work for your use cases? i.e. something like
import pickle

exchanges = ["XNYS", "XTSE", "XLON", "XAMS", "XTAE", "XASX", "XNZE"]
calendars  = dict()
for exchange in exchanges:
	calendars[exchange] = xcal.get_calendar(exchange, start=1950)

pickle.dump("calendar_cache.pkl")

and then loading that?
I think I'm leaning against having a cache in exchange_calendars itself but I'm open to suggestions on how we can help users solve their own caching needs. Alternatively we could do something like dumping the compressed numpy data somewhere and providing an easy way to hydrate the calendars directly.

exchange_calendars already has an in-memory cache although very basic.

So it does - I thought we'd removed it but looks like just I revised it to accommodate kwargs. Sorry, terrible memory, I should have looked.

The port I referred to has much simpler logic for handling Windows, but possibly wouldn't work on unusual/older Windows as I'm sure the appdirs complexity has a purpose.
There's no pressing need for this caching to be in xcal, I just thought it would be useful. Can roll my own.
A final suggestion: the memory cache would be much more useful if it could smartly handle:

get_calendar("XNYS", 2022)
get_calendar("XNYS", 2021)
get_calendar("XNYS", 2022)
... and so on
Currently (2) overwrites (1)

4. Currently (2) overwrites (1)

This was intentional. On a default "24/7" calendar the length of the .minutes attribute is over 11_000_000. sys.getsizeof returns its size as 88MB.


Slow producer when messages are published on multiple threads to same broker and topic

Description
The producer performance turns out to be very slow, takes up to 2 seconds in publishing messages on each thread. Each thread is publishing a batch of messages using ProduceAsync and then waiting for the batch to finish so that we can handle the errors for the batch on that thread. Running the same code on one thread to publish same amount of messages in batch takes significantly less time (0-50ms) .
After reading lots of threads, tried various options but it could not work as expected in multiple thread scenarios.
SampleKafkaProducer.zip
How to reproduce
Run the below code via a Windows Console Application .Net framework 4.6.2 using nuget version 1.0.0-RC1
This code has two methods

PublishParallel sends 2K messages to a topic on 100 threads in a batch of 20 messages
PublishSequential sends 2K messages on same topic on 1 thread in a batch of 20 messages

Application first run PublishParallel and print each batch time and total time and then prompt to run the same test using PublishSequential.
`using Confluent.Kafka;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace SampleKafkaProducer
{
class Program
{
    static void Main(string[] args)
    {
        DateTime start = DateTime.Now;

        PublishParallel("test-topic");
        Console.WriteLine($"done parallel {(DateTime.Now - start).TotalMilliseconds}");

        Console.WriteLine("Press any key to send messages on one thread");

        Console.ReadLine();
        start = DateTime.Now;
        PublishSequential("test-topic");
        Console.WriteLine($"done one thread {(DateTime.Now - start).TotalMilliseconds}");

        Console.ReadLine();

    }

    static void PublishParallel(string topic)
    {
        try
        {
            //parallel for loop spinning 100 threads to publish messages to same topic using same instance of producer.
            Parallel.For(0, 100, (count) =>
            {
                //always get same producer instance
                KafkaPublisher kafka = KafkaFactory.GetPublisher();
                List<string> messageList = new List<string>();
                for (int i = 0; i < 20; i++)
                    messageList.Add($"{count} - this is a test message {i.ToString()}");

                kafka.Publish(messageList, topic);
            });
        }
        catch (AggregateException ex)
        {

            var exceptions = from e in ex.InnerExceptions
                             select e as ProduceException<string, string>;

            foreach (var exc in exceptions)
                Console.WriteLine(exc != null ? "error:" + exc.DeliveryResult.Key.ToString() : "");

            Console.WriteLine(ex.ToString());
        }

    }

    static void PublishSequential(string topic)
    {
        try
        {
            for(int count = 0; count < 100;  count++)
            {
                //always get same producer instance
                KafkaPublisher kafka = KafkaFactory.GetPublisher();
                List<string> messageList = new List<string>();
                for (int i = 0; i < 20; i++)
                    messageList.Add($"{count} - this is a test message {i.ToString()}");

                kafka.Publish(messageList, topic);
            };
        }
        catch (AggregateException ex)
        {

            var exceptions = from e in ex.InnerExceptions
                             select e as ProduceException<string, string>;

            foreach (var exc in exceptions)
                Console.WriteLine(exc != null ? "error:" + exc.DeliveryResult.Key.ToString() : "");

            Console.WriteLine(ex.ToString());
        }

    }
}

internal class KafkaFactory
{
    static KafkaPublisher _publisher;
    static object _syncRoot = new object();
    internal static KafkaPublisher GetPublisher()
    {
        if (_publisher != null)
            return _publisher;

        else
        {
            lock (_syncRoot)
            {
                if (_publisher != null)
                    return _publisher;
                else
                {
                    Console.WriteLine("Creating new object");
                    _publisher = new KafkaPublisher();
                    return _publisher;
                }

            }
        }
    }

}
internal class KafkaPublisher : IDisposable
{
    IProducer<string, string> _producer;
    internal KafkaPublisher()
    {
        var config = new ProducerConfig { BootstrapServers = "localhost:9092" };
        //
        config.MessageSendMaxRetries = 0;
        config.MessageTimeoutMs = 10000;
        config.BatchNumMessages = 100;
        config.TopicMetadataRefreshIntervalMs = 10;
        //config.Debug = "all";

        //config.SocketNagleDisable = true;
        _producer = new ProducerBuilder<string, string>(config).Build();
    }

    public void Publish(List<string> messageList, string topic)
    {
        int i = 0;
        DateTime start = DateTime.Now;
        var tasks = from message in messageList
                    select _producer.ProduceAsync(topic, new Message<string, string> { Key = i++.ToString(), Value = message });

        Task.WaitAll(tasks.ToArray());
        Console.WriteLine($"published: {(DateTime.Now - start).TotalMilliseconds}");
    }
    public void Dispose()
    {
        if (_producer != null)
            _producer.Dispose();
    }
}

}
`
Checklist
Please provide the following information:

[x] Confluent.Kafka nuget version: 1.0.0-RC1
[x] Apache Kafka version: kafka_2.12-2.1.1 on Windows 2012 R2 DataCenter
[x] Client configuration: see app
[x] Operating system: Windows 2012 R2 Data Center
[ ] Provide logs (with "debug" : "..." as necessary in configuration) - Tried capturing debug info, nothing showed up when enabled.
[ ] Provide broker log excerpts
[ ] Critical issue

thanks @vikas15bhardwaj for providing a complete minimal example demonstrating the problem - was able to replicate, and also see the same behavior on linux. It's not immediately obvious to me why this is occurring, so want to look into it, however likely won't until after the 1.0 release.
As a general comment I think it's a good idea to avoid waiting on bunches of produce results in this way, unless it's a strong match to the specific use case.

Thanks Matt for quickly responding and reproducing it. I understand wait is not desirable but if we want to ensure messages are delivered and if we need to take some action on those messages after publishing, we have no option but to call wait. After looking into more, I also changed my above sample code Publish method slightly to use ContinueWith in addition to WaitAll
 var tasks = from message in messageList
                        select _producer.ProduceAsync(topic, new Message<string, string> { Key = i++.ToString(), Value = message })
                        .ContinueWith((dr) =>
                            {
                                //Console.WriteLine($"published: {(DateTime.Now - start).TotalMilliseconds}");
                                Console.WriteLine(dr.Result.TopicPartitionOffset.ToString());
                            });

            Task.WaitAll(tasks.ToArray());

and it gave me better results. I am not sure though why and how. This didn't fix it everything for me. As when I applied to my actual solution, it gave me inconsistent results, especially at the start of the process or when few thousands of small batch messages are sent on multiple threads concurrently. In these cases, I noticed ProduceAsync keep sending messages to Kafka but it does not return the thread to complete the wait and as a result threads keep waiting. Is this something you can look at before 1.0 release as it may help multiple people.

Below are four alternatives (with commentary) to what you are trying to do, all of which are fast. I admit to not fully understanding the root cause of why Parallel.For doesn't play nicely with ProduceAsync, but I did read it doesn't play nicely with async/await methods, and I think it's unlikely to be exactly what you want, so i didn't investigate further.
Test2: Is close to what you're trying to do - it uses Parallel.For but instead of ProduceAsync, uses BeginProduce. Note that BeginProduce is much faster than ProduceAsync because it has less overhead. It also doesn't have any async code so it works with Parallel.For. The (conceptual) problem with this variation is it wastes threads - there will be many threads blocking (the degree of the problem depends on the characteristics of the tasks). As it turns out, the overhead of this in these toy cases is minimal and this approach is very fast.
Test4: is Test2, but uses Task.Run instead of Parallel.For. I suspect this is what you would use in practice a real application (not parallel for). This is also very fast.
Test1: this is how to set it up properly in a fully async manner. Conceptually, no wasting of threads going on, but all the Tasks and async/await state machine overhead makes this about 3x slower than Test2 or Test4.
Test3: A cross between the above methods (primarily async). About the same performance as Test1.
In conclusion, if you want to set things up in a nice async way, go with something like Test1. If you're concerned with getting the highest performance possible, something like Test4 is probably going to win.
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Threading;
using System.Linq;
using System.Threading.Tasks;
using Confluent.Kafka;
using Confluent.Kafka.Admin;

namespace TestParallel
{
    class Program
    {
        async static Task BatchTask(IProducer<int, string> producer)
        {
            var tasks = Enumerable.Repeat<int>(0, 1000)
                .Select((_, i)
                    => producer.ProduceAsync(
                        "parallel-test-topic",
                        new Message<int, string> { Key = i, Value = $"message {i}" }))
                .ToArray();
            await Task.WhenAll(tasks);
            // await DoOtherStuff(); - other stuff that depends on the above being completed.
        }

        static void Test1(IProducer<int, string> producer)
        {
            var tasks = Enumerable.Repeat<int>(0, 1000)
                .Select(_ => BatchTask(producer))
                .ToArray();
            Task.WaitAll(tasks);
        }

        static void BatchTask2(IProducer<int, string> producer)
        {
            var N = 1000;
            var drCount = new CountdownEvent(N);
            for (int i=0; i<N; ++i)
            {
                producer.BeginProduce(
                    "parallel",
                    new Message<int, string> { Key = i, Value = $"message {i}" },
                    dr =>
                    {
                        drCount.Signal();
                    });
            }
            drCount.Wait();
        }

        static void Test2(IProducer<int, string> producer)
        {
            Parallel.For(0, 1000, count => BatchTask2(producer));
        }

        static void Test3(IProducer<int, string> producer)
        {
            var tasks = new List<Task>();
            for (int i=0; i<1000; ++i)
            {
                tasks.Add(Task.Run(async () =>
                {
                    await BatchTask(producer);
                }));
            }
            Task.WaitAll(tasks.ToArray());
        }

        static void Test4(IProducer<int, string> producer)
        {
            var tasks = new List<Task>();
            for (int i=0; i<1000; ++i)
            {
                tasks.Add(Task.Run(() =>
                {
                    BatchTask2(producer);
                }));
            }
            Task.WaitAll(tasks.ToArray());
        }

        static void Main(string[] args)
        {
            var config = new ProducerConfig
            {
                BootstrapServers = "<IP_ADDRESS>:9092",
                LingerMs = 5,
                QueueBufferingMaxMessages = 2000000
                // Debug = "msg"
            };

            using (var producer =
                new ProducerBuilder<int, string>(config)
                    .SetLogHandler((p, m) =>
                    {
                        Console.WriteLine(DateTime.Now.ToString("HH:mm:ss.FFF") + " " + m.Message);
                    })
                    .Build())
            {
                var methods = new Action<IProducer<int, string>>[] { Test1, Test2, Test3, Test4 };

                foreach (var method in methods)
                {
                    Stopwatch sw = new Stopwatch();
                    sw.Start();
                    method(producer);
                    Console.WriteLine($"total time: {sw.Elapsed}");
                }
            }
        }
    }
}

Thanks Matt for providing these options, I will look into these and will try. I also changed on my side the patterns threads were being creating and it removed the thread blocking issue. I will also give these options a try. For now I think I am good.


[SPARK-19877][SQL] Restrict the nested level of a view

What changes were proposed in this pull request?
We should restrict the nested level of a view, to avoid stack overflow exception during the view resolution.
How was this patch tested?
Add new test case in SQLViewSuite.

Test build #74318 has started for PR 17241 at commit 15e5366.

@jiangxb1987 I am not entirely sure about the usefulness of this (I thought it might be good to enforce some restriction when we wrote the design doc). I don't think it matters much what we do from an end user perspective: either analysis succeeds or it fails, only the error message is slightly different. WDYT?

@hvanhovell From an end user perspective, there may be two major differences:

If the nested level exceed the value, the user will see a explict message about what caused the failure, instead of an exception that may be confusing;
We don't have to wait for a long time to trigger a exception, we can fail earlier by setting a proper value for the property spark.sql.view.maxNestedViewDepth.

Test build #74318 has finished for PR 17241 at commit 15e5366.

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/74318/
Test PASSed.

Yeah you have a point there.
cc @rxin wdyt?

SGTM

Test build #74355 has started for PR 17241 at commit b4f9a57.

Test build #74355 has finished for PR 17241 at commit b4f9a57.

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/74355/
Test PASSed.

Please also add the related test cases. Thanks!

Test build #74483 has started for PR 17241 at commit 5c91ab7.

Test build #74483 has finished for PR 17241 at commit 5c91ab7.

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/74483/
Test PASSed.

Test build #74543 has started for PR 17241 at commit d28b676.

Test build #74543 has finished for PR 17241 at commit d28b676.

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/74543/
Test PASSed.

ping @hvanhovell @gatorsmile

LGTM

Thanks! Merging to master.


Added option to disable emitting events from native side

when event emitting is disabled from native side, then JS side will not receive unwanted events from native side.
when event subscription is removed then event emitting is disabled from native side for that event type and when event subscription is added then event emitting is enabled from native side.
If user does not want to disable event emitting from native side then this option is also available. This option is needed for the case when user is removing subscription and will add fresh subscriptions right away.
changing emitting events functionality is a braking change

I have not added Event Enable Status check in every place from where the event is being emitted. I need to discuss this with you @ygit


ci: implementing the integration testing in the ci with docker

this is somethings that we need to do when we have the base wrapper working on the CI, and an example can be this https://github.com/dart-lightning/lndart.clightning/tree/main/docker
If @gabbyprecious is new with docker on this I will take this task

Fixed in https://github.com/vincenzopalazzo/cln4go/pull/10


Consider adding ChatGPT description of this project to README.md

This is ChatGPT response to the What do you know about m3u-ipytv? prompt:

M3U is a file format used for multimedia playlists. It is commonly used for creating IPTV playlists to access live TV channels and on-demand content over the internet. IPYTV is a Python library that allows users to create, modify, and manage M3U playlists programmatically.
With M3U-IPYTV, users can generate M3U playlists from various sources and customize them according to their preferences. The library provides methods for adding or removing channels from a playlist, updating the channel information, and organizing the channels in different categories. It also allows users to filter channels by country or genre, and sort them alphabetically or by popularity.
M3U-IPYTV is open-source software and is available on GitHub. It requires some programming knowledge to use effectively, but it can be a powerful tool for creating personalized IPTV playlists.

Perhaps it could be used as overview in README.md

That's just useless.


[Feature] Enhance output formatting for code snippets

Story:
As a user, who works with code, I would like to have an improved readability of output of code snippets. At this point composed code outputs appear as a plane text, without any highlights and etc. It would be desired to have the similar output as given by "chat.openai.com" where it appears like it is given in a development environment, with all the components properly highlighted and an option to copy the code with a click of a button (screenshot attached).

While the same output from the app currently looks like that:

Add vote to this. Is the addition of a simple copy mechanism for chat responses within the development pipeline or is this something we should be looking at developing ourselves?


Allow symbol as default

As reported in #291

@clemera Not only symbol! As far as I've seen icomplete passes any default through! This is why I closed the original report as wontfix since I don't think it makes much sense. I think the default should be a string and only that.

Thanks, I think only list of strings and list of symbols additionally. At the moment when Selectrum gets passed a list we just take the car as default and behaviour wise this is the same as far as the return value is concerned when you submit the default, but I will recheck tomorrow.

@clemera For symbol lists completing read still returns strings for non-default values. Tbh I would enforce a stricter contract with cl-assert and see if things break.

Things will break in case people rely on this behaviour. For counsel it makes sense to improve such things but for Selectrum I would prefer to adhere exactly to the API whenever possible. See for example #180, there will always be corner cases of every idiosyncratic aspect of the API that packages or users rely on.

Sure, but I would probably be a bit more radical, enforce some contracts and rather push for changes in other packages. But this may not be the best behavior 😉
The question here is really how the api is meant to be used. If the packages are using accidental or undefined behavior, my approach would be justified.

As an alternative completion UI we need to output the same as completing-read-default. I would say even if the API is meant to be used differently we need to deal with how it could be used as we don't want to break existing code as a consequence of switching to Selectrum.

@clemera Sure, this is also a valid approach. But I still have a different opinion. I think it can be better to sometimes break things in that case and push for changes in other packages, as long as you are not overdoing it. In this particular case, it seems string-only default values worked well up to now.
Ideally the completing-read default implementation should enforce some contract. But since it does not, there is still some specification/documentation which can be used as a basis. Since the completing-read API is already a complex beast, I think enforcing rules a contract makes sense. @raxod502's approach of not passing through the initial argument also goes in that direction of enforcing some contract, but it was a step too far as we agreed in #254.
The issue #180 - I wonder about that. Maybe this is some accidental behavior in the other packages and there shouldn't been a reliance on the properties of the default value. But I think it also affected xref, in that case I would probably agree with passing things through since xref as part of upstream has an argument here.
But let's assume I find some really really weird edge case in icomplete completing-read and abuse it for consult, and it seems like an unintended effect, I think it would not be unreasonable from selectrum to refuse implementation.

But let's assume I find some really really weird edge case in icomplete completing-read and abuse it for consult, and it seems like an unintended effect, I think it would not be unreasonable from selectrum to refuse implementation.

Probably yes, but I think it depends how likely it is that there is other code out there which uses that edge case. In the case of symbols as default argument I don't think it is unlikely that someone uses it (you can also pass symbols as the collection).
For me not breaking existing code is most important but I also understand your point of view and it is certainly reasonable, too.

you can also pass symbols as the collection

This is how I found this - when adding support to symbol lists to consult--read. However the bad thing is that the non-default values which are returned are still strings, even if you have require-match set. Therefore I think the pass through of the default value is not a good idea. But as I said I am not necessarily disagreeing with your approach, it is just a matter of taste/preference and I tend to enforce contracts more strictly also because I am very much accustomed to strong type systems.

Another argument for personally is also the following - if I would find a package which breaks because it relies on a weird edge case, it is a good indicator for me to avoid a package or at least take a closer look and potentially submit a fix. I have the feeling that the whole Emacs system got somehow more robust over the years due to better maintenance, better idioms, lexical scoping etc. But years ago I often had problems with packages breaking randomly, but maybe this was also my lack of experience back then.


[AIRFLOW-1700] Support conn_type overwrite when url scheme is invalid

Dear Airflow maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA
https://issues.apache.org/jira/browse/AIRFLOW-1700
Description
When creating a new connection via airflow cli, the connection type is inferred from the conn-uri argument (i.e., conn_type = url scheme). However, for connection types like "hive_cli" and "google_cloud_platform", urlparse (by design) was unable to get the connection type as '_' is not a valid scheme character.
Tests

updated tests.core:CliTests.test_cli_connections_add_delete and local unit test passed without any issue.

@criccomini  PTAL and can we also get this into 1.9.0-alpha1?
Thank you.

Sorry, this duplicates with #2525.

Codecov Report

Merging #2682 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2682      +/-   ##
==========================================
+ Coverage   71.68%   71.69%   +<.01%
==========================================
  Files         154      154
  Lines       11814    11814
==========================================
+ Hits         8469     8470       +1
+ Misses       3345     3344       -1

Impacted Files
Coverage Δ

airflow/bin/cli.py
53.45% <100%> (ø)
:arrow_up:

airflow/models.py
87.14% <100%> (+0.04%)
:arrow_up:

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 21e94c7...56487b8. Read the comment docs.

Ack, missed that when I searched open issues re:conn_type. Thanks for the link.
@mrkm4ntr @criccomini
I like the ability to parse connection details from URI, it unfortunately breaks when scheme contains '_'. Instead of making every connection field accept cmd args (as in #2525), shall we just make conn-type overwritable? My concern is that It might be confusing when conn details can be set in multiple ways. I can also revise my PR to take conn_type only when scheme is None. IOW, conn_uri takes precedence over conn-type.  LMK.

@fenglu-g In my first commit, it was a fix like your suggestion to only add conn_type and overwrite it only if the schema is None. However, as discussed here,  I changed to the current fix because it is not preferable the schema of URI to be None.
I think that it is better to be able to give conn_uri which does not cause an error I think that it is better to be able to give conn_uri which does not cause an error even if contains _, or to give the same parameter as when registering from UI., or to give the same parameter as when registering from UI.
Anyway, if we continue discussion any further, I think I should do it here.

The discussion is moved to  #2525, closing this PR now.


Parameter inference breaks type intersection

TypeScript Version:  3.8.3 (also tested with 3.9.0-dev.20200425)
Search Terms:
inference
Code
type Effect<T, M> = {
  // NOTE: The problem seems to be here somewhere. Getting rid of the
  // intersection `& M` below gets rid of the error.
  do?: (o: T & M) => void;
};

type Obj = {};

function create<T, M>(params: {
  methods: M;
  effect: Effect<T, M>;
}): Obj & M {
  return params.methods
}

const obj = create({
  // If the parameter below is inferred then the Obj type
  // breaks and the methods are no longer merged in.
  // If a type is given (e.g. `obj:any`) the methods work
  // as expected
  effect:{do: (obj) => {}},
  methods: {
    something() {}
  }
});

// This will be an error if the effect infers the parameter type
obj.something();

Expected behavior:
Functions in methods should be merged into the type that is output by create or an error should be generated if there is a problem with the types.
Actual behavior:
Function in methods are only merged if do in effects is defined with explicitly typed parameters and no error is generated.
Playground Link: playground

The problem here is that you have no inference site for T, so T gets fixed to unknown, then this ends up with M getting unknown because of inference on the obj parameter. The straightforward fix is to just remove T from these declarations entirely. A more fleshed-out example might be something we could provide a better way to write a declaration for


Enforce JS style guide (again)

As reported in https://groups.google.com/d/msg/wagtail-developers/MjNuJnhXJv4/cPZX5LhnBgAJ - it appears that JS linting was broken when #2275 was merged (npm run lint:js now only checks the client folder). We need to:

fix the task to run across the whole codebase
add it to the make lint task https://github.com/torchbox/wagtail/blob/master/Makefile#L18-L20
fix the inevitable style violations that have crept in since #1237
add it to our CI setup

I tried this very briefly yesterday, works fine but it raises upwards of 5000 linting issues.
Waiting for the next release of Prettier (due sometime over the next few weeks, https://github.com/prettier/prettier/issues/2589), which has interesting config options, and could allow us to reformat all of the files in a sustainable way.

@thibaudcolas do you know of any progress on this one since you looked at this in 2017?
Prettier and Eslint have both had substantial updates in the last few years, using them together and help a lot. Eslint's fix option in conjunction with prettier can make a lot of minor linting issues automated.
I'm up to help with this if needed, I have implemented pretter/eslint configs on a few projects.
If we want to look in to pre-commit hooks, Husky seems to be a good option.

Nope, there's been no progress that I'm aware of. One of the problems to solve here is that files in client are transpiled with Babel, and bundled with Webpack, while the rest of the JS isn't. This means we'd need separate ESLint/Prettier configs, so we don't treat non-transpiled code as if it was  ES2015+.
I don't think this is particularly blocking though – main reason why this hasn't happened is that it's not particularly appealing to fix Wagtail's old JS.

@thibaudcolas - makes sense.
Hopefully this will become a bit easier when all code is moved to the webpack build process (client folder)
cc @jonnyscholes

See #5252. I think once that's done this JS linting enforcement issue will be 99% resolved.

Yep I'm linting the new JS as it goes in so in theory once that's all done all our JS will be consistent 😁
Although we might have to make some concessions for some jQuery plugins that whilst I'm hoping to remove, might have to stay around for a bit longer. Trying to avoid that though!

@jonnyscholes  - epic stuff, I am hoping to get some time to look at our external eslint config and get that upgraded :)
let me know if you need a hand with some of this stuff.

Following up a year later! 😄
https://github.com/wagtail/eslint-config-wagtail is now up-to-date with the Airbnb config and ESLint v6, thanks to work by @lb-. This is now released as @wagtail/eslint-config-wagtail. Next step here is to update the Wagtail codebase to use that config – I tried briefly and this raised lots of errors in client, which mostly seemed justified if we want to stick with quite a strict config.

For the JS that’s under different apps in wagtail/ – ESLint supports nested configurations. I would welcome a PR that adds a separate ESLint configuration file .eslintrc.js inside wagtail, overriding the configuration specifically for apps that are in there. I find it inelegant to have a separate config file in there, but pragmatically it would be useful for us to have some form of linting on those files, and they do need their own configuration. This config file will need to:

Lint for ES5 JS, while code under client/ can use ES2015+ syntax and APIs
Have configuration for a number of global variables used throughout this code (e.g. jQuery)

Otherwise I would welcome it being as lean as possible (extending eslint:recommended and then disabling as few rules as possible) – if there are rules that are only infringed on in a few places, I’d rather have local overrides with eslint-disable comments.

I believe #7536 (thank you @lb-!) covers enough of what this issue is about, so will close this now.

thanks @thibaudcolas


Automate release process via github actions

This PR automates the release process via Github actions.
It runs on two triggers:

When merged to main, the package is only published to TestPypi
When a new release is published, the package is published to PyPi.

I temporarily changed the triggers to get a test run on this PR:
https://github.com/spec-first/connexion/runs/5098593555

Yes they are. So only steps to release now are:

Push tag
Publish github release


Grafana+InfluxDB not on Default database

Hi,
I have setup influxdb + grafana. On grafana I have some other dashboard using same influxdb connection, so default dabase on the influx connection is not the one used by unpoller.
The result is that unpoller dashboard does not work, until I setup default db on influx connection, but this broke my other dashboard.
Is there a way to force dashboard to not use default connection and specify unflux DB name?
Thanks in advance

Do you have a datasource specifically named "InfluxDB-unifipoller"?
I have a default datasource of InfluxDB for other dashboards and one called "InfluxDB-unifipoller" which maps to the unifi database in Influx and everything just works...
If the above doesn't get you to a working setup let me know and I'll drop some screenshots here.

until I setup default db on influx connection

I'm not sure what this means? One of the steps/directions is to create a database named unifi. InfluxDB has no default database.

Is there a way to force dashboard to not use default connection and specify unflux DB name?

You may choose any database name you wish. You give the db name to the unpoller config. You give it to Grafana when you add the datasource.


v. 0.2.1

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/84106
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.2.1 -m "<description of version>" afde2d66eb0f77148efa497ebb640639415df5b0
git push origin v0.2.1


[BUG]

Describe the bug
I tried using the code provided in the readme but I got several errors
To Reproduce
In order to assist you with your problem, we need a minimal code snippet that replicates the bug. Avoid disclosing your API keys.
Steps to reproduce the behavior:

using this code provided in the readme and my api key

import asyncio
from bscscan import BscScan
YOUR_API_KEY = "MY_API_KEY_HERE"
async def main():
async with BscScan(YOUR_API_KEY) as bsc:
print(await bsc.get_bnb_balance(address="0x0000000000000000000000000000000000001004"))
if name == "main":
asyncio.run(main())
Expected behavior
supposed to return this value:
'167195709084498025431541166'
but returned this instead:
154418307945930954164147431
Exception ignored in: <function _ProactorBasePipeTransport.del at 0x0000025CA8B734C0>
Traceback (most recent call last):
File "E:\Program_Files\Python\Python39\lib\asyncio\proactor_events.py", line 116, in del
self.close()
File "E:\Program_Files\Python\Python39\lib\asyncio\proactor_events.py", line 108, in close
self._loop.call_soon(self._call_connection_lost, None)
File "E:\Program_Files\Python\Python39\lib\asyncio\base_events.py", line 746, in call_soon
self._check_closed()
File "E:\Program_Files\Python\Python39\lib\asyncio\base_events.py", line 510, in _check_closed
raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
Screenshots

System info (please complete the following information):

OS and version: Windows 10
Python version: 3.9.5
bscscan-python version: 2.0.0

Additional context
Add any other context about the problem here.

https://stackoverflow.com/a/66772242/6204860


[SPARK-42158][SQL] Integrate _LEGACY_ERROR_TEMP_1003 into FIELD_NOT_FOUND

What changes were proposed in this pull request?
This PR proposes to integrate _LEGACY_ERROR_TEMP_1003 into FIELD_NOT_FOUND
Why are the changes needed?
We should deduplicate the similar error classes into single error class by merging them.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Fixed exiting UTs.

@itholic Could you fix the test failures in V2CommandsCaseSensitivitySuite:

AlterTable: add column resolution - positional
AlterTable: add column resolution - nested positional

+1, LGTM. Merging to master.
Thank you, @itholic.

@itholic Could you backport this to 3.4, please.

Backport: https://github.com/apache/spark/pull/39828


Update appveyor.yml

:white_check_mark: Build bitcointrade-sdk-dotnet 1.0.168 completed (commit https://github.com/guibranco/bitcointrade-sdk-dotnet/commit/b2c3baa0a8 by @guibranco)


Custom validator in java to integrate in proto

Hi Team,
Is there a way that if we can write a custom validator in java and use it to integrate with proto file like below
message A {
string xxx = 1 [(buf.validate.field) = IMPORTED_RULE_VARIABLE];
}

No. This library only supports writing validators using CEL.
https://github.com/google/cel-spec


Add slugs to attack effects for Agents of Edgewatch

Follow-up to #5861

Renamed to fit with project standards. We can probably just lump any others into one PR.


docs: remove obsolete problem post-install hook

Issue
README > Common problems > Cannot run post-install hook recommends using  npm install --unsafe-perm.
Background
Currently the minimum supported version of Node.js is 18.x. The note relates to npm rather than Node.js itself. npm is bundled in Node.js.
The lowest Node.js 18.x version is Node.js 18.0.0 which bundles npm 8.6.0.
The npm CHANGELOG 7.0.0 > All Lifecycle Scripts says:

The user, group, uid, gid, and unsafe-perms configurations are  no longer relevant. When npm is run as root, scripts are always run with the effective uid and gid of the working directory owner.

The lowest version of npm currently supported is 8.6.0 (see above). The conclusion is that the problem no longer applies to any currently supported version of npm and therefore the problem description is obsolete.
Change
Remove the obsolete section README > Common problems > Cannot run post-install hook.

Preview
https://github.com/MikeMcC399/cypress-docker-images/blob/remove/unsafe-perm/README.md#common-problems

failed to solve: executor failed running [/bin/sh -c bash /opt/installScripts/node/install-node-version.sh ${APPLIED_FACTORY_DEFAULT_NODE_VERSION}]: exit code: 92


Add geocoding for GQ

Imported from Google Code issue #151 created by cfkoch on 2012-06-16T03:26:26.000Z:

Doesnt Exist.
Available At http://www.itu.int/oth/T0202000041/en
Although it's a bit more complicated, in that the fixed line network is in the format  3xx y z ssss; where y is the Region Identifier
So, it would be wagered that a full listing of
24033309|Bioko
24033319|Bioko
24033329|Bioko
24033308|Litoral
24033318|Litoral
24033328|Litoral
... etc, since only that final digit is significant in the location lookup....

We've accepted this issue and will fix it in an upcoming release.

Fixed in v8.0.0.


Deprecated guzzle/guzzle dependency

Warning on composer update: Package guzzle/guzzle is abandoned, you should avoid using it. Use guzzlehttp/guzzle instead.
% composer why guzzle/guzzle
satooshi/php-coveralls  v1.0.1  requires  guzzle/guzzle (^2.8|^3.0)

My bad, it was one of the first issues in the closed list...


Word highlighter error when opening accessibility help

open a text editor
open the accessibility help alt+f2

:bug: error in window log (no noticeable functionality loss)
2024-09-20 11:57:30.396 [error] Unable to resolve resource accessible-view:accessible-view-editor
...
at ResourceModelCollection.doCreateReferencedObject (vscode-file://vscode-app/c:/src/vscode/out/vs/workbench/services/textmodelResolver/common/textModelResolverService.js:84:15)
at ResourceModelCollection.doCreateReferencedObject (vscode-file://vscode-app/c:/src/vscode/out/vs/workbench/services/textmodelResolver/common/textModelResolverService.js:82:25)
at async AsyncReferenceCollection.acquire (vscode-file://vscode-app/c:/src/vscode/out/vs/base/common/lifecycle.js:531:28)
at async TextModelResolverService.createModelReference (vscode-file://vscode-app/c:/src/vscode/out/vs/workbench/services/textmodelResolver/common/textModelResolverService.js:205:16)
at async WordHighlighter._run (vscode-file://vscode-app/c:/src/vscode/out/vs/editor/contrib/wordHighlighter/browser/wordHighlighter.js:550:35)

no longer can repro. likely fixed with the accessibility candidate a month or two ago that megan found.