juicefs hang when sync .accesslog file

What happened:
root@bench-01:~/zhoucheng# rsync /tmp/sync-test/.accesslog  rsync_dir/.accesslog
root@bench-01:~/zhoucheng# cat rsync_dir/.accesslog
root@bench-01:~/zhoucheng# juicefs sync /tmp/sync-test/.accesslog juicefs/.accesslog
2022/04/25 13:39:49.477864 juicefs[1536126] <FATAL>: create file /root/zhoucheng/juicefs/.accesslog: Creating directory /root/zhoucheng/juicefs failed: "mkdir /root/zhoucheng/juicefs: not a directory" [main.go:85]
root@bench-01:~/zhoucheng# juicefs sync /tmp/sync-test/.accesslog jfs_sync_dir/.accesslog
2022/04/25 13:40:05.293277 juicefs[1536142] <INFO>: Syncing from file:///tmp/sync-test/.accesslog to file:///root/zhoucheng/jfs_sync_dir/.accesslog [sync.go:610]
Scanned objects count: 0 / 1 [--------------------------------------------------------------]   0 %    0s
 Copied objects count: 0                                                           ⠏
 Copied objects bytes: 0.00 b (0 Bytes)   0.00 b/s                                 ⠏
Checked objects bytes: 0.00 b (0 Bytes)   0.00 b/s                                 ⠏
Deleted objects count: 0                                                           ⠏
Skipped objects count: 0                                                           ⠏
 Failed objects count: 0                                                           ⠏
^C^C

root@bench-01:~/zhoucheng# stat /tmp/sync-test/.accesslog
  File: /tmp/sync-test/.accesslog
  Size: 0         	Blocks: 0          IO Block: 65536  regular empty file
Device: 6eh/110d	Inode:<PHONE_NUMBER>559808513  Links: 1
Access: (0400/-r--------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-04-25 13:19:47.000000000 +0800
Modify: 2022-04-25 13:19:47.000000000 +0800
Change: 2022-04-25 13:19:47.000000000 +0800
 Birth: -

What you expected to happen:
now juicefs sync will hang with .accesslog because this file is infinity which is always be written.
but rsync can handle this, rsync will check the size of file , if size is 0, it will create an empty file.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?
Environment:

JuiceFS version (use juicefs --version) or Hadoop Java SDK version:
Cloud provider or hardware configuration running JuiceFS:
OS (e.g cat /etc/os-release):
Kernel (e.g. uname -a):
Object storage (cloud provider and region, or self maintained):
Metadata engine info (version, cloud provider managed or self maintained):
Network connectivity (JuiceFS to metadata engine, JuiceFS to object storage):
Others:

Fixed by #1898


Fix cutoff COP behaviour of hybrid heat pumps

Background
The mechanical turk spec hybrid_heatpump_spec.rb tests the behaviour of hybrid heat pumps. One part of the spec tests whether an increase in insulation i.e., a decrease in useful space heating demand,   results in changed input shares for network_gas, ambient_heat and electricity.
expect(@scenario.turk_hhp_network_gas_input_share.increase).to be_within(1.0E-12).of -0.0005791348178179612
# then the ambient_heat and electricity share grow by this value, distributed in agreement with the COP
# the small window of 1.0E-12 is there because of the COP calculation
expect(@scenario.turk_hhp_electricity_input_share.increase).to be_within(1.0E-12).of 0.0002160631521914147
expect(@scenario.turk_hhp_ambient_heat_input_share.increase).to be_within(1.0E-12).of 0.0004036111028738465

According to this spec, a reduced heat demand therefore decreases the share of network_gas. Reproducing the scenario on production, we can verify that this is the case. Comparing a scenario without any changes, with a scenario with the changes indicated in the spec, a 2% increase of insulation:
EACH(
  V(households_space_heater_hybrid_heatpump_air_water_electricity,network_gas_input_conversion),
  V(households_space_heater_hybrid_heatpump_air_water_electricity,electricity_input_conversion),
  V(households_space_heater_hybrid_heatpump_air_water_electricity,ambient_heat_input_conversion)
)

Present:
[
  0.158836612133303,
  0.152938797793945,
  0.688224590072752,
]

Future (no changes):
[
  0.3465453982236986,
  0.22287045724654836,
  0.40632596665409415,
]

Future (insulation set):
[
  0.34596626340588066,
  0.22308652039873886,
  0.4067295777569689,
]

The input conversion of network_gas shows a (very) small decrease.
Issue
If I try to reproduce the behaviour on master, the demand decreases much in the same way, but the distribution of input carriers does not change. Comparing a scenario without any changes, with a scenario with the changes indicated in the spec, a 2% increase of insulation:
Future (no changes):
[
  0.41527148880985193,
  0.19900281843047687,
  0.3566566885429816,
]

Future (insulation set):
[
  0.41527148880985193,
  0.1990028184304767,
  0.3566566885429817,
]

The input conversion of each carrier remains the same.
Solution
The goal here is to understand how changes in insulation (effectively decreasing demand) should affect the behaviour of (hybrid) heat pumps. Then we can investigate why this behaviour no longer occurs properly on master, fix the behaviour and the spec.

Another interesting dynamic plays out on production for the hybrid heat pump on gas. In a blank scenario for nl2019, the heat pump initialises with a 101.11% useable_heat output efficiency in the present, which is interesting in itself:

For the future it looks like this:

When the cutoff COP for space heating is moved from the 2.6 default to 5.0, around &% of energy input 'appears' out of nowhere. Note, this behaviour occurs on production before any of the changes of heat modelling in the built environment:

Your link for the scenario with changes on beta points to pro, could you update that one please?

Thanks for the headsup. I updated the link

Could it have to do with the change in calculation of the future COP?

branch
COP future
FLH present
FLH future

pro
2.93
2,039.5
1,993.2

master
2.94
2,033.1
1,992.4

heat-final-fixes
2.9
1,950
1,911

Second theory:
We used to mix the demand curves of the households based on the insulation settings. This means that the shape of the curves would change according to the insulation settings.
With the new modeling, we don't mix the curves anymore, we just change the demand. So the shapes always stay the same. Could that explain the difference that the mix of inputs also stays the same?

I think you second theory is very likely to be the cause of this. I'll see if I can replicate the behaviour in the new heat modelling to verify this theory.

 In both cases I made sure that the useable heat demand was roughly the same. The share of the hybrid heat pump is set to 100%.
As becomes clear in the screenshots below, the input shares do change. This confirms your second theory @noracato! The issue with the cutoff COP remains and I renamed the issue accordingly.

When the cutoff COP for space heating is moved from the 2.6 default to 5.0, around 7% of energy input 'appears' out of nowhere. Note, this behaviour occurs on production before any of the changes of heat modelling in the built environment

According to the hhp_adapter description in ETEngine, the output of a hybrid heatpump is always set to 100%:

Since the efficiencies and shares of carriers may change by the Fever calculation, it is not possible to set an output conversion on the node other than 1.0. If half of the input energy for the node were to come from the primary component, and half from the secondary, setting an output conversion of 1.03 would result in inaccurate input of the primary component carriers. To that end, the node will be hard-coded to an output conversion of 1.0, and the input shares will be adjusted to ensure the flow of energy into the node is correct.

Energy appearing out of nowhere results from the >100% efficiency of the gas heater part of the hybrid heat pump. The efficiency of a gas boiler is 107% (because efficiency calculations in the EU are based on the lower heating value). Because the output is fixed at 100%, the input from the gas heater must be less than that by a factor of 1/1.07 = 93.46%.
Conversely, for hybrid heat pumps with a heater part that has an efficiency below 100%, the input will be higher than 100%. However, contrary to normal procedures, because the output is fixed at 100%, by definition there are 0% losses. As a result,  energy will seem to disappear between input and output.

Nice summary @KoenvanB, glad we clarified this!


add instruction

can you please add instruction that how we can run these code

put input.jpg in data file


Code Quality: Files is still using 7z 21.01 Alpha

Description
Files uses an outdated version of 7-zip is vulnerable and the dependency should be updated
Concerned code
src/Files.App/7z.dll
src/Files.App/7z64.dll
src/Files.App/7zArm64.dll
Gains

Address recently surfaced 7-zip CVE

Requirements

Replace all three dlls with their latest version

Comments
No response

Thank you. Do you know the easiest way to find the most up to date dlls?

Thank you. Do you know the easiest way to find the most up to date dlls?

I downloaded them from the official website(https://7-zip.de/download.html) and replaced them manually.

Resolved with #16585


Ignore corrupted tables on sys.shards queries

I'm not really sure if this is a good idea and whether we still need it after

https://github.com/crate/crate/pull/10713
https://github.com/crate/crate/pull/10706

It could potentially mask bugs?
Checklist

[ ] Added an entry in CHANGES.txt for user facing changes
[x] Updated documentation & sql_features table for user facing changes
[x] Touched code is covered by tests
[x] CLA is signed
[x] This does not contain breaking changes, or if it does:

It is released within a major release
It is recorded in CHANGES.txt
It was marked as deprecated in an earlier release if possible
You've thought about the consequences and other components are adapted
(E.g. AdminUI)

Won't do this for now. Also not https://github.com/crate/crate/pull/10714#discussion_r513319323
Users shouldn't be able to create broken tables or modify tables in a way that breaks them and we should rather fix bugs in that area than trying to cope with broken tables.
DROP TABLE can be used as an escape hatch and we already improved the validation for CREATE and ALTER TABLE.


Fixes #25 - Sync with Spec 0.6

Signed-off-by: Ricardo Zanini<EMAIL_ADDRESS>Fixes #25
TODO:

[x] Implement schema validation
[x] Update test case data with 0.6 examples
[x] Implement End as also a boolean field
[x] Implement string or struct fields

thats a big change-  ty!

With this PR we can release 2.0.0 version, and expand the possibilities :)

@iwita your review would be much appreciated

As far as I can judge, the PR seems to address both the new additions from the v0.6 specification( #25 ) and issue #16.


[Bug]: [iOS v10]: Occasional crash when MapView is unmounted before fully loaded

Mapbox Implementation
Mapbox
Mapbox Version
10.7.0
Platform
iOS
@rnmapbox/maps version
10.0.0-beta.11
Standalone component to reproduce
import React from 'react';
import {
  MapView,
  ShapeSource,
  LineLayer,
  Camera,
} from '@rnmapbox/maps';
import {
View,
TouchableOpacity,
} from 'react-native';

const aLine = {
  type: 'LineString',
  coordinates: [
    [-74.00597, 40.71427],
    [-74.00697, 40.71527],
  ],
};

class BugReportExample extends React.Component {
  constructor(props) {
    super(props);
    this.state = { showMap: true };
  }
  render() {
    return (
      <View style={{ flex: 1 }}>
        <TouchableOpacity onPress={() => this.setState({ showMap: !this.state.showMap })}>
         <View style={{ width: 100, height: 70, backgroundColor: 'red' }} />
       </TouchableOpacity>
       { this.state.showMap &&
      <MapView style={{flex: 1}}>
        <Camera centerCoordinate={[-74.00597, 40.71427]} zoomLevel={14} />
        <ShapeSource id="idStreetLayer" shape={aLine}>
          <LineLayer id="idStreetLayer" />
        </ShapeSource>
      </MapView>
      }
      </View>
    );
  }
}

Observed behavior and steps to reproduce
In our app we unmount the MapView onBlur during navigation to a new screen to prevent multiple MapViews from being rendered at once in the navigation view stack. Sometimes if the user navigates too quickly before the map is fully loaded a native exception is thrown as seen below:
rnmapbox_maps/RCTMGLMapViewManager.swift:32: Fatal error: Unexpectedly found nil while unwrapping an Optional value 2022-09-23 16:33:02.701738-0700 xxx[xxxx] rnmapbox_maps/RCTMGLMapViewManager.swift:32: Fatal error: Unexpectedly found nil while unwrapping an Optional value

Expected behavior
MapView should unmount without crashing the app
Notes / preliminary analysis
No response
Additional links and references
No response

@wen-kai thanks for the report.
I've tried but could not reproduce on  v10.0.0-beta.42 and mapbox 10.8.1, and simulator.
Please try with latest version and comment if you can still reproduce


#38 Fixed packaging

Codecov Report

Merging #41 (262ffc4) into dev (89ad163) will decrease coverage by 0.37%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              dev      #41      +/-   ##
==========================================
- Coverage   85.15%   84.78%   -0.38%
==========================================
  Files           2        2
  Lines         566      552      -14
==========================================
- Hits          482      468      -14
  Misses         84       84

Impacted Files
Coverage Δ

qiita_sync/qiita_sync.py
84.75% <100.00%> (-0.38%)
:arrow_down:

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 89ad163...262ffc4. Read the comment docs.


Fix deprecated get_active_clients

Great if merged.

Thank you!

Note that this is a duplicate of #62, which also handles backwards compatibility (so nvim 0.9 doesn't break)


Loading Button Animations Template

Please let me know if you find any issues
Please assign it under the hacktober fest , i want to work under it
Is your feature request related to a problem? Please describe.
sometimes we can show the user the loading instead of directly moving to other page
Describe the solution you'd like
this button looks cool

Submit your PR I will add hacktoberfest accept label


Mergify: Does not use master

Btw, have you guys considered using master? Mistakes like this are bound to happen when things are different across the repos in our organization.
@fsvehla @mijicd

Btw, have you guys considered using master? Mistakes like this are bound to happen when things are different across the repos in our organization.

This make completely sense because of the common, shared code, we’ll switch to master.


Allow compile to take custom compilation steps

first off, I'm not a fan of this PR as I think differentiating too far original C# implementation isn't the best idea.
Nevertheless I would love a way to add my own compile steps so i think it's worth discussing this or other ways to make it possible.
This changeset essentially adds an extra argument to compile allowing custom steps (they're added to the end of the default steps).
My first go at this, I tried to add the custom steps inside the Compiler. Although ideal that did not workout great since it required all sorts of bounds on the functions pointers. I'm not the best at rust so it quickly blew up in my face.
Definitely would be nice to hear it's possible though.

@stargazing-dino I had the same thought while writing the code. Good idea!
For backwards and C# compatibility, I suggest adding a new function instead: compile_with_custom_steps.

Ooohh yeah, that'd work perfectly I think. I'll see if I can't do that this weekend.
My use case: I have a naive implementation of a node analyzer that builds a graph using petgraph and checks for unreachable nodes/recursion and such using CompiledProgramAnalyser but I think it'd be a lot easier to do at the tree level than the instruction one. (note, it's nothing like the fancy z3 stuff jon manning was doing but still :P)
Happy to contribute it once it's working

@stargazing-dino that's a really cool idea! I'd love to include it in the crate :)

@janhohenheim Mind if I get your advice?
I got custom functions looking like this:
    /// Compiles the Yarn files previously added into a [`Compilation`].
    pub fn compile(&self) -> Result<Compilation> {
        run_compilation::compile(self, Self::default_compiler_steps())
    }

    /// Compiles the Yarn files previously added into a [`Compilation`] with custom compilation steps.
    pub fn compile_with_custom_steps(
        &self,
        custom_steps: Vec<&CompilationStep>,
    ) -> Result<Compilation> {
        run_compilation::compile(self, custom_steps)
    }

    /// The default compilation steps that the compiler will use.
    pub fn default_compiler_steps() -> Vec<&'static CompilationStep> {
        vec![
            &register_initial_variables,
            // etc.
        ]
    }

