Remove  tag inserted by Nokogiri.

This pull request removes the <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> inserted by Nokogiri, which makes nanoc check html fail.
It's a wontfix for Nokogiri (sparklemotion/nokogiri#1008).

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> shouldn’t cause the HTML to be invalid. I can’t reproduce the issue locally. Can you show me how it fails?

In combination with a meta charset tag (as one would typically do in an
HTML5 document), it gives an error.
You can see this with the default Nanoc template.

Nokogiri doesn’t support HTML5, so this is expected behavior.
Ideally, Nanoc would use Nokogumbo, but I’ve had trouble getting that one to work, and I believe it’s incompatible with JRuby as well.
If you need the meta tag removed, you could write a filter that removes the <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">.

That's what I do now, but it kind of seems a pity that a default Nanoc
filter doesn't support the latest HTML version, and that this filter
produces invalid HTML with the default init site.

https://github.com/DeSemWeb/ISWC2017/blob/master/lib/better_relativize_paths.rb

That's because you're running relativize_paths after items are laid out right?

Yes; I also need it to apply to stylesheet and script links from the
template.

Take a look at #1153, which uses Nokogumbo (a HTML5 parser) instead of Nokogiri, and thus avoids the meta problem.

Perfect, let's follow up there.


Instruction for running on Multiple Nodes / Machines

Hi, are there any instructions for how to run the code on multiple machines or nodes? I did not see the configuration or starting command for running on multiple nodes. Thanks.

You can simply follow the scripts in my experiments.
https://github.com/OpenGVLab/UniFormerV2/blob/d390105e588665af5029bfcceed5b9975d4b13bb/exp/k400/k400%2Bk710_l14_f16x224/run.sh#L1-L29
In our training, we use slurm to start training before python
srun -p video
-n$NUM_SHARDS
--gres=gpu:$NUM_GPUS
--ntasks-per-node=1
--cpus-per-task=$((NUM_CPU*NUM_GPUS)) \
--job-name ${JOB_NAME} \
python tools/run_net_multi_node.py \
......

Thanks for your reply. I am wondering how I can use master_port and master_addr to specify the multi-node training since I have no experience with slurm?

You do not need to set master_port and master_addr . It has been set in code
https://github.com/OpenGVLab/UniFormerV2/blob/d390105e588665af5029bfcceed5b9975d4b13bb/tools/run_net_multi_node.py#L31-L33

Besides, you can also use submitit to run the process on multiple nodes.
The TimeSformer codebase, which is also based on SlowFast, provide some instructions here.

BTW, if you want to develop your research based on pretrained UniFormerV2, you can also follow my PR for MMAction2. Thus you can use MMAction2 for multiple nodes.

Thank for your detailed answer!


add config option for httpRealm and note that it must match viewer

Add line to indicate httpRealm setting and that it must match what Viewer uses as set in config.pl.
I confirm that this contribution is made under an Apache 2.0 license and that I have the authority necessary to make this contribution on behalf of its copyright owner.

sorry took so long, i missed this


Provide better Typescript definition files

Hi Prismic folks :)
I'm trying to use the nodejs package with its bundled d.ts files.
However, types are not properly imported when using the module.
It comes from several facts:

First, this comes from the way the module is declared, ie. using a namespace. declare namespace Prismic {...} & export = Prismic;. Only what is in the namespace is visible if i'm not mistaken.
As a library, the barel file (index.d.ts) should re-export all public APIs. When fetching the api object with Prismic.getApi(...), I cannot write the proper response type since the PrismicApi type is hidden in the namespace.

It could be better to change the namespace to a plain object while re-exporting all sub modules. This way, both the Prismic object and all APIs are visible.
Last but not the least, a little quote from the TS documentation :

Exporting a namespace from your module is an example of adding too many layers of nesting. While namespaces sometime have their uses, they add an extra level of indirection when using modules. This can quickly become a pain point for users, and is usually unnecessary.

What do you guys think ?

with Angular 5 I get an outright error:
ERROR in src/app/prismic/prismic.service.ts(3,8): error TS1192: Module '"/node_modules/prismic-javascript/d.ts/index"' has no default export.

Hi @nimaen, sorry for the delay but we will try our best to look at this as soon as we are able.

I agree. Interfaces and Classes cannot be imported and it could be nice to have them exported in order not to keep using any everywhere (including the api client)

@mattiascibien but this violates the tslint rule no-submodule-imports:

+1

with typescript > 2.8 this should work
import * as Prismic from 'prismic-javascript'

type ThenArg<T> = T extends Promise<infer U> ? U : T
type PrismicAPIPromise = ReturnType<typeof Prismic.getApi>
type PrismicAPI = ThenArg<PrismicAPIPromise>

Unfortunately this is still open. I guess the issue could be resolved for many of us if d.ts/index.d.ts would also export the other parts of the declaration files, for example ResolvedApi.d.ts.
Now with Angular 9, the compiler issues a warning about the deep import paths, for example here: https://github.com/exportarts/ngx-prismic/issues/109.
I wonder if there is even still the need for separate d.ts files since the project is written in typescript anyway. What do you think?

Any updates here?

The example here: https://prismic.io/docs/reactjs/getting-started/prismic-nextjs#28_0-pass-the-preview-ref-to-all-of-your-pages even throws type errors. Is there any plans to get things lined up?

Perhaps this could be a naive approach, but I encountered this issue as well. I modified the types/index.d.ts accordingly in order to successfully use Prismic 3.0.2 with typescript. Here is a gist with the updated file that I'm using. and I import it using import * as Prismic from "prismic-javascript"
If anyone has any suggestions for making that more correct please chime in!

If anyone is interested, I made some modifications to the index.d.ts definitions in order to use Prismic 3.0.2 with typescript. Here is a gist of my changes. You can use it in a couple ways. You an import everything via import * as Prismic from 'prismic-javascript' and then do the usual instantiation with Prismic.client(...) and query via client.query(Prismic.Predicates.at("document.type", "blog01")), or you can import just what you need like import { client, Predicates } from 'prismic-javascript'
Hopefully this helps people, and if anyone has suggestions on making it cleaner please let me know!

When using import * as Prismic from 'prismic-javascript' types are not correctly detected and when using import Prismic from 'prismic-javascript' I get undefined errors. Why not simply use named exports? From my experience default exports are a very bad practice that lead to a lot of problems.

Hey @DaSchTour, I'm sorry you ran into those issues, we're aware that TypeScript support is not ideal right now on this package.
Great news though, we're currently working on the next major of our JavaScript SDK, improving TypeScript support being one of the goals there. An alpha should land in the coming weeks, in the meantime you can stay tuned to #163 🙂

Hey! Just letting you all know that @prismicio/client v6 has since been published in alpha 🎉
It's not documented yet but the API is pretty similar, now comes with built-in tsdoc and beautiful TypeScript support, we also have examples :)
https://github.com/prismicio/prismic-javascript/tree/aa/v6/examples
It will land in stable/lastest once properly documented and tested on our side!

Fixed in v6 🎉 Thank you for your contribution!
https://prismic.io/docs/technical-reference/prismicio-client?version=v6


Add helper functions: print_warning / print_error

These functions prepend a consistend prefix and they also use colors (when enabled).
Messages are written to stderr.

Hm, I think logging and regular program output should be separate. We don't use an info-level logger to print the tldr pages either. For me, logging should be about "what the program is doing", and not be part of an end user API. On the other hand, the warning about missing cache is not something that should be hidden by a logger reconfiguration.

Having the function like this means that we need to use format! at call sites instead of having the flexibility of a eprintln or so.

Well, that's not really something we need an external library for. We can easily convert those functions to a macro. However, in the interest of getting out a release soon, I'd postpone that for now 🙂


Re-direction of UWP design

Re-direction of UWP UI design is requested as represented in this link....
https://www.behance.net/gallery/74300939/Windows-10-File-Explorer

@mkmukund Thanks for the concept. Files follows Microsoft's Fluent Design trends already. Is there anything specific from that concept you'd like to see in Files?
Please open an issue report for each one so we can evaluate their individual feasibility.

Closing this in anticipation of your issue reports.


Clear Cache Button/Reset Storage Explorer Button

Expected Experience:
Be able to reset Storage Explorer and clear all cache and settings.
Actual Experience:
Customer's get into configuration issues or machine issues and it's difficult to get into a clean state.

Start with #149

It is already there.


Add interval support

Make SQL_INTERVAL_* types of pytype PyDateTimeAPI->DeltaType
Add date string parser
Add GetDataInterval handler and associated case in GetData

hey @mkleehammer any updates on this? Thanks :)

Hey I just realised I didn't have intervals on my Vertica DB and realised I needed this patch. Can you please merge? This is great

@mkleehammer any updates on this? That would be extremely useful!

I'll need to make some tests for a database I have easy access to.  Do any of the other ODBC libraries return interval types, such as PostgreSQL?

@mkleehammer PostgreSQL has interval types: http://www.postgresql.org/docs/9.1/static/datatype-datetime.html
as does MySQL: http://dev.mysql.com/doc/refman/5.0/en/time.html

Hold on. Having a couple of git issues.

I might close this PR in favor of opening a clean one.

It looks like with the patch PostgreSQL returns a time interval string, and MySQL has a floating point exception on my system (both before and after patch).

Two discussions need to be had:
We can't use STL functions that raise exceptions without catching them and converting them.  I try to use a safe subset of C++ that isn't going to raise unexpected exceptions.  Otherwise we're going to get a crash instead of a clean exit with a Python exception.  Perhaps that is what is going on with MySQL.  Can this be done with more or less straight C?
Second, the documented ODBC interface for intervals is here: Interval Data Types.  We should be calling GetData with a SQL_INTERVAL_STRUCT and returning an error if a driver doesn't support it.
I'm not clear where the format that the read_time_token_list function is reading is coming from.  If it is just what one DB happens to read when asking for data as a string, it won't work across databases.
Thoughts?

Which STL functions are you referring to? And no, the MySQL crash happens even with a clean fork from your repository.
I think you are right regarding the string — we have developed this primarily to work with Vertica. Can we add support for databases even if the driver does not support it?

