quick Swipe gesture trigger the onClickListener

Hi, i've configure your library correctly, i used the BaseSwipeAdapter with the onOpen method and an onClickListener method for the surface. But sometimes when i swipe without keeping my finger on the screen, my move trigger the onClickListener of my row (when i swipe to Open and sometimes when i swipe to close). How can i manage to avoid this behavior?
Thanks

Here is a video of the problem
https://mega.nz/#!PAJmXYYY!SkxP83OB04aidyXiu5bQ55QkjGAkwiB-6Uutd12RYEw

just dropping in here to say "same here", I haven't really investigated it yet though.

Think i found something:
in your onClickListener:
    swipeLayout.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            // test if the swipe is closed
            if(swipeLayout.getOpenStatus() == SwipeLayout.Status.Close){
                //DO WHAT YOU WANT
            }//if
        }
    });

Try it and tell me?!

It still triggers the onClickListener when you close (swipe back) the surface view

You may want to try this work-around:
swipeLayout.setOnClickListener(new View.OnClickListener()
{
  boolean wasClosed = true;

  @Override
  public void onClick(View v)
  {
    if (SwipeLayout.Status.Close == swipeLayout.getOpenStatus())
    {
      if (wasClosed)
      {
        //DO WHAT YOU WANT
      }
      else
      {
        wasClosed = true;
      }
    }
    else
    {
      wasClosed = false;
    }
  }
});

Alrighty, so the problem is (essentially) here:
https://github.com/daimajia/AndroidSwipeLayout/blob/cc6a322f745c3f7acfc9b02223e4cb3067e9fdc5/library/src/main/java/com/daimajia/swipe/SwipeLayout.java#L1002-L1013
private void performAdapterViewItemClick() {
    if(getOpenStatus()!= Status.Close) return;
    ViewParent t = getParent();
    if (t instanceof AdapterView) {
        AdapterView view = (AdapterView) t;
        int p = view.getPositionForView(SwipeLayout.this);
        if (p != AdapterView.INVALID_POSITION){
            view.performItemClick(view.getChildAt(p - view.getFirstVisiblePosition()), p, view
                    .getAdapter().getItemId(p));
        }
    }
}

If you e.g. swipe an open layout closed, and the layout closes before you release your finger (e.g. if the background view is 100dp, and you swiped 110dp before lifting), the getOpenStatus() will return Close, because it's only based on the current layout.
Unfortunately I'm not sure what a clean solution would look like.  Maybe this is worth special-casing, and adding an "if swiped by this touch" flag?

Hi,
I am also getting this in my listview.
I am using this latest one
com.daimajia.swipelayout:library:1.2.0@aar"
Thanks,

Easy workaround is:
swipeLayout.setOnClickListener(new View.OnClickListener() {
  @Override
  public void onClick(View v)  {
    if (swipeLayout.getOpenStatus() == SwipeLayout.Status.Middle) return;
    // From here you are in correct state
 });

Tested that @Groxx 's commit using jitpack. It's finally working perfectly in my case.
This is the dependency line I'm using: compile 'com.github.Groxx:AndroidSwipeLayout:c8a42d84c1', don't forget to add maven { url "https://jitpack.io" } line to your repositories block.
Going to use this workaround until that fix got into this upstream repo. Hope it will be merged soon.

Any updates?
I have to downgrade the library to v1.1.9 to get rid of this problem.

One thing that I did that fix this was instead of putting the onClickListener on the whole layout (itemView of a ViewHolder, for example), I put it only on the SurfaceView. For what I understood, the SwipeLayout get the click first and use it if dragging, don't pass to children. If not dragging, then the click will be used by children.
Using the same layout on the wiki, would be something like this:
<com.daimajia.swipe.SwipeLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent" android:layout_height="80dp"
    android:id="@+id/swipe_layout">
    <!-- Bottom View Start-->
     <LinearLayout
        android:id="@+id/bottom_wrapper"
        android:layout_width="160dp"
        android:layout_height="match_parent">
        <!--What you want to show-->
    </LinearLayout>
    <!-- Bottom View End-->

    <!-- Surface View Start -->
     <LinearLayout
        android:id="@+id/ll_surface_view"
        android:layout_width="match_parent"
        android:background="?attr/selectableItemBackground"
        android:layout_height="match_parent">
        <!--What you want to show in SurfaceView-->
    </LinearLayout>
    <!-- Surface View End -->
</com.daimajia.swipe.SwipeLayout>

And on my ViewHolder
ll_surface_view.setOnClickListener(view -> {
    if(swipe_layout.getOpenStatus() == SwipeLayout.Status.Close){
        listener.onSubjectClicked(subject);
    }
});

Used @tsuharesu solution, worked perfectly, I guess you could close the issue so people will know there a solution when looking at the issue.

Used @tsuharesu solution with Cursor Adaptor and the problem is solved1 Thanks

Not the perfect workaround but it works well for my purposes
public class CSwipeLayout extends SwipeLayout {
    public enum SwipeStatus {OPENING, OPENED, CLOSING, CLOSED}

    SwipeStatus swipeStatus = SwipeStatus.OPENED;

    public CSwipeLayout(Context context) {
        super(context);

        init(context);
    }

    public CSwipeLayout(Context context, AttributeSet attrs) {
        super(context, attrs);

        init(context);
    }

    public CSwipeLayout(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);

        init(context);
    }

    private void init(Context context) {
        addSwipeListener(new SimpleSwipeListener() {
            Handler handler = new Handler();
            Runnable closeRunnable = new Runnable() {
                @Override
                public void run() {
                    swipeStatus = SwipeStatus.CLOSED;
                }
            };
            Runnable openRunnable = new Runnable() {
                @Override
                public void run() {
                    swipeStatus = SwipeStatus.OPENED;
                }
            };

            @Override
            public void onStartOpen(SwipeLayout layout) {
                swipeStatus = SwipeStatus.OPENING;
                handler.removeCallbacks(closeRunnable);
            }

            @Override
            public void onOpen(SwipeLayout layout) {
                handler.removeCallbacks(closeRunnable);
                handler.postDelayed(openRunnable, 100);
            }

            @Override
            public void onStartClose(SwipeLayout layout) {
                swipeStatus = SwipeStatus.CLOSING;
                handler.removeCallbacks(closeRunnable);
            }

            @Override
            public void onClose(SwipeLayout layout) {
                handler.removeCallbacks(openRunnable);
                handler.postDelayed(closeRunnable, 100);
            }
        });
    }

    public SwipeStatus getSwipeStatus() {
        return swipeStatus;
    }
}

Then
swipeLayout.setOnClickListener(new OnClickListener() {
            @Override
            public void onClick(View view) {
                if (swipeLayout.getSwipeStatus() == CSwipeLayout.SwipeStatus.CLOSED) {
                    // DO WHATEVER YOU WANT
                } else if (swipeLayout.getSwipeStatus() == CSwipeLayout.SwipeStatus.OPENED) {
                    // This will close the layout in case of a click while already opened
                    swipeLayout.close(true);
                }
            }
        });

Think i found something:
in your onClickListener test the swipelayout Status
    swipeLayout.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            // test if the swipe is closed
            if(swipeLayout.getOpenStatus() == SwipeLayout.Status.Close){
                //DO WHAT YOU WANT
            }//if
        }
    });

Try it and tell me?!

its working for me.. thanks a lot. you saved my time

Think i found something:
in your onClickListener test the swipelayout Status
    swipeLayout.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            // test if the swipe is closed
            if(swipeLayout.getOpenStatus() == SwipeLayout.Status.Close){
                //DO WHAT YOU WANT
            }//if
        }
    });

Try it and tell me?!

its working for me. thanks a lot.  you saved my time


Logging MDC variables in jetty request log

Hi,
I want to log some of the attributes from MDC into request log.
Dropwizard, by default, uses logback-access which doesn't support logging MDC variables (https://logback.qos.ch/manual/layouts.html#logback-access).
Is there a way to add some custom data(user-info, request params) to request logs?

Duplicate of #2419


Dados

Sensacional!
[Insira comentários aqui]

Detalhes do documento
⚠ Não edite esta seção. É necessário para a vinculação de problema do learn.microsoft.com ➟ GitHub.