For that, I made all compiler_steps pub. I also had to pub the CompilationStep and anything around that.
I then got a simple test going that adds a line to the string table:
#[test]
fn test_compile_with_custom_steps() {
    let source = "
        <<declare $int = 42>>
        <<declare $str = \"Hello\">>
        <<declare $bool = true>>
    ";

    let custom_steps: Vec<&dyn Fn(CompilationIntermediate) -> CompilationIntermediate> = vec![
        // ... all other steps here
        &|state| {
            // Custom step: Update the string table
            let mut string_table = state.string_table;
            string_table.insert(
                "custom_line_id".into(),
                StringInfo {
                    text: "Custom line".to_string(),
                    node_name: "Start".to_string(),
                    line_number: 1,
                    file_name: "<input>".to_string(),
                    is_implicit_tag: false,
                    metadata: vec![],
                },
            );
            CompilationIntermediate {
                string_table,
                ..state
            }
        },
    ];

    let result = Compiler::from_test_source(source)
        .compile_with_custom_steps(custom_steps)
        .unwrap();

    // Check that the custom line is present in the string table
    assert!(result.string_table.contains_key(&"custom_line_id".into()));
    assert_eq!(
        result.string_table.get(&"custom_line_id".into()).unwrap(),
        &StringInfo {
            text: "Custom line".to_string(),
            node_name: "Start".to_string(),
            line_number: 1,
            file_name: "<input>".to_string(),
            is_implicit_tag: false,
            metadata: vec![],
        }
    );
}

Then I got sidetracked and thought well, there's not much use in that unless you have visitors...
and so took a crack at that and made a custom step that had it's own Visitor that counts the number of strings.
struct StringLiteralCounter {
    pub count: usize,
    _dummy: (),
}

impl StringLiteralCounter {
    pub fn new() -> Self {
        Self {
            count: 0,
            _dummy: (),
        }
    }
}

impl<'input> ParseTreeVisitorCompat<'input> for StringLiteralCounter {
    type Node = YarnSpinnerParserContextType;
    type Return = ();

    fn temp_result(&mut self) -> &mut Self::Return {
        &mut self._dummy
    }
}

impl<'input> YarnSpinnerParserVisitorCompat<'input> for StringLiteralCounter {
    fn visit_valueString(&mut self, _ctx: &ValueStringContext<'input>) -> Self::Return {
        self.count += 1;
    }
}

pub fn count_string_literals(mut state: CompilationIntermediate) -> CompilationIntermediate {
    let mut string_literal_count = 0;
    for file in &state.parsed_files {
        let mut visitor = StringLiteralCounter::new();
        visitor.visit(file.tree.as_ref());
        string_literal_count += visitor.count;
    }
    // state.string_literal = string_literal_count; // <-- Nope
    state
}

but the problem is that CompilationIntermediate is not extendable. We'd likely need to make it a trait so the user can make their own allowing for whatever metadata they want.
Anyways, what do you think about the

Scope of this PR. Is it too large? Should I break it up?
How pub should we go? I first made a test and only pubified things needed for it to compile but I don't know what's common.
Thoughts on making the CompilationIntermediate a trait?

Hey, sorry for not looking into your query yet. I was really busy the last weeks and will probably still be for another week or so. I'll check it out in a more in-depth fashion then.
From a quick glance:

Smaller PRs are always good, but if you don't feel like it, this one is still fine for me
Try to keep things only pub(crate). pub types will be something that other devs will depend on, so we won't be able to refactor them later without breaking people's code. I haven't looked at the specific types in question yet, so I'll comment on them later. In general, the current pubs are oriented around what is public in the C# code.
Sounds like a good solution. I'm also fine with storing Box<dyn CompilationIntermediate>, since this would definitely not be a performance bottleneck for us.

Sounds good :D
Yeah, I'll likely start with the Box<dyn CompilationIntermediate> this weekend as it's own PR since it's largely self-contained

@stargazing-dino I've got a bit more time now. Anything I can do to help with this PR? :)


re-organise donotanswer prompts

the failure modes the DNA probes check for are grouped unclearly in the original setup.

[ ] set current probes to active=False, and name them "orig" or "paper" or similar, leaving the original paper's work accessible
[ ] work out what groupings we'd like to test for, and re-allocate the prompts into these
[ ] implement another dynamically-defined set of DNA probes using the new groups

Refactor DoNotAnswer as a policy test


responsive navbar and some css

Title and Issue number

Close #1807

Checklist:

[] I have mentioned the issue number in my Pull Request.
[] I have commented my code, particularly in hard-to-understand areas
[] I have created a helpful and easy to understand README.md

@MohitGupta121
Here is screen recording of my changes
https://github.com/pranjay-poddar/Dev-Geeks/assets/104628038/2f2ff9a3-066e-452d-a30a-ed5447dcfdf4


gui: disable daemon jsonrpc client for windows

It is not certain that uds_windows will work so we prefer
to remove it.

utACK 37562608ecd9471fe37ea123fe21512b6d373068. That sounds more reasonable, and removes 8 dependencies :tada:.

So merging this apparently broke Cirrus CI. I'm going to revert it in #216.


Adding code logic for tagcloud-link attribute

Similarly to tagcloud-weight this change takes an attribute tagcloud-link and generates an a href element linking within the presentation.
For example Twitter Bootstrap will generate a link to /#/42, which is the 42nd slide in the presentation.
Fixes #5