Almost all STL functions can throw exceptions, including all vector methods like push_back.  However, if you can get Vertica to return a SQL_INTERVAL_STRUCT (by asking for one in GetData) then that issue would go away anyway.  A dynamic container wouldn't be needed to parse.

Good news - #80 is simpler interval patch.  I do want to update it so it isn't available just yet.  I am, however, going to close this one.  Thank you very much for supplying something, but I think you'll like #80 just as much.


Oracle Price Endpoints / Documentation (UNI)

kevin is working on this
Documentation for validators for the steps to do the upgrade for Uni

Can vals run any endpoints so long as std divination is within reason between exchanges?

Endpoints:

Coinbase, Kraken, Osmosis
No JunoSwap

Will put in its own PR from new tracking issue


Fix regression in bookshelf preflight check

The commit 0f4ded20d740d2a771da13d7b095d4575577cbc2 removed the to_s
coercion from the Bookshelf preflight checks. However, those checks
happen before the type coercion in the library, so we still need the
string coercion there since some configs have symbols in them.
Signed-off-by: Steven Danna<EMAIL_ADDRESS>

👍 I can confirm the use case here. This also effects the current version of chef-backend-ctl gen-server-config since that generates bookshelf['storage_type'] = :sql using the symbol.

cc @chef/chef-server-maintainers

:+1: LGTM


Can't login, only gives an error [BUG]

Describe the bug
Attempting to log in gives an "exception" error written in Japanese. Translating it says "account not found". Tried logging in with 2 different accounts
To Reproduce
Steps to reproduce the behavior:
Go to account and +
Enter login details
Login
Expected behavior
Login.
Screenshots
Smartphone (please complete the following information):

Device: pixel 4a 5g

Additional info
Add any other context about the problem here.

What version of the App are you running?


A11y - OU: Form elements must have labels