ID: fcb3c6d7-aa3e-9a76-181b-d0963ac685b9
Version Independent ID: da9c883b-93bf-8864-015a-a7b10a6fcb5f
Content: ETL (extrair, transformar e carregar) - Azure Architecture Center
Content Source: docs/data-guide/relational-data/etl.yml
Service: architecture-center
Sub-service: azure-guide
GitHub Login: @raunakjhawar
Microsoft Alias: rajhawar

@moises77filipe
Thanks for your feedback! We will investigate and update as appropriate.
It would be great if you could add a link to the documentation you are following for these steps? This would help us redirect the issue to the appropriate team. Thanks!

It is unclear what is needed, if assistance is needed, please re-open with additional information.


Fix: Enable adapter only if jest installed

instead of looking for direct dependency, it would be better to look if node_modules/.bin/jest exists, because it could be a peerDependency or even a child dependency

Hi @jigfox, thanks for sharing your thoughts,
Initially, I considered your solution and I think it's good, but IMHO there are very little cons:

Adapter won't be enabled if dependencies are not yet installed. (user could be interested in working on a JS project and read the tests list before or during dependencies installation)
In some monorepos dependencies can be shared among packages/apps and as a consequence, you couldn't find jest executable in .bin folder of the single package/app

About your suggestion, We can look also for peerDependency in the package.json and I don't think We should enable neotest-jest in case of Jest is installed as a child dep. I struggle to find a real case it could happen. Please tell me if you're not convinced

@haydenmeade @marilari88 Can you merge this?

@haydenmeade @marilari88 Can you merge this?

I have no permission to merge this. Sorry

In some monorepos dependencies can be shared among packages/apps and as a consequence, you couldn't find jest executable in .bin folder of the single package/app

Can we revise how this is done given it's breaking monorepos? https://github.com/nvim-neotest/neotest-jest/issues/60


CubeSphere vs LatLonCap

https://github.com/JuliaClimate/IndividualDisplacements.jl/blob/7a5df040c6674013deb461f5fe6bd3feb21d3ba4/src/compute.jl#L27-L28
Is there a type here and you actually want to call a function like update_location_llc or similar in L28? Otherwise the branching doesn't make much sense...

https://github.com/openjournals/joss-reviews/issues/2813

They actually do the same thing because the face connections that matter are set up the same way (as highlighted by the color scheme in Fig 1 of https://doi.org/10.5194/gmd-8-3071-2015 ) while face connections on Antartica  do not need to be represented for the llc grid since this is an ocean only grid (unlike cube sphere which makes sense for the Atmosphere and Ocean). I know this is tricky ...
In any event, I introduced an alias for update_location_llc! to make it more clear that this is not a bug

Great, good to know, I never worked with LLC...


Feat/inversion tooltip

Изменила цвет и тень у hint, добавила инверсию

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

4 of 4 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.0006%) to 82.347%

Totals

Change from base Build<PHONE_NUMBER>:
0.0006%

Covered Lines:
5047

Relevant Lines:
5694

💛  - Coveralls


Version 0.4.1 - Add fsspec, use Pyarrow from Pandas

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

https://github.com/evidentlyai/evidently/issues/862#issuecomment-1853883789
https://github.com/pandas-dev/pandas/blob/main/pyproject.toml
parquet = ['pyarrow>=10.0.1']

@conda-forge-admin, please rerender

@thewchan could you please review and merge please.


Let content elements update their own configuration

Add hook to let content elements update their configuration which

updates entry state in place to preserve object identity
posts a message out to update Backbone collections

Make watchCollections ignore those updates to prevent extra entry
state updates.
REDMINE-17336

Coverage remained the same at 99.208% when pulling 5177edfec981c0c69c71f5fe6a31048e6ff15a51 on tf:update-content-element-hook into 0f882d85bcd4317d73b0b12a09202ece4699008f on codevise:master.


Speed improvements for govendor

Implement an ast.File cache in context to avoid
parsing the same files over and over again
Context.updatePackageReferences implement
a cache of directory, canonical import to
package

Both these improvements took the run time on my source
down from:
time govendor list
...
real	1m28.345s
user	2m5.077s
sys	0m4.551s
To:
time govendor list
...
real	0m3.492s
user	0m4.565s
sys	0m1.144s

Wowzorz!

I like the effect of this PR. Woot! It shows that somewhere govendor is not caching when it should or is searching excessively. I like the updatePackageReferences function cache implementation.
For the ast cache, I'd like to see Context.ParsedFiles not be exported. It also needs to be cleared (invalidated) at the top of ctx.loadPackage().
Another issue that I just noticed is that while the dirty flag is set to true, it is never set to false in loadPackage(). I just corrected this in the latest push. Could you rebase on master? If you wouldn't mind, could you also do timing deltas for each change separately? Thanks.

K there are three runs:
Before changes:
real	1m31.080s
user	2m8.802s
sys	0m4.412s
With just ast cache:
real	1m27.658s
user	2m6.308s
sys	0m3.549s
With just updatePackageReferences() cache:
real	0m5.997s
user	0m8.349s
sys	0m2.019s
With both:
real	0m3.557s
user	0m4.576s
sys	0m1.196s
@kardianos do you want me to split this into two commits?

Is this at current master? Just add in the updatePackageReferences for now if you would.
I like the updatePackageReferences change. I'm okay with the ast cache, but I'm wondering why it is needed, it seems like it is probably papering over some other issue. I'd like to add to the Context obj a "map[dir string]struct{}" that gets cleared on loadPackage. Then if we try to parse a file twice we panic. See if we panic for tests or if we need a new test to trigger. Then find root cause. I can do that if you'd like too, let me know.

Okay just updated with something onto of master that just has the Context.updatePackageReferences improvement

LGTM

@tedoc2000 Could you run timings against tip again? I'd like to see if that brings it back down to 3.5s without additional cache.

I got
real	0m2.455s
user	0m2.413s
sys	0m0.196s
So even better.


Added port input and renamed port_scaner.py to port_scanner.py

Type of change

[ ] Added new project
[ ] Bug fix
[x] New features
[ ] Enhanced documentation

Changes proposed in this pull request

Project name : Port Scaner

Short description : Added input field for port number, and renamed the file to include correct spelling of "scanner"

Checklist

[ ] The code is Python 3 compatible
[ ] I have added relevant comments in my file to make code understandable
[ ] I have added my project in a folder which includes all the necessary files

Thanks for the contribution 🚀


[T4A3][T15-A2]Yoshiaki Nishimura

Ready for Review

Accepting this PR without a review because another of your PRs for this tutorial was reviewed in detail.

@yoshi-1224 Some comments added. Please close the PR after reading comments. Sorry to bother you again. You may want to see the comments.


Paramz

pulled out paramz and made sure everything works fine in GPy
testing paramz now and making sure it is properly stable.

Will this mean that everyone who has ever written a GPy model or component
will have to rewrite it or else it will no longer work?! Seems like quite a
big deal!!
Alan
On 15 October 2015 at 15:04, Max Zwiessele<EMAIL_ADDRESS>wrote:

pulled out paramz and made sure everything works fine in GPy
testing paramz now and making sure it is properly stable.
You can view, comment on, or merge this pull request online at:
https://github.com/SheffieldML/GPy/pull/269
Commit Summary

[paramz] started to pull paramz out
[paramz] fully integrated all tests running
[python3] paramz integration
[setup] paramz integrated

File Changes

