[regression] 1.3.2 regresses on "SinkBinding on KSVC results into ping-pong between operators #1936"

When deploying the splitter integration in the example/knative dir with latest Knative (verified on Serverless 1.13 and 1.14) and camel-k operator 1.3.2, splitter ksvc is repeatedly reconciled between two operators.
The same scenario works fine with camel-k operator  1.3.1, so it seems to be a regression in camel-k 1.3.2 vs 1.3.1.
See also https://github.com/apache/camel-k/issues/1936
possibly introduced by https://github.com/apache/camel-k/pull/2042/files  ? (not verified)

NAME                                         READY   STATUS              RESTARTS   AGE
camel-k-kit-c1hmlapse357at2e5n40-1-build     0/1     Completed           0          2m45s
camel-k-kit-c1hmlapse357at2e5n40-builder     0/1     Completed           0          3m30s
camel-k-kit-c1hmlb1se357at2e5n4g-1-build     0/1     Completed           0          86s
camel-k-kit-c1hmlb1se357at2e5n4g-builder     0/1     Completed           0          2m5s
camel-k-kit-c1hmlb9se357at2e5n50-builder     1/1     Running             0          58s
splitter-00001-deployment-66c99c65c9-tzxlh   1/2     Running             1          58s
splitter-00002-deployment-646bd5c67b-5cwrb   2/2     Running             0          58s
splitter-00003-deployment-7f65746644-dr7xd   1/2     Running             2          56s
splitter-00004-deployment-6f8d7c8d48-v2zzl   2/2     Running             0          56s
splitter-00005-deployment-6fbd456fd5-vjj4l   1/2     Running             2          55s
splitter-00006-deployment-5c5cf58d79-442tj   2/2     Running             0          55s
splitter-00007-deployment-748bf46445-sg2cz   1/2     Running             1          54s
splitter-00008-deployment-777845d7d9-tmsr9   2/2     Running             0          53s
splitter-00009-deployment-6bf7f74475-fnc4x   0/2     Error               1          52s
splitter-00010-deployment-7ff6b966c-crlpw    1/2     Running             0          51s
splitter-00011-deployment-69c54f7c85-78dm7   1/2     Running             1          51s
splitter-00012-deployment-55757c7686-phvzx   2/2     Running             0          50s
splitter-00013-deployment-99d7fd48c-wgvss    1/2     Running             1          50s
splitter-00014-deployment-6c6b88b67d-5dcvj   1/2     Running             0          49s
splitter-00015-deployment-7f5d76496c-zqh6v   1/2     Running             1          48s
splitter-00016-deployment-79d7bcb6dc-fbdrp   2/2     Running             0          48s
splitter-00017-deployment-5d98c79ccd-5kg52   1/2     Running             1          47s
splitter-00018-deployment-7d7fbf5cb4-jxmj8   1/2     Running             0          47s
splitter-00019-deployment-56b79846d5-4w4dj   1/2     Running             1          46s
splitter-00020-deployment-c87644d94-r7s6m    2/2     Running             0          46s
splitter-00021-deployment-5db4cb69b5-rlq8j   0/2     Error               1          44s
splitter-00022-deployment-6d9bc8d86b-w4flv   1/2     Running             0          43s
splitter-00023-deployment-56f8dd4cf6-gmncl   0/2     Error               0          42s
splitter-00024-deployment-7d45b49459-cw854   2/2     Running             0          41s
splitter-00025-deployment-578977fc74-btvfg   1/2     Running             1          40s
splitter-00026-deployment-7d8fdb988c-6fgdp   2/2     Running             0          39s
splitter-00027-deployment-6dcccf67cc-sxtfl   1/2     Running             0          39s
splitter-00028-deployment-8684bbfdcb-4j8pg   1/2     Running             0          38s
splitter-00029-deployment-6c45f89db9-9l95g   1/2     Running             1          37s
splitter-00030-deployment-6dd8556d8f-gmqnf   1/2     Running             0          36s
splitter-00031-deployment-6758cfc687-kxfmh   1/2     Running             0          35s
splitter-00032-deployment-85854d4498-q4g7p   1/2     Running             0          34s
splitter-00033-deployment-7865b98856-qwttm   1/2     Running             1          32s
splitter-00034-deployment-7d8fc987f-kh6km    1/2     Running             0          31s
splitter-00035-deployment-86d7544c48-cf9w7   1/2     Running             0          30s
splitter-00036-deployment-66ff4bb7d6-hpsfl   1/2     Running             0          30s
splitter-00037-deployment-b5455569d-2fq4m    1/2     Running             0          27s
splitter-00038-deployment-6bfbf7595b-bj6hv   1/2     Running             0          26s
splitter-00039-deployment-6569dfd8b6-jp7x4   1/2     Running             0          22s
splitter-00040-deployment-674ff4797f-bhmx4   1/2     Running             0          21s
splitter-00041-deployment-64c556b7b6-jfwmm   1/2     Running             0          17s
splitter-00042-deployment-54bf57d879-kp6hh   1/2     Running             0          16s
splitter-00043-deployment-7db48ffb96-2gj6v   1/2     Running             0          14s
splitter-00044-deployment-549bbbd666-gb4nn   1/2     Running             0          13s
splitter-00045-deployment-554b8896db-jz26v   0/2     ContainerCreating   0          1s
splitter-00046-deployment-549d66cfc6-dgggf   0/2     ContainerCreating   0          1s

Do we have a CI image of the operator I can use, or do I have to build it locally myself first?

@astefanutti  I still see the same issue with docker.io/maschmid/camel-k:1.4.0-SNAPSHOT  , which I built from current master
{"level":"info","ts":1617188536.706038,"logger":"cmd","msg":"Go Version: go1.15.8"}
{"level":"info","ts":1617188536.7060597,"logger":"cmd","msg":"Go OS/Arch: linux/amd64"}
{"level":"info","ts":1617188536.706063,"logger":"cmd","msg":"Buildah Version: 1.14.0"}
{"level":"info","ts":1617188536.7060657,"logger":"cmd","msg":"Kaniko Version: 0.17.1"}
{"level":"info","ts":1617188536.7060683,"logger":"cmd","msg":"Camel K Operator Version: 1.4.0-SNAPSHOT"}
{"level":"info","ts":1617188536.706071,"logger":"cmd","msg":"Camel K Default Runtime Version: 1.7.0-SNAPSHOT"}
{"level":"info","ts":1617188536.7060733,"logger":"cmd","msg":"Camel K Git Commit: 18eb00851c92906cce668ba197c71176443495bd"}

@maschmid sorry for the delayed answer, as I was AFK. Thanks a lot for the testing!
I've tried to test it on my setup (Camel K master branch, Knative 0.20 with Kourier, OCP 4.6) and could not reproduce. I can have the feed, splitter and printer integrations from the examples/knative directory working :( I'll try to understand what's different in my setup...
In the meantime, could you please share the content of the KnativeService and the Deployment resources? That may help me understanding what are the conflicting changes the Camel K operator and the Knative controller / webhook contend for.
In master branch we moved to using server-side apply (#2039), to try to cope with the issue. I assumed the problem is for environment variables set on the KnativeService, and that Knative also uses server-side apply.
In the 1.3.x branch, #2042 is a fixed on top of #1937, that was too aggressive and prevented some required updates to the resources metadata.
Still, the fact I cannot reproduce on my setup puzzles me, and I'd like to have the bottom line of all this.

With OpenShift Serverless 1.13 (knative serving/eventing 0.19)
splitter ksvc: https://gist.github.com/maschmid/bcc929c842ca5c93ac650ff8f1ae3007

all the deployments (there are lots of splitter deployments, as each revision has a new one...)    https://gist.github.com/maschmid/ae0da49fa58283e2317043679e15f316

Thanks. I'm interested by the managed fields, that show all the controllers cooperating on the resource.
In my tests, I only have the camel-k-operator and  (Knative) controller, but yours shows also the webhook as controller, that seems to have ownership for the containers field.

One theory I have is this could be caused by a different sinkbinding configuration in Serverless... It uses SINK_BINDING_SELECTION_MODE=inclusion   , which requires resources bound by SinkBinding to have bindings.knative.dev/include: "true" label.. (in this case, the ksvc)
without the label, the eventing webhook will not modify the ksvc during creation, but it will try to replace it at runtime... I suppose this could be causing the issue.

Yes, that sounds like an interesting theory. Here is what I have that is compatible with it:
$ k get deployment -n knative-eventing eventing-webhook -o yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "2"
  generation: 2
  labels:
    eventing.knative.dev/release: v0.20.1
  name: eventing-webhook
  namespace: knative-eventing
spec:
  template:
    spec:
      containers:
      - env:
        - name: SINK_BINDING_SELECTION_MODE
          value: exclusion

That would also explain why upstream CI passes, as it seems the webhook is set to exclusion mode by default.
Let me try to change the value on my setup...

exclusion is default in upstream, OpenShift Serverless defaults to inclusion, because that causes potentially any Deployment on the cluster to go via eventing webhook, which could cause instability (when a SinkBinding binding to Deployment exists, even system Deployments would go through eventing webhook)

I've been able to reproduce by editing the eventing webhook and setting SINK_BINDING_SELECTION_MODE=inclusion.
I can now analyse the issue and research what's the best strategy.

I'm realizing that adding the bindings.knative.dev/include: "true" label, to the source object referenced in the SinkBinding, may have been the solution all along.
The source objects are owned by Camel K, and we always want the eventing webhook to select them, irrespective of the Knative sink binding configuration (Inclusion or Exclusion).
I've tried that approach and it seems to be working well.

Current proposed fix #2190.
@maschmid could you please review it, and maybe test it on your side.
Once it validated, I'll adapt it for the 1.3.x branch.

Works for me, and the fix looks good to me, too. I agree the "bindings.knative.dev/include=true" should be safe to add with either setting.

I am facing the same issue. it there a workaround for it for now?

@weimeilin79  If you install via an Operator (Serverless operator or Knative Operator), a possible workaround could be to switch KnativeEventing  sinkBindingSelectionMode to exclusion
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  sinkBindingSelectionMode: exclusion

Thanks @maschmid  :) it works like a charm!!