Ensure every form element has a label. [https://dequeuniversity.com/rules/axe/4.10/label?application=AxeChrome|https://dequeuniversity.com/rules/axe/4.10/label?application=AxeChrome|smart-link]
h3. Element Location:
{noformat}div[data-popper-placement="bottom-end"] > .multiple-dropdown[data-no-result="No results found"] > .dropdown-item > .form-check-input[type="checkbox"]
div[data-popper-placement="bottom-end"] > .multiple-dropdown[data-no-result="No results found"] > .active.is-default.dropdown-item > .js-ou-checkbox.form-check-input[data-id=""]
div[data-popper-placement="bottom-end"] > .multiple-dropdown[data-no-result="No results found"] > .active.is-default.dropdown-item > .js-ou-checkbox.form-check-input[data-id=""]{noformat}
h3. To solve this problem, you need to fix at least (1) of the following:

Element does not have an implicit (wrapped)
Element does not have an explicit
aria-label attribute does not exist or is empty
aria-labelled by attribute does not exist, references elements that do not exist or references elements that are empty
Element has no title attribute
Element has no placeholder attribute
Element's default semantics were not overridden with role="none" or role="presentation"

!Screen Shot 2024-11-13 at 16.33.30 PM.png|width=748,height=592,alt="Screen Shot 2024-11-13 at 16.33.30 PM.png"!
!Screen Shot 2024-11-13 at 16.33.06 PM.png|width=570,height=342,alt="Screen Shot 2024-11-13 at 16.33.06 PM.png"!
!Screen Shot 2024-11-13 at 16.34.10 PM.png|width=736,height=638,alt="Screen Shot 2024-11-13 at 16.34.10 PM.png"!

[public] Shopware automated response: This issue is linked to the internal issue: NEXT-39571
[created from NEXT-39571, comment 512390]

[public]

FixVersion Change: <IP_ADDRESS>

This issue will be / was solved in Shopware version <IP_ADDRESS>.
[created from NEXT-39571, comment 521036]


New API for 1.0

I am opening the PR to prepare the 1.0 release with a cleaner API. I am already pretty happy with the state of that PR (I spent a couple of weeks working on that). Any feedback would be welcome, especially from existing users, e.g. @talex5, @kayceesrk, @avsm, @hnrgrgr, etc. but given the amount of changes, I won't except a detailed review :p
The main changes in the new API are:

no more mirage-tc to define new contents, but simpler type-based combinators based on depyt (note: I will probably just move depyt.ml inside irmin project so the combinators could be tailored for mergeable datastructures in the future)
subtrees now have first-class support in the API. No more mutable views, use immutable subtrees (with full caching and lazy writes), strongly inspired by #357 and the datakit tree API.

And lots of more minor improvement/fixes that I will document in the next few days. Check the raw diff for irmin.mli if you are impatient.
TODO:

[ ] document the changes
[ ] remove Irmin_git.LOCK => need a new release of ocaml-git to include test-and-set
[x] move core of Depyt in Irmin.Type (remove read/write, just keep jsonm converters? the goal is to add protobof converters next)

First draft for the immutable commit API pushed. Still need to address the rest of the feedback.

All the feedback have been taken into account, thanks for the reviews!
The last missing piece (that I discussed briefly with @talex5) is about avoiding the racy S.set. To address this, I have started to modify the API to implement:
  val set_tree: t -> ?allow_empty:bool -> info -> key -> (tree -> tree) ->
    unit Lwt.t
  (** [set_tree t k f] replaces {i atomically} the sub-tree [v] under
      [k] in the store [t] by the contents of the tree [f v], using
      the commit info [i]. If the subtree is modified between the
      initial tree read and the write, the transaction is aborted and
      tried again until it succeeds.

      If [allow_empty] is set (by default it is not), empty commits
      are allowed.

      {b Note:} Irmin transactions provides
      {{:https://en.wikipedia.org/wiki/Snapshot_isolation}snapshot
      isolation} guarantees: reads and writes are isolated in every
      transaction, but only write conflicts are visible on commi. *)

  val merge_tree: t -> info -> ?allow_empty:bool -> ?max_depth:int -> ?n:int ->
    key -> (tree -> tree) -> unit Lwt.t
  (** [merge_tree t i k f] is similar to {!set_tree} but try to merge
      the read and write sub-trees before aborting the transaction. *)

Thanks @samoht. Removing mirage-tc and using depyt is an excellent improvement. Looks like this could enable generic merges for arbitrary types if the changes are non-overlapping similar to merge-ropes.

I really would like to see that dynamic type library to specialise to mergeable data types - I am not sure this kind of library makes sense on its own, but I am fine to split it later when we understand the design space a bit better.


[ADD] Adding project scope

This is the first scope of this project, I'm thinking of adding more features in the future.

Nice start!
Couple of suggestions first:

Normally repo names are written under sneak case convention. That means this repo can be renamed to: bistro_management.
It is recommended in this stage to at least have the following branches: main -> qa -> dev. We don't have DevOps tools right now so we should be careful about which version is on the main branch and what is being tested.
I would suggest to create your PR against the dev branch.


Encrypt database

i have got privacy concerns....
Optional feature. Enable in preferences, set password and be prompted at startup.
simply zip database directory and use some algorithm to encrypt.

NOPE


Input does not hide the hintText when a value is entered

The Input and InputField widgets retain their hintText widget even after a text value has been entered.
See example below:

@HansMuller so you have any context here?

This functionality works fine on TextField but not on Input or InputField.  I also made sure it is inside a Material.

I don't know when this regressed. We really need a test for this behavior for all of the input widgets.

Going to bump this to M1 given the regression status and the fact that it's blocking Hoppy.  @HansMuller are you the right person to stab at this? Or maybe @jason-simmons or @Hixie?

Took a look at this and was able to show an Input/InputField clearing the hint text once its value becomes nonempty.
Note that unlike TextField, Input/InputField requires an onChanged handler that does a setState() which updates the field's value.

@abarth I see you self-assigned, but I'm not sure what the next work here is.  Do we have an update for Posse?  I'm meeting with them this afternoon. :)

@eseidelGoogle Sorry, I should have responded earlier.  I saw the bug and was planning to fix it when I rationalized the input widgets.
This should be fixed as of ae8994860e42c3eff67149282e93be47c07f9f93


No way to stop in between stage

Hi Team
build-test-staging-prod, In this example all the stages are executing one by one immediately, we need manual user testing after deploying to test and then deploy to prod, so how do we stop in between stages and start the production deployment when needed.seems like all your example is not addressing that and the example are not real world scenarios without that

This will be available soon. When it is we'll provide some more documentation on how to use manual approvals.

I where really looking forward to these new multi-stage pipelines. But without the ability to have manual approvals or other of the gating features between the stages, then its really not that useful.
So would love to know if you have any ETA on when this will be in the preview?

Without this the value of multi stage yml's is meager at best.

@Barsonax  You can make it conditional (condition works in Yaml), but you cannot have any manual interactions/approvals in your pipeline.

But what I want is conditional manual approvals

Wondering if this is what we are looking for:
https://docs.microsoft.com/en-us/azure/devops/release-notes/2019/sprint-155-update#approvals-in-multi-stage-yaml-pipelines
I just cannot see how to use it, or if it has not been made available yet.


Feature/multiple return values

DO NOT MERGE THIS
This is a first exploration on the discussion here. I have not made much attempt at making the code elegant at this point.
I have added a new pattern, the AugmentedFunction. Currently, this pattern can be used to return multiple return values, but theoretically it could be updated to also handle fallible functions. The goal would be to eventually add something similar for the service pattern, but I have left this as out of scope for the current exploration.
I have not attempted to write the back-end writers for cpython and C# yet, as I'm not experienced with creating bindings there. I have for now only shown how the C back-end would be modified.
I am having some difficulty understanding how to run all the tests. For now, I have done some basic testing inside of the hello_world example by calling cargo test there, and inspecting the generated C header file that gets generated.
I've been using cargo expand inside of the hello_world example to inspect what the proc macros are generating. In a nutshell, the idea is that clients write:
/// Function using the type.
#[ffi_function]
#[no_mangle]
pub extern "C" fn my_function3(input: Vec2) -> (i32, i32) {
    (1, 2)
}

This function will then get renamed by the macro to my_function3_interoptopus_internal. The macro will also generate another new function with the original name my_function3 that contains OUT parameters. The output of of this macro, obtained by cargo expand, for this example is currently:
/// Function using the type.
#[no_mangle]
pub extern "C" fn my_function3_interoptopus_internal(input: Vec2) -> (i32, i32) {
    (1, 2)
}

/// TODO put the documentation strings here
#[no_mangle]
pub extern "C" fn my_function3(
    input: Vec2,
    out_param_0: *mut i32,
    out_param_1: *mut i32,
) {
    let (return_value_0, return_value_1) = my_function3_interoptopus_internal(input);
    unsafe {
        *out_param_0 = return_value_0;
        *out_param_1 = return_value_1;
    }
}

For now I have not attempted to add user-defined names for the OUT parameters. This could be done by adding arguments to the ffi_function attribute macro, but has been left as an open point for now.
The header file that is generated contains the following:
void my_function3(vec2 input, int32_t* out_param_0, int32_t* out_param_1);

The function my_function3_interoptopus_internal is not exposed in the header function.
The idea is that the backend writers realise that they are dealing with an AugmentedFunction and translate the OUT parameters into something that is idiomatic for them. For instance, Python could return a tuple directly.
Note that, since the macro works with tokens and not type information, the user cannot write something like
type MultipleOutput = (f32, i32);
#[no_mangle]
pub extern "C" fn foo() -> MultipleOutput {
    todo!()
}

The macro needs to see the tuple in the token stream in order to realise that this is an augmented function with multiple return values.
At this stage I am not 100% sure whether the AugmentedFunction pattern has been hooked up properly to the writers. The function is still exposed via the function! macro. I'm not sure if this function will have to be edited, or whether the definition of FunctionInfo should be changed such that AugmentedFunction will be received by the backend writers.
Finally, fallible functions could be added to this AugmentedFunction by adding another OUT parameter representing the error type. The function would then return an enum for the success status of the function call.

Sorry for delay, few days off, will look into this once back.

Alright, I managed to have a quick look, some thoughts:

Having a transform for pub extern "C" fn my_function3(input: Vec2) -> (i32, i32) looks great!
That is works with a vanilla #[ffi_function] is a bit too magic IMO. I think a plain ffi_function should only enable a function to be exported. To transform output to input parameters should probably be handled by another annotation.
I'm not sure yet what's the best way for annotating that would be. For example ffi_service is a 'pattern annotation' (and as such it's implied that it may generate or transform methods), while ffi_function so far is only a marker annotation. That said this distinction might only exist in my head, and from a UX perspective maybe ffi_function should 'just work' ... What do you think?
Once implemented for real this probably needs a whole bunch of unit tests (e.g., using generics, lifetimes in return types, custom opaque pointer returns, ...).
I'm not sure this pattern is a TypePattern ... I mean, it sort of is, but also the actual pattern is also a function transformation, which in turn would open the can of worms of having a new pattern type ...

About your comments:

I am having some difficulty understanding how to run all the tests

Yeah ... it's a bit of a mess. Ideally you have dotnet and python installed, then cargo test should actually run the tests. In addition there are a few tests that rely on .expected files which, if changed, can be regenerated with the scripts. Feel free to reach out if you need help.

I've been using cargo expand inside of the hello_world example to inspect what the proc macros are generating

Many attributes (should be all, but I might not have come around) should have a debug flag to help with that, although the formatting often gets messy.


Create maricopa.txt

Add Maricopa

@madasu Regrettably, this domain cannot be added. Please see #2393 for more details. Thank you for your understanding.


Can't build BioGears docker container using existing codebase

I have a goal of building a BioGears container which includes some other software I'm building. This prevents me from using the stock BioGears container which is also about a year old.
So I tried using the Dockerfiles referenced on the Docker Hub page for BioGears.
The release Dockerfile referenced depends on biogears-external. However, biogears-external does not appear on https://hub.docker.com/u/biogears . Attempting to pull that image results in unauthorized access.
Additionally, the second line in the above Dockerfile proceeds to issue RUN git clone https://github.com/BioGearsEngine/core.git && mkdir core/build which is potentially problematic as it pulls the latest version of the code posted on Github which may not be stable.
So I tried to build a new Dockerfile which essentially combines what the biogears-external Docker file does with what the release docker file proceeds to do:
FROM ubuntu:18.04
RUN apt update && apt -y install git wget ninja-build libncurses5-dev build-essential g++ automake libeigen3-dev liblog4cpp5-dev libxerces-c-dev

WORKDIR /root/src
RUN wget https://cmake.org/files/v3.12/cmake-3.12.0-rc3.tar.gz && tar -xf cmake-3.12.0-rc3.tar.gz && wget https://www.codesynthesis.com/download/xsd/4.0/linux-gnu/x86_64/xsd_4.0.0-1_amd64.deb && dpkg -i xsd_4.0.0-1_amd64.deb
WORKDIR /root/src/cmake-3.12.0-rc3
RUN ./bootstrap --parallel=4 --prefix=/usr/local && make -j4 && make install
WORKDIR /opt/biogears

RUN git clone https://github.com/BioGearsEngine/core.git && mkdir core/build
WORKDIR core/build
RUN cmake -DCMAKE_INSTALL_PREFIX=/opt/biogears/usr -DARA_Biogears_BUILD_JAVATOOLS=OFF -DARA_Biogears_BUILD_HOWTOS=ON -DCMAKE_BUILD_TYPE=Release .. && make -j4
WORKDIR runtime

This results in a compiler error. I'm investigating whether it was an out of memory issue. In the meantime could someone confirm whether the above docker file should work given the current code base in master?

I'm using the Docker Desktop on Mac. Docker engine version: 18.09.2 . By default I had 2GB of memory allocated to the local docker engine. Increasing the memory limit to 8 GB has solved the build problem.  The Docker file I posted above successfully builds BioGears.  The only change I'd make to my Docker file is perhaps changing this line : RUN git clone https://github.com/BioGearsEngine/core.git && mkdir core/build to pull a known release rather than latest.  That would ensure that a docker image would correspond with a known BioGears release.

Thanks for your comment, and sorry for the delayed response. We recommend having at least 5GB of disk space allocated to building BioGears, that was likely what caused your previous issue.

@LucasJMO No worries - thanks for such an awesome project! I'm excited to continue my journey with BioGears. Please feel free to close this ticket.


l4t 32.2 integration

Hey Matt, not an actual issue more like a question, are you planning to bring in the new l4t 32.2 too? I know it's just been released end of last week but wanted to know if you have any estimate of a wip branch or anything.
Thanks a lot!

Yep, it's in the works. Once I'm a bit further along, I'll push a branch with the work in progress.  Can't promise a particular timeline, but hopefully within the next week or so.

Sounds great, thank you!


chore: Upgrade electron and upgrade vulnerable dependencies

Upgrade electron - https://github.com/electron/electron/releases/tag/v10.4.1
Upgrade vulnerable dependencies - npm audit fix

@adlk Please check.


Added option to enable CacheDB Module with Redis backend

Added option to enable CacheDB Module with Redis backend.
How to use:
The Cache DB module must be configured in the (unbound.conf) module-config: directive, e.g.: module-config: "validator cachedb iterator"
Additionally, must be created cachedb.conf file under custom.conf.d directory with Redis credentials.
Resolves: https://github.com/klutchell/unbound-docker/issues/372

Thanks for the contribution! Your changes should be available in the main tag shortly!


Can't add package into the progect

Hello!
First Vortex looks great! I tried to use it but couldn't finally. An error occurs on adding it to the project. Please look at pictures enclosed.
Xcode Version 14.2 (14C18)
Target iOS 16.2
MacOS 12.7.2. Monterey

Your Xcode version is too old. Although you can target older versions of macOS, I'm not able to support older versions of Swift.

Ok, Thanks! I was supposing that reason. Anyway thank your for your great job! Will try it on my ne Mac obligatory!


Made bouncycastle dependencies optional

Continuing with trying to get rid of the CVE errors we have.
Most users of izettle-cryptography aren't using org.bouncycastle dependencies and the dependencies are generating on build because of CVE-2005-0366 and CVE-2001-0381. Therefore marking them as optional so they wont get added as a dependency for projects that are using izettle-cryptography or izettle-messaging. If you need to use these org.bouncycastle libraries you have to explicitly include them in your pom.
From our awesome search feature in zli it seems like it's only sun, izettle-messaging and invoice in which these dependencies are used.

I'll update and add it to sun

Love the ambition of this! Question: when reading up on the optional property in maven, it seems like splitting up the project is preferred. Is that doable instead?

The base problem here is that developers need to investigate and read up on the CVE errors for this dependency.
After some AFK talks we reached the conclusion that we'll instead try to solve this by having a global ignore file for CVE checks for issues we already know are false positives or problems that are safe to ignore.


Input binding options: updateOn and debounce

Hey Dave, me again 😁 . Currently since the library uses the onChange handler to persist model updates and perform validation, validation errors for minLength or maxLength will display immediately as the user types, without giving them a chance to complete their input. This can be a little annoying and confusing in certain instances.
Angular and other libraries typically handle this by providing options to evaluate on blur or by using a debounce. This is an implementation of that approach which modifies bindInput to allow the user to configure each binding as appropriate.
Note: the asyncHandler is required due to React's event pooling (see: https://facebook.github.io/react/docs/events.html#event-pooling).

Thank you for another great PR :), I will review it when I get into the office. I'm aware that the form support provided here is not fully featured, but it does seem sensible to try to add a few more of these features.
Leaving some notes for myself so I don't forget:

This may also be a good time to consider implementing rudimentary dirty flags, since this could be debounced on the initial change. Main problem is going from valid -> invalid immediately; user generally wants to see invalid -> valid immediately.
What is accomplishable via middleware? Would like to keep core as simple as possible.

Hey @davezuko, I'm making reasonable progress on an approach that I'll push up to a branch on my fork in a bit. Maybe you can take a look at that and I'll merge it into this PR if you agree.

Here is the new approach: https://github.com/dylansmith/react-reformed/commit/53d90a3a62b815aa6e0d0bae901b8590f6e65002
In summary:

reformed now listens for blur, focus and change events on bound inputs
the type, target and name of the last input event is stored in state  and exposed via props.lastInputEvent
validateSchema can now inspect props.lastInputEvent to determine whether it should perform validation for a particular field
validateSchema now needs to maintain a cache of the last set of validation results so that the last known result can be used in cases where validation is skipped; this also means we can revalidate immediately in cases where the last known result was invalid.

Now with dirty and touched flags per input being passed through props and used in validation: https://github.com/dylansmith/react-reformed/commit/96bdcc98d91b655a9d4a62f9d70fb593109dccaa

More work on generation and use of flags in: https://github.com/dylansmith/react-reformed/commit/beeaee9b866aab07fed81a0006d3b8390b40cac3
It would be great if you could check out the branch (https://github.com/dylansmith/react-reformed/tree/enhanced-validation-options) and let me know your thoughts on the approach. It's working well enough for my use case now, but you might have other ideas for this project.

Thanks for the updates, I hope/plan to review them this weekend. Speaking of which, have a great weekend!

Update: got a bit tied up this weekend/start of the week, will make it a priority tomorrow.

@dylansmith I checked it out today, it honestly looks pretty good. I hesitate to say it's mergeable as-is, not because I see anything blocking, but just because I want to sit on in a bit longer to make sure I'm not ignoring anything.
Would you be interested in updating this PR to match the features on your fork? That way we can consolidate discussion.

@davezuko thanks, I've squash merged in from the other branch so this PR now contains the latest changes.

By the way, I thought it was worth mentioning that I've left the old isValid keys in the schema object for backwards-compatibility. There is obvious redundancy with schema.isValid and schema.form.isValid, and I feel the latter is the better approach now that we have a bunch of aggregate flags instead of just one. Also, from a convention perspective it's a bit odd to have isValid alongside dirty et al (as opposed to isDirty) so changing it to simply valid would be more consistent, but would be a breaking change.

Hey @dylansmith , sorry for letting this linger. I've been busier than usual and haven't had the time to address this as thoroughly and completely as I'd like. Just giving you an update to know that your work is appreciated, and that any delay from me is only from a lack of time. I've added it to my priority list for the week, so hopefully that leads to something.

@davezuko no sweat, I know how it goes. It's not holding me up at all.

Any news here? 😄

As you can see, "priority list" doesn't always hold up. :/
The only real blocker that I see is the forced re-render found here. If this can be resolved I'd be happy to merge this in. I think it's incredibly useful, and I'm apologetic for my lack of attention to the effort @dylansmith has put into this.
One thing I would recommend is publishing this as a 3rd-party package. That would have additional benefits beyond the obvious, such as giving you full control over how sophisticated you'd like the schema validation to be. React-reformed was never something I planned on growing; it was essentially a toy project meant as proof of concept. If you are still interested in pursuing this PR, I will do my best to stay on top of it, but at the same time I completely understand if you feel differently.
The other alternative, and one that @dylansmith may find more appealing, is to expose this as a standalone middleware within react-reformed. The one reason I didn't merge this in immediately, despite its utility, was a fear of complicating a tiny core. From reading the proposed changes, it seems like it would be fairly easy to contain the entire implementation inside of another layer. If this is the case, I'd be happy to not only 1) merge this (given that change), and then 2) simply extend contributor/commit rights to @dylansmith so he can continue work on this project without relying on my crazy schedule. He's clearly committed to helping out, and I regret hindering that.
Thanks guys.