Nice idea! I will have a look on it! Please be patient for some days as I am quite busy right now ;-)
Sebastian Hildebrandt

Am 21.01.2016 um 17:24 schrieb Christian Prior<EMAIL_ADDRESS>Similarly to tagcloud-weight this change takes an attribute tagcloud-link and generates an a href element linking within the presentation.
For example Twitter Bootstrap will generate a link to /#/42, which is the 42nd slide in the presentation.
You can view, comment on, or merge this pull request online at:
https://github.com/sebhildebrandt/reveal.js-tagcloud-plugin/pull/4
Commit Summary
Adding code logic for tagcloud-link attribute
File Changes
M tagcloud/tagcloud.js (12)
Patch Links:
https://github.com/sebhildebrandt/reveal.js-tagcloud-plugin/pull/4.patch
https://github.com/sebhildebrandt/reveal.js-tagcloud-plugin/pull/4.diff
—
Reply to this email directly or view it on GitHub.


Shade Alternate Rows

When you have many rows it is useful to have a shading in alternate rows to identify the correct row.
There are more urgent things, but I think that in the future it would be good.

this could be an easy addition for future versions, sure!


partial test not added yet

could someone add partial tests?  add the tests in canner-core.

https://github.com/Canner/canner-core/tree/master/test


Revert "Configure cloud provider"

Reverts dszczurek/github-actions-continuous-delivery-azure#2

ok


Schema rename multiple fields

Tests for rename_schema for #810. Don't look at this yet since I'll be adding comments explaining some of the trickier parts of what I've written so far and discussing other edge cases for which I haven't written tests yet.
I'll probably split this into a number of smaller PRs as this grows (since this is already a pretty decent-sized PR), but for now I wanted to have things all in one place so i can keep track of things.

Possibly non-obvious decisions about the changes that are already here

All existing schema renaming tests have a 1-1 renaming, so we simply change the string to a list containing that string: A->B becomes A->[B].

If we suppress every field in the schema, you can't query anything. To avoid suppressing every field, I've added a field to the tests and input for non_null_schema. As a result, I also updated test_merge_schemas which uses this input string.

The tests are named as follows: test_detail_renametype.

Detail gives some more detailed information about what's being tested, e.g. specifying that a particular test renames an enum.

Rename type describes whether the test is suppressing a field or performing a one-to-many renaming (or both)

reverse_name_map should still work the same way as before even if the renaming is not 1-1. In particular, reverse_name_map maps an entry A->B iff rename_schema's renamings parameter maps B to a list containing A and A and B are different strings (and there are no naming conflicts).

This implies reverse_name_map will never map a string to itself.