M GPy/init.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-0 (8)
M GPy/core/init.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-1 (6)
M GPy/core/gp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-2 (11)
D GPy/core/model.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-3 (437)
M GPy/core/parameterization/init.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-4 (6)
D GPy/core/parameterization/domains.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-5 (25)
D GPy/core/parameterization/index_operations.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-6 (327)
D GPy/core/parameterization/lists_and_dicts.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-7 (139)
D GPy/core/parameterization/observable.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-8 (71)
D GPy/core/parameterization/observable_array.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-9 (147)
M GPy/core/parameterization/param.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-10 (496)
D GPy/core/parameterization/parameter_core.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-11 (1088)
M GPy/core/parameterization/parameterized.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-12 (389)
A GPy/core/parameterization/priorizable.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-13 (77)
D GPy/core/parameterization/ties_and_remappings.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-14 (225)
M GPy/core/parameterization/transformations.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-15 (518)
D GPy/core/parameterization/updateable.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-16 (54)
R GPy/core/priors.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-17 (9)
A GPy/core/probabilistic_model.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-18 (48)
M GPy/core/sparse_gp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-19 (4)
M GPy/core/svgp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-20 (2)
R GPy/core/variational.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-21 (8)
D GPy/core/verbose_optimization.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-22 (185)
M
GPy/inference/latent_function_inference/expectation_propagation.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-23 (2)
M GPy/inference/latent_function_inference/inferenceX.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-24 (23)
M GPy/inference/latent_function_inference/var_dtc.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-25 (7)
M GPy/inference/latent_function_inference/var_dtc_parallel.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-26 (2)
M GPy/kern/src/ODE_UY.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-27 (2)
M GPy/kern/src/ODE_UYC.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-28 (2)
M GPy/kern/src/ODE_st.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-29 (2)
M GPy/kern/src/ODE_t.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-30 (2)
M GPy/kern/src/add.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-31 (2)
M GPy/kern/src/basis_funcs.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-32 (4)
M GPy/kern/src/brownian.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-33 (2)
M GPy/kern/src/coregionalize.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-34 (2)
M GPy/kern/src/eq_ode2.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-35 (4)
M GPy/kern/src/kern.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-36 (14)
M GPy/kern/src/kernel_slice_operations.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-37 (2)
M GPy/kern/src/linear.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-38 (4)
M GPy/kern/src/mlp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-39 (4)
M GPy/kern/src/periodic.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-40 (2)
M GPy/kern/src/poly.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-41 (3)
M GPy/kern/src/prod.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-42 (2)
M GPy/kern/src/psi_comp/init.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-43 (6)
M GPy/kern/src/psi_comp/gaussherm.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-44 (4)
M GPy/kern/src/psi_comp/rbf_psi_comp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-45 (2)
M GPy/kern/src/psi_comp/rbf_psi_gpucomp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-46 (2)
M GPy/kern/src/psi_comp/ssrbf_psi_gpucomp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-47 (2)
M GPy/kern/src/rbf.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-48 (2)
M GPy/kern/src/spline.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-49 (2)
M GPy/kern/src/standard_periodic.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-50 (2)
M GPy/kern/src/static.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-51 (2)
M GPy/kern/src/stationary.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-52 (8)
M GPy/kern/src/trunclinear.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-53 (4)
M GPy/likelihoods/gaussian.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-54 (2)
M GPy/likelihoods/mixed_noise.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-55 (2)
M GPy/likelihoods/student_t.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-56 (2)
M GPy/models/bayesian_gplvm.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-57 (2)
M GPy/models/bayesian_gplvm_minibatch.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-58 (10)
M GPy/models/dpgplvm.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-59 (3)
M GPy/models/gp_kronecker_gaussian_regression.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-60 (8)
M GPy/models/gp_var_gauss.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-61 (2)
M GPy/models/gradient_checker.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-62 (10)
M GPy/models/mrd.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-63 (10)
M GPy/models/one_vs_all_classification.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-64 (1)
M GPy/models/sparse_gp_classification.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-65 (2)
M GPy/models/sparse_gp_coregionalized_regression.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-66 (1)
M GPy/models/sparse_gp_minibatch.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-67 (9)
M GPy/models/sparse_gp_regression.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-68 (3)
M GPy/models/sparse_gplvm.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-69 (3)
M GPy/models/ss_gplvm.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-70 (6)
M GPy/models/ss_mrd.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-71 (12)
M GPy/plotting/gpy_plot/plot_util.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-72 (2)
M GPy/plotting/matplot_dep/visualize.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-73 (2)
D GPy/testing/cacher_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-74 (37)
M GPy/testing/examples_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-75 (2)
M GPy/testing/gp_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-76 (2)
D GPy/testing/index_operations_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-77 (137)
M GPy/testing/inference_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-78 (2)
M GPy/testing/kernel_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-79 (7)
M GPy/testing/mapping_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-80 (2)
D GPy/testing/observable_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-81 (132)
D GPy/testing/parameterized_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-82 (264)
M GPy/testing/pickle_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-83 (97)
M GPy/testing/rv_transformation_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-84 (4)
M GPy/util/init.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-85 (1)
D GPy/util/caching.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-86 (197)
M GPy/util/choleskies.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-87 (4)
M GPy/util/warping_functions.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-88 (2)
M setup.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-89 (19)

Patch Links:

https://github.com/SheffieldML/GPy/pull/269.patch
https://github.com/SheffieldML/GPy/pull/269.diff

—
Reply to this email directly or view it on GitHub
https://github.com/SheffieldML/GPy/pull/269.

In general, it is a good direction to separate parameterization framework out of GPy. However, a lot of our extensions rely on the current setting of GPy.

Nope it will work just fine.

On 15 Oct 2015, at 15:07, Alan Saul<EMAIL_ADDRESS>wrote:
Will this mean that everyone who has ever written a GPy model or component
will have to rewrite it or else it will no longer work?! Seems like quite a
big deal!!
Alan
On 15 October 2015 at 15:04, Max Zwiessele<EMAIL_ADDRESS>wrote:

pulled out paramz and made sure everything works fine in GPy
testing paramz now and making sure it is properly stable.
You can view, comment on, or merge this pull request online at:
https://github.com/SheffieldML/GPy/pull/269
Commit Summary

[paramz] started to pull paramz out
[paramz] fully integrated all tests running
[python3] paramz integration
[setup] paramz integrated

File Changes

M GPy/init.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-0 (8)
M GPy/core/init.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-1 (6)
M GPy/core/gp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-2 (11)
D GPy/core/model.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-3 (437)
M GPy/core/parameterization/init.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-4 (6)
D GPy/core/parameterization/domains.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-5 (25)
D GPy/core/parameterization/index_operations.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-6 (327)
D GPy/core/parameterization/lists_and_dicts.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-7 (139)
D GPy/core/parameterization/observable.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-8 (71)
D GPy/core/parameterization/observable_array.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-9 (147)
M GPy/core/parameterization/param.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-10 (496)
D GPy/core/parameterization/parameter_core.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-11 (1088)
M GPy/core/parameterization/parameterized.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-12 (389)
A GPy/core/parameterization/priorizable.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-13 (77)
D GPy/core/parameterization/ties_and_remappings.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-14 (225)
M GPy/core/parameterization/transformations.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-15 (518)
D GPy/core/parameterization/updateable.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-16 (54)
R GPy/core/priors.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-17 (9)
A GPy/core/probabilistic_model.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-18 (48)
M GPy/core/sparse_gp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-19 (4)
M GPy/core/svgp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-20 (2)
R GPy/core/variational.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-21 (8)
D GPy/core/verbose_optimization.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-22 (185)
M
GPy/inference/latent_function_inference/expectation_propagation.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-23 (2)
M GPy/inference/latent_function_inference/inferenceX.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-24 (23)
M GPy/inference/latent_function_inference/var_dtc.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-25 (7)
M GPy/inference/latent_function_inference/var_dtc_parallel.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-26 (2)
M GPy/kern/src/ODE_UY.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-27 (2)
M GPy/kern/src/ODE_UYC.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-28 (2)
M GPy/kern/src/ODE_st.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-29 (2)
M GPy/kern/src/ODE_t.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-30 (2)
M GPy/kern/src/add.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-31 (2)
M GPy/kern/src/basis_funcs.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-32 (4)
M GPy/kern/src/brownian.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-33 (2)
M GPy/kern/src/coregionalize.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-34 (2)
M GPy/kern/src/eq_ode2.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-35 (4)
M GPy/kern/src/kern.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-36 (14)
M GPy/kern/src/kernel_slice_operations.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-37 (2)
M GPy/kern/src/linear.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-38 (4)
M GPy/kern/src/mlp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-39 (4)
M GPy/kern/src/periodic.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-40 (2)
M GPy/kern/src/poly.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-41 (3)
M GPy/kern/src/prod.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-42 (2)
M GPy/kern/src/psi_comp/init.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-43 (6)
M GPy/kern/src/psi_comp/gaussherm.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-44 (4)
M GPy/kern/src/psi_comp/rbf_psi_comp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-45 (2)
M GPy/kern/src/psi_comp/rbf_psi_gpucomp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-46 (2)
M GPy/kern/src/psi_comp/ssrbf_psi_gpucomp.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-47 (2)
M GPy/kern/src/rbf.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-48 (2)
M GPy/kern/src/spline.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-49 (2)
M GPy/kern/src/standard_periodic.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-50 (2)
M GPy/kern/src/static.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-51 (2)
M GPy/kern/src/stationary.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-52 (8)
M GPy/kern/src/trunclinear.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-53 (4)
M GPy/likelihoods/gaussian.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-54 (2)
M GPy/likelihoods/mixed_noise.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-55 (2)
M GPy/likelihoods/student_t.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-56 (2)
M GPy/models/bayesian_gplvm.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-57 (2)
M GPy/models/bayesian_gplvm_minibatch.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-58 (10)
M GPy/models/dpgplvm.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-59 (3)
M GPy/models/gp_kronecker_gaussian_regression.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-60 (8)
M GPy/models/gp_var_gauss.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-61 (2)
M GPy/models/gradient_checker.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-62 (10)
M GPy/models/mrd.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-63 (10)
M GPy/models/one_vs_all_classification.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-64 (1)
M GPy/models/sparse_gp_classification.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-65 (2)
M GPy/models/sparse_gp_coregionalized_regression.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-66 (1)
M GPy/models/sparse_gp_minibatch.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-67 (9)
M GPy/models/sparse_gp_regression.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-68 (3)
M GPy/models/sparse_gplvm.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-69 (3)
M GPy/models/ss_gplvm.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-70 (6)
M GPy/models/ss_mrd.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-71 (12)
M GPy/plotting/gpy_plot/plot_util.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-72 (2)
M GPy/plotting/matplot_dep/visualize.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-73 (2)
D GPy/testing/cacher_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-74 (37)
M GPy/testing/examples_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-75 (2)
M GPy/testing/gp_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-76 (2)
D GPy/testing/index_operations_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-77 (137)
M GPy/testing/inference_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-78 (2)
M GPy/testing/kernel_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-79 (7)
M GPy/testing/mapping_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-80 (2)
D GPy/testing/observable_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-81 (132)
D GPy/testing/parameterized_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-82 (264)
M GPy/testing/pickle_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-83 (97)
M GPy/testing/rv_transformation_tests.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-84 (4)
M GPy/util/init.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-85 (1)
D GPy/util/caching.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-86 (197)
M GPy/util/choleskies.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-87 (4)
M GPy/util/warping_functions.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-88 (2)
M setup.py
https://github.com/SheffieldML/GPy/pull/269/files#diff-89 (19)