Thanks for the update @davezuko. Let me take a look at both options and see which is most feasible.


Destroy with empty state: Invalid index

Description
terraform destroy fails when not all resources could be removed due to an error and the destroy command needs to be executed again. terraform destroy fails with this error:
╷
│ Error: Invalid index
│
│   on main.tf line 24, in locals:
│   24:   iam_instance_profile_arn  = var.create_iam_instance_profile ? aws_iam_instance_profile.this[0].arn : var.iam_instance_profile_arn
│     ├────────────────
│     │ aws_iam_instance_profile.this is empty tuple
│
│ The given key does not identify an element in this collection value: the
│ collection has no elements.
╵

Versions

Module version [Required]: 6.5.3

Terraform version:

Terraform v1.3.4
on darwin_arm64

Provider version(s):

provider registry.terraform.io/hashicorp/aws v4.40.0

This is a provider related issue and not a module issue:

https://github.com/hashicorp/terraform/pull/32207
https://github.com/hashicorp/terraform/pull/32208


Move data-ref to signals

ctx.refs exists because datastar at the time didn't "pollute" the store.  now that _dsPlugins is a namespace it should move over.

In any case, any element with an ID is accessible by the global scope.
As you can see in the lower image, this is the console output of clicking on the div.

true, but you want to be able to access via actions


Fix aplite build error