@maschmid thanks a lot for the testing and reviewing. I've merged #2190, and I'm now preparing the back port into 1.3.x branch.

In case changing the Serverless / Knative configuration is not an option, another work-around is to add the label manually, e.g.:
$ kamel run --label bindings.knative.dev/include=true -t owner.target-labels=bindings.knative.dev/include

1.3.x backport PR: #2191.


Metadata filtering

brain dump:
pseudocode:
client.search('my amazing red electric car driving on mars', {metadata: {pilot: '%elon musk%',}})
use case:

want to search similar content but narrow down on specific "boxes" (metadata is a kind of classification?)

it works


question: Is it normal that "23/07/2023" renders "'23/07/2023"?

Question
It's pretty weird but it happens for 23/07/2023 and 23/07/23 it renders a ' at the start when rendering it and it prevents for formatting the date (I put a .set_num_format("dd mmm yyyy") in the format, but it shows the ' even without the format). Is this normal behaviour?
(I made it a question because I didn't want to make another bug for then it to be solved after 15 minutes.)

Datetimes in Excel are numbers with a format. See the docs on ExcelDateTime and Datetimes in Excel.
So, if you are trying to write dates as strings that won't work. If that isn't the case then submit a small working program that shows the issue.

(I made it a question because I didn't want to make another bug for then it to be solved after 15 minutes.)

Questions are fine. But for your own sake have a read through the Tutorial and maybe some of the reference examples in the Cookbook.

Thanks for the information, I'll read the Tutorial and the Cookbook. Anyways I saw that this is present even with single numbers (like "5" renders '5)

Anyways I saw that this is present even with single numbers (like "5" renders '5)

In that case add a small complete example program that demonstrates the issue.

This is what I used:
worksheet.write_string_with_format(row+1, col+7, "5", &Format::new().set_num_format("€ 0,00").set_border_top(FormatBorder::Dashed).set_border_bottom(FormatBorder::Double).set_border_left(FormatBorder::Thin).set_border_right(FormatBorder::Thin))?;```

Alright I guess that the error was me using worksheet.write_string_with_format instead of worksheet.write_number_with_format

Yes it was the issue. Thanks for pointing out where to search in case I'm not understanding something 😄

Alright I guess that the error was me using worksheet.write_string_with_format instead of worksheet.write_number_with_format

Yes it was the issue. Thanks for pointing out where to search in case I'm not understanding something

No worries. For what it is worth here is what that output would look like in Excel:

I think the apostrophe is LibreOffice's way of saying "Number stored as string".

Such an odd way but at least I now know it. Thanks for the information and hard work 😃


bug: No errors shown if loading from dir= fails

Did you check docs and existing issues?

[X] I have read all the lazy.nvim docs
[X] I have updated the plugin to the latest version before submitting this issue
[X] I have searched the existing issues of lazy.nvim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
v0.10.1
Operating system/version
Nixos unstable
Describe the bug
When loading a plugin via the dir= directive, there is no error shown if this fails. The plugin will just silently not be there, instead of showing an error message.
Example plugin definition:
	{
		dir = pluginpaths .. "/outline.nvim",
		config = function()
			-- Example mapping to toggle outline
			vim.keymap.set("n", "<leader>o", "<cmd>Outline<CR>", { desc = "Toggle Outline" })

			require("outline").setup({
				-- Your setup opts here (leave empty to use defaults)
			})
		end,
	},

If for some reason (e.g. a typo) the path in dir= is missing outline.nvim it will just not load the plugin, without showing any errors.
Steps To Reproduce
Try to load non-existent plugin from dir=
Expected Behavior
A error is shown
Repro
vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
  spec = {
	 { dir = "/does/not/exist" }
  },
})

This just got me too. Wasn't until I noticed that I had mistyped the path of a local plugin, that I realized lazy.nvim couldn't find my local package and wasn't throwing an error.

Not stale


[release-1.3] fix gitlab-org wrapper

Description
fixes missing embedded dependency in gitlab-org plugin
Which issue(s) does this PR fix

Fixes https://issues.redhat.com/browse/RHIDP-5319

PR acceptance criteria
Please make sure that the following steps are complete:

[ ] GitHub Actions are completed and successful
[ ] Unit Tests are updated and passing
[ ] E2E Tests are updated and passing
[ ] Documentation is updated if necessary (requirement for new features)
[ ] Add a screenshot if the change is UX/UI related

How to test changes / Special notes to the reviewer

/retest

not sure what is going on with tests
/bin/bash: line 2: /tmp/droute-linux-amd64: Text file busy
command terminated with exit code 126

/retest

https://github.com/janus-idp/backstage-showcase/pull/2125 should resolve droute issue

/test e2e-tests


Connect data sources - first step is wrong

Under "Connect data sources", first step "1. Click Data collection." should be corrected to "1. Click Data connectors."

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ddafba5c-f652-3d1a-e4b4-f8eedc14e740
Version Independent ID: ea24a163-6533-24eb-630c-559bd1549dc7
Content: Onboard in Azure Sentinel Preview
Content Source: articles/sentinel/quickstart-onboard.md
Service: sentinel
GitHub Login: @rkarlin
Microsoft Alias: rkarlin

Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

Hi @azureandsecurityotaku, thanks for having submitted this issue!
I can see that our current docs are now up to date, so I'm going to close this up.
Feel free to continue commenting if you have more feedback.
Thanks for your contributions to docs!
#please-close


reco module models support

Currently reco module models have a different API compared to other models in creme:

they don't inherit from creme.base.Estimator that handles Pipeline and TransformerUnion compatibility. This first point could be easily solved by making reco.base.Recommender inherits from creme.base.Estimator
they expect a two variable input (r_id and c_id) instead of a dictionnary which make them incompatible with progressive_val_score and successive_halving (hope I don't forget other utilities). As discussed with @MaxHalford, it should be possible to make those methods work with this different type of model input

I totally forgot about this, sorry!

Yeah I suppose everything should work fine if Recommender inherits from Estimator. There might be some edge-cases but I'm sure they'll be easy to handle.
This takes a bit more thinking, but it's manageable. I'll get something done in the afternoon and tell you when :)

Actually I just took a look and it's a bit difficult to adapt progressive_val_score without breaking the API, which isn't something I want to do. It seems that the "easiest" solution is to pass dicts to the update method of each recommender. The dicts will need to contain the user and item keys. It's a bit ugly because the keys are imposed, but it's not that bad. The advantage is that we can add other keys if required. For example we can add a timestamp key to use with the on parameter of progressive_val_score.
Thoughts @gbolmier? Sorry I should have looked at this much earlier.

No worries Max! Thx for the prompt reply :)
I agree with your first solution, using dicts as inputs seems better as it avoid a lot of compatibility issues (e.g. datasets generating dicts). I also like your 2nd solution but the inherited fit_one must therefore know which keys to unpack right?
Imposed keys being the only drawback to the 1st solution. If I'm not wrong, as we handle item recommendation case and not social recommendation from graphs, using user and item keys makes sense for all the case we cover right now.
Any opinion @VaysseRobin?

Indeed @gbolmier fit_one must know which keys to unpack, but at least that logic is only in one place. Yeah for the moment user and item LGTM.

Sounds good to me! I was wondering if we should allow the users to pass optional arguments to the inherited  fit_one(self, x, y, row_key='user', col_key='item') or force them to stick with user and item keys?
You can assign me this task and I will merge the changes within the FM pull request #187

Sounds good to me! I was wondering if we should allow the users to pass optional arguments to the inherited fit_one(self, x, y, row_key='user', col_key='item') or force them to stick with user and item keys?

For the moment let's stick with user and item.

You can assign me this task and I will merge the changes within the FM pull request #187

Will do!


test: Enable cohere tests

Why:
The modification addresses the issue of compatibility and abstraction within the testing suite for the openapi-llm package. Previously, the LLMProvider was being explicitly referenced, which could lead to less flexible integration and hard coupling with the provider's specifics. By introducing a direct reference to CohereProvider, the change enhances modularity and allows for more adaptable client configuration that aligns with the actual provider's API.
What:

Added an import statement for CohereProvider from the openapi_llm.providers.cohere module.
Replaced the usage of LLMProvider.COHERE with CohereProvider() within two test methods.
The changes reflect in the test methods test_serperdev and test_github, aligning the test configuration with the Cohere API.

How can it be used:

This change impacts test cases for configurations expecting a language model provider, specifically pertaining to Cohere.
Instantiate the CohereProvider in a similar fashion within your own configurations for better modularity:config = ClientConfig(llm_provider=CohereProvider())

How did you test it:
The changes are within test files implying tests will utilize the updated configuration for execution. The test coverage appears to support test_serperdev and test_github, ensuring the integration with the Cohere API remains functional. Additional testing can include validation of provider swaps and verifying response integrity with new configurations.
Notes for the reviewer:

Pay attention to the possible side effects of introducing CohereProvider in place of LLMProvider.COHERE, especially concerning error handling or configuration intricacies that are provider specific.
Consider reviewing other provider configurations for similar enhancements to maintain uniform integration patterns within the test suite.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>6
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+1.8%) to 81.293%

Totals

Change from base Build<PHONE_NUMBER>0:
1.8%

Covered Lines:
352

Relevant Lines:
433

💛  - Coveralls


Update API AMI

Issue Number
#315
Purpose/Implementation Notes

Uses the latest ubuntu 22.04 AMI
Adds docker install to user-data
fixes tabs in user-data
updates apt-get -> apt

Types of changes

Bugfix (non-breaking change which fixes an issue)

Functional tests
n/a
Checklist

[X] Lint and unit tests pass locally with my changes

Screenshots
N/A

@davidsmejia  Besides the question regarding the gnupg package installation I asked you yesterday(and thank you for the answer!), the commands look good to me. Since I've never done this installation workflow, please skip my 'Approval' at this time and merge the code as soon as it's ready. Thank you, David!

I like the idea for the improvements with adding more constants, I actually want to revisit this next term and improve the script overall. I think we can clean it up significantly and also make the logic more portable for other instances we want to spin up.


Fix Hugo build issue:

Issue #, if available:
failed to extract shortcode: shortcode "blocks/section" must be closed or self-closed This allows the local build and serve to work.
properly.
Description of changes:
Testing (if applicable):
Documentation added/planned (if applicable):
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


Even distribution clients between threads

Hello!
We have 3 separate redis instances. Now in top cpu used 80% and raising every month. So we decided to migrate to keydb 2 nodes with active-replica and multiple threads.
I've configured keydb with 8 threads, but the client's distribution not evenly. Also, we are using 3 haproxy load-balancing nodes on the front.
Is it normal that one thread load to 99.9%?

Run parameters
      --port 7000
      --bind <IP_ADDRESS>
      --server-threads 8
      --server-thread-affinity true
      --active-replica yes
      --replicaof <IP_ADDRESS>
      --client-output-buffer-limit slave 0 0 0
      --save 3600 1
      --save 1800 10
      --save 300 10000

INFO
# Server
redis_version:6.0.13
redis_git_sha1:a6782a3c
redis_git_dirty:1
redis_build_id:4c36a0f29d258da9
redis_mode:standalone
os:Linux 4.4.0-130-generic x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:7.5.0
process_id:1
run_id:2b33ff722ed116b61bdb82d4deeb4eff35091aa5
tcp_port:7000
uptime_in_seconds:22569
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:7209256
executable:/data/keydb-server
config_file:

# Clients
connected_clients:114
client_recent_max_input_buffer:10
client_recent_max_output_buffer:3776
blocked_clients:0
tracking_clients:0
clients_in_timeout_table:0
current_client_thread:2
thread_0_clients:47
thread_1_clients:50
thread_2_clients:17
thread_3_clients:1
thread_4_clients:0
thread_5_clients:0
thread_6_clients:0
thread_7_clients:0

# Memory
used_memory:254998400
used_memory_human:243.19M
used_memory_rss:435576832
used_memory_rss_human:415.40M
used_memory_peak:470049472
used_memory_peak_human:448.27M
used_memory_peak_perc:54.25%
used_memory_overhead:12247260
used_memory_startup:9233520
used_memory_dataset:242751140
used_memory_dataset_perc:98.77%
allocator_allocated:255528568
allocator_active:419897344
allocator_resident:432103424
total_system_memory:135180136448
total_system_memory_human:125.90G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.64
allocator_frag_bytes:164368776
allocator_rss_ratio:1.03
allocator_rss_bytes:12206080
rss_overhead_ratio:1.01
rss_overhead_bytes:3473408
mem_fragmentation_ratio:1.71
mem_fragmentation_bytes:180655200
mem_not_counted_for_evict:6136
mem_replication_backlog:1048576
mem_clients_slaves:20962
mem_clients_normal:1942018
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

# Persistence
loading:0
rdb_changes_since_last_save:3903991
rdb_bgsave_in_progress:0
rdb_last_save_time:1601044675
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:6
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:31645696
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0

# Stats
total_connections_received:69163
total_commands_processed:1008373790
instantaneous_ops_per_sec:50002
total_net_input_bytes:225514588370
total_net_output_bytes:152321011451
instantaneous_input_kbps:10988.76
instantaneous_output_kbps:7643.44
rejected_connections:0
sync_full:3
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
expire_cycle_cpu_milliseconds:0
evicted_keys:0
keyspace_hits:272135
keyspace_misses:1
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:15960
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
tracking_total_keys:0
tracking_total_items:0
tracking_total_prefixes:0
unexpected_error_replies:0

# Replication
role:active-replica
master_global_link_status:up
Master 0:
master_host:<IP_ADDRESS>
master_port:7000
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:115738676320
slave_priority:100
slave_read_only:0
connected_slaves:1
slave0:ip=<IP_ADDRESS>,port=7000,state=online,offset=296224675393,lag=1
master_replid:6245a3de3ff281e0373712e37c58f029f322388b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:296231698469
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:296230649894
repl_backlog_histlen:1048576

# CPU
used_cpu_sys:15476.256000
used_cpu_user:40963.700000
used_cpu_sys_children:27.788000
used_cpu_user_children:186.476000
server_threads:8
long_lock_waits:35726

# Modules

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=2,expires=0,avg_ttl=0

setting the config min-clients-per-thread to 0 will distribute clients across all threads evenly. By default we will try to bunch at least 50 clients to a thread.
Usually, bunching a small number of clients results in lower overall latency as there is fixed overhead that needs to be overcome.

I think the default of 50 is a bit too high though. I set that on a high clocked desktop CPU. Server CPUs tend to prefer a lower number, of around 20 or so.

@JohnSully  I've set min-clients-per-thread to 20, clients distribution and cpu looks better now. Thank you!
thread_0_clients:17
thread_1_clients:20
thread_2_clients:20
thread_3_clients:20
thread_4_clients:13
thread_5_clients:18
thread_6_clients:0
thread_7_clients:0

One more question. Why CPU with keydb instances so loaded? Now it's half of all traffic.
Redis use about 120% CPU
Keydb use about 280% CPU x 2 instances
Maybe I can customize something else?

Its a timely question, the reason it uses so much CPU is because its waiting in a spinlock.
As of the next release we’ve dramatically reduced the lock contention and CPU usage is much lower.
If you want a sneak peek give the unstable branch a try.

I think, I can add more threads and waiting for new release. Thanks for answer!

This bug tracks lowering the min-clients-per-thread setting to 20.

When are you planning to release the next stable version?

Hey @artful88533 I just tagged the release.  Docker images are being built now and will be up soon.  This fix is included.

Unfortunately, after update, I don't see any improvement in CPU usage (

@artful88533 You really want the minimum number of threads necessary for your workload. Usually 8 threads is more than sufficient for workloads with more clients than you have there.
Each thread has overhead and using too many can reduce performance.

I originally implemented min-clients-per-thread because of a tendency to select too many threads.
I’d recommend running memtier and observing what setup works best on your hardware when tweaking that setting.

Hi!
Before I've tried to run keydb on virtual machines (Xenserver).
Now I've installed keydb master-master cluster directly on physical servers. It works much better! =)


Problem with lines where colon is used: invalid point

There is a weird problem which might be related to my configuration, but
In lines where I use colons - such as if conditions or for loops - it gives the error "Flake8 error: invalid point" on the first line, instead of the line with the error.
Like the example given below, If I remove the colon in line 3, the linter highlights the first line where variable declaration is made, and says "Flake8 error: invalid point" while it should highlight line 3 with the actual error.
a = 1
for x in range(4):
    if x == 3
        print(x)

I tried with different versions of Flake8, uninstalled and reinstalled linter-flake8 but couldn't solve the issue.
Thank you in advance.

Me too, on windows.


[HOLD for payment 2024-08-01] [$250] Expense - Description row in transaction thread is empty after saving the description

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

Version Number: 9.0.10-2
Reproducible in staging?: y
Reproducible in production?: no
If this was caught during regression testing, add the test name, ID and link from TestRail: n/a
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause internal team
Slack conversation:
Action Performed:

Go to staging.new.expensify.com
Go to workspace chat.
Submit an expense.
Go to transaction thread.
Click Description.
Enter description and save it.

Expected Result:
The saved description will appear on Description row in transaction thread.
Actual Result:
The Description row in transaction thread is empty after saving the description.
Workaround:
unknown
Platforms:

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

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

Screenshots/Videos
https://github.com/user-attachments/assets/a93a5353-4ee7-402a-b516-15b5b901c7f1

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~019f38e792188ee307
Upwork Job ID:<PHONE_NUMBER>762713976
Last Price Increase: 2024-07-22

Issue OwnerCurrent Issue Owner: @
Issue OwnerCurrent Issue Owner: @mallenexpensify

cc @pecanoro @JmillsExpensify @parasharrajat
This is also coming from the dupe detection PR

@parasharrajat I have raised a quick PR and assigned you as its coming from the dupe detection PR

@Krishna2323 I will offer you a partial reward for help spotting it.
Please remember that for any issues that are deploy blockers, always link the offending PR in your proposal. In this case it was super simple to find. Thanks!

@dominictb can you please raise the PR?

@dominictb can you please accept the job and reply here once you have?
https://www.upwork.com/jobs/~019f38e792188ee307

@johncschuster I'm off til Monday afternoon, can you help with payment here? Thx

Payment Summary
Reviewer: @parasharrajat owed $250 via NewDot - please request payment
Contributor: @dominictb paid $250 via Upwork - PAID 👍

$250 approved for @parasharrajat


[INCR-98] and [INCR-99] Run Python modernize -w .

Fixes https://openedx.atlassian.net/browse/INCR-98, https://openedx.atlassian.net/browse/INCR-99

Thanks for the pull request, @cclauss! I've created OSPR-3125 to keep track of it in JIRA. JIRA is a place for product owners to prioritize feature reviews by the engineering development teams.
Feel free to add as much of the following information to the ticket:

supporting documentation
edx-code email threads
timeline information ("this must be merged by XX date", and why that is)
partner information ("this is a course on edx.org")
any other information that can help Product understand the context for the PR

All technical communication about the code itself will still be done via the GitHub pull request interface. As a reminder, our process documentation is here.

@cclauss Thank you for your contribution. @edx/incr-reviewers Would you like to review this?

The commits were:

Run python-modernized
Placate pylint
Run isort
Disable isort

The Travis error at the end of commit 2 was an isort complaint so in commit 3, I ran isort and it shuffled the imports around as it does but then complained again that the imports were improperly sorted.  Given that isort does not agree with isort, I made commit 4.

@cclauss we would rather keep the isort check in place. Can you give some more fine-grained details about what was actually failing so we can help out?

https://travis-ci.org/edx/xblock-sdk/jobs/497524653#L311

Try adding the --diff parameter to isort to get more useful output from it, like in https://github.com/edx/cookiecutter-django-app/blob/master/tox.ini#L31 .  (We found that option a little while after we started using isort, and haven't gone back to update everything to use it yet.)

@estute I think we are set now...

@cclauss 🎉 Your pull request was merged!
Please take a moment to answer a two question survey so we can improve your experience in the future.


Update API Docs link

Latest API Docs Link was pointed to a 404 page
I have updated ui-react readme file a working link

1bd9b59ccecf4dbf992f5e0e71c9123a3ce8c2bb


Dependency cycles when using with theforeman/puppet-dhcp

Hi,
I get the following dependency cycles when using this in conjunction with theforeman/puppet-dhcp:
Error: Found 1 dependency cycle:
(Exec[pkg update] => Package[isc-dhcp44-server] => File[/usr/local/etc] => File[/usr/local/etc/pkg.conf] => Exec[pkg update])

The only thing I've noticed is that theforeman/puppet-dhcp manages the /usr/local/etc directory and has a package referenced:
  file { $dhcp_dir:
    mode    => '0755',
    require => Package[$packagename],
  }

(https://github.com/theforeman/puppet-dhcp/blob/53e8e4abe0f8da9d85aec883098f2e43e09ca859/manifests/init.pp#L68-L71)
I've read the relevant parts in theforeman/puppet-dhcp and it looks good to me, not an uncommon pattern.
It looks like it's an unfortunate choice of resource relationships causes this issue. Do you see any chance to adjust the related resource relationships in the pkng module to avoid this kind of dependency cycle?

Hi, thank you for raising the issue.  I've looked this over a bit and I don't see a simple solution without a change to either this module or the dhcp module.  This is tricky, but a couple things come to mind.
I do wonder what situation requires the file resource you point to.  I'd expect that in the case of redhat and debian both, that the /etc/dhcp directory would be created with the correct permissions without modification.  The concat resources already require the package, so maybe it lines up without that resource.
I see also that the dhcp module is using a somewhat older pattern of passing parameters based on hiera data.  Converting to this newer pattern could make it much simpler to include a new boolean that says something like manage_dhcp: false for freebsd, and returns true for everything else.  Wrapping a condition around the file resource for the value of that variable could skip the resource on freebsd.
The ordering of this module is largely managed by these lines, which are the source of the resource conflict.
  Exec['pkg update']
  -> Package <| provider == 'pkgng' or provider == undef |>

Without the ordering here, changes to pkg.conf or repo files may require more puppet runs to be accurate, and could result in package installation from undesirable sources the first run, and then reinstall those packages from another repo on the second puppet run.
Updating the dhcp module as mentioned above I think would be my preference, but I'm also not seeing a clear path forward without that change.  It would also get dhcp following a more modern hiera pattern of module if that were included in the final solution.


Arrays have a 'silent' length limit due to Int32 type on size.

arr = Array(UInt8).new(2147483647,1u8)
arr << 2_u8
arr.size #=> -2147483648

This could be a very surprising behaviour to run across. Ideally an error should be raised or the limit removed entirely (hopefully).
A similar bug exists in Indexable, trying to use each_index also doesn't work if size is greater than 2**31-1 because the index variable (i) defaults to the Int32 type. https://github.com/crystal-lang/crystal/blob/master/src/indexable.cr#L181
Version: Crystal 0.20.5+37 [2b57a98a9] (2017-02-08)
OS: Arch Linux x86_64

Removing the limit would mean that you could store an arbitrary number of elements in an Array, and still be oblivious to the implications of that. I think if you're writing code that needs to hold more than<PHONE_NUMBER> elements in memory:

You should have a deep understanding of the hardware you're running on.
You are likely to need very particular algorithms to deal with them.

Maybe raising a compilation error would be a more acceptable solution, but then again, if it means that to implement it we need to penalize the compiler's performance, I wouldn't do it. Storing more than<PHONE_NUMBER> elements in a normal Array is a 1 in 10000 case, it doesn't make sense to penalize the other 9999.

I've written programs where<PHONE_NUMBER> was an incredibly huge limit (in the context of the program) when it was written, only to have the program still be in use when that limit became a serious issue.  Programs which dealt with disk-sizes, for instance.  Once you do hit that limit, maybe years after writing a program, it is very helpful if the program fails in a spectacular way instead of silently doing the wrong thing.
It would be nice if there was a way to ask the compiler to add those checks wherever they were needed (which is to say "for all arithmetic which might cause an overflow").   Then programmers who were paranoid could turn on that checking, and those who needed top performance would leave it off.
I'll also note that many years ago I worked with a group who wrote a systems-programming compiler where there was an option like this.  And it turned out that the performance penalty of checking for overflows (*1) was not significant, and we compiled almost everything with the checks turned on.  Even in production code which was being used by thousands of users on a single machine.
(*1 - this was true for the kinds of programs we were writing.  It might not be true for everyone!)

This is one of the exact problems Rust (https://www.rust-lang.org) was created to prevent.  I understand Crystal uses the libc, et al, C libraries to build upon.  Is this correct?  Have you considered using Rust equivalent libraries?

Who, me?  I have considered rust.  At this point I have no interest in it.  I'd also think that the main problem they want to solve is ownership of memory, which did interest me.  But the more I looked into the language, the less I liked what they were doing.
But if you want me to leave the crystal community, I'm willing to do that.

:+1: for raising if an array tries to expand through Int32::MAX elements
:-1: for increasing the max size of array. If arrays being too small ever emerges as a big problem, we can rvisit this.

@jzakiya @drosehn I don't think rust has anything to do with this. Crystal can implement overflow checking, and there is a separate issue for that you can make your opinion known at.

Is there really any significant cost to increasing the max size of the array? As I understand it, it would result in the array type being 8 bytes larger (Int32 -> UInt64 for both @size and @capacity). Would there be any performance detriment?

@shelvacu It's not about the performance, it's about consistency and expected behaviour. We don't want to make the size be UInt64: unsigned integers are very unintuitive and bug-prone. Int64 could work, but the default numeric type for literals is Int32, so for example this will stop working:
a = [] of Int32
a << 1
a << a.size # Error: you'll have to do a.size.to_i

Also, right now creating the array from the first snippet in this thread, the one with<PHONE_NUMBER> elements, takes 14 seconds. I don't think such big arrays are common. So making the language work for a very rare use case at the cost of making everything else worse (like the example above) is not good. If you need a big array you could make one yourself, with Pointer you can allocate more memory than the limit of Int32.
That said, we do need these checks in Array, Hash and other containers, instead of silently failing.

I think that, in addition to what @asterite said, once your array gets to Int32::MAX members, it's often better to fail hard than continue to eat memory. Consider an array of objects (pointers, assume 64bit), that will itself eat 16GiB of memory before it fails. Its much better to fail then than continue to eat memory until we run out. In fact for that case it's way too high.

suggest:

return nil if not defined
add limit check

irb(main):001:0> a=[]
=> []
irb(main):002:0> a[999]
=> nil
irb(main):003:0> a[999999999]
=> nil
irb(main):004:0> a[9999999999999999]
RangeError: bignum too big to convert into `long'

return nil if not defined

Not type safe...

why we need type safe ,  duck typing is useful :
class Object
  def add(y)
    t = choose_type(self.type,y.type)
    self.to_type(t) + y.to_type(t)
  end
end
# Number -> String

Because type safety is useful too, and Crystal already checks for nil, so that's not even possible...

As a note, this issue changes with Crystal 1.0.0 (and several versions before) due to arithmetic overflow checking. The length limit is no longer silent, though the error could be wrapped to be more informative.


chore(kafka-instance-sdk): generate client and errors

@rkpattnaik780 looks good. I'm wondering if issue you see is specific to golang. This means that we might also need to try sdk-js :/


Remove any trait from StatusModifier

This was discussed in #8 but somehow didn't make it before the merge

Merge! :rainbow:  (After a rebase)

Nice one :laughing:  We needed 3 pull requests to change two lines of code!

:grin: hehehe


Overwatch wrapper not lighting up all the keys

Expected behavior:
 The Corsair K95 keyboard LEDs should all be lit up.
Actual behavior:
 Wrapper works as intended but some keys don't light up, specifically G6 -> G18 (weird because G1 -> G5 work fine). Also all media keys and lights/lock are not working, but I'm not sure those were working before.
How often does this problem occur?

This problem started occuring today, no idea why, after the wrapper worked flawlessly for many months.
Please describe the steps to reproduce this issue:
The issue can be reproduced by doing following steps:

Patch Overwatch
Start the game
Wrapper kicks in as expected, only not fully

What is the version of Aurora you are experiencing this issue with?

My version is beta v0.6.2b
Does the previous version of Aurora have this issue?
The previous version, did not have this issue, however i just downloaded it and tested and it happens again, same thing. Also tried reinstalling the most recent version to no avail
Please include any logs, screenshots, or files that are related to this issue:

The lighting from Overwatch is generated on that side and afaik no Razer keyboards have more than 5 G-keys so that's why the rest aren't lighting. For the rewrite I can try and get it working better as some effects (not all) could just be copied from the rest of the G keys

You're right, I just checked and there are no Razers with more than 5 G-keys, and those aren't even being made anymore. It's really odd though, because I could have sworn that those keys were working before...
Do you know what effects can't be copied?
Anyway, thanks a lot for the help so far!

Possibly could you look into creating layer to clone keys, opened request #1269

Fixed thanks to #1341!


support kebab casing in vite_asset template tag

Attributes can be set on the entry script tag by using the following syntax:
{% vite_asset '<path to your asset>' foo="bar" hello="world" %}

However, this does not allow for kebab-cased attributes. We are using a framework that requires we set the data attribute data-turbo-track="reload" on the entry <script />.
Since kebab-cased attributes cannot be supported via kwargs, vite_asset has been updated to support JSON encoded attributes:
from django.utils.safestring import SafeString

def your_view(request):
  json_encoded_attributes = json.dumps({
    "some-item": "3",
    "some-other-item": "value",
  })

  render(request, template, context={ "json_encoded_attributes": SafeString(json_encoded_attributes) })

{% vite_asset '<path to your asset>' json_encoded_attributes=json_encoded_attributes %}

Closes https://github.com/MrBin99/django-vite/issues/127

This is a great feature idea! I made a PR that expands on it -- we should convert underscore_cased attributes to kebab-case automatically.
See: https://github.com/MrBin99/django-vite/pull/131
Thank you for your contribution!


COM-739: fix RTE value not updating on outside value change

This is done by adding additional internal React states.

PR Checklist

[ ] Verify if the change requires a changeset. See CONTRIBUTING.md
[x] Link to the respective task if one exists:
[x] Provide screenshots/screencasts if the change contains visual changes

Screenshots/screencasts

Vanilla RTE
https://github.com/vivid-planet/comet/assets/56400587/9cf944cc-5be2-473b-8206-20dc59bb3603
RTE admin block in Final Form
https://github.com/vivid-planet/comet/assets/56400587/e865077b-c7d4-4c42-90ef-f1b23fd96131

We decided to not implement this since it's probably a faulty implementation in the project. The story added in #2374 showcases how to update the RTE's state from the outside.


testamatta 011 rev2 matrix issue with keys duplicating output

Hi! This is a LOVELY keyboard. I am friends with @yingeling, who introduced me to the board. I think he also requested that you make the rev2 with additional thumb keys.
I built one, and I am running into issues with specific keys. Whenever I type fast, I get duplicate keys. It mostly happens on the E and spacebar keys (I use colemak-dh). There are two pictures below, one of the whole keyboard, and one of the keys that I experience the issue with
My firmware is here:
https://github.com/sadekbaroudi/qmk_firmware/tree/develop_fingerpunch/keyboards/fingerpunch/personal/testamatta
Do you have any thoughts why this would be happening?

Hello @hide-key
Thank you so much for the quick and thoughtful response! I am more than happy to diagnose myself, but the source is not available, which makes it very time consuming. I realize and respect if that you did not open source it, and I appreciate that you did open source the gerbers. If it would be possible to (privately) share the schematics and/or layout files, it would help me diagnose the problem much more easily. I checked for shorts, and I don't have any.
If you would rather not share, I completely understand, but I thought I would ask in case it was a possibility.
You can reach out to me on discord as well! I have a discord server:
https://fingerpunch.xyz/discord
My handle is @sadekbaroudi
Your designs are quite beautiful, I must say :)

I have a different GitHub handle, but I am yingeling 😄

I have a different GitHub handle, but I am yingeling 😄

I see, I understand.


[SPARK-40811][SQL][TESTS] Use checkError() to intercept ParseException

What changes were proposed in this pull request?
In the PR, I propose to port the following tests suites onto checkError to check valuable error parts instead of error messages:

JDBCWriteSuite
JDBCTableCatalogSuite
JdbcUtilsSuite
CreateTableAsSelectSuite
SparkScriptTransformationSuite
SQLViewSuite
InsertSuite

Why are the changes needed?
Migration on checkError() will make the tests independent from the text of error messages.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
By running the modified test suites:
$ build/sbt "test:testOnly *SQLViewSuite"
$ build/sbt -Phive-2.3 -Phive-thriftserver "test:testOnly org.apache.spark.sql.execution.datasources.v2.jdbc.JDBCTableCatalogSuite"
$ build/sbt "test:testOnly *JdbcUtilsSuite"
$ build/sbt -Phive-2.3 -Phive-thriftserver "test:testOnly *SparkScriptTransformationSuite"

@panbingkun FYI

@cloud-fan Could you approve this PR, please.

Merging to master. Thank you, @amaliujia and @cloud-fan for review.


Same issue as #6019 - correct code does not validate, tried adding and removing lines

Challenge use-comments-to-clarify-code has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 Safari/537.36.
Correct code shown below results in red X error "Start a comment with

jQuery Playground

#left-well

        <button class="btn btn-default target" id="target1">#target1</button>
        <button class="btn btn-default target" id="target2">#target2</button>
        <button class="btn btn-default target" id="target3">#target3</button>

#right-well

        <button class="btn btn-default target" id="target4">#target4</button>
        <button class="btn btn-default target" id="target5">#target5</button>
        <button class="btn btn-default target" id="target6">#target6</button>

I'm not able to repro this error and it looks like it came during our rocky React launch that has been rolled back. I'm closing this as resolved, but please let us know if you're still experiencing the issue after doing a browser cache clear and refresh. Thanks and happy coding!


Where can I contact you?

Hi, sorry leaving this here but where can I contact the developer. I have some questions that might not be very appropriate to be in a github issue. Please leave an email or some sort of social media contact here so I can contact you. Very nice project btw. Love it. Thanks.

Emails of all the authors provided in the paper as usual. My email is<EMAIL_ADDRESS>

Sorry I missed it then haha. Thanks. I'll contact you.


Trying to use the $this->be() method in tests throws an exception

When trying to run a test for a logged in user, if $this->be seems to throw a BadMethodCallException. Would be good to get some details on how to go about testing Auth with LaraParse

@nicklee1990 Did you ever find out why this is?

Haven't had a chance to really get my tests filled out yet. Will try and have a look into this tonight or at least this weekend


fix(ci): remove Go and refactor install nfpm line

Follow-up PR from https://github.com/cdr/code-server/pull/3076#discussion_r610111979

[x] remove Go
[x] use @jawnsy's suggestion

Now that CI has been refactored the only place this is used is in run.sh right? Does anyone here actually use the Docker container for development? I wonder if it even makes sense to maintain.

Oh! I didn't even realize it but you're right. I don't use it for development. Not sure if others do, but I would be in favor of closing this PR and removing ci/images/debian10/Dockerfile.
Not sure if run.sh is even used?

Closing in favor of #3134


Schematic made external editor not working

Describe the Bug
I made a schematic in minecraft using create, this one works fine in the table, but if I make one with https://cubical.xyz/ and export it doesn't load in the schematic table. the empty schematic is just lost when pressing the checkmark
Reproduction Steps

go to https://cubical.xyz/ and make something
export as nbt
put in schematic folder
try to load using an empty schematic in game
empty schematic is lost

Expected Result
you get the schematic on the paper
Screenshots and Videos
No response
Crash Report or Log
No response
Operating System
Windows 10
Mod Version
0.4.1
Minecraft Version
1.18.2
Other Mods
No response
Additional Context
No response

do these schematics work on forge? can you provide a log?

someone on forge tested it and it did work. I will need to get a log later but I thought I would let you know that it did seem to work on forge. that's when I came to post about it here


[proposal] Reservation supports fine-grained CPU orchestration

What is your proposal:
Reservation should support fine-grained CPU orchestration. i.e. A reservation can allocate fine-grained CPU resources via our NodeNUMAResource plugin, and an owner pod can allocate reserved fine-grained CPU resources and get the same CPU binding result.
Furthermore, we expect a generic approach for other scheduling plugins to get compatible with the resource reservation. We've added some utility functions in #550 to facilitate this work.
Why is this needed:
Reservation is designed to reserve node resources for specific pods or workloads.  When an LSR/LSE pod is rescheduled, we hope to use resource reservation to ensure node resources. Nevertheless, it cannot reserve fine-grained CPU resources with our NodeNUMAResource plugin, because the reservation plugin does not identify the CPU allocation protocol in the pod annotations.
Is there a suggested solution, if so, please add it:

/area koord-scheduler

/assign


[TwigComponent] Component attribute merging... how to merge two stimulus_action (from component usage and the component itself)?

I have a Popup component which uses stimlus_action (call close() on ESC key press):
<div
    {{ attributes.defaults(stimulus_controller("popup")) }}
    {{ stimulus_action('popup', 'close', 'keydown.esc') }}
>
    {% block content %}{% endblock %}
</div>

When using this component, I may need additional actions (i.e. call show() on load):
<twig:Popup {{ ...stimulus_action('popup', 'show', 'load@window') }} />

... but this will override the default action defined in the component.
I know I can chain stimulus_action|stimulus_action as explained here, but I don't know how to to that in my specific case.
In my component, I can extract attributes("data-action") obtaining data-action="load@window->popup#show" but I don't know how to "send" it raw to stimulus_action, for chaining.
Maybe it's not even possible?
EDIT: Here https://github.com/symfony/ux-twig-component/blob/2.x/src/ComponentAttributes.php#L109 attributes like data-action are merged. Still can't understand how to the raw value from {{ stimulus_action('popup', 'close', 'keydown.esc') }} (without the data-action attribute name).

Found the way:
{{ attributes.defaults(
    stimulus_controller("popup"),
).defaults(
    stimulus_action('popup', 'close', 'keydown.esc')
) }}

For some reason, you need an additional .defaults().


Require Java 11 for building

We're now requiring Java 11 at runtime in Gemma. This would be the moment to fully switch.


Robot display - necessary and sufficient conditions

As a baby step, I'm trying to get a generic robot to show up in CAMP.  I'm wondering what the necessary and sufficient conditions are for the USV to be displayed.
From the CAMP getting started example (`roslaunch project11_simulation sim_local.launch'), it looks like there are position, velocity and orientation being subscribed to by CAMP (in the /ben/nav namespace).  Here is the graph

I tried an example where the system only publishes the position topic...

It appears that the position publications alone are insufficient for the display to show up (I think).  What are the ROS API necessary and sufficient conditions for the robot to be  drawn in the dispay?

There are also at least a couple of "heartbeat" messages being subscribed to by CAMP - with publications at 20 Hz.

Are one or both necessary?
Is the a minimum publication rate?
Are there conditions on the key/value pairs that need to be included?

Heartbeat
~ 20 Hz
/ben/project11/heartbeat [marine_msgs/Heartbeat]
header:
seq: 46140
stamp:
secs:<PHONE_NUMBER>
nsecs: 198406124
frame_id: ''
values:
key: "piloting_mode"
value: ''

key: "sim"
value: "asv_sim"
key: "have_commands"
value: "false"
Mission Manager Heartbeat
~ 20 Hz

/ben/project11/status/mission_manager [marine_msgs/Heartbeat]
header:
seq: 23795
stamp:
secs:<PHONE_NUMBER>
nsecs: 548406124
frame_id: ''
values:
key: "state"
value: "Pause"

key: "tasks_count"
value: "0"
key: "current_task"
value: "None"

Brian,
CAMP expects primary vehicle position/heading from

/ben/sensors/oem/position (sensor_msgs::NavSatFix)
/ben/sensors/oem/orientation (sensor_msgs::Imu)

and

/ben/nav/position (sensor_msgs::NavSatFix)
/ben/nav/orientation" (sensor_msgs::Imu)

The "ben" portion can be overridden using the robotNamespace config variable.  Much of CAMP's ROS interface and vehicle specific drawing code is in:
https://github.com/CCOMJHC/camp/blob/noetic/src/roslink.cpp
It doesn't seem like there would be any heartbeats necessary to display a vehicle but I could easily be wrong.  I don't believe the view recenters on the vehicle so you might have to zoom way out to initially see it.
Detail taken from the Trello card:
https://trello.com/c/zHiH4ovp
Best,
Andy

Awesome.  Thank you @apob .  I'll give it a shot

Good detective work! Heartbeats aren't necessary, just position.
This is all changing as I update the code to support our new DriX. Instead of hard coded topics, camp will listen to a topic (defaults to /project11/platforms) where descriptions of assets to track can be published. This will remove the hard coded components that you discovered above and allow the tracking and control of multiple vehicles.

This is probably more for @apob .
I had the Gazebo simulation publish position, orientation and velocity.  The pertinent part of the rosgraph is this...

The example setup is here: https://bitbucket.org/gfoe/project12/wiki/demo_annie_gazebo_camp
I still don't see the USV icon in the CAMP view.  I verified the the position (lat/lon) being published is such that it should show up on the map.
My next step would be to start digging into the CAMP source, but I thought if you already had an understanding of the source, then we might be more efficient to divide and conquer.

Brian,
Part of the issue at least is that CAMP doesn't seem to like our geotiff.  It loads and displays it but latitude and longitude are transposed.  As far as I can tell this might be from from differing "Data axis to CRS axis mapping":
https://gdal.org/tutorials/osr_api_tut.html#crs-and-axis-order
I'm basing this on differing gdalinfo output where the image that doesn't work reports "Data axis to CRS axis mapping: 2,1" while those that do report "Data axis to CRS axis mapping: 1,2".
I attempted to find a fix then decided discretion is the better part of valor :) and reprojected our image to UTM12N, which we'll need for Hypack anyway, and that worked as expected.  You can find this image here:
https://drive.google.com/file/d/1e_DyX4rI-OlwjawT75T8hr5gidTS_QBM/view?usp=sharing
Using "R600-YS-UTM12N-v2-meters.tif" and this:
rostopic pub -r 10 /annie/sensors/oem/position sensor_msgs/NavSatFix '{longitude: -110.388, latitude: 44.524}'
I can see the boat icon right off the northern tip of Stevenson island in CAMP.

I followed your demo instructions here:
https://bitbucket.org/gfoe/project12/wiki/demo_annie_gazebo_camp
and the subscriptions seem to be there but rostopic echo didn't show anything publishing on:

/jacm_gps_position
/annie/sensors/oem/position
/annie/nav/position

so even after I fixed the chart issue I didn't see anything on CAMP.
This problem could definitely be on my end though as ystone_camp.launch/Gazebo puts a serious hurt on development VM which could affect my results.
Best,
Andy

Andy, could you provide me with the geotiff that doesn't work? You could open a new issue just for this. Thanks!

Thank you @apob - the projection issue was my problem.  I didn't register that lat/lon was switched, so wasn't seeing the USV.
Is there a move-view-to-vessel feature in CAMP?  If not, I'll open an issue as a nice-to-have feature.

@bsb808 I don't believe there is a center view on vessel feature.  In the meantime zooming way out always works.
@rolker the "Look Here" and "Look at ASV" context menus are intended to control a base robotic camera correct (Johnny5 camera)?  I opened up another issue as you requested.  If there's any testing or help I can give there let me know.  I was hesitant to poke around too much without a larger stable of known working rasters.

Closing as resolved by @apob with the underlay reprojection.


Typescript reports circular dependency error in Record type but not in dynamic object type

I have two kinds of type, while using the Record, typescript is giving circular reference error. But when I do the same with a dynamic object, no error pops. Why typescript show two completely contrasting behaviours?
The expected output should be error on both or on none.
type ScopeItem =
    | string
    | {
            all: string;
            team: string;
      };

type ScopesTree = Record<string, ScopeItem | Record<string, ScopesTree>>; // error: Type alias 'ScopesTree' circular references itself
type ScopesTree2 = Record<string, ScopeItem | { [key: string]: ScopesTree2 }>; // no error

Is it something to do with the computation of the typescript type in both the cases? Please enlighten.
Thanks.

Duplicate of #41164.
There's a whole template you're prompted to fill out when you open a bug here; did you miss it?


Add support for long options with double hyphen in dita command

To follow the UNIX convention in command arguments, long option form should start with double hyphen. For backwards compatibility, the single hyphen form should be retained. After the change, the following commands are equivalent:
$ dita -install
$ dita --install

Should we also extend the CLI syntax so that you could set parameters directly with the long form? That is, the following would be equivalent
$ dita -Dfoo.bar=baz
$ dita --doo.bar=baz

The long form option would only be available for parameters configured in plugin configuration file.

👍

Should we also extend the CLI syntax so that you could set parameters directly with the long form?

I think that would make the CLI syntax more readable, as the -D syntax is hardly intuitive.
In the Ant/Java world, I'm sure -D was originally intended as a mnemonic for something — perhaps Define … a value for a property? — but I'm not sure how many users find this helpful.

The long form option would only be available for parameters configured in plugin configuration file

Maybe you are already thinking this ... but when supporting this for parameters in the shipped code, do we take the opportunity to consolidate on a parameter naming scheme? On the plus side - we'd officially have consistent, defined "parameters for common use on the command line". On the down side, we'd end up with different values -- -Dclean.temp=no versus --args.clean.temp=no

I think, because breaking things seem to be OK for 3.0, that it would be a good point of time to harmonize the naming patterns of parameters and deprecate deviations (e.g. args., dita.).

@robander, remember... years ago, I suggested we'd harmonize the argument names, with three different groups: public, internal but overridable, private. That never happened :)

One option would be to add a backwards compatibility layer that mapped e.g. the old dita.temp.dir into new temp-dir. The problem is, backwards compatibility layers have a tendency to become permanent fixture.

I definitely remember. The argument against is for the churn - existing scripts have to change, in addition to the general mess of making the changes. I don't like breaking things without a really good reason.
The reason I ask here is that these are, in a sense, new parameters. There is no parameter like --some.parm.name today. So when adding them, we could declare new values, even if the ones in Ant (under the covers) stay the same.
@xephon2 :

I think, because breaking things seem to be OK for 3.0, that it would be a good point ...

While we're allowed to break things, I still feel pretty strongly that we need to do it with great care. Even some of the relatively minor (incompatible) changes in 2.0 have proven scary enough to DITA-OT customers that they have not upgraded. If there are significant changes in 3.0 then I think we really risk people sticking at 1.8.5 forever.

One option would be to add a backwards compatibility layer ...
The problem is, backwards compatibility layers have a tendency to become permanent fixture.

In this case, I'd probably be fine with such a layer, particularly with the push to use dita making the Ant code less visible / less relevant. I think the biggest problem with compatibility layers is that they can get in the way of new development. For this, I don't really see that happening. Provided that we use the standardized scheme for any new parameters, the compatibility layer will never have a reason to grow; it can exist forever as an import to the Ant code without being edited or in the way. Still not exactly elegant - but provides for the new common scheme with zero disruption for existing scripts.

@robander: While we're allowed to break things, I still feel pretty strongly that we need to do it with great care. Even some of the relatively minor (incompatible) changes in 2.0 have proven scary enough to DITA-OT customers that they have not upgraded. If there are significant changes in 3.0 then I think we really risk people sticking at 1.8.5 forever.

Sure, I think it is way too early to start developing a new major release with > 250 open bugs, but that is another topic.
I'd recommend to implement fallback solutions for such things from major version to major version (e.g. from 3.0 to 4.0) and write a list with deprecated things at the end of each build log to force people to do somethin.

I know we talked about that sort of layer in the past, but decided against it, and I don't remember exactly why. It might have just been "this is too much work for too little benefit" -- and at the time everything was still Ant, so the changes would have been more in-your-face.

The backwards compatibility layer would need to be at Ant level, not CLI (dita command), because not all users use CLI.

One of the problems with a backwards compatibility layer is that if we e.g. have support for args.xsl -> stylesheet, users could use either the old or new name when passing the name to CLI or Ant. But, then we'd need to add a forwards compatibility layer, so that when user sets the new parameter, custom plugins would have access to the old parameter.

Ah, right. I remember that. They basically have to be interchangeable ... old stylesheets that set the old parameter need to keep working, old code that expect the old parameter need to keep working, so just switching to the new parameter (but pulling a value from the old) isn't enough. All coming back now.

Looks like this is covered by PR #2492. I think we can close this.


Remove use of ServerStatus from tritonserver.cc

I am adding ModelStatistics API which still uses lserver->GetStatus to collect stats, should I add an endpoint in server.h to return the stats directly?

I don't think you can just yet... the ServerStatus class needs to be streamlined to drop the non-stats parts (which is being done in this PR) and then you will have an lserver->GetStatistics method that you can use. For now it is ok to keep using GetStatus.


avoid multiple calls to records->count() In PermissionCheckboxSetField

these calls are not cached and lead to duplicate queries
example

drops the number of queries from 50 to 18 in my project to display a typical member

@GuySartorelli with pleasure ;)


Rotating ips

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

I'll close this PR, cause it doesn't really makes sense to PR a fork of DevYukine's LP into Fred's LP.
We'll do a back PR from his branch when everything is set.


Fix Altcoin/BTC Pair Graph

I fixed the Altcoin Graph's :)

cool, however I want only gdax enabled by default so zenbot incurs the minimum overhead out of the box. Thanks!

Sorry about that, I forgot to remove those changes before I made the pull request. I hope contribute more as I find time, thanks for open sourcing this!


Corrections for some of the DeepEval documentation/help pages

@penguine-ip
There are two separate pages that need to be corrected + one possible addition to cover off an undocumented parameter:
The example under https://docs.confident-ai.com/docs/synthesizer-introduction#filteration-quality
is wrongly referencing Synthesizer(filteration_config=...) when it should be filtration_config.  That is removal of "e" in the spelling.
And the object instance probably should consistently be renamed accordingly (to avoid naming confusion).
The full example would become:
from deepeval.synthesizer.config import FiltrationConfig

filtration_config = FiltrationConfig(
  critic_model="gpt-4o",
  synthetic_input_quality_threshold=0.5
)

synthesizer = Synthesizer(filtration_config=filtration_config)

Finally the Title of this section and URL reference to jump to this section should be updated accordingly from:
https://docs.confident-ai.com/docs/synthesizer-introduction#filteration-quality
to
https://docs.confident-ai.com/docs/synthesizer-introduction#filtration-quality
(or similar)

The section under https://docs.confident-ai.com/docs/synthesizer-generate-from-docs#customize-context-construction
wrongly references ContextExtractionConfig whereas the actual class in synthesizer/config.py has defined the
class ContextConstructionConfig.
The example and the two related text references in this section need to be updated (eg see the first sentence of this section).
NB: Minor but there is also a typo in the example saying "from deepeval.synthesizer.confg ..." instead of "config".
Summary of updates needed:
The two class name references in this section should be updated, and the full example should be updated from:
from deepeval.synthesizer.confg import ContextExtractionConfig

...
synthesizer.generate_goldens_from_docs(
  document_paths=['example.txt', 'example.docx', 'example.pdf'],
  context_extraction_config=ContextExtractionConfig()
)

To:
from deepeval.synthesizer.config import ContextConstructionConfig

...
synthesizer.generate_goldens_from_docs(
  document_paths=['example.txt', 'example.docx', 'example.pdf'],
  context_construction_config=ContextConstructionConfig()
)

There is an undocumented optional parameter for generate_goldens_from_contexts method being source_files that you might like to now document under the relevant section.
URL = https://docs.confident-ai.com/docs/synthesizer-generate-from-contexts#generate-your-goldens
Could add new bullet point:

[Optional] source_files: a list of strings being the source of the contexts.  Length must be aligned with the length of contexts.

(or similar wording)

@CAW-nz It's corrected now, appreciate it ! :)

Closing as all updated now.


Upgrade to netcoreapp22

@ryanbrandenburg Given that EF 2.1+ targeting netcoreapp2.0 is still a valid scenario, is this something that has to be done on the EF repo?

The decision was made in engineering triage to only have net461 and netcoreapp2.2 as TFM's in tests and samples. If you have specific reasons why this shouldn't be the case for EF lets start an email thread.

@ryanbrandenburg What I'm really asking is what is broken if we don't remove netcoreapp2.0 on EF?


feature request, solid round stroke color

H!,
Are you going to build solid round border function in it, in the near future ?
Say for example, a white text, and a [n.n] 'px' black border.
Like this program  https://www.71squared.com/glyphdesigner , https://www.bmglyph.com

Hi!, sorry, there are no such plans in the near future. Anyway, PRs are welcome!


Feat/various

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


chore(main): release 0.6.0

:robot: I have created a release beep boop
0.6.0 (2024-01-01)
Features

reconnect to eventsource endpoint after errors (b46141f)

Bug Fixes

deps: update rust crate config to v0.13.4 (f246116)
deps: update rust crate eventsource-client to v0.12.0 (c15c73c)
deps: update rust crate eventsource-client to v0.12.1 (23b27a5)
deps: update rust crate eventsource-client to v0.12.2 (3c69a81)
deps: update rust crate eyre to v0.6.10 (e877611)
deps: update rust crate eyre to v0.6.11 (7681be3)
deps: update rust crate eyre to v0.6.9 (4d20714)
deps: update rust crate futures to v0.3.29 (d789573)
deps: update rust crate futures to v0.3.30 (e7e0a11)
deps: update rust crate hyper to v0.14.28 (82a30ac)
deps: update rust crate hyper-rustls to v0.24.2 (3dd3555)
deps: update rust crate rustls-pemfile to v1.0.4 (4e2c2fe)
deps: update rust crate serde to 1.0.190 (99c2f71)
deps: update rust crate serde to v1.0.192 (b0372a1)
deps: update rust crate serde to v1.0.193 (5046e92)
deps: update rust crate serde_json to v1.0.108 (c4b07c8)
deps: update rust crate serde_json to v1.0.109 (171f915)
deps: update rust crate tokio to v1.34.0 (688abd7)
deps: update rust crate tokio to v1.35.0 (1e8c8a3)
deps: update rust crate tokio to v1.35.1 (9a8350d)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/FruitieX/hue-mqtt/releases/tag/v0.6.0 :sunflower:


Shrink

Replaces #65

This looks to be the same error (multiple times)

spaaaaack!

More seriously, I'll take a look at it.  My binutils external detection PR merged, so that will help.  The biggest things left are actually getting a sparse checkout, which I want to talk over with you, and possibly dealing with this: https://github.com/spack/spack/pull/29031

Ok, I'm going to add the fixes for the gold issue and some other cleanup here now that it proved out in the clang update.

This should now build a good bit faster, since it's no longer building cmake in spack, but it has more in it that downstream packages can use, and configures spack to automatically reuse what's there.
If you don't like any of this, say so and I'll pull it out, but I also re-worked it to use an environment to manage the view, and configure spack through the environment to use that so a spack install in a downstream container will automatically install into the environment and update the view.  It also updates the paths for man, pkgconfig, aclocal and cmake so CI or others that use these with build systems that are not spack will find all spack built components without extra work.
Was arguing with myself about getting rid of the git overhead for grabbing spack.  We could grab the commit and unpack it with: curl -L https://github.com/spack/spack/tarball/9e2d78cffc1beaec2c6e4c3a379c17f25a35b31f |  tar -xz
That drops the container size by ~100mb, and fetches in less than 5 seconds, but of course the result is not a functioning git repo.  If the point is to keep the one pinned commit, then that's probably fine, but if not... Not sure, what do you think?
The follow-on question is, now that this builds in just over 3 minutes in github actions, what do you think about wiring up the build so the containers based on this one to build based on the version for the current day? I have no idea how complex this is, so treat that as a completely naive question.

Sorry didn't see this been so distracted with dwarf and gather.town today lol! Let me take a look.

That drops the container size by ~100mb, and fetches in less than 5 seconds, but of course the result is not a functioning git repo. If the point is to keep the one pinned commit, then that's probably fine, but if not... Not sure, what do you think?

I think we probably want a functioning git repo for anyone that wants to use a different spack history commit, etc.

The follow-on question is, now that this builds in just over 3 minutes in github actions, what do you think about wiring up the build so the containers based on this one to build based on the version for the current day? I have no idea how complex this is, so treat that as a completely naive question.

You mean the other matrix builds? They will already use whatever is latest for the base images. Or do you mean something else?

The follow-on question is, now that this builds in just over 3 minutes in github actions, what do you think about wiring up the build so the containers based on this one to build based on the version for the current day? I have no idea how complex this is, so treat that as a completely naive question.

You mean the other matrix builds? They will already use whatever is latest for the base images. Or do you mean something else?

You've mentioned a couple of times that there's a day delay, I assume because when the build starts each one picks up the base that exists when it's created rather than the one that would be generated that day.  Perhaps I misunderstood?

You've mentioned a couple of times that there's a day delay, I assume because when the build starts each one picks up the base that exists when it's created rather than the one that would be generated that day. Perhaps I misunderstood?

That can happen yes - but the base images workflow triggers before the matrix images, so I think they could be used the same day but I cannot guarantee it. What does have a day delay is a non base image (e.g., a matrix build) that uses another matrix build (since they build at the same time).

Ah, got it, so probably nothing to do then. Great!
If you're happy with this behavior, I can propagate it to the other Ubuntu base images. What do you think?

I think that would be ok with me - ping @davidbeckingsale to check! I'm wondering if we have a lot of redundancy in chunks that we run if we should have scripts to copy and run instead? :thinking:

We have a lot of redundancy right now, especially after what I added.  I was actually planning to ask you about scripts, shall I add a scripts directory either at the ubuntu level or at the top? At least the spack setup and the cmake setup could easily be scripts, will take a look at the others.

@trws we can remove the autamus cache, it's going to be refactored to be something different and probably mostly broken given all the hash changes anyway.

It seems like the clang builds are failing with a bus error in the clang build again, I think that means they are not pulling the up-to-date ubuntu images, since those configure spack to re-use the system python. 🤔

Aside from the comments, which I'll work on in a second, I need to figure out how to get the clang builds to use the ubuntu builds from this PR, or how to get them out of this entirely.  They depend on things from the new base, and because they're using an older version as base instead they consistently fail even if they build.  Trying reverting the clang dockerfile for now.

@trws for a PR if you make changes to a file it will build, so you are 100% correct! Just remove the clang changes and we can open a PR for that separately after the base ubuntu's are merged/deployed (and then the matrix ones won't fail). It's definitely not a perfect system having base containers --> used by --> matrix containers but if you have an idea to make it better we can definitely try!
btw if the lab had peer bonuses I'd totally give you one for this work, I am extremely grateful for the time/attention you are putting into these improvements!

Cool! And thanks, I'm happy to help get some of this stuff going again.  We need a solid base to use for our testing and deployment stuff, it's well worth it, and I like how you set this up.  My biggest gripe with our old way was getting newer or "latest" versions was a pain, having uptodate in the mix should make that a lot nicer.
As a side-note, while we do not have peer bonuses (or real bonuses in general) comp does do "SPOT awards" nominations that one can put in for other employees.  Not fishing here, but I've heard group leads asking for more nominations so it may be something to keep in mind.

Ok, I think this one is cleaned up and ready to go.  There will need to be at least one downstream PR to do clang and the other ubuntu downstream containers, and if you would like I can apply this to the alpine base as well.

They are deployed! :partying_face:


[Feature] [Ready for Code Review] Consolidate expand/collapse use in two locations

Purpose
Based on issue #3689 this PR replaces the expand/collapse functionality of two locations

View Only Link table in Sharing page
Addon active projects list in user settings page

closes #3689
Changes
Removes existing expand collapse logic and markup from the two locations and replaces with the osfToggleHeight plugin.
Known Side Effects
None
Screenshots of New Implementation
(see issue #3689 for originals)

After talking with @erinmayhood I should add some notes on this feature for QA:
This fix utilizes an existing expand/collapse plugin to unify two other instances. Now there are three instances where this is used:

Account Settings: Configure Add-on Accounts: table of projects that have the add-on.
Sharing: Add Private Link: table that shows the private link project and subcomponents
Project Summary: List of contributors.
If the core plugin toggleHeight is changed in subsequent PR's, all these three locations need to be tested for functionality)

About uniformity:
This expand/collapse plugin is not designed to replace all instances of expanding. It can be used where  some content needs to be shown to give people there is more of the same. That's why some content in these cases is always visible. The toggle is also always under the cut content so people know it will expand.
It is NOT intended for locations where the expand/collapse happens in a different location or completely closes/hides certain sections. For instance Panels have their own expand/collapse plugin, treebeard and component widgets have their own functions.
It also required height to be changeable, so if a component has its own height management this plugin will not work (i.e. treebeard has its own height and toggle management).

Pass finished.

First pass complete. :star:


createChildCompiler does not remember target

This is related to webpack-contrib/worker-loader#44 but if I'm correct this is an issue with webpack itself rather than the loader. The basic issue is that createChildCompiler does not take into account the target (in my case 'node-webkit') when creating a subcompiler. The reason seems to be that compile-plugins are filtered out.
A quick hack fix was to include the compile-plugins in the child compiler, but, as I'm unfamiliar with the code base, I don't know of the unwanted side-effects (which I presume are plenty).
I've tested this on master release as well as the latest release (2.2.1). It also seems to be an issue in v1 as that's what the project I'm working on which spawned the error was using.

It looks like you just deleted our lovely crafted issue template. It was there for good reasons. Please help us solving your issue by answering the questions asked in this template. I'm closing this. Please either update the issue with the template and reopen, or open a new issue.

I'm sorry, I deleted it because the other issue describes it in more detail. Will update it now.