reverse_name_map isn't affected by field suppression. If we suppress A by mapping it to the empty list, then there is no way to write a query with a field that gets renamed to A via rename_query. So, there's no need for this information to exist in reverse_name_map (it's unrepresentable anyways).

I considered an alternate representation of reverse_name_map which includes the mapping A->A for all such A where either A is not renamed or renamings includes a mapping A -> a list of strings that includes A.

This would also implicitly specify which fields are suppressed, because they'd be the only fields from the original schema that nothing maps to in reverse_name_map.

Although this has the nice property of including more information than the expected implementation of reverse_name_map, I decided not to choose this implementation because it would require building a dictionary proportional to an arbitrarily-large schema even for small renamings and there is no obvious benefit from this alternate implementation that I can see right now. I've written this here mainly to serve as a reference in case there is some reason to revise what we need from reverse_name_map.

For migrations as described in #810, a one-to-many renaming would include the original name in the list (e.g. renaming A-> [A, B, C]). However, from a programming perspective, so far I haven't seen anything that would make it harder to have a one-to-many renaming that doesn't include the original (e.g. renaming A-> [B, C]), so I've tested for both cases.

Non-obvious decisions that I haven't made yet and would like feedback on

How to safeguard against suppressing every field in the schema? Such a renaming might not even require a large number of renamings-- see the bullet point on cascading suppression.

Cascading suppression: if we suppress all the schema fields that a particular type has, should we also suppress that type? This may lead to a cascade of suppressions, for instance:

type A {
    Listb: [B]
}

type B {
    c: C
}

enum C {
    YES
    NO
    MAYBE
}

Suppressing C also means suppressing B because all of B's fields are suppressed, which in turn suppresses A. The same question applies for union types.

If we suppress schema fields belonging to a union type, what do we do beyond simply removing the suppressed fields? Suppose we have a schema where A, B, and C are defined:

union AOrBOrC = A | B | C

If we suppress A, we're left with:
union AOrBOrC = B | C

This has two drawbacks: the name may be misleading because it doesn't match the types, and may reveal information about the datatypes, which suppression is supposed to prevent. Is this union name issue because of the test input unions have names based on which types they could be, or is there something more fundamental we should be concerned about here? If the former, we may be able to just leave the union name as-is.
One final note: if we also suppressed B in this example, union AOrBOrC = C would be misleading but still valid GraphQL according to the GraphQL spec, even though there's only one type left!

One-to-many renamings get complicated when other types depend on the schema fields being renamed.

For instance, if we start with this enum as part of the schema:
enum Height {
  TALL
  SHORT
}

And rename Height -> [Height, NewHeight], this renamed schema would seem to work:
enum Height {
  TALL
  SHORT
}

enum NewHeight {
  TALL
  SHORT
}

But if we also have a type that uses Height, then it's unclear how to proceed:
type Droid {
  height: Height
}

Neither of the following two options are good because now the schema has name conflicts:
1.
type Droid {
  height: Height
}
type Droid {
  height: NewHeight
}

type Droid {
  height: Height
  height: NewHeight
}

A plausible third option exists, involving unions:
3.
type Droid {
  height: HeightOrNewHeight
}
union HeightOrNewHeight = Height | NewHeight

However, this also fails if Height was a union of types, rather than an enum, to begin with because "you can't create a union type out of ... other unions". I don't have a great solution to this at the moment.
The same problem happens with non-enum fields.

Interfaces also present a similar but different problem: if A implements B originally, and interface B gets renamed to [B, C], then we end up with A implements B & C. Although this is valid GraphQL, it may be misleading, especially if it's not obvious that B and C refer to the same interface.

Note: still no need to look at the code since I'll almost certainly split this into smaller PRs-- before diving into implementations or even writing out a bunch of tests that I'm not sure are correct, I wanted to iron out some uncertain and tricky parts conceptually in these two previous comments.

Issue 1:
I don't have an issue with cascading suppression.
Issue 2:
Some thoughts:

We auto-generate union names during schema generation using a certain template, but users can manually generate their own schema and don't need to follow the template that we use for union fieldnames. Since the original union field name doesn't need to follow a template, it is not clear if the new autogenerated name would be any better than the original one.
If we renamed the union, then we could be implicitly breaking existing queries and I am not sure that's something we want to do.
By changing the type of a field from GraphQLUnionType to GraphQLObjectType, we could also be implicitly breaking queries. So even though the one-union type situation is not great, I don't think that we should be automatically changing the field types.

So I think it's best to solely omit the object type from the union type and do nothing more.
Two ideas that I am thinking to improve on this would be to:

Add another function that allows one to change the type of fields to deal with the one-type union.
Returning a dictionary of suggested renamings.

I would prioritize getting a basic version of schema renaming working before focusing on improvements like these though. For now simply omitting the object type seems good enough to me.
Issue 3:
When we remap a type to multiple types, we want to avoid breaking any existing queries. I think we could do that by using the new type in all existing fields except unions. So we would have:
type Droid {
   height: NewHeight
}

For unions, we need to have both the old and new type as part of the union field. (The old type to avoid breaking any existing queries, and the new type to allow users to start referring to solely the new type in queries).

As you correctly point out, the operations happening here are complex and difficult to think about. Thank you for writing up all the edge cases you are considering, it was very useful.
I'd like to make an observation here that might simplify things. We have two use cases that we are trying to cover here:

migrations that change names
permanent schema renaming, where we simply don't like what the underlying schema calls things and want to assign them new names

The latter only requires 1-1 renaming, which are conceptually simple. The former is solvable by 1-many renaming, but that's not the only viable solution and doesn't have to be the full story here. So I'd propose a hybrid approach for supporting migrations: allow 1-many renaming of fields, and use an alternative approach for types of all kinds: scalars, enums, interfaces, objects, unions, etc.
That means I'm suggesting we reduce scope and only allow renaming types to 0 or 1 names, raising NotImplementedError() or another error otherwise. This is because 1-many renaming of types is both extremely difficult to do well and will result in a massively bloated, user-unfriendly schema. Instead, we can handle migration-style renames of such schema elements by simply building the reverse_name_map component for them manually, and accepting schema-incompatible queries during the migration period by rewriting them into schema-compatible ones.
Also, I'd recommend we play it safe and don't implicitly cascade type hiding, since on a large schema (ours stretch into hundreds of MB!) it's going to be impractical to hand-review the changes resulting from a given operation. Instead, my preference would be to make the user explicitly state all the changes they'd like to perform, and have the code complain by raising errors if we end up in an illegal state, such as:

type has no fields
union has no types
type is being hidden but fields of that type exist, etc.

Importantly, such complaints must be clear ("input X said to do Y which caused illegal state Z") and actionable ("here are the actions that would resolve the problem") for the user.

Thanks for the feedback! A few follow up questions:

simply building the reverse_name_map component for them manually, and accepting schema-incompatible queries during the migration period by rewriting them

If we do this for types, enums, etc. then instead of 1-many renamings for fields could we treat fields the same way we do everything else? Then we wouldn't have a mix of what happens to different parts of the schema. We could say that 1-1 and 1-0 is always done in rename_schema while 1-many is handled by being more permissive with queries than the schema suggests and renaming the query accordingly.

Does this mean that someone writing a query would see the schema after it was modified with 1-1 and 1-0 renamings and that we'd modify reverse_name_map somewhere in rename_query? Unsure where this extra processing should be happening.

such complaints must be clear ... and actionable

Makes sense-- what would be the actionable thing to do here though? Suppose we have this schema:

type A {
    Listb: [B]
}

type B {
    c: C
}

enum C {
    YES
    NO
    MAYBE
}

and C gets suppressed. This should raise an error, but what should the suggested action be?

If we suggest the user remove C from things to suppress, that kind of defeats the point of suppressing a field

If we suggest the user also suppress B, then they'd re-run the schema rename and get another error telling them to suppress A. That'd be annoying to deal with, especially if there's a long chain of suppression required

If we tell the user everything that would eventually need to get suppressed, we might end up showing them a massive, probably hard-to-reason-about error message (same problem with the long chain of suppression)

Great points! My thoughts inline:

If we do this for types, enums, etc. then instead of 1-many renamings for fields could we treat fields the same way we do everything else? Then we wouldn't have a mix of what happens to different parts of the schema. We could say that 1-1 and 1-0 is always done in rename_schema while 1-many is handled by being more permissive with queries than the schema suggests and renaming the query accordingly.

This is definitely a viable approach. I would argue it's slightly less desirable, though, because it doesn't help users be self-sufficient. Let me take a step back and explain what I mean.
GraphQL has a built-in directive called @deprecated which takes an optional string reason parameter, and may be applied to field definitions or enum values. This is something that common UIs natively support: for example, GraphiQL will automatically give you a squiggly yellow underline if you use a deprecated field (together with a pop-over showing you the listed deprecation reason), and will avoid suggesting deprecated fields as a typeahead suggestion for as long as alternative valid suggestions exist. This is a very pleasant workflow: queries with deprecated fields remain valid in the UI, and the user is given specific and actionable advice like "field X is deprecated, please use the new field Y instead". Building on this, one could also imagine a world where we have a tool that is aware of "X field was replaced by the equivalent Y field" deprecations, and offers to rewrite your queries to avoid deprecations — using a nice sanity-check invariant that both the input and output queries must validate against the schema, but the output query has only a subset of the deprecation warnings of the input.
Deprecating a type in GraphQL, however, is semantically strange. A type definition by itself doesn't do anything except for "special" types like the root query or mutation type: if no fields of that type are reachable, you can't do anything with it anyway — hence the special-casing of the root query/mutation types, since those are reachable by default. Correspondingly, @deprecated isn't allowed to be present on object type/interface/union/enum definitions.
Let's refer to having both old and new copies in the schema as a "soft" migration (both queries valid, one deprecated), and let's call only having the new copy in the schema + a fall-back path that accepts queries under the old schema a "hard" migration.
Because of the @deprecated directive and associated tooling's support for it, supporting soft migrations for field definitions and enum values has a much higher payoff value than supporting soft migrations for types of all kinds. Coincidentally, soft migrations are also much easier to pull off for field definitions and enum values than they are for types, as we discussed previously.
On the basis of that, my recommendation was to support soft migrations for field definitions and enum values (because it's very good and not that hard), and only support hard migrations for object types/interfaces/unions/enums (because soft migrations are less good here anyway, and much harder to pull off).

Does this mean that someone writing a query would see the schema after it was modified with 1-1 and 1-0 renamings and that we'd modify reverse_name_map somewhere in rename_query? Unsure where this extra processing should be happening.

After applying all the renaming, the generated schema would be used to write queries against, yes. It may be used through a tool like GraphiQL directly, or simply used by the compiler to compile a user's query against that schema.
I wouldn't necessarily worry about rename_query and the hard migration's fallback path for type renaming. For that, we may want to add an extra preprocessing step (i.e. a separate function) that the user has to explicitly opt into (i.e. call), since we are technically accepting illegal queries and attempting on a best-effort basis to make them legal. That makes it tricky, because it's more difficult to differentiate between the buggy "illegal query should have become legal, but didn't" case and the works-as-intended "illegal query was illegal in a non-fixable way, so it remained illegal as expected" case.

such complaints must be clear ... and actionable

Makes sense-- what would be the actionable thing to do here though? Suppose we have this schema:

type A {
    Listb: [B]
}

type B {
    c: C
}

enum C {
    YES
    NO
    MAYBE
}

and C gets suppressed. This should raise an error, but what should the suggested action be?

If we suggest the user remove C from things to suppress, that kind of defeats the point of suppressing a field
If we suggest the user also suppress B, then they'd re-run the schema rename and get another error telling them to suppress A. That'd be annoying to deal with, especially if there's a long chain of suppression required
If we tell the user everything that would eventually need to get suppressed, we might end up showing them a massive, probably hard-to-reason-about error message (same problem with the long chain of suppression)

I'd pick the middle option. As you point out, the first one is counter to the user's expressed intent, and giving that message as feedback is akin to a "don't do that", which is unhelpful. The middle option is a nice balance of "reasonable to implement" and "works most of the time", because most real-world schemas wouldn't have these cascading situations, and if they do, they are unlikely to have many of them. Saving the user from needing to iterate 2-3 times, on a relative basis given our development bandwidth, is not worth the comparatively large amount of effort it would take to implement a system that would find and appropriately communicate the correct sequence of steps to take and the reasons for them to the user.

Sounds good to me-- I'll aim to get the type hard migration/ suppression part for rename_schema done first and put that out in a separate PR whose code can be reviewed.
Just a few lingering issues:

Since fields only exist in their local scope (so a type foo and a type bar can both have a field name), I think it'd make more sense to create a separate parameter for field/ enum value renamings that maps a schema type T (string) to a dictionary that maps T's fields (string) a list of strings. For instance:

{
  "Human": {"name": [], "id": ["id", "id1"]}
}

suppresses name and 1-many renames id. Conveniently, the existing renaming code doesn't do anything to fields and enum values, which is exactly what this extra parameter lets us do.

If we have a type foo with fields A and B, is it legal to suppress A and one-to-many rename B to A and B? On one hand, both the expected beginning and end states are technically legal-- but if you try to rename B before suppressing A, the intermediate state would not be legal.

Good points. Open to adopting the API you suggest, mapping types to dicts of fields with their own remappings — I'd just suggest that we treat that info as overriding the default of "change nothing", so that we don't have to have lots of entries that simply communicate "don't change this field".
To avoid describing the illegal intermediate state in the spec, perhaps we could specify the order of operations more fully — maybe something like "field suppressions happen before field renames, either 1-1 or 1-many". So long as the implementation's start-to-finish behavior is indistinguishable from the spec, whether the implementation actually follows that order shouldn't matter.

Most of the work here has gotten merged, closing for the same reason as 834 to clean up


ERR_MODULE_NOT_FOUND due to relative import paths missing file extension

mdast-util-definition-list^1.1.0 exports an index.js which internally imports ES-Modules using relative paths but without the mandatory .js file extension.
This bug causes node to stop module loading with an error:
Error: Cannot import `../node_modules/remark-definition-list/lib/index.js`
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/redacted/node_modules/mdast-util-definition-list/lib/from-markdown' imported from /redacted/node_modules/mdast-util-definition-list/index.js
    at new NodeError (node:internal/errors:363:5)
    at finalizeResolution (node:internal/modules/esm/resolve:307:11)
    at moduleResolve (node:internal/modules/esm/resolve:742:10)
    at Loader.defaultResolve [as _resolve] (node:internal/modules/esm/resolve:853:11)
    at Loader.resolve (node:internal/modules/esm/loader:89:40)
    at Loader.getModuleJob (node:internal/modules/esm/loader:242:28)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:73:40)
    at link (node:internal/modules/esm/module_job:72:36)

Environment
I am using

remark-definition-list^1.1.0
mdast-util-definition-list^1.1.0

with

node 16.0.0
unified-engine^9.0.3

My own project has a package.json which declares
package.json
{
   "type": "module"
}

@about-code Thanks for reporting.
I've released fixed versions of mdast-util-definition-list and micromark-definition-list which remark-definition-list depends on.
Please try and let me know if there's any problem.

No errors anymore. Thank you very much for the fix and your work on these lib(s).


Watermark feature

hey, Franiac! Are you considering adding a watermark feature?

Adding stuff to a video means re-encoding it. TL does not and should not re-encode. Depending on the PC and video/codec settings re-encoding a 3 hour video can easily last +10 hours.
Clear answer: No, sorry 😄


WIP: Beautify The ReadMe.

Hi! I was going through the readme and It is too hard to read.
Here are a few of them problems.

Inconsistent spaces and line breaks.
Inconsistent screenshot sizes.
Inconsistent Alignment.
Inconsistent Visual Hierarchy.

ok @ruhend

@ruhend ?

@arpit456jain will do it in a few days...


Add support for ebess/advanced-nova-media-library

Add support for ebess/advanced-nova-media-library please.
Thank you

Yes, you have to take a look. Spatie saves it to the ID of a line... Of course it will be a bit more "tricky" to think of something useful...


readme.md code

Was curious where the code listed in readme.md goes. I tried pasting it into /etc/nixos/configuration.nix but that just seems to cause nixos-rebuild switch to throw errors. :(

You should enable flake and add readme code to flake.nix.
This one is one of the good start point to try flake.

You can see how i made it in my nixos config here.

I'll go ahead and close this, but do please re-open if you found anything else unclear!


Make the default ReadAdvice configurable by sysprop

Followup after #13244: This makes the default ReadAdvice for index files configurable via system property org.apache.lucene.store.defaultReadAdvice.
I moved the corresponding constant to the oal.util.Constants class because this makes reading and error reporting easier as @rmuir and I added some framework to safely support security manager and map those variables (we used this for vectorization).
It would be good to move all reading of system properties to that class so we do not have the splattered AccessControllers everywhere.

P.S.: I moved the lookup cache to a new constant name and placed it next to the withReadAdvice() method.

This makes sense to me. At first I wondered if we needed this since it's possible to create a FilterDirectory that calls ioContext.withReadAdvice(ReadAdvice.NORMAL) on Directory#openIndexInput or something along these lines. But actually this wouldn't work as well, as this would override explicit decisions made from the code, which is probably not what we want.

That was exactly my problem with making the default hardcoded.
I thought about making it configurable "per directory", but this is too much changes for little benefit. As this is mostly machine specific, a system property that can be passed at command line was my favourite.
In addition, we should still pass iocontext.withReadAdvice(ReadAdvice.RANDOM) in our index files, where we know for sure that the access will be fully random (like HNSW), so the other PR you implemented was still fine.
So the default specified by system property is only used for cases where no explicit read advice is given at all .


Replace SwirldsLabs with Hashgraph

🆕🐥 First Timers Only
This issue is reserved for people who have never contributed to this project or any open source software (OSS) in general.
We know that creating a pull request (PR) is a major barrier for new contributors.
The goal of this issue and all other issues labeled by 'good first issue' is to help you make your first contribution.
👾 Description of the issue
The company SwirldsLabs has been renamed to Hashgraph (https://www.hashgraph.com) and should be replaced in the customers and partners section at https://open-elements.com/about/
The text can be the same since the company has only been renamed.
The content can be found at https://github.com/OpenElements/open-elements-website/blob/main/data/en/partners.json and https://github.com/OpenElements/open-elements-website/blob/main/data/de/partners.json
New URL for Hashgraph: https://www.hashgraph.com
The new logo of Hashgraph:

📋 Step by step guide to do a contribution
If you have never contributed to an open source project at GitHub, the following step-by-step guide will introduce you to the workflow.
A more detailed general documentation of the GitHub PR workflow can be found here.

[ ] Claim this issue: Comment below that you are interested in working on the issue
[ ] Wait for assignment: A community member with the given rights will add you as an assignee of the issue
[ ] Fork the repository: You can do that in GitHub (by simply clicking the 'fork' button)
[ ] Check out the forked repository on your local machine
[ ] Create a feature branch for the issue
[ ] Solve the issue in your branch
[ ] Commit your changes: to your branch
[ ] Start a Pull Request (PR): in our repository
[ ] Check GitHub Actions: Several GitHub Actions will be triggered automatically for each PR. If a GitHub Action fails and you do not understand the cause of that error, do not hesitate to add a comment to the PR and ask the community for support.
[ ] Wait for reviews: Members of the community will review your PR. If a reviewer finds any missing pieces or a problem, he or she will discuss it with you and describe the next steps for solving it.
[ ] You did it 🎉: We will merge the fix in the develop branch. Thanks for being part of our community as an open-source contributor ❤

🎉 Contribute to Hacktoberfest
Solve this issue as part of the Hacktoberfest event and get a chance to receive cool goodies like a T-Shirt. 🎽

Hi @hendrikebbers
I am interested in this task. can you please assign me ?

Hi @hendrikebbers
I am done with changes in local. Shall i raise a PR ?


Champ addition

This branch adds the CHAMP accelerometer instrument, STAR, to pysat.  Also adds the ability to specify the file format for any file.
Includes a few pep8 and documentation improvements.

Clearly forgot to grab your updates beforehand.  Let's see how painful this will be...


[MediaPlayerElement] Corner Radius not working as expected

Describe the bug
Unable to clip a media player element to have a corner radius. It sometimes works on my secondary monitor, but not my primary, some aspect ratios sometimes work, others not, larger corner radiuses sometimes work, but not after a restart. Bit of an inconsistent mess.
I found that sometimes making the width / height smaller it will work, sometimes....
Steps to reproduce the bug

Wrap a MediaPlayerElement within a grid with a corner radius, try different radii, widths / heights, aspect ratios.
Observe inconsistent corner radius behaviour.

Expected behavior
No response
Screenshots

NuGet package version
None
Windows version
Windows 11 (22H2): Build 22621
Additional context
WinUI: 1.2.230217.4
https://github.com/DominicMaas/Repro_MediaPlayerElementClipping
<Grid
        HorizontalAlignment="Stretch"
        VerticalAlignment="Stretch"
        Background="Green">
        <StackPanel Spacing="20" HorizontalAlignment="Center" VerticalAlignment="Top">
            <Border
                Width="200"
                Height="200"
                Background="Red"
                CornerRadius="18">
                <MediaPlayerElement
                    AutoPlay="True"
                    CornerRadius="18"
                    Source="ms-appx:///Assets/Video.mp4"
                    Stretch="UniformToFill" />
            </Border>

            <Border
                Width="400"
                Height="200"
                Background="Red"
                CornerRadius="18">
                <MediaPlayerElement
                    AutoPlay="True"
                    CornerRadius="18"
                    Source="ms-appx:///Assets/Video.mp4"
                    Stretch="UniformToFill" />
            </Border>

            <Grid
                Width="100"
                Height="200"
                Background="Red"
                CornerRadius="18">
                <MediaPlayerElement
                    AutoPlay="True"
                    CornerRadius="18"
                    Source="ms-appx:///Assets/Video.mp4"
                    Stretch="UniformToFill" />
            </Grid>
        </StackPanel>
    </Grid>

I read the issue you mentioned. In your code, MediaPlayerElement is wrapped by layout controls to set CornerRadius. But we expect the MediaPlayerElement's CornerRadius property works. In addtion, Opacity property too.

@DominicMaas there have been some fixes in WASDK 1.4 . Can you please try the 1.4 preview 1 and reactivate if you still hit this issue ? Thanks!


Resolve values (part 1)

I may not have tested all corner cases

Goes together with https://github.com/ibissource/iaf/pull/4300, but please merge this PR before the iaf PR.

It turns out that no private fields have to be seen by the doclet. Closed the F!F issue that brought them in: https://github.com/ibissource/iaf/pull/4300.


Constant error messages/notifications about rekeying a private folder. Unable to do it.

I just re-installed keybase on all new devices after like 2 years of not using it (good thing I had my paper key stashed) and have a warning/notification about my private folder private/nico_r needing to be rekeyed. I can access the contents of that folder and actually deleted everything but still keep getting the error messages on the apps for Windows, Linux and Android.
C:\Users\Nico>keybase rekey status
TLFs need rekeying:
private/nico_r

Devices that can rekey:
desktop Desktop - Win10
backup  diet marble

C:\Users\Nico>

Doing keybase rekey paper asks me for my paper key but then does nothing. Opening the Linux client shows up a popup message saying I need to enable either of those two devices listed above but there's nothing to click/accept. If I select to enter a paper key and put my current one it says "Success, rekeying" but nothing happens.
Here are the logs:
------------
Success! Your log ID is:

  5e6337023f5a3fa7e689d11c

Here's a URL to submit new bug reports containing this ID:

  https://github.com/keybase/client/issues/new?body=[write%20something%20useful%20and%20descriptive%20here]%0A%0Amy%20log%20id:%205e6337023f5a3fa7e689d11c

Thanks!
------------

Any idea what the issue might be?. Thanks!.

Nevermind... seemed after some more trial and error (and registering one extra device) this seems to be fixed now!.


Network slowness on aliyun when pulling container images

The pod is pulling container image abnormally because there are other pods pulling it at the same time, which may block the current process. The pods's container images are [ghcr.io/risingwavelabs/risingwave:v1.3.0 ghcr.io/risingwavelabs/risingwave:v1.3.0 ghcr.io/risingwavelabs/risingwave:v1.3.0].

Pod my-risingwave-compactor-58d5c94d5b-jn99t 存在异常：拉取镜像超时

Just replaced the default registry with docker.io. Please try it with the 0.1.28 version.


Migrating test/code-coverage from TravisCI to github actions

Shouldn't we compile assets before running tests?

Ugh... you're right.  Travis had that step in there and I removed it because I couldn't think of a reason to keep it.  I'll add that back in tomorrow

I would need to check when the other types occur because just reading the name I would say we only need opened,  edited and maybe synchronize.
      - synchronize
      - opened
      - edited
      - ready_for_review
      - reopened
      - unlocked

Open/edit are obvious.
Assuming synchronize is triggered by "update branch", yes we want that.
Reopened definitely (PRs don't update while closed, unless that also triggers synchronize as well).
I'll tentatively agree that ready_for_review and unlocked are likely not required


PYI052 should ignore assignments in subclass of enum without enum members

PYI052 correctly accepts the following code:
from enum import Enum

class Baz(Enum):
    FOO = 0
    BAR = 1

However, it flags the assignments to FOO and BAR in this code:
from enum import Enum

class Foo(Enum):
    ...

class Bar(Foo):
    FOO = 0
    BAR = 1

Inheriting from enums without enum members works at runtime and is understood by typecheckers, so I think these two examples should be treated the same. https://mypy-play.net/?mypy=latest&python=3.11&gist=cdb6a82662cbb77416bb64692606cb83
Reproduced with v0.1.6 running ruff foo.pyi --select PYI052 without any settings in pyproject.toml.

Thanks for the prompt fix as always, you're awesome!


[5.2] Amend keyBy() method w/ callback for duplicates

I raised the issue in detail here: https://github.com/laravel/internals/issues/152
I suggest this change so that the user has an opportunity to resolve the duplicate key with a callback.

I'm going to hold off on this for now mainly because I think it would just be sort of ... odd to pass two Closures into a single method. You are free to use Collection::macro to define this method yourself.

Ah yes, didn't think of that. Good point, that is pretty awkward. Thanks for taking a look and I'll check out the Collection macro you mentioned.

@taylorotwell you could probably close laravel/internals#152 if this isn't getting added.


Fix animations for 0.8 models

The animations were not being converted from axis-angle to quaternion.
Afterwards I will update this in the 2.0 and 2.0-cesium branch, and then update Cesium.
@likangning93 can you review?

Coverage increased (+0.05%) to 92.875% when pulling ff6e0a605f9db6c9c796f42dd4b23b975cf0d101 on animation-fix into 3c7be90bbe85f7daa1cbf043d08d366e97fd37fa on master.


Fido is !Sync due to static debug flag? Changed in master

Remove Fido since the init fn does nothing. Add thread local debug enable fn.

^ make sure of this


Tweak documentation in helphelp.txt

NOTE:
L455-L456:

Tweak the incorrect line break position.
Fixed "change" appearing twice.

L457:

The "#{" notation is for legacy script use only, so it has been changed.
(Just change "let" to "var" to make it usable in Vim9 script)

L460-L462:

Tweak the incorrect line break position.
Fix to "two-space" convention.

L464:

Capitalize first character.

L484-L486, L492:

Fix to "two-space" convention.

The g:help_example_languages documentation entry can be
improved upon by moving around its sentences.  First, say
about >vim, because it is available by default.  Then, say
about >bash etc. and g:help_example_languages.
For example:
diff --git a/runtime/doc/helphelp.txt b/runtime/doc/helphelp.txt
index 5ab112d60..3bfff42e5 100644
--- a/runtime/doc/helphelp.txt
+++ b/runtime/doc/helphelp.txt
@@ -438,30 +438,24 @@ also implicitly stops the block of ex-commands before it.  E.g. >
 	endfunction
 <

-To add annotation in the block, place the annotation (ex: "lua") after a
-greater than (>) character.  E.g: >lua
-	print("hello")
-<
-Note: uses lua syntax highlighting, if "lua" key is in
-|g:help_example_languages|.
-
-It's possible to add Vim syntax highlighting support to code examples.
-E.g: >vim
+To enable syntax highlighting for a block of code, place a language name
+annotation (e.g. "vim") after a greater than (>) character.  E.g. >vim
 	function Example_Func()
 	  echo "Example"
 	endfunction
 <
 						*g:help_example_languages*
-If you want to change the syntax highlighting in the block, you can
-change it like this: >
+By default, help files only support Vim script highlighting.  If you need
+syntax highlighting for other languages, add to your |vimrc|: >
 	:let g:help_example_languages = #{ vim: 'vim', sh: 'bash' }
 The key represents the annotation marker name, and the value is the 'syntax'
-name.  By default, help files support only Vim script highlighting.
-Note: When setting "g:help_example_languages", if you do not include "vim"
-key, the Vim syntax highlighting will not be enabled. If you set it to an
+name.
+
+Note: If you do not include "vim" in "g:help_example_languages", its syntax
+highlighting will not be enabled.  If you set "g:help_example_languages" to an
 empty value, syntax highlighting for embedded languages will be disabled.

-Further note: including additional syntax languages into help files may not
+Further note: Including additional syntax languages into help files may not
 always work perfectly, if the included 'syntax' script does not account for
 such an import.
 						*help-notation*

Why g:help_example_languages is not a list of language
names?

@chrisbra
I'll not make any changes to this PR of my own volition. I'll respond to requests.
Please feel free to make any corrections you like.

thanks, Including the suggestion from @zzzyxwvut
Regarding this:

Why g:help_example_languages is not a list of language names?

I suppose the idea is to have different annotations and lanuage names. Perhaps it would make sense to simplify it and just allow a list of language?

I suppose the idea is to have different annotations and lanuage names. Perhaps it would make sense to simplify it and just allow a list of language?

I don't think it would be useful to apply the syntax of "bash" or "zsh" to ">sh" later as a variable, since the syntax is different.
I think a simple list of syntax names (language names) would be fine.


Refactor inline bold styles to use CSS

Closes #1104
Refactored portions of code that were using the HTML bold tag to instead use the 'font-weight' CSS property per improving site accessibility.
Testing
Relevant URLs:

http://localhost:3000/join-index/how-to-add

It is passing the Site Improve but it is showing error in HowToAdd/index.js file as below ' can be escaped with ', ‘, ', ’. on line 59
it shows this documentation for reference attaching the link https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/no-unescaped-entities.md

Thanks Bhaggya, I'm going to check this out!


Fix link in docs

Coverage remained the same at 100.0% when pulling 5d41045dcb3db2fcc29fc05d95e15661c48a2a47 on bobbyrullo:patch-1 into 614ca3ed39f8db90996ab616812420310d34c918 on zalando:master.

:+1:


App Additions & Improvements

As a hobbyist subtitler myself, here's a list of things I'd like to see improved and added to the app.
Additions

[ ] A proper waveform feature (like SE has)
[ ] More user friendly features to aid in syncing (since most people who do subtitling as a hobby might not know how to sync)
[ ] Option to show subtitles as the video/audio is transcribing (such as in Tero Subtitler)

Improvements

[ ] A new icon pack for light theme mode (as of now the icons are greyed out)
[ ] A prettier and tabbed settings screen
[ ] An option for tabbed windows (each file can be opened in its own tab)

What features are you missing in the waveform?
What user friendly sync features are you talking about?

Option to show subtitles as the video/audio is transcribing
In Whisper audio to text?

Yes, light theme is on the TODO list.
Tabbed settings is probably not happening, as I try to go for the more modern Windows style (like windows settings).


Ensure "native" keyword (reserved) is not used for YUI

This PR attempt to solve this issue https://github.com/chartjs/Chart.js/issues/4711 because of this bug https://github.com/yui/yuicompressor/issues/288

Well, CodeClimate and Travis (which is using eslint like CodeClimate) is not happy because I'm not using the dot notation... especially to dodge this issue. Is there any annotation to tell eslint to avoid warning at this particular place?

According to this https://eslint.org/docs/rules/dot-notation I can use this syntax:
// eslint-disable-dot-notation

We might want to tweak the eslintrc file:

https://eslint.org/docs/rules/dot-notation
https://eslint.org/docs/rules/quote-props

@simonbrunel I agree. There's a high probability that a future change will reopen this issue.  I like the RegEx suggestion since it keeps the fix container.
I agree with native -> nativeEvent as a good long term change. Not sure if it is worth the effort to do though.

@sandvige yuicompressor is essentially abandoned having received very little work the past couple of years. Uglifyjs is a much more widely used alternative, so I'd suggest you try it instead
I agree with @simonbrunel and @etimberg that we should not try to work around bugs in yuicompressor especially since it's abandoned and there are better alternatives. I'd suggest closing this PR

Thanks for your feedback, we will probably go with Uglifyjs :)


OMS-32 Updated Getting Started Page

Description
Changing Content of Getting Started Page in CloudMyDc Docs.
Gettting Started Page content provided by @Tanishka Mogha
https://omsmsp.slack.com/archives/D07MRF2LMSS/p1726659395258229

@VKumar786 This requires a Jira ticket not a slack private message


Toggle port forwarding automatic open firewall rule

This PR adds a new configuration attribute called pf_open_firewall, which is set to true by default for backwards compatibility.
When set to false, the API call that creates the port forwarding rule does not automatically create a rule to open the firewall.
Fixes #69

Coverage increased (+0.24%) to 84.34% when pulling 111e1f948168a55477b992aa70288a2834eb3a5b on miguelaferreira:toggle-pf-open-firewall into fe77491e13051ae8955bf70812b3ea2f3dacb877 on schubergphilis:master.

LGTM


missing documentation

Hi,
in section "5.5.3. Changing how Generic Types are Named" of your documentation http://springfox.github.io/springfox/docs/current/#docket-spring-java-configuration I think you missed a piece of example code.

Thanks for pointing that out! Its not missing anything, just that the documentation isn't cleaned up!


Expanded hyperlinks

Would it be possible (based on the GND links of person entries) to automatically incorporate links to ACDH-CH projects such as ÖML and ÖBL? It works with Wikidata links, so I assume this would also be possible with these projects?

ÖML: https://www.wikidata.org/wiki/Property:P8432
ÖBL: https://www.wikidata.org/wiki/Property:P6194

oebl and oeml URIs are now part of the person detail pages e.g. https://hanslick-online.github.io/hsl-app-dev/hsl_person_id_2416.html
No all persons have these Identifies. YOu can find them in Baserow.


Removed the UNIX command and added the shelljs equivalent

@ealmansi This should Fix #6
Thanks to @ismaelbej for pointing out the error causing code.
Also, this should improve Windows Compatibility.

This PR is no longer relevant for verison 0.2.

This PR is no longer relevant for verison 0.2. Thanks regardless @AliabbasMerchant!


Image height and retina images

Sorry if this is a silly question, but how do I actually change the height of the images in the slider?
Changing the height of the img element in the HTML page doesn't seem to do anything, and changing it through CSS doesn't work either.
On a related note, how do I use the plugin as an image slider in conjunction with non-retina and retina versions of the images? Any best-practice advice?

Please ask general web-dev questions on StackOverflow, @brakai295 :) ...this is a bug-tracking forum. Good luck, feel free to share the link to your question here.


[framework] Animation.map

Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.
List which issues are fixed by this PR. You must list at least one issue.
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Pre-launch Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I read the Tree Hygiene wiki page, which explains my responsibilities.
[ ] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[ ] I signed the CLA.
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is test-exempt.
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Drive solves this problem. Perhaps I should re-tool this PR into an additional of how to use Animation.drive?

Drive solves this problem. Perhaps I should re-tool this PR into an additional of how to use Animation.drive?

That would be much appreciated!


I'm unable to run Loras?

I've downloaded loras, even slapped them into models/Loras (by way of importing from notebook importer, then creating a "Lora" folder, then moving the imported loras into said folder. However, it seems they're only listed on the area where I'm supposed to select my MODEL? And NOT in the lora selection box? I'm... absolutely confused here.

I'm also of the opinion this may not be running the VAEs that are baked into some models, though this may require some testing.

Yeah, the model linker isn't set up to correctly link loras yet.

lol yeah, I quickly learned that looking at the file explorer on the side. Finding it easier to use wget/gdown within the folders and avoid the symlinks altogether. 😅
I'm still a bit curious why I'm getting washed out images with this, though, despite using models with baked VAEs. I'm putting in the same ENSDs, clip skips, but the outputs are oh so vaguely different, and the baked VAEs don't seem to be applying for some reason. But that might require a new thread.

Are Loras still unavailable or am I just doing it wrong?

Did you update your notebook?


UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 11295: ordinal not in range(128)

Since setuptools 25.0.0 setuptools can't be installed with python 2.6
setuptools 24.2.0 seems to be the last version that still work with python 2.6,
python 2.7 also works with later versions
Python version:
Python 2.6 (r26:66721, Oct  2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on win32
[16:21:31,43] c:\temp> python ez_setup.py --version 25.0.0
Downloading https://pypi.io/packages/source/s/setuptools/setuptools-25.0.0.zip
Extracting in c:\temp\tmp8iiskc
Now working in c:\temp\tmp8iiskc\setuptools-25.0.0
Installing Setuptools
running install
running bdist_egg
running egg_info
writing requirements to setuptools.egg-info\requires.txt
writing setuptools.egg-info\PKG-INFO
Traceback (most recent call last):
  File "setup.py", line 174, in <module>
    dist = setuptools.setup(**setup_params)
  File "c:\sdk\win32\1.1\Python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "c:\sdk\win32\1.1\Python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "c:\sdk\win32\1.1\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "c:\temp\tmp8iiskc\setuptools-25.0.0\setuptools\command\install.py", line 67, in run
    self.do_egg_install()
  File "c:\temp\tmp8iiskc\setuptools-25.0.0\setuptools\command\install.py", line 109, in do_egg_install
    self.run_command('bdist_egg')
  File "c:\sdk\win32\1.1\Python26\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "c:\sdk\win32\1.1\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "c:\temp\tmp8iiskc\setuptools-25.0.0\setuptools\command\bdist_egg.py", line 152, in run
    self.run_command("egg_info")
  File "c:\sdk\win32\1.1\Python26\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "c:\sdk\win32\1.1\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "c:\temp\tmp8iiskc\setuptools-25.0.0\setuptools\command\egg_info.py", line 188, in run
    writer(self, ep.name, os.path.join(self.egg_info, ep.name))
  File "c:\temp\tmp8iiskc\setuptools-25.0.0\setuptools\command\egg_info.py", line 403, in write_pkg_info
    metadata.write_pkg_info(cmd.egg_info)
  File "c:\sdk\win32\1.1\Python26\lib\distutils\dist.py", line 1077, in write_pkg_info
    self.write_pkg_file(pkg_info)
  File "c:\temp\tmp8iiskc\setuptools-25.0.0\setuptools\dist.py", line 71, in write_pkg_file
    file.write('Description: %s\n' % long_desc)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 11295: ordinal not in range(128)
Something went wrong during the installation.
See the error message above.

Can you find precisely in which version it fails? There are a few releases between 24.2.0 and 25.0.0.

Nevermind - you did say 24.2.0 was the last one that works, so the first failing one must be 24.2.1. Here's what changed between those two, and it does seem that the code added in d079163e is implicated in the traceback. @xavfernandez Can you help devise a solution?

Hmm, I took the write_pkg_file from python3 but apparently the python2 version was based on self._write_field which took care of encoding.

@stuertz Does #824 fix your issue ? I tried to make the code equivalent to the distutils code.

Yes. That fixes the issue. Looks good.

Somehow I cannot create a failing test for 2.6 that exhibits this issue :-/
Feedback welcome on #824

With python 2.6.9, python ez_setup.py --version 25.0.0 works fine on my machine (linux), so there must be something else...

Sorry for not updating over the weekend. I can reproduce this up to python 2.6.4 on windows. Since 2.6.5 the issue does not occur. :-( Sorry for having such an old python version.

Given that it works with later versions of Python 2.6, I'll assume it was an upstream bug and avoid complicating the code. My recommendation for users encountering this issue is to upgrade to Python 2.6.5 or downgrade Setuptools.
I might consider additional protections to warn about these broken versions of Python, but I'm guessing the value is not worth the effort. Thanks to xavfernandez for working out a solution here - and thanks to stuertz for following up with extended testing.


WIP: ability to start a process

Initial support to orchestrate processes instead of solo5 unikernels. It's enough to start a binary - there is no support for block/network yet.

Disclaimer: It's of course not a good idea to use this in production, but still, it's very useful to test things locally.

It's of course not a good idea to use this in production

This also means to me that it is no good idea to have this in any albatross release, or maintain that code in the git repository. Or is there something I'm missing?

How do you debug new features in albatross? Right now it's difficult to do so if you are on macOS as you cannot run solo5 :-(

Ok let me rephrase this - my goal is to use albatross on my dev machine while I am developing apps on macOS. Right now I can't do this as albatross requires solo5. I am happy to do something different (like abstracting the execution engine and the memory quotas) and build another binary for this, but that might complexify the code a bit. What do you recommend there?

Dear Thomas,
thanks for your remark what you'd like to achieve - develop and use albatross on macOS.
With the approach proposed here, my main issue is that it undermines the security story of albatross-daemon. If this PR is merged and deployed (although there is a disclaimer in this PR - not checked by any code), any client can execute arbitrary code as superuser (since this PR allows to upload any executable that is executed with albatross-daemon privileges). Certainly, more code could be added to configure the behaviour of albatross depending on some flag etc. - but this will only increase the complexity, and the likelihood that in the future there will be issues.
The path forward, depending on your mileage and goals can be:

Develop a solo5 backend for macOS hypervisor.framework, and then use solo5-hvt with albatross.
(Please excuse my not-too-deep knowledge since I do not have access to a macOS computer) Use "Docker for Mac" to run and develop albatross in a Linux container on your laptop (using solo5-spt this should work).
Run albatross on a remote machine, and connect via the TLS endpoint (this certainly depends on where you want to extend what -- is it in albatross itself, or in projects on top of albatross?).
On a macOS machine, pretend that solo5 exists: provide a solo5-hvt shell script (which consumes the command line arguments, but executes a unix process). Your albatross-client could upload macOS executables, and the shell-script executes them. As far as I can tell, you will only need a custom solo5-elftool (the OCaml library) which always returns Ok (and doesn't perform any checks) - which you can pin on your machine. This would only need marginal changes to albatross (to know which commands to execute for a macOS host), which should be fine to be merged.
"Abstract the execution engine" may be worth a look as well, it may be useful for testing to be able to mock that. I've planned to do this for the ability to test all of albatross, but so far have been too worried about the increase of the complexity of the code (by i.e. using functors) -- I'd at the moment instead prefer to mock the environment by providing shell scripts for solo5-hvt, ip, taskset and mess around with PATH for such tests.
Keep and maintain your changes in a fork.

Does any path resonate with you? If not, would you mind to describe a bit more in detail what you'd like to achieve (i.e. develop albatross or projects on top of it, use albatross for executing actual unikernels on a macOS, ...)?

Thanks Hannes!
Running random executables on the production host is certainly not a good idea. Hence my disclaimer :-) I'm happy to ditch my patch; it was a quick exploration to understand the albatross code better.
Indeed 2. and 3. are already possible but not great in terms of UX. 1. would be an ideal solution in the long-term, @MagnusS had investigated this a bit, so might be possible in the near future (but not today). I'm happy to work on 4. in the short term. I'm also happy to help explore the design space of 5. to see if the complexity is worthwhile if you think that's helpful.

I think 4 is pretty straightforward and the path to go.

Closing as I don't have time to work on this right now.


Implement Clear Function and Slight Refactor

added a clear function per git issue #1
instead of requiring inheriting contracts to create a publicly accessible function for setters, included a blockListOwner variable.
removed require statements and made custom errors

need to be able to transfer blocklist ownership


FastList is not thread-safe

Hi @brettwooldridge,
This issue is to notify you about a concurrency bug. When multiple threads create and close PreparedStatements, ProxyStatement.close() calls ProxyConnection.untrackStatement(Statement) multiple times with different statements. ProxyConnection then attempts to remove these from openStatements. The problem is that FastList is not thread-safe, so these concurrent removes end up throwing an ArrayIndexOutOfBoundsException. I've created ConcurrentCloseConnectionTest to demonstrate this problem (see #590).
As we said in #451, we're getting closer to our 7.0 release. We have a workaround so our CI tests pass, but we'd like to have a real solution in place with enough time to allow for rigorous testing. Please let me know if you have any questions or need more input.
Thanks!
Matt
cc @shuyangzhou

IMHO, the test case given in 590 is not valid. JDBC api is thread safe as long as you are NOT SHARING connection / statement with multiple threads.
You should refactor as::
 ExecutorService executorService = Executors.newFixedThreadPool(10);
List futures = new ArrayList<>();
try (HikariDataSource ds = new HikariDataSource(config) {
futures.add(executorService.submit(new Callable() {
public Void call() throws Exception {
try (Connection connection = ds.getConnection()) {
try (PreparedStatement preparedStatement = connection.prepareStatement("")) {
preparedStatement.execute(...)
}
}
return null;
}
}
}
`
or use add/ExecuteBatch() appropriately for performance.

IMHO, the test case given in 590 is not valid. JDBC api is thread safe as long as you are NOT SHARING connection / statement with multiple threads.
You should refactor as::
ExecutorService` executorService = Executors.newFixedThreadPool(10);
List<Future> futures = new ArrayList<>();
try (HikariDataSource ds = new HikariDataSource(config) {
   futures.add(executorService.submit(new Callable<Void>() {
      public Void call() throws Exception {
         try (Connection connection = ds.getConnection()) {
            try (PreparedStatement preparedStatement = connection.prepareStatement("")) {
               preparedStatement.execute(...)
            }
         }
         return null;
      }
   }
}

or use add/ExecuteBatch() appropriately for performance.

@nitincchauhan the test in #590 is not sharing connection or statement across threads.
The connection is only used in main test thread. And we use it to create many different PreparedStatements. Then in the thread pool, each thread is using a different PreparedStatement. There is no connection or PreparedStatement shared among threads.
The real problem is the statement tracking from the com.zaxxer.hikari.pool.ProxyConnection, it links all com.zaxxer.hikari.pool.ProxyPreparedStatements back to the origin com.zaxxer.hikari.pool.ProxyConnection inexplicitly. Therefore causing different ProxyPreparedStatements can not be threadsafely used across threads.
The jdbs spec states clearly that closing connection must close all its opened statements, which means all drivers must have it already. Not sure why hikari must duplicate the implementation here.
We can take 2 possible solutions:

Make this statement tracking threadsafe
Drop of the statement tracking support, or at least make a switch for it that allows it to be turned off.

I consider this to be a bug.  While statements should be prepared serially on a single connection , after that each statement should be independently accessible to a thread.  The Statement.close() path needs to be made thread safe, likely through synchronization of the untrack statement method.

Thanks @brettwooldridge ! That is similar to the work around we are doing, synchronized on the connection when closing the statement. Hope to see your fixed release soon, then we will drop the work around.

There might be faster alternatives than synchronizing; depending on the access pattern? MPSC or MPMC?
Check this project which has fast concurrent data structures, one example that could help here is:
https://github.com/JCTools/JCTools/blob/master/jctools-core/src/main/java/org/jctools/queues/MpscArrayQueue.java

This a typicaly an extremely low-contention path, in fact this kind of multi-threaded access is relatively rare (hence this issue going undiscovered despite 3 years of use by thousands of users).  The JIT's biased locking optimizations should remove most of the overhead of the lock in this case.

@brettwooldridge I think the trackStatement() and closeStatements() should be synced too.

While a thread is closing a statement, and other thread could use the connection to create a new statement, then trackStatement will race with untrackStatement().
A concurrent closing could happen on both the connection and statements, then the untrackStatement() will race with closeStatements().

I don't mind to synchronize trackStatement(), but it is not valid to close statements while closing the connection.

I am not saying it is on purposely to close connection and statements concurrently.
But it could happen, as long as the statements are handled to other threads, their lifecycles are out of  control.

@shuyangzhou While I agree it is a theoretical race, I would consider that usage a coding error in the application.  Closing a connection while simultaneously closing statements is likely to lead to SQLException in many drivers anyway, because the driver cannot know there is a thread executing in a Statement it is likely to close the socket and therefore induce an exception in the thread executing the Statement.close().

@brettwooldridge I do agree with you on it is not an expected usage, and even we sync on it, it won't fix everything.
But there is a slight difference here. If we do sync it, like you said one might get SQLException with error stack leading to the driver's classes. So most likely the developer will realize this a wrongful usage. Then he/she will start on digging and fixing it.
If we don't sync it, there is a chance that, in stead of failing at the driver, it fails on the concurrent modification to FastList first with an IndexOutOfBoundary exception with error stack leading to Hikari classes which could be very misleading. Then most likely they just file a bug report to you instead of starting to fix their own issues.

@shuyangzhou Ok, I have added protection in the close path for closeStatements() and synchronized trackStatement().  There is still an unprotected code path that I will not change because it affects the hot-path performance too much; it is still possible to provoke thread-safety issues if statements are created while the connection is being closed.  But because this constitutes simultaneous thread access to the Connection it is considered by HikariCP to be invalid.

Thanks @brettwooldridge !

HikariCP 2.4.5 was been released with a fix for this issue.

Thanks @brettwooldridge ! we will try it out :)

Getting similar exception with HikariCP version 2.6.3. I have studied this issue.  I am pretty sure my threads are not sharing the same connection at least directly. As a matter of fact, the exceptions happen when both are trying to return their current connection and get a new connection from the pool.  There are over 512 threads running on a 16 cores machine. Here are the two exceptions, the exceptions are coming from two different threads:
Exception in thread "MainWorker-171" java.lang.ArrayIndexOutOfBoundsException: -1 	at com.zaxxer.hikari.util.FastList.remove(FastList.java:136) 	at com.zaxxer.hikari.pool.ProxyConnection.untrackStatement(ProxyConnection.java:169) 	at com.zaxxer.hikari.pool.ProxyStatement.close(ProxyStatement.java:70) 	at com.xxx.fsmon.summary.DirectorySummaryDAO.close(DirectorySummaryDAO.java:194) 	at com.xxx.fsmon.summary.DirectorySummaryDAO.renewConnectionToDb(DirectorySummaryDAO.java:159) 	at com.xxx.fsmon.directory.ThreadByDir.DirectoryRunnableExtractor.extract(DirectoryRunnableExtractor.java:215) 	at com.xxx.fsmon.directory.ThreadByDir.DirectoryRunnableExtractor.run(DirectoryRunnableExtractor.java:454) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 	at java.lang.Thread.run(Thread.java:745)
and
[MainWorker-488] ERROR com.xxx.fsmon.summary.FileSummaryDAO: Could not prepare the statements! java.lang.ArrayIndexOutOfBoundsException: -1         at com.zaxxer.hikari.util.FastList.add(FastList.java:78)         at com.zaxxer.hikari.pool.ProxyConnection.trackStatement(ProxyConnection.java:189)         at com.zaxxer.hikari.pool.ProxyConnection.prepareStatement(ProxyConnection.java:312)         at com.zaxxer.hikari.pool.HikariProxyConnection.prepareStatement(HikariProxyConnection.java)         at com.xxx.fsmon.summary.FileSummaryDAO.<init>(FileSummaryDAO.java:116)         at com.xxx.fsmon.summary.DirectorySummaryDAO.renewConnectionToDb(DirectorySummaryDAO.java:171)         at com.xxx.fsmon.directory.ThreadByDir.DirectoryRunnableExtractor.extract(DirectoryRunnableExtractor.java:215)         at com.xxx.fsmon.directory.ThreadByDir.DirectoryRunnableExtractor.run(DirectoryRunnableExtractor.java:454)          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)         at java.lang.Thread.run(Thread.java:745)
Could this be caused by a race condition where one thread closes a connection, but has not finished closing all its statements and the other thread somehow gets that connection and is trying to open a new prepareStatement on it?
I am going to synchronize my renewConnectionToDb() method and see if the exception goes away.
Any suggestion is greatly appreciated.


Dragen germline inline csv update

Updates

As discussed for https://github.com/umccr/cwl-ica/pull/67 - I have added my JS code changes in this branch. Hopefully this makes it easier to compare.
Mainly attempted to extract the full set of keys and values from fastq list csv content in a single function, removing the need to iterate over each fastq list row again and collect the values. Most of other functions are unchanged.

Testing within CWL tool
I have tested the code locally by replacing the Dragen image with alpine:latest.
Inputs for local testing
fastq_list_rows:
  - "rgsm": "my-sample"
    "rglb": "my-library"
    "rgid": "my-sample__my-library"
    "lane": 4
    "read_1":
      class: File
      location: inputs/my-read_R1.fastq.gz
    "read_2":
      class: File
      location: inputs/my-read_R2.fastq.gz
  - "rgsm": "your-sample"
    "rglb": "your-library"
    "rgid": "your-sample__your-library"
    "lane": 3
    "read_1":
      class: File
      location: inputs/your-read_R1.fastq.gz
    "read_2":
      class: File
      location: inputs/your-read_R2.fastq.gz
reference_tar:
  class: File
  location: inputs/reference.tar.gz
output_file_prefix: "blaaa"
output_directory: "booo"

Output file
RGSM,RGLB,RGID,Lane,Read1File,Read2File
my-sample,my-library,my-sample__my-library,4,/var/lib/cwl/stg2eecc50c-05b3-47e0-8e43-00013e52fa87/my-read_R1.fastq.gz,/var/lib/cwl/stg05875c15-a6d5-4802-b3df-9bfd6df679cf/my-read_R2.fastq.gz
your-sample,your-library,your-sample__your-library,3,/var/lib/cwl/stg95f8513b-f464-4f14-9780-90dfc94bcd12/your-read_R1.fastq.gz,/var/lib/cwl/stg732fe626-e258-4ff3-90fd-dc1f17b596a6/your-read_R2.fastq.gz

Independent testing of JS code
In case of interest, adding here the explicit JS code I have been playing with:
var data = [
  {
    "rgsm": "my-sample",
    "rglb": "my-library",
    "rgid": "my-sample__my-library",
    "lane": 4,
    "read_1": {
      "class": "File",
      "location": "inputs/my-read_R1.fastq.gz"
    },
    "read_2": {
      "class": "File",
      "location": "inputs/my-read_R2.fastq.gz"
    }
  },
  {
    "rgsm": "your-sample",
    "rglb": "your-library",
    "rgid": "your-sample__my-library",
    "lane": 4,
    "read_1": {
      "class": "File",
      "location": "inputs/your-read_R1.fastq.gz"
    },
    "read_2": {
      "class": "File",
      "location": "inputs/your-read_R2.fastq.gz"
    }
  }
]

var get_unique_elements_of_list = function(list){
      /*
      Get unique elements of an array
      */
      return list.filter(function (x, i, a) {
          /*console.log("x=" + x + " i=" + i + " a=" + a);*/
          return a.indexOf(x) == i;
      });
}

var convert_to_csv = function(double_array, column_headers){
    /*
    Given a list of lists and a set of column headers, generate a csv
    */
    var str = column_headers.join(",") + "\n";
    for (var line_iter=0; line_iter < double_array.length; line_iter++){
      str += double_array[line_iter].join(",") + "\n";
    }

    /*
    Return string of csv
    */
    return str;
}

var get_fastq_list_csv_contents_from_fastq_list_rows_object = function(fastq_list_rows_object){
    /*
    Get the fastq list csv contents
    Get full set of keys and values
    */
    var my_all_keys = [];
    var my_all_value = [];

    data.forEach(function(item) {
      var items = Object.keys(item);
      var my_all_values = [];
      items.forEach(function(key) {
        /*console.log('this is a key-> ' + key + ' & this is its value-> ' + item[key]);*/
        my_all_keys.push(key);
        if (item[key] === null){
          my_all_values.push("");
      } else if ( item[key] !== null && item[key].class === "File" ){
          my_all_values.push(item[key].path);
      } else {
          my_all_values.push(item[key]);
      }
    })
    my_all_value.push(my_all_values);
    });

    /*
    Unique keys - this will be the header of the csv
    */
    var keys_set = get_unique_elements_of_list(my_all_keys);
    console.log("keys set = " + keys_set);

    /*
    Update rglb, rgsm and rgid to RGLB, RGSM and RGID respectively
    Update read_1 and read_2 to Read1File and Read2File in column headers
    Update lane to Lane
    */
    var new_keys_set = [];
    for (var key_iter=0; key_iter < keys_set.length; key_iter++ ){
      var key_value = keys_set[key_iter];
      if (key_value.indexOf("rg") === 0){
        new_keys_set.push(key_value.toUpperCase());
      } else if (key_value === "read_1"){
        new_keys_set.push("Read1File");
      } else if (key_value === "read_2"){
        new_keys_set.push("Read2File");
      } else if (key_value === "lane"){
        new_keys_set.push("Lane");
      }
    }

    /*
    Return the string value of the csv
    */
    /*return convert_to_csv(rows_as_list, new_keys_set);*/
    return convert_to_csv(my_all_value, new_keys_set);
}

var res = get_fastq_list_csv_contents_from_fastq_list_rows_object(data);
console.log(res);

Had a look through this, one small issue is that this assumes each fastq list row has the same order for keys.
If I rearrange the data variable to be:
var data = [
  {
    "rglb": "my-library",
    "rgsm": "my-sample",
    "rgid": "my-sample__my-library",
    "lane": 4,
    "read_1": {
      "class": "File",
      "location": "inputs/my-read_R1.fastq.gz"
    },
    "read_2": {
      "class": "File",
      "location": "inputs/my-read_R2.fastq.gz"
    }
  },
  {
    "rgsm": "your-sample",
    "rglb": "your-library",
    "rgid": "your-sample__my-library",
    "lane": 4,
    "read_1": {
      "class": "File",
      "location": "inputs/your-read_R1.fastq.gz"
    },
    "read_2": {
      "class": "File",
      "location": "inputs/your-read_R2.fastq.gz"
    }
  }
]

My output is:
RGLB,RGSM,RGID,Lane,Read1File,Read2File
my-library,my-sample,my-sample__my-library,4,,
your-sample,your-library,your-sample__my-library,4,,

Note the sample and library in the second row are in the wrong spot.


Delete UseDeclaredVarsMoreThanAssignments.md

PR Summary

PR Checklist

[ ] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[ ] Summarized changes
[ ] Change is not breaking
[ ] Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
[ ] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

To me it looks like an accidentally created PR or something we wouldn't accept anyway. Closing therefore.