I think the error is due to the discrepancy in the underlying data type of GColor between the 2.x aplite SDK and the new 3.8 aplite SDK (for which I'm experiencing a build error). This fix might not be the best if you still want to support the 2.x aplite SDK.

:+1:
This is fixed in the appstore version, but thanks for fixing it here.


Give rewards for winners in verification game

We probably want to do this, there is a disadvantage though, to get the rewards, an attacker might want to start a verification game, and then win it using DoS attack.

Some of this is implemented in the current version.


Add cleanup mechanism for ServerStats

NetflixOSS » ribbon » ribbon-pull-requests #3 SUCCESS
This pull request looks good


fix coverity bug

Coverage increased (+0.01%) to 50.192% when pulling c8f3486ecc252ff4abd208311e3f56ddf5d2f16f on nobodyiam:fix-coverity-bug into f1a1ee1ec75e1de8021e9df72287336537a24844 on ctripcorp:master.

Codecov Report

Merging #544 into master will increase coverage by 0.02%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #544      +/-   ##
============================================
+ Coverage     46.84%   46.86%   +0.02%
- Complexity     1339     1340       +1
============================================
  Files           319      319
  Lines          8575     8575
  Branches        824      824
============================================
+ Hits           4017     4019       +2
+ Misses         4273     4272       -1
+ Partials        285      284       -1

Impacted Files
Coverage Δ
Complexity Δ

...ervice/service/ReleaseMessageServiceWithCache.java
86.9% <ø> (+2.38%)
25% <ø> (+1%)
:white_check_mark:

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 f1a1ee1...c8f3486. Read the comment docs.


Value tuning...

I've found these values yield better results in real life ..Over-Team-Worked servers (east asia - china) that I play at does muuch better with these settings..
Feel free to try ..

replaced isfood with comparesize that does the same thing? just wondering why

no it doesn't...is food is set at 1.33 which is should be left at that .. but if you use isfood in threat assessment then you also have to use 1.33 , this way I can define 1.30 (or whatever) for it ..

I guess similar was a better word for that I guess better safe than sorry for threat assessment then. (I didn't check all of the context of that change so thats why I got confused)

my aim in all these is to make the bot survive better against two or more humans teaming up against ..there is no way other than learning neural networks for the bot to understand that ..so with these values I can at least give it a little chance for the "tricks" people seem to favor.
If no one teamed up , these changes will probably be unnecessary but that's far from reality ..

So just to make it clear for others too . .
With these settings bot will alert for a virus even though it can safely hover above it (disabling someone feeding the bot to eat the virus however)
also it will think people the same size of you are threats (while in reality they are not, with a friend to feed them a few mass they become a threat and bot is in underwater)
It also thinks people greater than 7 times your size (up to 20 indeed) can still be mean enough to split at you ...When teams are spit-flooding the place they just don't care . .

And oh . .the adjustment in cansplit also works well when assessing threats as someone exactly 2.66 of the bot trying to eat it is a very vague threat due to the same reason I've explained before..So with this value those guys are not threat anymore . ..

We can try it.


Fix #19: Manager Drivers of Sample.UITest via Nuget

I was too fast and FF was not tested properly, so please do not take any action.

I have tested also on FF and created a bug #21 stating that the is already problem with FF and it does not affect this PR.
I am not able to run IE test on my current machine, so maybe somebody else can do it.

This commit was so inspiring so I've created another issue #22. @kmorcinek what do you think about this idea?

This issue was solved with Tellurium.SeleniumDriverInstaller


Try to extract layer names from Chain, Parallel and SkipConnection

Fixes #94
This adds functionality to extract layer names from Chain, Parallel and SkipConnection.
This functionality is enabled by default, meaning that if the model to be serialized is a Chain with named layers, ONNXNaiveNASflux will use those names instead of the default ones. The name hunting will recurse to any nested Chains and into  Parallels and SkipConnections.
@alicewith: You can see some examples of what this does in the tests, starting here.
Note that the input node is a special node in ONNX which does not exist in a Flux Chain, so just naming the first layer "input" will not give you the result you want; You have to give the name as input to save just as on current master.

It looks good! Thank you.

Alright, just triggered the release process so it should be available soon.


How can i use MultiSelect with GroupData?

Oops! Unfortunately, that's unavailable. But, I will consider adding it in the future.


pair via asset ID or asset description

Allow setting of the pairing token via Chrome Management Console on Chrome OS. Investigate centralized methods for other platforms.
https://cookcompany.zendesk.com/agent/tickets/530

https://mail.google.com/mail/u/0/#inbox/FMfcgxwDqfJvppBbtnMblsqXkqVkVvKh

https://mail.google.com/mail/u/0/#inbox/FMfcgxwDqTfXrcJZzsjbrNdqGHrWBkFB


Another attempt to fix signedness warnings

This is an experiment similar to #261 and #266.
Rather than cast everything to (int) I've tried to plumb though the type enum vm_reg_name and only cast to (int) at the lower level.

I prefer this approach, using enums, over the simple casts to (int). CI failure seems unrelated...

@rn thanks for the feedback! I think I've finally managed to fix the CI: I've bumped the Xcode version the opam version for OCaml and worked around a couple of failures. Let me know what you think.


provide a mechanism that allows Tasks' dependencies to be modified at runtime

For instance, I may add in my project a Task that should be run before a particular Task available in my recipe.

This task makes no sense alone; A task should not change the dependency of other (parent) tasks because they will not be programmed to use this (son) task.
This feature becomes useful while streaming a result to another Task. This requires that the son task is launched before the parent.


Evaluate Azure SEA with respect to Foundation

Describe the issue
We want to observe the SEA and see how destructive or good fit it is for the existing foundation
Additional context

After deploying the SEA
Jon requires high-level access

Definition of done

A demo from Warren to rest of Max, Julian and Jon, showcasing what's there and automation gaps, compare to AWS
Create well-formed tickets once more is known

This is blocked until we have an Azure SEA

Azure SEA is set up for access. Moving this to unblocked.

I demoed the SEA dev environment to @ActionAnalytics and @jon-mc-git. @jon-mc-git is going to look at and compare the SEA to foundation.

On hold (blocked) until can get demo of what has been achieved currently in initial code deploy 'dev' environment, along with what has been learned SEA infrastructure wise when compared to AWS.  After this with Warren, will re-evaluate and create questions\review package for Warren and I to discuss further.  Next steps\action items will come from there, so we can have separate discussions on these and move forward planfully.

No longer relevant


Follow-up to pull request #62

That pull request got merged before I had a chance to improve it.  I took the many forks as an indication that people use this package with their own fixes.
Quote tkelman:

what are you using that was first in 0.16? looks like 0.9.5 might be good enough for take!

A low Compat number may enable some combinations of packages and Julia. I can follow up with another PR to keep the version number as low as possible fora follow-up.
What about the badges? They say 0.6.1 fail. Why is that? And could we do something to indicate that this also works on Windows? I guess I need to get up to date on how the evaluation system works.

It turns out dropping 0.4 is not necessary. It may even still work in 0.3 - to be tested before submit.
I have converted comments to inline docs, and cleaned indents.

0.3 won't work of course, due to pre-compilation. #64 drops dead code for Julia 0.3.

Thanks for doing this. I will close this since your changes are now released. Cheers!


Images for the select options?

Is there currently a way to get images in the select options? Ive been trying to get it working, but I havent found a way yet.  If images arent supported, is there a way to set a class or id on each option so that I could try to find a css solution?
Not a deal breaker, but it would be nice if the package supported this :)

If I'm right, then after porting it to support Vue 2.0, it would be easier to support custom option templates (as this would be just a render function then). Supporting Vue 2.0 is something I want to achieve in the next 2 weeks, so this is when I could add support for custom option templates. The current Slot implementation does not enable that, as it is compiled within the parent's scope.
Right now this (and much much more) is already possible if you create a custom component that uses multiselect's mixins. All the javascript code not related to the default template is encapsulated in mixins. What you have to do to make it work:

Look into multiselect.vue component.
Copy the template and css code to your new custom multiselect component.

Import fhe { multiselectMixin, pointerMixin } like in the Readme and add it to your component.
Customize the template and css however you like. Just make sure you don't remove any bindings from the template that you actually need.
Have fun!

This is not the ideal solution but gives you all the freedom to customize the component and still be up to date with most of the fixes (as those happen mostly within multiselectMixin file).
If you decide to follow this path, I would be happy to see the customized result! We could then create an examples catalog with different skins for multiselect.
Next week I would probably create some such examples myself.

Thanks for your detailed reply, shentao! Ive got it basically working, just need to iron out a few small problems and clean it up a bit. Once I get it all working, Ill let you know.

Glad to hear that! Would love to see it live!

@liamcharmer Yes. You can use either the tag or selection slot to modify how the selected elements look like. You can also use the option slot to change how the options in the list look like. See the docs for examples (cmd/ctrl+f).


Merge upstream HEAD (da6668b, 2024-01-02) for auth fix

The recently cherry-picked CVE-2023-51663 fix (PR #323) included refactored code dependent on recent upstream code that was not cherry-picked. This caused:
{"severity":"ERROR","levelname":"ERROR","asctime":"2024-01-03 01:59:09,079","filename":"auth.py",
"funcNameAndLine":"callback:341","message":"oauth2 callback: could not fetch and verify token",
"exc_info":"Traceback (most recent call last):\n
File \"/usr/local/lib/python3.9/dist-packages/auth/auth.py\", line 335, in callback\n
    flow_client = request.app[AppKeys.FLOW_CLIENT]\n
NameError: name 'AppKeys' is not defined",
"hail_log":1}

Context: https://centrepopgen.slack.com/archives/C030X7WGFCL/p1704243108737559
This merges current upstream HEAD to include the necessary AppKeys class (see auth/auth/auth.py) and any unrelated fixes and improvements.
Merge conflicts resolved included letsencrypt/subdomains.txt, in which we omitted upstream's addition of guide-analysis which is specific to their lab.

Yep, I was just looking at the batch/sql/rename-job-groups-tables.sql migration script, which will be interesting to observe running…


Fix typo in SEMANTICS.md

programatically -> programmatically

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and I agree to the terms of the Developer Certificate of Origin (DCO).

Integration test failure on the PR is expected, tracking in #143.


[FEATURE]Compare to FasterTransformer

Is there any comparison between BMInf and Nvidia's FasterTransformer?

I would like to use some tools to improve our model's inference performance. BMInf is great, and it seems like use CUDA implementation to boost inference performance, just like FasterTransformer. So, is there any comparison in inference time between BMInf and FasterTransformer?

We haven't compared which is faster. But as far as I am concerned, FasterTransformer will be faster on a high performance platform.
BMInf is designed to be able to run giant models in low-resource environments, and not much performance detail has been considered currently. We don't use FasterTransformer now because the implementation details of CPM are not quite the same as FasterTransformer.
We are going to optimize the efficiency on high performance platforms in later releases.


HitTestBehavior.translucent is broken

void main() {
  runApp(new Stack(children: [
    new Listener(
        onPointerDown: (_) {
          print("Listener1, onPointerDown!");
        },
        behavior: HitTestBehavior.translucent,
        child: new Container(
            decoration:
                new BoxDecoration(backgroundColor: new Color(0x80FF0000)))),
    new Listener(
        onPointerDown: (_) {
          print("Listener2, onPointerDown!");
        },
        behavior: HitTestBehavior.translucent,
        child: new Container(
            decoration:
                new BoxDecoration(backgroundColor: new Color(0x8000FF00))))
  ]));
}

You only ever see "Listener2, onPointerDown!".

If you take out the children with the backgrounds set it will work.

After some discussion this is WAI.

After some discussion this is WAI.

what is the discussion?I have the same question.


[BUG]: Ignore: testing csm bot

Bug Description
This is a test
Logs
This is a test
Screenshots
No response
Additional Environment Information
No response
Steps to Reproduce
This is a test
Expected Behavior
This is a test
CSM Driver(s)
CSI Driver For PowerFlex
Installation Type
No response
Container Storage Modules Enabled
No response
Container Orchestrator
K8s 1.25
Operating System
CentOS 8

/sync


pnpm --dev change to -D

--dev seems to give an error ( ERROR   ERROR  Unknown option: 'dev')

Ah, sorry, I missed it. 🙇


importlib_metadata missing. Suggestion: Install importlib_metadata on Python < 3.8

click 8.0.0 now relies on importlib.metadata under certain conditions.
On Python 3.8, click will raise an error and ask the user to install the importlib_metadata backport package.
Ex:
Traceback (most recent call last):
  File "/path_to_my_venv/bin/myexecutable", line 8, in <module>
    sys.exit(cli())
  File "/path_to_my_venv/lib/python3.6/site-packages/click/core.py", line 1134, in __call__
    return self.main(*args, **kwargs)
  File "/path_to_my_venv/lib/python3.6/site-packages/click/core.py", line 1058, in main
    with self.make_context(prog_name, args, **extra) as ctx:
  File "/path_to_my_venv/lib/python3.6/site-packages/click/core.py", line 927, in make_context
    self.parse_args(ctx, args)
  File "/path_to_my_venv/lib/python3.6/site-packages/click/core.py", line 1621, in parse_args
    rest = super().parse_args(ctx, args)
  File "/path_to_my_venv/lib/python3.6/site-packages/click/core.py", line 1376, in parse_args
    value, args = param.handle_parse_result(ctx, opts, args)
  File "/path_to_my_venv/lib/python3.6/site-packages/click/core.py", line 2352, in handle_parse_result
    value = self.process_value(ctx, value)
  File "/path_to_my_venv/lib/python3.6/site-packages/click/core.py", line 2314, in process_value
    value = self.callback(ctx, self, value)
  File "/path_to_my_venv/lib/python3.6/site-packages/click/decorators.py", line 380, in callback
    "Install 'importlib_metadata' to get the version on Python < 3.8."
RuntimeError: Install 'importlib_metadata' to get the version on Python < 3.8.

The user can install importlib_metadata, but I think Click could use environment markers to install the importlib_metadata backport package on Python 3.8, in the same manner that colorama is installed on Windows.
I will send a PR soon. Feel free to express any concerns, doubts or considerations to the project context that I've missed.
Environment:

Python version: 3.6
Click version: 8.0.0

I've relaxed my view on backport dependencies with environment markers since we added this code, so I'm fine with changing it.


Add compatibility to Swift 4.2 on Xcode 10 GM

Fixed the 2 errors thrown by Xcode 10 GM on 5.1.0 version of PKHUD with Swift version set to 4.2.
Both fixes required minimal changes (just one init and one enum that got renamed).

Can we get this merged soon please?

Hey @pkluz, @PGLongo is it possible to merge this?
Since the .swift-version file is deprecated and the podspec does not contain a swift_version property PKHUD will not compile by default on a Swift 4.2 project (CocoaPods will set PKHUD to Swift 4.2 and it will throw two compile errors)

@pkluz please update to Swift 4.2 version.

@PGLongo can we get this PR merged? Thanks!

Done. Sorry for the delay

Can you please release a new version with this merge? Thank you

Thanks, @PGLongo !
Are you planning to make a new release anytime soon? I would really appreciate that :)
Also, when you make a new release, I think it might be a good idea to add a s.swift_version = '4.2' to the podspec in order to avoid compatibility issues when the next version of Swift gets released!

Still need a new release created.

Hi @PGLongo any chance you can make a new release so we can install it properly without needing to use :git => on the Podfile?

I'm working on it

@PGLongo Change your build setting "Swift 3 @objc Inference" to "Default" (Project -> Build Settings tab -> search term "inference").

Thanks @anthonypuppo and everyone


8 gpus test example raise error.

When I do Unit Tests, it can pass when use two gpu devices, run command below:
CUDA_VISIBLE_DEVICES=0,1 python3 -m unittest discover -v -s tests
But I do Unit Tests with eight gpu devices, it raise ncclSystemError.
run command:
CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 python3 -m unittest discover -v -s tests
raise error:
RuntimeError: NCCL error in ../torch/lib/c10d/ProcessGroupNCCL.cpp:825, unhandled system error, NCCL version 2.7.8
ncclSystemError: System call (socket, malloc, munmap, etc) failed.
Is it necessary to pass unittest in eights gpu devices?

When I do Unit Tests, it can pass when use two gpu devices, run command below:
CUDA_VISIBLE_DEVICES=0,1 python3 -m unittest discover -v -s tests
But I do Unit Tests with eight gpu devices, it raise ncclSystemError.
run command:
CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 python3 -m unittest discover -v -s tests
raise error:
RuntimeError: NCCL error in ../torch/lib/c10d/ProcessGroupNCCL.cpp:825, unhandled system error, NCCL version 2.7.8
ncclSystemError: System call (socket, malloc, munmap, etc) failed.
Is it necessary to pass unittest in eights gpu devices?

I have solve it, by run docker add "--ipc=host".


feat: Add *ResourceApp trait to allow more generic applications

I am not sure about the use of this, I think it's quite limited. But it does not hurt to have it so if you think it's good to have it we can merge it.

Please no, keep it as is.


Reduce lock contention in manifest cache

High Level Overview of Change
Since apply_mutex and read_mutex both protect the same data, remove the two
member vars and add a new mutex_ var. Use a shared_mutex for this new
mutex_ var mutex. This allows multiple readers (a common case) and helps
reduce lock contention.

Closing this for now. I need to think about how removing the apply_lock effects lock contention.


"postureCheckRoles" needs to be x-nullable

When consuming the openapi spec in csharp and returning a seservice-policies which was created with no postureCheckRoles, the csharp deserializer throws an exception indicating required field "postureCheckRoles" cannot be null.
find the four references in the openapi spec and add:
x-nullable: true
-- or --
return an empty value instead of null
Example json returned from the v0.30.3 controller:
  "data": [
    {
      ...
      "name": "test-weather.sp.dial",
      "postureCheckRoles": null,
      "postureCheckRolesDisplay": [],
      ...
    }

The API be changed to return []string{}. golang clients and they treat nil (null) as an empty list. However other languages do not share that opinion.

I'm not sure what you're advocating for the consumer to do for the case where the language consuming the spec has 'null' (csharp, maybe java).
Are you agreeing to change the response to ensure an empty, initialized list is returned? Or agreeing to add x-nullable? Or advocating for csharp consumers to "deal with it" on their own?

The solution is to make sure that an empty slice ([]string{}) is always present in the output so that [] is rendered in the API output and never null.


Test / implement time types for Microsoft SQL Server

This issue aims to add automatic tests for Microsoft SQL Server time types (Date, Timestamp, Timestamp with time zone, Time, Time with time zone, ...). Test examples are available in PostgreSqlTest class. If SQL test data generator does not manage a time type for Microsoft SQL Server  yet, please update the ColumnValueFormatter class to make it works.

I will start with this one.

Fixed with bc4859a83d593e39df92a068e73392f7429d5771 Thank you @raychenon


⚠ GitLab Server has degraded performance

In 7af5365, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 11524 ms

Resolved: GitLab Server performance has improved in cb18b2b.


Extend support to Python 3.11

Description:

I.e., add CI tests using 3.11.
Closes #120
Type of change:

[ ] Bug fix.
[ ] New feature.
[ ] Documentation update.

Checklist for the reviewer:

This checklist should be used as a help for the reviewer.

[ ] Is the change limited to one issue?
[ ] Does this PR close the issue?
[ ] Is the code easy to read and understand?
[ ] Do all new feature have an accompanying new test?
[ ] Has the documentation been updated as necessary?

Codecov Report
Patch and project coverage have no change.

Comparison is base (7f98a04) 90.76% compared to head (04e0094) 90.76%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master     #136   +/-   ##
=======================================
  Coverage   90.76%   90.76%
=======================================
  Files          26       26
  Lines         433      433
=======================================
  Hits          393      393
  Misses         40       40

Flag
Coverage Δ

linux
90.76% <ø> (ø)

windows
?

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

While the tests now succeed, I am very unhappy with the changes introduced in the code due to changes for enum in Python 3.11.
The main issue is that in Python 3.11 all the different ways of casting an Enum to a string (with str mix-in) have been unified (good) but to the Enum's class name and the enumeration, i.e.:
from enum import Enum

class Foo(str, Enum):
    BAR = "bar"

Prints Foo.BAR for all cases now (in Python 3.11), where it used to print the enumeration value, i.e., "bar" (for f-strings and format()).
This is all good and well, since they then also introduced a new enumeration class to handle this case specifically, namely StrEnum. BUT this is only available in Python 3.11 and cannot be imported or used in <3.11 in any way. Sometimes features in newer versions are available through the __future__ lib, but not in this case.
So the only solution now is to go over all uses of a str mix-in enum value and do getattr(enum_inst, "value", enum_inst) instead of enum_inst, or in the best case "just" enum_inst.value instead of enum_inst. The former case is when the type has been specified as either str or the enum class and mypy tries to clear it (it will fail if one "just" uses .value, since this is not a property of str).
So - all in all, I don't know what to do. There's a lib one can use to mimic Python 3.11's StrEnum - but it specifically states at the bottom of its README that it is not a drop-in replacement for Python 3.11's StrEnum ...

As an additional comment, it might be better to switch to using a Literal type instead of Enum classes, where possible? For example, this is also what is recommended now in pydantic.

While the tests now succeed, I am very unhappy with the changes introduced in the code due to changes for enum in Python 3.11.
The main issue is that in Python 3.11 all the different ways of casting an Enum to a string (with str mix-in) have been unified (good) but to the Enum's class name and the enumeration, i.e.:
from enum import Enum

class Foo(str, Enum):
    BAR = "bar"

Prints Foo.BAR for all cases now (in Python 3.11), where it used to print the enumeration value, i.e., "bar" (for f-strings and format()).
This is all good and well, since they then also introduced a new enumeration class to handle this case specifically, namely StrEnum. BUT this is only available in Python 3.11 and cannot be imported or used in <3.11 in any way. Sometimes features in newer versions are available through the __future__ lib, but not in this case.
So the only solution now is to go over all uses of a str mix-in enum value and do getattr(enum_inst, "value", enum_inst) instead of enum_inst, or in the best case "just" enum_inst.value instead of enum_inst. The former case is when the type has been specified as either str or the enum class and mypy tries to clear it (it will fail if one "just" uses .value, since this is not a property of str).
So - all in all, I don't know what to do. There's a lib one can use to mimic Python 3.11's StrEnum - but it specifically states at the bottom of its README that it is not a drop-in replacement for Python 3.11's StrEnum ...
Edit: I suppose one way would be to add an explicit __str__() method (and possibly __repr__() method as well) to all supposed "StrEnum" classes?

I think str() would be the best. This would keep the usage for end users/plugin-developers consistent across versions seems the least cumbersome. (this might even be what strEnum is effectively doing behind the scenes..

As an additional comment, it might be better to switch to using a Literal type instead of Enum classes, where possible? For example, this is also what is recommended now in pydantic.

I would advice against it, unless the modification is both easy to add and backwards compatible. The change is only recommended for performance reasons, and, in general one should avoid modifying things for performance without benchmarking data. [at the top of the page they actually state 'In most cases Pydantic won't be your bottle neck, only follow this if you're sure it's necessary']. But, its easy to change and backwards compatible then go for it, why not. Or, if you have some compelling reason that this will be a bottleneck

I would advice against it, unless the modification is both easy to add and backwards compatible. The change is only recommended for performance reasons, and, in general one should avoid modifying things for performance without benchmarking data. [at the top of the page they actually state 'In most cases Pydantic won't be your bottle neck, only follow this if you're sure it's necessary']. But, its easy to change and backwards compatible then go for it, why not. Or, if you have some compelling reason that this will be a bottleneck

This is an excellent point (I actually hadn't seen that this was the context for this suggestion).

I think str() would be the best. This would keep the usage for end users/plugin-developers consistent across versions seems the least cumbersome. (this might even be what strEnum is effectively doing behind the scenes..

I'll try it out - don't think it's that simple behind the scenes - but it might never the less be a good solution for our use case 👍

I think str() would be the best. This would keep the usage for end users/plugin-developers consistent across versions seems the least cumbersome. (this might even be what strEnum is effectively doing behind the scenes..

I'll try it out - don't think it's that simple behind the scenes - but it might never the less be a good solution for our use case 👍

It seems to work fine. There's not complete back-compatibility, as one should now explicitly cast to str() if str-methods are desired to be used (at least in Python 3.11).

I got a bright idea (I think) to simply use enum.StrEnum if it exists (i.e., for Python 3.11+) and otherwise create an empty class called StrEnum that inherits from str and enum.Enum (as did the original Enum classes).
This effectively means no other changes have to be implemented and everything can be used as is. The existing Enum classes just need to change their inheritance to be from StrEnum, and everything should resolve as intended.


No backends present. You must configure backends in the Backends section of the Server tab before you can continue.

Suddenly the error appeared!

it, uh, looks like you don't have any backends?
Is this a new installation? If so, you may have just not selected to install one - in which case go back, reinstall and select the comfy backend.
If this is a pre-existing installation, did you edit the backend list or launch params? If so you'll have to go to the Server tab and add your preferred backend back. The default is comfy self start, unless you wanted a different one.
If this is a pre-existing install but you updated and that broke it ... uh, update again, might've been a temp path handling bug that's fixed? Or check if there's something weird in your Data dir?

it, uh, looks like you don't have any backends?
Is this a new installation? If so, you may have just not selected to install one - in which case go back, reinstall and select the comfy backend. If this is a pre-existing installation, did you edit the backend list or launch params? If so you'll have to go to the Server tab and add your preferred backend back. The default is comfy self start, unless you wanted a different one. If this is a pre-existing install but you updated and that broke it ... uh, update again, might've been a temp path handling bug that's fixed? Or check if there's something weird in your Data dir?

I've been using it for a while now and the error popped up today!
Is this how the backend is set up? I can enter comfyui after setting it, but there are many warnings!

That looks correct. Those errors indicate that you have some custom nodes installed that are missing dependencies.
A recent change was made that disabled ComfyUI accidentally accessing the global python lib folder, so if those nodes worked before now you may need to reinstall them (if installing manually, make sure to use the dlbackend/comfy/ComfyUI/python_embeded/python.exe to install rather than global python)


Add cloud source repositories section to Team Explorer

Add data source for cloud source repositories
Expose an empty user control to Team Explorer connect section
It must be built for both VS2015 and VS2017
So we creates v14 and v15 versions of section interface.

Now is too late, but please, create smaller PRs. It takes a LONG time to go through this long ones and it makes it more difficult to find issues. Please, please, please.

Hi Ivan,
I've been sending small PRs for Debugger feature. And hence I accumulated code for reviews.  I ask you guys for this exception.  And sorry for the large PR.

+1 to smaller PRs I know this can be a pain but it's even harder for us to review.

I understand.  But please look into this.  This is not big.  It creates projects that adds project files.  The real code is small.  The data source code can be split, this is a small part though .  The other parts are the minimum code that creates an empty section at Team Explorer, it's hard to split.
Being said that, I appreciate you guys that have been "undertaken the pain" for doing the code reviews.

I found this fine. It touches a lot of files, but most of the lines are auto-generated (AssemblyInfo.cs, .csproj). The actual code files are mostly stubs, so there isn't much to review there. If the PR had this many files, this many line, and implementations that actually took thought to review, I would agree it is too big. As it is, I think it is fine.

Codecov Report

Merging #655 into m_csr will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            m_csr     #655   +/-   ##
=======================================
  Coverage   57.85%   57.85%
=======================================
  Files          26       26
  Lines        1070     1070
=======================================
  Hits          619      619
  Misses        451      451

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 536cec2...013f1f8. Read the comment docs.

Thank you, looks better. But we should remove the functionality to create the repos unless we can provide all of the functionality in the VS extension. Point them to the cloud console for now.

I added Readme.md.  Let me know if it is clear.

Some interface properties only has public get. When I add private set, it does not accept explicit declaration.

Thanks for the code review.


nano fail helpppp

$ nano main.c
5 [main] nano (8424) C:\Program Files\Git\usr\bin\nano.exe: *** fatal error - cygheap base mismatch detected - 0x1802FD410/0x180301410.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version should
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.
helppp i can t run helloworld

@stomaras Can you provide more information from your environment.

Windows version
Git for Windows version
Cygwin version
Bash version
nano version

at least.

This can happen if your PATH environment variable has some other directory on it containing cygwin1.dll earlier than the path to C:\Program Files\Git\usr\bin\.
What does echo $PATH show at the command line?


[react] Create Grid component

Create Grid component following the atomics approach, same as https://github.com/mui/pigment-css/pull/118.
Summary
This is the Pigment version of the Grid v2 component. It supports all the use cases the original supports but has some API differences:
Sizing
Instead of using the breakpoints as props for size (xs, sm, md, ...), there's a size prop. Some conversions

xs={2} turns into size={2}
xs={2} md={4} turns into size={{ xs: 2, md: 4 }}
xs turns into size='grow'
xs='auto' turns into size='auto'
xs={2} sm md={4} lg='auto' turns into size={{ xs: 2, sm: 'grow', md: 4, lg: 'auto' }}

Offset
Instead of using the breakpoints as props for offset (xsOffset, smOffset, mdOffset, ...), there's a offset prop. Some conversions

xsOffset={2} turns into offset={2}
xsOffset={2} mdOffset={4} turns into offset={{ xs: 2, md: 4 }}
xsOffset='auto' turns into offset='auto'
xsOffset={2} mdOffset={4} lgOffset='auto' turns into offset={{ xs: 2, md: 4, lg: 'auto' }}

This was done as it works better with the no runtime approach. It might be possible to maintain the previous API, but I don't think it's worth it as it might introduce some tech debt, and this API is more consistent IMO. It is also easy to cover with a codemod.
Unstable internal props.
The original Grid v2 uses a unstable_level prop for nesting grids. This uses a similar approach but instead of levels it takes advantage of CSS variable scoping. This is the only way I could find to achieve nested grids. The problem it solves is that when a Grid is both a container and an item, it has to read from and set the column count.
There might be alternatives to remove the use of these unstable internal props and check the component muiName, but I couldn't find a better way and I think we should move forward now. If someone has an idea for alternative implementations, I will test them. I don't think using :has would help.
Play with the Grid
// project root
pnpm build

// pigment-css-vite-app
pnpm install
pnpm dev

The demo is at http://localhost:5173/grid and the code is at apps/pigment-css-vite-app/src/pages/grid.tsx
Preview
I've copied all demos from the docs to the test apps.
https://github.com/brijeshb42/pigment-css/assets/16889233/42909b01-345c-4fc1-8374-2737ae7f7629

As explained in the description, the APIs from Grid v2 to the Pigment Grid differ. It's easy to cover these differences with a codemod, which I think we should provide. The question would be should we implement this new API in the Grid v2?

For the sizing changes, is it an improvement or a mandatory change to make the Grid works?

Please add the test for the component. You can follow this pattern.

@DiegoAndai about the API, some thoughts and questions:

Ideally we should have the same API, no matter the styling solution.

Side note: it's unfortunate we need to have different APIs based on the styling solution. These weird decisions is something we can improve in the future if we detach Material UI APIs from styling solutions as we discussed in other forums.

I think the new API is way better and better aligned with how responsive values are handled using sx and other libraries across the industry.
If we all consider the new API to be better, can we upgrade Grid v2 to use this new API and provide the codemod for the v6 upgrade?

Please see my suggestion, I'd prefer to keep the existing APIs as much as possible. I imagine that developers might switch back and forth between Emotion/Pigment CSS in v6.

@siriwatknp yes! your suggestion would work. I thought of implementing it that way, but I agree with @aarongarciah:

I think the new API is way better and better aligned with how responsive values are handled using sx and other libraries across the industry.

In other words, I think having size and offset props is better. They're easier to understand, and they have the same usage as the columns or spacing props. I also think 'grow' is easier to understand than the boolean true used in Grid v2.
So while I agree that the APIs should be the same if possible, I suggest keeping this API, deprecating the breakpoint props in Grid v2 (xs, xsOffset, sm, smOffset, ...) and implementing the size and offset props instead. We can have a codemod for it.
What do you think? Do you see any reason not to follow this approach?

So while I agree that the APIs should be the same if possible, I suggest keeping this API, deprecating (or removing) the breakpoint props in Grid v2 (xs, xsOffset, sm, smOffset, ...) and implementing the size and offset props instead. We can have a codemod for it.

To me, if the change in the API fixes issues I would consider going for it. However, it sounds like the change is based on our assumption that it is better. So if we compare "better API" with "more work + breaking change", I'd go with keeping the same API for now.
To the people who want to upgrade to v6, these breaking changes might not be better for them (since it is not fixing any issue). Even though we have codemod, it could not be enough. You will be surprised how fancy the codebase could look like when they open an issue that the codemod does not work 😅.
What do you think @mnajdova? Have you seen any issues regarding the existing API since older version @oliviertassinari?

However, it sounds like the change is based on our assumption that it is better.

I wouldn't say it's an assumption. It's objectively more consistent with the sx, columns, and spacing props. The naming is also objectively easier to understand: xs is a breakpoint, so why is it used as a name for a size prop?

So if we compare "better API" with "more work + breaking change", I'd go with keeping the same API for now.

This is a good moment to improve the API: we are working on a new major, introducing an alternative no-runtime component, and Grid v2 is currently marked as unstable. This is the moment when we're focused on the layout components, I don't know if there will be another major soon that is focused on them.

Agree with Diego here. We can pitch this as a upcoming stable equivalent of Grid v2 and we have this time to do the API changes that we want.
Also agree with the new props.

Hey @siriwatknp! I added the Grid tests setup. I wanted to add more tests to Grid.test.js but I wasn't able to import the Grid output from fixtures/Grid.output (like it's done for the Hidden component for example). There's an issue with this:
// fixtures/Grid.output.js

import _default from '@pigment-css/react';
// ...

const GridComponent = /*#__PURE__*/ _default('div')({
// ...

Which fails with:
TypeError: (0 , _src.default) is not a function

I noticed the Container fixture also has this issue, so importing it doesn't work either. Do you know what might be going on?
cc: @brijeshb42

@DiegoAndai Modifying line 419 in processors/styled.ts to
const styledImportIdentifier = t.addNamedImport('styled', process.env.PACKAGE_NAME as string);

should fix your issue.

Thanks @brijeshb42, it works now 👌🏼

This is ready, the only thing left to decide is the API discussion.

This is ready, the only thing left to decide is the API discussion.

To adopt the new API size and offset, these are extra works:

update the Grid v2 to use the new props.
create a codemod to transform into new props.

Let's vote, 👍 for yes and ❌ for no. cc @DiegoAndai @aarongarciah @brijeshb42 @mnajdova (@danilo-leal @zanivan tag both of you for user perspective)

Let's vote, 👍 for Yes and 😕 for No

I want to justify my vote, as I haven't leave any comment so far. I am voting for the new API as it feels better, it's closer to the sx prop syntax that people are already familiar with. This is a major version, and the change is somewhat related to providing a support for new styling engine, considering we don't have almost any breaking change, it makes sense to include it, rather then adding more technical dept if we do want to change the API anyway in the next major.

@DiegoAndai based on https://github.com/mui/pigment-css/pull/144#issuecomment-2179809493, let's move forward with the new API. Can you update the Unstable_Grid in a separate PR?

@DiegoAndai based on https://github.com/mui/pigment-css/pull/144#issuecomment-2179809493, let's move forward with the new API. Can you update the Unstable_Grid in a separate PR?

Yes, I'll merge this today and open the PR to update the Unstable_Grid

@DiegoAndai I think wrap prop is missing. It's not a system prop (similar to direction). Can you fix it?

Created PR https://github.com/mui/pigment-css/pull/159 for adding a wrap prop


Will you accept a PR that lets users schedule to the second?

Background
I'm working for a company that is trying to develop software to manage the electronic TV-screen-sized ad-billboards you see in malls.  The billboard software needs to be able to schedule various events throughout the day, with the events often needing to be scheduled to the second or possibly even tenth or hundredth of a second.  The CTO recommended using this schedule package to handle this.
The problem
I've noticed that the at() function in this package does not allow users to schedule things to the second or millisecond, and I'm wondering if I can submit a PR that will add this functionality, or if there's some other package that I should consider instead.  For example, I've spent a few minutes looking at the Python built-in sched package and it seems like it may do what I need.  It seems like this schedule package is really meant more for cron-job-like tasks.

Hey @NathanWailes I don't really see a use case for millisecond precision because schedule wasn't built with that in mind. Like you said this is meant to be a cron replacement and not a real-time scheduler.
However I'd be interested in making at() accept timestamps with 1 second precision, e.g. at("13:00:30"). If you're interested in putting together a PR for that let me know! Oh, and Happy New Year 🎆 :-)

Thanks for the quick response!  I asked the CTO and he said he'd be OK with 1 second precision, so I created a PR: https://github.com/dbader/schedule/pull/267
Happy New Year!


Import WIP into breadcrumbs template

Please import the WorkInProgress component into the BreadcrumbsTemplate found inside components/ContentTemplates folder.
Then render the WorkInProgress component instead of the current div and placeholder sentence.
See the AlertsTemplate component if unsure how to do this and follow the same pattern.

Hey @EmmaDawsonDev, I would like to work on this issue.

Hey, yes, go ahead!

Hey @ctoffanin, made a PR for this issue.


Cross: Screen recording

Try to implement cross-platform screen recording.

Bleh, this is hard.

Super hard to implement because there are almost no mature rust crates to do this.


Histogram with large data (vaex instead of pandas)

Hi,
great project and it was on my wishlist to try it out with vaex (an out of core dataframe alternative to pandas), which I've done here: https://github.com/vaexio/vaex/pull/383
However, when I try the histogram:
h = px.histogram(df, x='VendorId)'

I notice that plotly asks vaex for that data (150 million rows), and adds the data to the plotly Histogram object. Trying to send that to the browser will fail (it will crash chrome). I was expecting plotly express to do a groupby (which vaex then will handle instead of pandas), and only send the aggregated data. Is this a bug or a feature, and is this likely to change?
Regards,
Maarten

Hi @maartenbreddels, thanks for checking out the project!
At the moment, this limitation is by design because the px.histogram function maps directly to the plotly.js histogram trace type, which does all of the binning on the JavaScript side.
I think it would be nice to have some kind of server_side option to perform the binning in Python. In that case, we would display the results using a bar trace.  If we implemented all of the bin function options, we might be able to make this the default.
@nicolaskruchten interested in your thoughts on this when you're back in the office

Hi Jon!
ok, good to know, so that would only be the exception I assume?
cheers,
Maarten

Hi both, sorry for the delay in responding.
I agree that for this kind of thing, leveraging "server-side" Python is a clear winner. My philosophy with px initially had been that it would do as little work as possible server-side, so as to provide a more coherent wrapper around plotly.js, but this kind of thing is an obvious limitation of this approach. The downside of implementing a server_side flag to the aggregating trace types like px.histogram but also px.density_heatmap, px.density_contours and even px.box possibly, is that we have to implement in Python something which is ideally identical to the behaviour of the underlying JS library, which is a challenge, but also that it's not clear what trace type to use in the output. If we do server-side aggregation in px.histogram, do we then produce a figure composed of bar trace types? That seems a bit weird...

Migrated over to the main plotly repo: https://github.com/plotly/plotly.py/issues/2649


Commit default args are unintuitive and differ from CLI git

Currently if I have a situation like:
M - test.txt
M - test-2.txt
And I do: $git->add('test.txt');
Then I do: $git->commit("Commit message here.");
Then the git-wrapper actually does a git commit -a -m "Commit message here.", meaning both files are added to the commit (instead of the one I explicitly added).
I've also tried manually overriding this strange default behavior (on the CLI, if you do a git commit with no args, it will not add all modified files, only those that have been added/staged), but this still seems to sneak in the '-a' arg too:
$git->commit('', ['m' => "Commit message here."]);

Is there any way to do a commit without the library throwing in the -a arg and adding all modified files?
Code in question: https://github.com/cpliakas/git-wrapper/blob/05a047acc578c2d0ca6fdb985598467860285dc7/src/GitWorkingCopy.php#L430-L446

Thank you for the issue!

The work of this package continues in https://github.com/symplify/symplify
See https://github.com/cpliakas/git-wrapper/issues/225


[Bug] Forge - Sodium incompatibility

Latest Logs
No crash logs

Such is an issue that is fixed with the Fabric Version due to the easy way of manipulating what mixins are on and off. Will need to investigate a compatibility method for Forge.

Seems that the Rubidium does have support for disabling mixins so I hope to release an update fixing such.

Due to this line of code being commented out, I can't use the easy method of disabling the mixin within the toml until for 1.19.2. Such should work with 1.19.4 and 1.20 but 1.19.2 will require an update on their side to say the least

Tested the new version, still doesnt work
Latest Logs
[30Aug2023 12:15:56.673] [main/FATAL] [mixin/]: Mixin apply failed seamless_loading_screen-common.mixins.json:LevelLoadingScreenMixin -> net.minecraft.client.gui.screens.LevelLoadingScreen: org.spongepowered.asm.mixin.injection.throwables.InvalidInjectionException @At("INVOKE") on net/minecraft/client/gui/screens/LevelLoadingScreen::changeBackgroundColor with priority 1000 cannot inject into net/minecraft/client/gui/screens/LevelLoadingScreen::m_96149_(Lcom/mojang/blaze3d/vertex/PoseStack;Lnet/minecraft/server/level/progress/StoringChunkProgressListener;IIII)V merged by me.jellysquid.mods.sodium.mixin.features.gui.fast_loading_screen.MixinLevelLoadingScreen with priority 1000 [PREINJECT Applicator Phase -> seamless_loading_screen-common.mixins.json:LevelLoadingScreenMixin -> Prepare Injections ->  -> modify$egi000$changeBackgroundColor(I)I -> Prepare]

Tested the new version, still doesnt work
Latest Logs
[30Aug2023 12:15:56.673] [main/FATAL] [mixin/]: Mixin apply failed seamless_loading_screen-common.mixins.json:LevelLoadingScreenMixin -> net.minecraft.client.gui.screens.LevelLoadingScreen: org.spongepowered.asm.mixin.injection.throwables.InvalidInjectionException @At("INVOKE") on net/minecraft/client/gui/screens/LevelLoadingScreen::changeBackgroundColor with priority 1000 cannot inject into net/minecraft/client/gui/screens/LevelLoadingScreen::m_96149_(Lcom/mojang/blaze3d/vertex/PoseStack;Lnet/minecraft/server/level/progress/StoringChunkProgressListener;IIII)V merged by me.jellysquid.mods.sodium.mixin.features.gui.fast_loading_screen.MixinLevelLoadingScreen with priority 1000 [PREINJECT Applicator Phase -> seamless_loading_screen-common.mixins.json:LevelLoadingScreenMixin -> Prepare Injections ->  -> modify$egi000$changeBackgroundColor(I)I -> Prepare]

This can not be fixed until Rubidum backports the needed feature. Place mixin.features.gui.fast_loading_screen=false into the sodium-mixins.properties file under the config folder as a temp fix until the port gets working as this only applies for 1.19.2

yes i did that, but i found a bug where when you leave the world it doesn't make a new screenshot

Send a log so I got something to go off due to this being a new issue

this is the Latest logs

Due to the size of log file and the limit time for which to try and find the issue, I recommend making a new Issue and possibly narrowing the mod causing the issue. I am closing this issue as resolved with the first issue though.


Fixed yaml syntax for Subscription v2alpha1 spec example

Thank you for helping make the Dapr documentation better!
Please follow this checklist before submitting:

[x] Commits are signed with Developer Certificate of Origin (DCO - learn more)
[x] Read the contribution guide
[x] Commands include options for Linux, MacOS, and Windows within codetabs
[x] New file and folder names are globally unique
[x] Page references use shortcodes instead of markdown or URL links
[x] Images use HTML style and have alternative text
[x] Places where multiple code/command options are given have codetabs

In addition, please fill out the following to help reviewers understand this pull request:
Description

Fixed the v2alpha1 example's spec.routes to be an object instead of array.
Fixed spec.bulkSubscribe's members to not be array values since the parent is not an array.

Issue reference

Thanks for your contribution!

@holopin-bot @adrianhr91 Thank you for your contribution!


POST to leftovers broken

Trying to move to a more recent Deno std lib but things are broken now.
Error: Did not expect an array. key: image
at getUploaded (file:///Users/ollie/Documents/Code/Leftovers/app/handlers/leftovers.ts:148:36)
at async Object.postLeftoverItem [as handler] (file:///Users/ollie/Documents/Code/Leftovers/app/handlers/leftovers.ts:59:20)
at async DsRouteServer.handleRequest (file:///var/folders/6z/x6_ksh3d2blc7s6rn5fy098h0000gn/T/041328701/sandbox-code/ds-route-server.ts:130:4)

Can no longer reproduce. Probably fixed in abebb053aa1174419f1cbce8983e1f3fab2edd19