Patch Links:

https://github.com/SheffieldML/GPy/pull/269.patch
https://github.com/SheffieldML/GPy/pull/269.diff

—
Reply to this email directly or view it on GitHub
https://github.com/SheffieldML/GPy/pull/269.

—
Reply to this email directly or view it on GitHub https://github.com/SheffieldML/GPy/pull/269#issuecomment-148396839.

But doing the deprecation is a good thing!
I will go through the relevant bits in the imports and do some deprecations.
It should be done in a way so that it will not be problamatic though.

Actually I am trying to do it, so that the average developer doesnt even know, that it has been pulled out.
So lets see, maybe you want to try it out as soon as the tests pass.

Current coverage is 45.85%

Merging #269 into devel will decrease coverage by -4.37% as of 9fb42cb

@@            devel    #269   diff @@
=====================================
  Files         166     156     -10
  Stmts       17002   14584   -2418
  Branches        0       0
  Methods         0       0
=====================================
- Hit          8539    6688   -1851
  Partial         0       0
+ Missed       8463    7896    -567

Review entire Coverage Diff as of 9fb42cb

Powered by Codecov. Updated on successful CI builds.


Added Microsoft Office Courses (Spanish)

free-courses-es.md update
What does this PR do?
Add Resource(s)
For resources
Description
Added Microsoft Office Courses in Spanish (From Beginner to Advanced).

Excel
Access
Word
PowerPoint

Why is this valuable (or not)
Free courses made by Juan Díaz (founder of Píldoras Informáticas) available all year round (permanent links).
Website: https://www.pildorasinformaticas.es
YouTube: https://www.youtube.com/user/pildorasinformaticas
How do we know it's really free?
We can register and enroll in courses without the need for a payment method.
For book lists, is it a book?
Checklist:

[x] Not a duplicate
[ ] Included author(s) if appropriate
[x] Lists are in alphabetical order
[ ] Needed indications added (PDF, access notes, under construction)

please add name of instructor and platform
check linter errors

please add name of instructor and platform
check linter errors

done! :D

super


Printing error message for huge ChainerX array blocks REPL

When the type of function's argument is incompatible, chainerx tries to show TypeError with the details of the invoked array X in the Invoked with: section. If the X is huge, ChainerX still shows all data contained in X. It takes much time and blocks REPL.
>>> import chainerx as chx
>>> X = chx.arange(10000000)  # huge data
>>> x = X.take([0], axis=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: take(): incompatible function arguments. The following argument types are supported:
    1. (self: chainerx.ndarray, indices: chainerx.ndarray, axis: Optional[int]=None) -> chainerx.ndarray

Invoked with: array([[0., 0.],
       [0., 0.]], shape=(2, 2), dtype=float64, device='cuda:0'), [0]; kwargs: axis=1

Thanks for the catch! The message is auto-generated by pybind11, so there are two options.

Switch to a custom type error message in which the whole array repr is not printed.
Fix __repr__ to omit middle items when the array is too large.

I'm not sure if we can accomplish the option 1 (I think we should anyway have a way to customize it, though...). The option 2 is anyway needed for other places. We can follow NumPy, whose __repr__ also omits middle items of large arrays.

It is related to #6452.

It is still a problem in invoking such as ".reshape(-1)".


Retrieving the matched rule fields

What is your idea?
Is there currently any way to retrieve the matched rule fields? For example, given the following event and rule, can event-ruler return me the list: ['detail-type', 'resources', 'detail.state']?
{
  "version": "0",
  "id": "ddddd4-aaaa-7777-4444-345dd43cc333",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "account": "012345679012",
  "time": "2017-10-02T16:24:49Z",
  "region": "us-east-1",
  "resources": [
    "arn:aws:ec2:us-east-1:123456789012:instance/i-000000aaaaaa00000"
  ],
  "detail": {
    "c-count": 5,
    "d-count": 3,
    "x-limit": 301.8,
    "source-ip": "<IP_ADDRESS>",
    "instance-id": "i-000000aaaaaa00000",
    "state": "running"
  }
}

{
  "detail-type": [ "EC2 Instance State-change Notification" ],
  "resources": [ "arn:aws:ec2:us-east-1:123456789012:instance/i-000000aaaaaa00000" ],
  "detail": {
    "state": [ "initializing", "running" ]
  }
}

Would you be willing to make the change?
Yes
Additional context
Consider also how it'd work for an or group. Only one of the list sets would be returned
Add any other context (such as images, docs, posts) about the idea here.

hey @baldawar, the difference between using the rule itself and the matched attributes is more clear in an example using $or (in retrospect I should have supplied this example):
{
    "source": [ "aws.cloudwatch" ],
    "$or": {
        "metricType": [ "MetricType" ] ,
        "namespace": [ "AWS/EC2", "AWS/ES" ]
    }
}

for the following event and above rule, the resulting list would be ['source', 'metricType']
{
  "source": "aws.cloudwatch",
  "metricType": "MetricType"
}

for this other event and above rule, the resulting list would be ['source', 'namespace']
{
  "source": "aws.cloudwatch",
  "namesapce": "AWS/EC2"
}

Oh I see. That makes sense though I'm a big unclear on why you'd want to combine multiple rules into one when Ruler supports a ton of rules at the same time.
{
  "source": [ "aws.cloudwatch" ],
  "metricType": [ "MetricType" ],
}

and
{
  "source": [ "aws.cloudwatch" ],
  "namespace": [ "AWS/EC2" ]
}

I've mostly seen $or as helpful way to check for different combinations of the same set of fields. Nothing wrong with the rule you shared above (I fixed a typo in it); but its a use-case I don't see often enough to make changes.
I do see a path to help gain more visibility into which all paths were compared, and where ruler found a mismatch but it'll come with memory & perf impact; so I'm hesitant on turning on outside of a new debugging-specific API.
Let me know if you'd like to add this in. I'll be happy to dig into the code more and come back with the effort involved. Otherwise its probably best to close this until someone can volunteer to work on the this.

Yeah I agree that would be a less complicated way to define a rule and would allow us to extract the key set cleanly off the definition. However, our rules are defined by our customers and they can do so with $or group config like I shared above (whether the fields are related or not).
I also agree this may not be a great addition until more users are requesting it. It would be great if you could provide some context, my team could put up a PR if called for.
If not added to the library, I was even thinking there may be a helper we could build for ourselves to run against a one-off machine with only the matching rule(s) added. Appreciate your help!

I've backed up a very rough but functional solution in https://github.com/aws/event-ruler/commit/6544dbc6e255430b062a6ddbffbc9b39b205421c but I do not expect to push into mainline. As I was working on this today, I realized a more usable solution requires logging / metricing what ruler is doing under the cover (flattening events, processing a specific field, matching a specific part) as it helps with debugging as user and also when developing new features (or just learning how ruler works).
I'm hesitant on adding a new logger framework as dependency as it can conflict with what consumers use, so we might have to go towards the route of implementing a placeholder interface that consumers can implement based on their needs.


Apex test run takes a long time to finish the buffer

Yesterday I realized this issue.
Despite the apex test has finished and the test report has returned to the term, the execution thread is not completed until a while after. This prevents subsequent term actions to take place.
Will take time to check it out.

it's the sf cli issue not the nvim.
It's stuck without returning after the test run. Not sure i'ts the cli version bug or other stuff.


Fixed bug in yii\db\mysql\QueryBuilder

Q
A

Is bugfix?
yes

New feature?
no

Breaks BC?
no

In yii\db\mysql\QueryBuilder::insert() function,the $columns should be an array for the foreach.
Here is a simple fix that just turns the param into an array.
An example for reproducing the bug:
-- (without a primary key)
create table yiitest（
test int(11) default 1
）
//The code below will throw a warning
Yii::$db->createCommand()->insert('yiitest',[]);

CHANGELOG entry missing

@klimov-paul  well..seem i mess up again..I think i should try later after learning more about the workflow..

well..seem i mess up again..I think i should try later after learning more about the workflow..

It almost fine: you just need one more commit to fix CHANGELOG file.

@kimov-paul I have fixed it.Hope it is right.Thanks for your patient!

Merged. Thank you.


2472: Add support for container_name in docker-compose file

Closes: #2472
This PR adds support for container_name in the docker-compose file by pulling the container names out in ParsedDockerComposeFile and adding some additional logic in DockerComposeContainer
This is my first time contributing to the repo, so any feedback is welcomed.

I'm not really sure about this failing CI. Any suggestions? I just wanted to rebase this branch with master

@reggiemcdonald I just triggered a re-run, there was some issue with downloading Gradle stuff

@bsideup thanks!

@rnorth @bsideup @kiview having this feature is a blocking issue for me is there a plan to merge this change in?

Thanks @reggiemcdonald great work
Is this still looking to be merged in? Currently the latest version (as of writing this) is 1.15.2 and this issue is still casuing problems.

Hi @reggiemcdonald, thank you! Do you have any plan on merging it @rnorth?

@reggiemcdonald Can this get merged?

Any update on landing this?

@rnorth @bsideup @kiview Can this PR be merged, please?

Is there any news about this PR?

@bsideup or @reggiemcdonald , what's the status here? If you don't have time or energy here, I'm happy to take over the PR

Would also love to see this merged, and can take it over if someone needs to.  Status?

Thanks for the PR @reggiemcdonald, but unfortunately we have to close it. Mainly, there are 2 reasons why we don't want to add support for container_name to DockerComposeContainer:

It requires us to further parse the Docker Compose file and its format has been slightly volatile in the past. So we generally want to avoid further semantically parsing the Docker Compose file, independent from the actual container_name key.
Using container_name would break existing DockerComposeContainer features, like scaling.
As the Testcontainers library, we want to avoid the usage of fixed things, such as ports, names, etc., since those introduce the anti-pattern of integrated tests that can fail depending on the state of the environment in which they are running.


yt-dlp configuration issue ???

Checklist

[X] I'm reporting a broken site
[X] I've verified that I'm running yt-dlp version 2022.06.29 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
No response
Provide a description that is worded well enough to be understood
I get a traceback whenever I try to download the video, something I probably misunderstood or something/ This is what I came up with. -

 ~/.config/yt-dlp$ cat config
--cookies ~/.mozilla/9dzivtwy.default/cookies.sqlite
 --no-keep-fragments

Please let me know if I did do any mistakes.
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
$ yt-dlp -vu -c -f 247 --write-auto-sub
[debug] Command-line config: ['-vu', '-c', '-f', '247', '--write-auto-sub']
[debug] User config "/home/shirish/.config/yt-dlp/config": ['--cookies-from-browser', 'firefox=~/.mozilla/9dzivtwy.default/cookies.sqlite', '--no-keep-fragments']

Usage: yt-dlp [OPTIONS] URL [URL...]

yt-dlp: error: unsupported browser specified for cookies: "firefox=~/.mozilla/9dzivtwy.default/cookies.sqlite". Supported browsers are: brave, chrome, chromium, edge, firefox, opera, safari, vivaldi
shirish@debian:"02 Jul 2022 19:48:16"

https://github.com/yt-dlp/yt-dlp/issues/4239#issuecomment-1172289573

I actually used what you shared but it doesn't work :( -
https://github.com/yt-dlp/yt-dlp/issues/4239#issuecomment-1172289573

I modified the configuration file and now it works -

$ yt-dlp -c -f 247 6PYl7cosPsM --write-auto-sub
[Cookies] Extracting cookies from firefox
[Cookies] Extracted xxxx cookies from firefox
[youtube] 6PYl7cosPsM: Downloading webpage
[youtube] 6PYl7cosPsM: Downloading android player API JSON
[info] 6PYl7cosPsM: Downloading 1 format(s): 247
[info] Writing video subtitles to: Diving Station _ Subsistence Gameplay _ Part 36 [6PYl7cosPsM].en.vtt
[download] Destination: Diving Station _ Subsistence Gameplay _ Part 36 [6PYl7cosPsM].en.vtt
[download] 100% of 246.26KiB in 00:00
[download] Destination: Diving Station _ Subsistence Gameplay _ Part 36 [6PYl7cosPsM].webm
[download] 100% of 293.18MiB in 00:41

$ cat config
--cookies-from-browser firefox
--no-keep-fragment


BED-4463: Implement BOM encoding package and refactor WriteAndValidateJSON for improved Unicode handling

Description
This PR introduces a robust package for handling Byte Order Mark (BOM) encoding detection and UTF conversions and refactors the WriteAndValidateJSON function to use this new package. The changes include:

Implement an Encoding interface to handle different encodings.
Precise BOM detection for UTF-8, UTF-16 (BE/LE), and UTF-32 (BE/LE).
Implementation of UTF-16 and UTF-32 to UTF-8 conversion with proper handling of surrogate pairs.
Refactoring of WriteAndValidateJSON to use the new bomenc package for BOM handling and UTF normalization.
Improved error handling and simplified logic in WriteAndValidateJSON.

Motivation and Context
This PR addresses: BED-4463
These changes are necessary to enhance our management of diverse text encodings across the codebase, especially in IO operations involving potentially BOM-prefixed content. The introduction of the bomenc package offers a more robust and comprehensive solution for handling various Unicode encodings. The refactoring of WriteAndValidateJSON leverages this package to simplify the function and enhance its versatility and reliability.
How Has This Been Tested?
Developed comprehensive test suites for the bomenc package, including:

Tests for encoding detection, conversion, and edge cases.
Tests for custom encodings and the new HasSequence method.
Tests covering various scenarios of BOM detection and removal.
Tests for UTF normalization with different input encodings.

Testing the refactored WriteAndValidateJSON function to ensure correct behavior with inputs of various encodings and with/without BOMs.
Types of changes

New feature (non-breaking change which adds functionality)
Chore (a change that does not modify the application functionality)

Checklist:

[x] I have met the contributing prerequisites

Assigned myself to this PR
Added the appropriate labels
Associated an issue: https://github.com/SpecterOps/BloodHound/issues/672
Read the Contributing guide: https://github.com/SpecterOps/BloodHound/wiki/Contributing

[x] I have ensured that related documentation is up-to-date

Open API docs
Code comments (GoDocs / JSDocs)

[x] I have followed proper test practices

Added/updated tests to cover my changes
All new and existing tests passed

I have read the CLA Document and I hereby sign the CLA

@zinic here's my finding for the alternative:
func utf16ToUTF8Alternative(data []byte, bigEndian bool) ([]byte, error) {
	var u16s []uint16
	for i := 0; i < len(data); i += 2 {
		if bigEndian {
			u16s = append(u16s, binary.BigEndian.Uint16(data[i:i+2]))
		} else {
			u16s = append(u16s, binary.LittleEndian.Uint16(data[i:i+2]))
		}
	}

	runes := utf16.Decode(u16s)
	var buf []byte
	for _, r := range runes {
		b := make([]byte, utf8.RuneLen(r))
		utf8.EncodeRune(b, r)
		buf = append(buf, b...)
	}
	return buf, nil
}

func utf32ToUTF8Alternative(data []byte, bigEndian bool) ([]byte, error) {
	var buf []byte
	for i := 0; i < len(data); i += 4 {
		var r rune
		if bigEndian {
			r = rune(binary.BigEndian.Uint32(data[i : i+4]))
		} else {
			r = rune(binary.LittleEndian.Uint32(data[i : i+4]))
		}

		// Check if the rune is a valid Unicode code point
		if r > unicode.MaxRune || (r >= 0xD800 && r <= 0xDFFF) {
			r = unicode.ReplacementChar
		}

		b := make([]byte, utf8.RuneLen(r))
		utf8.EncodeRune(b, r)
		buf = append(buf, b...)
	}
	return buf, nil
}

bench_1.txt
bench_2.txt
bench_3.txt
bench_4.txt
bench_5.txt
goos: darwin
goarch: arm64
pkg: github.com/specterops/bloodhound/boomenc
                         │ bench_1.txt  │            bench_2.txt             │            bench_3.txt             │            bench_4.txt             │            bench_5.txt             │
                         │    sec/op    │    sec/op     vs base              │    sec/op     vs base              │    sec/op     vs base              │    sec/op     vs base              │
UTF16ToUTF8                3.297µ ± ∞ ¹   3.214µ ± ∞ ¹       ~ (p=0.056 n=5)   3.200µ ± ∞ ¹  -2.94% (p=0.008 n=5)   3.211µ ± ∞ ¹       ~ (p=0.087 n=5)   3.261µ ± ∞ ¹       ~ (p=0.151 n=5)
UTF16ToUTF8-2              2.420µ ± ∞ ¹   2.429µ ± ∞ ¹       ~ (p=0.802 n=5)   2.419µ ± ∞ ¹       ~ (p=0.540 n=5)   2.417µ ± ∞ ¹       ~ (p=0.810 n=5)   2.433µ ± ∞ ¹       ~ (p=0.206 n=5)
UTF16ToUTF8-4              2.409µ ± ∞ ¹   2.402µ ± ∞ ¹       ~ (p=0.071 n=5)   2.413µ ± ∞ ¹       ~ (p=0.246 n=5)   2.405µ ± ∞ ¹       ~ (p=0.302 n=5)   2.407µ ± ∞ ¹       ~ (p=0.667 n=5)
UTF32ToUTF8                3.031µ ± ∞ ¹   3.049µ ± ∞ ¹  +0.59% (p=0.016 n=5)   3.012µ ± ∞ ¹  -0.63% (p=0.008 n=5)   3.041µ ± ∞ ¹       ~ (p=0.063 n=5)   3.017µ ± ∞ ¹  -0.46% (p=0.008 n=5)
UTF32ToUTF8-2              2.241µ ± ∞ ¹   2.251µ ± ∞ ¹  +0.45% (p=0.032 n=5)   2.248µ ± ∞ ¹       ~ (p=0.159 n=5)   2.247µ ± ∞ ¹       ~ (p=0.437 n=5)   2.244µ ± ∞ ¹       ~ (p=0.881 n=5)
UTF32ToUTF8-4              2.229µ ± ∞ ¹   2.226µ ± ∞ ¹       ~ (p=0.587 n=5)   2.227µ ± ∞ ¹       ~ (p=0.667 n=5)   2.226µ ± ∞ ¹       ~ (p=0.690 n=5)   2.228µ ± ∞ ¹       ~ (p=0.849 n=5)
UTF16ToUTF8Alternative     7.600µ ± ∞ ¹   7.544µ ± ∞ ¹       ~ (p=0.421 n=5)   7.538µ ± ∞ ¹       ~ (p=0.460 n=5)   7.498µ ± ∞ ¹       ~ (p=0.095 n=5)   7.587µ ± ∞ ¹       ~ (p=0.841 n=5)
UTF16ToUTF8Alternative-2   7.194µ ± ∞ ¹   7.148µ ± ∞ ¹       ~ (p=0.095 n=5)   7.161µ ± ∞ ¹       ~ (p=0.238 n=5)   7.143µ ± ∞ ¹       ~ (p=0.206 n=5)   7.209µ ± ∞ ¹       ~ (p=1.000 n=5)
UTF16ToUTF8Alternative-4   7.151µ ± ∞ ¹   7.170µ ± ∞ ¹       ~ (p=0.841 n=5)   7.180µ ± ∞ ¹       ~ (p=0.310 n=5)   7.149µ ± ∞ ¹       ~ (p=0.730 n=5)   7.166µ ± ∞ ¹       ~ (p=0.548 n=5)
UTF32ToUTF8Alternative     1.058µ ± ∞ ¹   1.037µ ± ∞ ¹  -1.98% (p=0.008 n=5)   1.047µ ± ∞ ¹       ~ (p=0.127 n=5)   1.039µ ± ∞ ¹  -1.80% (p=0.008 n=5)   1.035µ ± ∞ ¹  -2.17% (p=0.008 n=5)
UTF32ToUTF8Alternative-2   1.020µ ± ∞ ¹   1.022µ ± ∞ ¹       ~ (p=0.119 n=5)   1.031µ ± ∞ ¹       ~ (p=0.135 n=5)   1.018µ ± ∞ ¹       ~ (p=0.389 n=5)   1.018µ ± ∞ ¹       ~ (p=0.095 n=5)
UTF32ToUTF8Alternative-4   1.018µ ± ∞ ¹   1.022µ ± ∞ ¹  +0.39% (p=0.008 n=5)   1.023µ ± ∞ ¹       ~ (p=0.095 n=5)   1.019µ ± ∞ ¹       ~ (p=0.317 n=5)   1.019µ ± ∞ ¹       ~ (p=0.619 n=5)
geomean                    2.659µ         2.650µ        -0.34%                 2.651µ        -0.30%                 2.645µ        -0.54%                 2.652µ        -0.26%
¹ need >= 6 samples for confidence interval at level 0.95

                         │  bench_1.txt  │              bench_2.txt              │              bench_3.txt              │              bench_4.txt              │              bench_5.txt              │
                         │     B/op      │     B/op       vs base                │     B/op       vs base                │     B/op       vs base                │     B/op       vs base                │
UTF16ToUTF8                3.938Ki ± ∞ ¹   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF16ToUTF8-2              3.938Ki ± ∞ ¹   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF16ToUTF8-4              3.938Ki ± ∞ ¹   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8                3.938Ki ± ∞ ¹   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8-2              3.938Ki ± ∞ ¹   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8-4              3.938Ki ± ∞ ¹   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   3.938Ki ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF16ToUTF8Alternative     12.28Ki ± ∞ ¹   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF16ToUTF8Alternative-2   12.28Ki ± ∞ ¹   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF16ToUTF8Alternative-4   12.28Ki ± ∞ ¹   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²   12.28Ki ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8Alternative       352.0 ± ∞ ¹     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8Alternative-2     352.0 ± ∞ ¹     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8Alternative-4     352.0 ± ∞ ¹     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²     352.0 ± ∞ ¹       ~ (p=1.000 n=5) ²
geomean                    2.844Ki         2.844Ki        +0.00%                   2.844Ki        +0.00%                   2.844Ki        +0.00%                   2.844Ki        +0.00%
¹ need >= 6 samples for confidence interval at level 0.95
² all samples are equal

                         │ bench_1.txt │             bench_2.txt             │             bench_3.txt             │             bench_4.txt             │             bench_5.txt             │
                         │  allocs/op  │  allocs/op   vs base                │  allocs/op   vs base                │  allocs/op   vs base                │  allocs/op   vs base                │
UTF16ToUTF8                6.000 ± ∞ ¹   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF16ToUTF8-2              6.000 ± ∞ ¹   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF16ToUTF8-4              6.000 ± ∞ ¹   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8                6.000 ± ∞ ¹   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8-2              6.000 ± ∞ ¹   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8-4              6.000 ± ∞ ¹   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²   6.000 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF16ToUTF8Alternative     517.0 ± ∞ ¹   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF16ToUTF8Alternative-2   517.0 ± ∞ ¹   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF16ToUTF8Alternative-4   517.0 ± ∞ ¹   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   517.0 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8Alternative     105.0 ± ∞ ¹   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8Alternative-2   105.0 ± ∞ ¹   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²
UTF32ToUTF8Alternative-4   105.0 ± ∞ ¹   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²   105.0 ± ∞ ¹       ~ (p=1.000 n=5) ²
geomean                    37.39         37.39        +0.00%                   37.39        +0.00%                   37.39        +0.00%                   37.39        +0.00%
¹ need >= 6 samples for confidence interval at level 0.95
² all samples are equal

Benchmark Results

UTF-16 to UTF-8 Conversion:
Original implementation (UTF16ToUTF8):

Average time: ~3.2-3.3 µs/op
Memory allocation: 4032 B/op
Allocations: 6 allocs/op

Alternative implementation (UTF16ToUTF8Alternative):

Average time: ~7.5-7.6 µs/op
Memory allocation: 12576 B/op
Allocations: 517 allocs/op

Analysis: The original implementation is significantly faster (more than 2x) and uses less memory than the alternative. It also has far fewer allocations, which contributes to its better performance.

UTF-32 to UTF-8 Conversion:
Original implementation (UTF32ToUTF8):

Average time: ~3.0-3.1 µs/op
Memory allocation: 4032 B/op
Allocations: 6 allocs/op

Alternative implementation (UTF32ToUTF8Alternative):

Average time: ~1.0-1.1 µs/op
Memory allocation: 352 B/op
Allocations: 105 allocs/op

Analysis: Interestingly, the alternative implementation for UTF-32 to UTF-8 is faster (about 3x) than the original. It also uses less memory but with more allocations.

CPU Core Scaling:
In general, when running tests with 1, 2, and 4 CPU cores, performance needs to improve more when increasing the number of cores, suggesting that these operations are not highly parallelizable or that the overhead of parallelization outweighs the benefits for these specific tasks.

Consistency:
The results are consistent across the five runs, with only slight variations in timing suggesting that the benchmarks are reliable and the performance characteristics are stable.

Memory and Allocations:
For each implementation, the memory usage and number of allocations remain constant across different runs and core counts.

Conclusions:

For UTF-16 to UTF-8 conversion, the original implementation is superior in speed and resource usage.
For UTF-32 to UTF-8 conversion, the alternative implementation is faster and uses less memory, making it the better choice despite having more allocations.
These operations benefit only a little from multiple CPU cores, at least not in their current implementation.
The original implementations perform consistently across UTF-16 and UTF-32 conversions, while the alternative implementations have very different characteristics between UTF-16 and UTF-32.

Recommendations:

Stick with the original implementation for UTF-16 to UTF-8 conversion.
Consider using the alternative implementation for UTF-32 to UTF-8 conversion, but profile in real-world scenarios to ensure the increased number of allocations doesn't cause issues (e.g., increased GC pressure).
If you need to optimize further, focus on reducing allocations, especially in the alternative implementations.
Given the lack of improvement with multiple cores, don't prioritize parallelization for these specific operations.

These benchmarks provide valuable insights into the performance characteristics of your UTF conversion implementations, allowing you to make informed decisions about which methods to use in your application.
Original Implementations (using bitwise operations):
Pros:

Compact code: The implementations are generally more concise.
Direct control: Provides fine-grained control over the conversion process.
No dependencies: Don't rely on additional standard library packages beyond the basics.
Consistent approach: Using similar logic for UTF-16 and UTF-32 conversions.

Cons:

Readability: Bitwise operations can be more complex to read and understand, especially for developers who need to become more familiar with low-level operations.
Error-prone: Bit manipulation is susceptible to subtle errors that can be difficult to spot.
Limited built-in safety: Lacks some built-in safety checks with standard library functions.
Harder to modify: Log changes might require careful consideration of the bit-level operations.

Alternative Implementations (using standard library functions):
Pros:

Readability: Generally easier to understand at a glance, especially for developers familiar with Go's standard library.
Built-in safety: Standard library functions often include built-in checks and safeguards.
Standardization: Uses well-tested and widely-used standard library functions.
Easier to modify: Logic changes can often be made by adjusting function calls rather than rewriting bit manipulations.

Cons:

Less control: It relies on the behavior of standard library functions, which may only sometimes perfectly align with specific needs.
Potential overhead: This may include unnecessary checks or operations for the specific use case.
More verbose: This can result in more extended code, especially when chaining multiple standard library function calls.
Dependency on the standard library: Changes to the standard library in future Go versions could affect the code.

General Observations:

Consistency: The original implementations have a more consistent approach between UTF-16 and UTF-32, while the alternative implementations differ more significantly.
Learning curve: The original implementations require a deeper understanding of Unicode and bitwise operations, while the alternative implementations rely more on knowledge of Go's standard library.
Documentation needs: The original implementations likely require more detailed comments explaining the bitwise logic, while the alternative implementations might be more self-documenting.
Testing: The alternative implementations might be more straightforward to test in isolation, as they rely on standard library functions that are already well-tested.
Flexibility: The original implementations might be more flexible for handling edge cases or specific optimizations, while the alternative implementations are more rigid but potentially more robust for general cases.

Regarding maintainability, these approaches often depend on the team's expertise, the project's specific requirements, and the expected frequency and nature of future modifications. The alternative implementations might be more maintainable in a general sense, especially for teams more familiar with Go's standard library. However, the original implementations could be more maintainable in the long run for teams with low-level programming expertise or projects with particular performance requirements.


Refactor the Count.css ✨

Issue Description:
I have made significant improvements to the CSS code in our project to optimize the code and enhance its readability and maintainability. The changes I made are as follows:

Combined multiple gradient classes (.bx-1, .bx-2, .bx-3, .bx-4) into single classes with pseudo-elements for code optimization. This optimization reduces redundancy and helps in better code management.

Reorganized the CSS rules and properties to improve readability and maintainability. The styles are now grouped logically, making it easier for developers to locate and modify specific components.

Removed unnecessary comments and duplicated styles. By eliminating clutter and redundant code, the CSS file is now cleaner and more concise.

Adjusted spacing and indentation for better code formatting. Consistent indentation ensures a uniform and aesthetically pleasing appearance, making the code easier to read and understand.

Grouped related styles together for better organization. Styles that apply to the same elements are now grouped together, making it easier to identify and manage styles for specific components.

These changes significantly enhance the overall code quality, making it easier for developers to maintain and extend the project in the future. It also improves the performance of the application by reducing redundant CSS rules and optimizing the rendering of gradient backgrounds.
Please review the changes and let me know if you have any feedback or suggestions for further improvements. Once the changes are approved, we can merge them into the main codebase, ensuring a more efficient and maintainable project going forward.

Hey @Vaishnavi-Patil2211  Please assign me this issue


Create release to update dependencies

We are using this action and get a deprecation warning of node 16. If I'm right the only step missing is the release as main already is updated to node 20. Could you please consider creating a new release, Thanks.

Hi @adlerhurst - v1.1.1 is now available, appreciate your patience!


Workbench asks me to sign into Settings Sync after startup, on some windows only

Restart VS Code

🐛 Sometimes, some windows report that I need to sign in, yet that goes away quickly.
🐛 Other times, some windows report that I need to sign in and that notifications sticks around. Other windows of the same profile, though, appear signed in.

https://github.com/user-attachments/assets/28516791-250f-4140-bad0-ebc486f4cbab

/duplicate
https://github.com/microsoft/vscode/issues/232516


test PR with Github API

Please pull this in!

Docs Build status updates of commit 893f307:
:warning: Validation status: warnings

File
Status
Preview URL
Details
Dependent Files

sdp-test/page-model-documents/Tutorial.yml
:warning:Warning

Details

sdp-test/page-model-documents/Tutorial.yml

[Warning] Unable to find uid "challenge-uid".

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit dea197d:
:warning: Validation status: warnings

File
Status
Preview URL
Details
Dependent Files

sdp-test/page-model-documents/Tutorial.yml
:warning:Warning

Details

sdp-test/page-model-documents/Tutorial.yml

[Warning] Unable to find uid "challenge-uid".

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


⚠ CIOOS Pacific ERDDAP dataset DFO_MEDS_BUOYS has degraded performance

In 26b32a7, CIOOS Pacific ERDDAP dataset DFO_MEDS_BUOYS (https://data.cioospacific.ca/erddap/tabledap/DFO_MEDS_BUOYS.htmlTable?STN_ID&time>=now-1week&distinct()) experienced degraded performance:

HTTP code: 503
Response time: 17283 ms

Resolved: CIOOS Pacific ERDDAP dataset DFO_MEDS_BUOYS performance has improved in ca9b344.


Cleanup

Lots of whitespace and variable name changes, but no functionality should have changed. Tests and benchmark results stayed the same AFAICT. I didn't added much in the way of comments.
One last nit: I don't really like having almost-identical functions cubic_farthest_fit and _cubic_farthest_fit. Removing _cubic_farthest_fit does add running time (~5-10%?) but personally I don't think it's worth it in this case.

One last nit: I don't really like having almost-identical functions cubic_farthest_fit and _cubic_farthest_fit. Removing _cubic_farthest_fit does add running time (~5-10%?) but personally I don't think it's worth it in this case.

I have one more thing to optimize to use the _cubic... version, and gives another small boost.  So I'll add that and rename it to be more useful.


[beta] incomplete error messages in popups

See this example:

Possibly related to the presence of a single quote char?

I thought this had been fixed already?

We html escpape all error messages, makes me wonder how this bug comes into being then.

@FichteFoll I'm on the SL available through package control, wouldn't know how to check the version. On ST 3143 if that helps.

You can check with the "Package Control: List  Packages" command. There have definitely been a few releases since that commit.

Turns out it's 4.0.0-rc.9

Release candidates are tagged after I test new contributions, tagged versions should propagate through package control within a few hours. And updates via package control are only installed on restart. So, we’re pushing updates out regularly, but they might not land on your end immediately.
I really appreciate everyone who takes the time to have a look and report possible issues though. 👍🏻


Overlapping multi-word phrases break text representation

When two bigrams from the gazetteer overlap in the text, the text representation of the first one is broken. Consider the following code:
import spacy.en
import spacy.matcher
from spacy.attrs import ORTH, TAG, LOWER, IS_ALPHA, FLAG63

patterns = [
    [{LOWER: 'food'}, {LOWER: 'safety'}],
    [{LOWER: 'safety'}, {LOWER: 'standards'}],
]

nlp = spacy.en.English(tagger=False, parser=False, load_vectors=False)

nlp.matcher.add('FOOD', 'FOOD', {}, patterns)

docs = nlp('There are different food safety standards in different countries.')

for e in docs.ents:
    print(e.text, e.label_)

Output:
>>> food FOOD
>>> safety standards FOOD

Thanks! I'll take a look at this next week.

Sorry for leaving this to sit for so long.
There's really a deeper design problem here that I should've seen sooner. The code is all doing the right thing.
The problem is that the Matcher class automatically sets named entity annotations, but the named entity annotations don't allow overlapping entities. The lack of overlapping entities is not ideal, but it's a standard limitation, and not so problematic. But the Matcher class is useful for lots of other situations --- it's a generic way to recognise contiguous sequences of tokens.
I think the Matcher class shouldn't set entity annotations. It should just return Span objects.

I agree. In fact, I am using it at the moment for a few separate groups of annotations, which have to be loaded in separate objects because the overlap. It would be nice to make the overlap optional though because picking the longest match is sometimes desirable. Thoughts?

This is finally fixed in 1.0 — the matcher returns a sequence of (ent_id, label_id, start, end) tuples, and you can associate an on_match and/or acceptor callback with each entity ID. The on_match callback is only called after all matches are collected. The callback takes 4 arguments: the matcher, the doc, the index of the match to handle, and the list of matches. This allows the user to resolve the matches considering the total set of matches.


Update patterns that our compiler will complain about.

Calling getClass() is likely to return an internal Proxy class (ie
com.sun.proxy.$Proxy1) so use annotationType() instead.
Assignment in an if statement is ambiguous so wrap in parens to make it
obvious that it's intended.
This are things that our compiler will fail on.

Codecov Report

Merging #1236 into master will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##             master    #1236   +/-   ##
=========================================
  Coverage     94.25%   94.25%
  Complexity      455      455
=========================================
  Files             2        2
  Lines          6689     6689
  Branches       1799     1799
=========================================
  Hits           6305     6305
  Misses          106      106
  Partials        278      278

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/picocli/CommandLine.java
94.09% <100.00%> (ø)
314.00 <0.00> (ø)

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 6ae8009...cc4ef4a. Read the comment docs.

Merged.
Thank you for the contribution!


Add Feature: Alternative Flag Timer Materials

Brief Description:

Add alternative flag timer materials. Granular intervals can be achieved as originally suggested by adding multiple entries to the config. For example, 3 entries of ancient debris, 5 of obsidian, and a flag length of 8 minutes would satisfy the example in the original suggestion.

Changes:

Changes in FlagWarConfig.java:

Add logger to FlagWarConfig

Used in #getCustomTimerBlocks()

Move old classic wool TIMER_MATERIALS to DEFAULT_TIMER_MATERIALS
Add boolean #isUsingDefaultTimerBlocks

Used in new TIMER_MATERIALS
Checks config boolean value "timer_blocks.use_default"

Add new TIMER_MATERIALS

Checks value of #isUsingDefaultTimerBlocks()

If true, is set to DEFAULT_TIMER_MATERIALS
If false, is set to #getCustomTimerBlocks()

Add #getCustomTimerBlocks()

Gets list of materials from config.yml, timer_blocks.blocks

If the list is missing, will return null as default value.
An error will be logged and DEFAULT_TIMER_MATERIALS is returned.

If list is not null, attempts to convert each entry to a Material

If all entries are valid, the custom material list is returned
If one or more entries are invalid, an error is logged and the default list is returned.

Changes in config.yml

Add section: timer_blocks

Add timer_blocks.use_default

If true, will use classic wool timer blocks.
If false, blocks list will be used.

Add timer_blocks.blocks

List of materials to be used if use_default is false.
Must be a valid Bukkit Material.
Case-insensitive.
A sample palette of terracotta is included.

Relevant FlagWar Issue tickets:

Closes #5

[x] I have tested this pull request for defects on a server.

By making this pull request, I represent that I have read and agree to release my own changes that I
have submitted under the terms of the accompanying license (Apache-2.0). I guarantee that these
changes are mine and are not encumbered by any other license or restriction to the best of my
knowledge.

Hey, thanks for the contribution. I'll check it out this evening when I get off work.


Clang toolchain does not work from Android Studio

Specifying stl = 'c++_static' and toolchain = 'clang' with:

Android Studio 1.5.1 or 2.0 or 2.1 beta
NDK 10e or 11c
Gradle 2.10
plugin 0.6.0 or 0.7.0 beta1
results in bogus errors (mostly about incomplete -x parameters passed to the compiler when you try to build the project) both in my 'private' projects and in freshly imported 'googlesamples'...
Using Clang+libc++ through the 'old fashioned' NDK_BUILD works OK...

("interesting" considering that GCC is deprecated and Clang should be the default...yet it not only isn't the default, it does not work)...

maybe you are on windows?
there is a bug when android studio/gradle generating clang compile options, so clang on windows build is busted [ for a long while and still is]. Good thing is that this is brought up as urgent thing, it will be fixed soon and those samples should be updated accordingly then
On Mac build, clang seems to be ok to me, but could not enable -Wall -Werror, because clang throws warning about "inline"; I tried to use -Wall -Werror with gcc, correct all errors and then change back to clang AND remove -Wall -Werror.
hope this helps

clang is re-enabled with 0.7.0-rc1 ( will update to 0.7.0 soon ); so this is ok now.  I think we are more leaning toward gnustl_static/shared now, and recommending thorough validation when using c++_static/shared.  close this one, reopen if you still see the problem.


Add --face-list flag

Reference Issues/PRs
#55
What does this implement/fix? Explain your changes.
Added the --face-list flag, showing all available faces for showing the time.
Any other comments?

Thanks for your efforts.
Your dev was not originated from sepandhaghighi:dev, please solve the conflicts by either merging sepandhaghighi:dev or redo the process this time extracting branch from sepandhaghighi:dev instead of sepandhaghighi:master.