param being a list of an entity

Say I want to create a create_blog command. One of the params should be a list of posts. How would one go about setting that up with seed factory.

In general, I avoid inserting a list of something by default, as the more data in the DB - the slower tests are. But let's look at a couple of approaches.

Standard and recommended way: use separate commands to create blog and to create posts:

# schema
command :create_blog do
  resolve(...)
  produce :blog
end
command :create_post do
  param :blog, entity: :blog
  resolve(...)
  produce :post
end

# usage
ctx
|> produce(:blog)
|> produce(post: :post1)
|> produce(post: :post2)

Use generate option which generates a list of params. This should work fine if you can generate all data points with faker/etc and other entities (associations) are not required. However, even if posts require other associations, they can be passed using another parameter:

param :post_params, generate: fn -> [%{text: random_text()}, %{text: random_text()}] end
param :post_author, entity: :author
resolve(fn args ->
   post_params = Enum.map(args.post_params, &Map.put(&1, author: args.post_author))
  ...
end)

The downside of this approach is that you cannot put each post separately to the context using produce directive. They can be put only all together as a list of items. I don't have a use case for having an entity that is represented as a list. Perhaps, this approach fits only to embedded data that should not be used as standalone entities outside the parent entity.

Create only a single post with the blog, other posts can be created with a separate command:

command :create_blog do
  param :post do
    param :text, generate: &random_text/0
  end
  param :author, entity: :author

  resolve(fn args ->
    blog = MyApp.create_blog!(args.author)
    post = MyApp.create_post!(blog, args.post, args.author)
    {:ok, %{blog: blog, post: post}}
  end)

  produce :blog
  produce :post
end

command :add_post_to_blog do
  param :blog, entity: :blog
  param :text, generate: &random_text/0

  resolve(fn args ->
    post = MyApp.create_post!(args.blog, %{text: args.text}, args.author)
    {:ok, %{post: post}}
  end)

  produce :post
end

# usage
ctx
|> produce([:blog, post: :post1])
|> rebind([post: :post2], &exec(:add_post_to_blog))

This approach is convenient if you always need a blog and a post to be created at once but sometimes there is a need for more posts. If you don't like rebind + exec, you can create a trait for :post entity that uses add_post_to_blog command and use it in produce:
# schema
...
trait :additional, :post do
  exec :add_post_to_blog
end
# usage
ctx
|> produce([:blog, post: :post1])
|> produce(post: [:additional, as: :post2])

Separate tail and head of the list. This approach doesn't fit into blog + post business domain, but it can be used if you need a list of entities for establishing many-to-many connections

# schema
command :create_email do
  param :sender, entity: :admin
  param :to_recipient, entity: :user
  param :other_to_recipients, generate: fn -> [] end
  resolve(fn args ->
    email = MyApp.save_email!(%{sender: args.sender, to_recipients: [args.to_recipient | args.other_to_recipients]})
    {:ok, %{email: email}}
  end)
  produce :email
end
# usage
produce(ctx, :email) # produces admin, email and user.
# if you need more recipients, then use exec/3 and pass them explicitly
%{user: boss} = produce(ctx, :user)
exec(ctx, :create_email, other_to_recipients: [boss])

And the last approach is when the association is kinda inversed - when you have children entities first and you want to attach them to parent entity at some point.

command :init_uninvoiced_line_item_ids do
  resolve(fn _ ->
    {:ok, %{uninvoiced_line_item_ids: []}}
  end)

  produce :uninvoiced_line_item_ids
end

command :create_line_item_for_cucumber do
  parma :cucumber, entity: :cucumber
  param :uninvoiced_line_item_ids, entity: :uninvoiced_line_item_ids

  resolve(fn args ->
    line_item = MyApp.create_line_item(args.cucumber)

    {:ok,
     %{
       line_item_for_cucumber: line_item,
       uninvoiced_line_item_ids: [line_item.id | args.uninvoiced_line_item_ids]
     }}
  end)

  produce :line_item_for_cucumber
end

command :create_line_item_for_potato do
  parma :potato, entity: :potato
  param :uninvoiced_line_item_ids, entity: :uninvoiced_line_item_ids

  resolve(fn args ->
    line_item = MyApp.create_line_item(args.potato)

    {:ok,
     %{
       line_item_for_potato: line_item,
       uninvoiced_line_item_ids: [line_item.id | args.uninvoiced_line_item_ids]
     }}
  end)

  produce :line_item_for_potato
end

command :create_invoice do
  param :uninvoiced_line_item_ids, entity: :uninvoiced_line_item_ids

  resolve(fn args ->
    invoice = MyApp.create_invoice(args.uninvoiced_line_item_ids)
    {:ok, %{invoice: invoice, uninvoiced_line_item_ids: []}}
  end)
  update :uninvoiced_line_item_ids
  produce :invoice
end

# usage
# create invoice with 1 associated line item
ctx
|> produce(:line_item_for_cucumber)
|> produce(:invoice)

# create invoice with 3 associated line items
ctx
|> produce(:line_item_for_cucumber)
|> produce(:line_item_for_potato: :li_for_potato1, potato: :potato1)
|> produce(:line_item_for_potato: :li_for_potato2, potato: :potato2)
|> produce(:invoice)

Hope it helps.

Thanks for the thorough list of options. I'll certainly have to ponder a bit on those options. I can see the idea behind the first one, but I currently don't allow what would be the blog in this example to be created without posts. So I cannot really do step by step creation. The idea of having each entity somewhat identifiable is certainly powerful, but also might become tedious.
I think for now I'll go with param :series, entity: :series_param, map: &List.wrap/1, which like one of your options at least gives me a list even if just of length 1.
I've a bunch of has_many associations to deal with, so I guess I'll have to see how things go and try out what you suggested.


Error: Request failed with status code 403

When I start the bot, I got this error :
[PteroStats Debug] Error: Request failed with status code 403

But I gave Read & Write permissions to the Admin API
Is it possible that this error occurs because the panel is not under HTTPS?
Or maybe because the Panel URL is an IP not a domain ?
Maybe both ?

same

remake a admin api key

Recreate admin apikey with all permission


Weaver  / Cecil upgrade

It's for the best that #408 is closed. I've gone way past that now. But If you don't like that you are really not going to like what comes next. I don't know what the original reason for switching to source Weaver was, I guess @paulpach will have to speak to that, but sooner or later you are going to have to own this Weaver library. Maybe Unity will continue to produce new Cecil binaries, but maybe not (they haven't in over a year afaik). Maybe the current versions will work for a long time, and maybe not. Inevitably though, something is going to happen where you need to change the behaviour of Weaver or at least update it. It's merely a question of when. Also if I were you, I'd want to wipe out all references to UNet in my netcode just as an eff you for the pain this library caused everyone who relied on it :D 🗡 :D
Fact: Weaver is a tire fire inherited from Unity. The issues I've seen thusfar (after about 8 hours of work):

there's close to zero code quality enforced and the style is inconsistent (eg. there should be clarity about why something is public, but there is not. Weaver class members obviously were hastily rescoped to public and shared among helper classes. Some private members are prefixed m_ ... but some public members are prefixed m_ ... and some of both are not prefixed. Wuuuut?)
basic naming conventions and OO coding 101 were not followed when implementing class members (eg "public static bool fail;" seriously? that is confusing ... you could hardly think of something more confusing if you tried. It looks like a local variable everywhere you see it, but it's used to indicate a GLOBAL FAILURE to weave the current assembly!!!)
the two issues above make it extremely confusing to figure out what the code is even trying to accomplish, let alone why it fails when it fails
your project deserves to have something clear and intelligible where the complexity arises not from hastily written code, but out of the actual complexity of what the code is doing

Most of my work is cosmetic. The functionality remains unchanged, but I'm not just hacking in fixes into this tire fire. That's what Unity obviously kept doing and it did not work out for them. We can do better. I'm reshaping the parts I work on to make sense and be readable. You can actually tell what parts are internal implementation methods and what parts are external APIs (imagine that!). You can see clearly the purpose of public members (which are now Properties) just from their name. If you want I can even add docu, at least to the main Weaver.cs.
I'm now working on adding tests that weave multiple assemblies with known success / failure outcomes so we will be able to know instantly if:

Weaver successfully weaves valid assemblies
Weaver successfully fails to weave invalid assemblies (no crashing or spitting out wrong / incoherent / misleading errors)
updates to a version of Unity cause an issue with Weaver
updates to Weaver cause a regression

You are relying on this library in a big way. The game plan should be independence from anything like Unity Cecil assemblies with uncertain futures and release schedules. I have Weaver successfully using the latest Cecil 0.10.3 in a test branch in my fork. Cecil is (or rather has) been folded into the MS family ... JB Evain (author of Mono and Cecil) now works at MS in Seattle on C# debugging and MS tools for Unity. Cecil is a big part of that and its future is rock solid. MS has been making sizable contributions to Cecil in terms of coding resources, not just fixing bugs but tuning up performance. Regardless of what runtime Unity uses in the future, you are going to be sticking with Cecil.
We should talk about landing these updates in the project somehow once there are tests that prove it is functionally equivalent to what you already have. I'm doing this to lend a hand because it seemed like an issue, and I felt I could grasp it. But if I am mistaken, just let me know and I can work on my transport instead.

Looking forward to your work. Just do be clear, no one likes the weaver as it is.
If you want to do everything in one giant pull requests then that's understandable.
Ideally we prefer small, incremental improvements. E.g. cecil version first. Then fail. Then refactoring one part after another.
It's less risky in case we introduce new bugs. This way we can go back through commits and see when they started.

We should consider moving from Cecil to dnlib, it's a better library created by dnSpy creator

We should consider moving from Cecil to dnlib, it's a better library created by dnSpy creator

Better is often subjective. I'd rather place my longterm bets on the library that MS is throwing resources into. What's better about dnlib and do you expect that to last when Cecil is now being used by MS?

v3.0 requires VS2017 (C#7.3) or later to build it. .NET Core SDK 2.1 or later is also required

That's from dnlib readme. It may indeed be a better library, and we may indeed one day switch to using it, but I don't think they are going in the same direction as we are. Our needs are perfectly aligned with Cecil and we have a non trivial amount of integration to it. It's being used by MS to improve C# debugging and as a basis for Unity tools. We are using it for a Unity tool. It has new Core support and MS clearly has big plans for it, so we are not limited to Unity either. It's the perfect tool for this job and what we are doing with it already works. What can't we do because of Cecil?

Ideally we prefer small, incremental improvements.

Roger that. I will refactor everything into a series of tiny, easy to swallow pills :)

@c6burns dnlib would solve the issue with Unitys packages also supplying Cecil dlls, and its really big adventage is that it works with obfuscated assemblies

Unity doesn't ship those dlls anymore, so is this really a problem going forward? If we wanted we could load Cecil assemblies or generate an error ourselves conditionally based on whether or not certain symbols are already defined, but I think the "f@#$ you delete those old assemblies solution" is good at the moment. Unless Unity re-introduces Cecil into their runtime stuff down the road, we don't have to do anything. I see this as a quality of life issue for an ever decreasing segment of users. It's not a bad idea, but it's also a problem that is currently solving itself.
Wouldn't you obfuscate your assemblies as a last step before shipping? I wouldn't know about this as I've never done it, nor do I have any intention to do it. But if this is a popular thing, we can provide delegates for users to further process DLLs when the weave is complete. If that's not enough, can you provide me with an assembly that fails because it has been obfuscated? It really depends on how it's obfuscating ... if it mangles the attribute names then yeah, obv that's gonna mess up the tool that finds all your stuff by attribute name. Though it's not immediately clear to me why dnlib would be helpful here. Because the obfuscator uses dnlib and your plan would be to just reverse the obfuscation, weave, and then re-obfuscate? I'm not making the connection between this and why we need our weaving to directly use dnlib.
I'll be 100% honest neither of these issues push me anywhere near considering dnlib. Non-trivial is the term for our level of integration with Cecil. It's not as if we have some abstraction for assembly reading / writing such that swapping implementations is simple. Maybe one day, but I'm not doing that right this moment. So bandaids are what I have to offer you for those 2 issues, but they might be very nice bandaids that make you happy :D

It ships them for example with ECS causing ton of errors

OK then I agree. If they are shipping it with ECS we should swap out the namespace on ours. Then we can guarantee we never get hijacked by some rando version of Cecil we don't test against. Or if we ever need theirs for some reason, we could take it and do the same provided that doesn't land us in some kind of licensing limbo.

OK I have Cecil all under the Mono.MirrorCecil namespace. I have it working in the current 2019 beta, with ECS package imported. We can't weave the Unity.Entities.dll or the Unity.Entities.Tests.dll, presumably because they are using overlapping attribs to ours (I didn't actually verify since it seems so plausible). I added these two assemblies to be ignored along with editor assemblies.
It would be pretty trivial to automate this Cecil build as part of some automated Weaver pre-process if we ever get to that point - it's just a pattern replace in the .cs files and the .csproj AssemblyName and RootNamespace tags. But I suspect we are fine with just occasionally dropping in a new Cecil assembly when needed.
I took a good hard look at dynamically instantiating the required types at runtime within an abstraction - using System.Reflection - but that's a serious amount of work compared to what I've done here. While an abstraction would set us up to switch libs to dnlib if we wanted, it's not an easy job and I think it's best to leave well enough alone for now. There are other things I can focus on and this is already a substantial update to a delicate library. Certainly nothing I'm doing now will block us from such future work.
As for obfuscation, I briefly looked into this. They must be tying into the build system using the same hooks we are (through UnityEditor.Compilation). All those hooks are a System.Action aka a Delegate. Delegate execution order is undefined, so I don't see any way to preempt anyone else's delegate. @MichalPetryka if you have specific obfuscators in mind (like one that you use) and they are mangling attribute names (which I think is the only way to trick us ... mangling symbol names isnt enough to break us, is it?) then I'd be happy to take a look, or work with them on a solution. We can provide a post weave delegate for them, or they can provide a pre-obfuscate delegate for us, thus setting up a pipeline.

just to clarify: so Unity does ship cecil with 2019 by default, or only when enabling ECS mode somewhere?
in that case: shouldn't we just use their cecil DLLs and hope for the best?

@vis2k only with ECS

Let's say for some reason we did want to use theirs (which is 0.10.0 cecil). We could actually do that, by using ILMerge and merging theirs as private symbols into one of our own assemblies. Which to be honest it makes me pretty pissed they aren't already doing to not clash with us, but whatevs. But without doing anything, we will be screwed any time someone drops in Unity.Entities.* using package manager

Btw I've solved everything we need. Just writing unit tests where we compile custom assemblies within unity, but outside the unity folder using their AssemblyBuilder

You asked why source?  Debugging it is a royal pain if it is dll based.
By far the weaver is the most complicated part of Mirror.  But it is also extremely useful.  I am not married to unity's cecil.   As vis2k said,  if it can be done in small incremental steps it would be preferred.
It is very important to keep a good workflow.   I don't want to have to compile my game's code outside of unity,  or jump through hoops.

Totally agreed. Everything should work from within Unity for end users. Even the tests are compiling just one assembly at a time and checking the results all within Unity. The only thing happening outside Unity is building the custom cecil assemblies, which I think is fine since that's not part of any use case.
I'm only married to cecil because every single class in the dependency chain beginning with Mirror.Weaver directly interacts with cecil or uses it's types directly in the code (all the processors, the helper, everything below Program class). Also cecil totally works right now, and will probably outlast us all.
I'm finishing my work and then I'll go back and break it into small commits that each leave the library in a good state, but as they progress they will depend on previous commits. So itll be easy to see the work that was done, or hunt for specific commits that introduced an issue, but it won't be easy to take or leave individual commits except the last few.

Another thing:  the first time I saw the fail global variable,  I did not like it.   My first instinct was to replace it with throwing exceptions,  so that we don't have to keep state and we work on a functional way.
But after I thought about it, throwing excepiton, while it would simplify a lot of things,  would mean that you only see the first error.   If you have 10 errors,  it means you would have to fix one at a time, which would slow the developer down.  That is why I have not touched it.

I'm leaving all the functionality of that fail variable in place, but at least it'll be a property that cant be confused with a local variable. WeavingFailed vs fail

Are we still supporting .NET 3.5 going forward, or that's all done and 4.x is a requirement?

4.x

    // Original UNET name is SyncListStruct and original Weaver weavers anything
    // that contains the name 'SyncListStruct', without considering the name-
    // space.
    //
    // In other words, we need another name until the original Weaver is removed
    // in Unity 2019.1.
    //
    // TODO rename back to SyncListStruct after 2019.1!
    public class SyncListSTRUCT<T> : SyncList<T> where T : struct

Can anyone demonstrate the issue that caused this the above name change? I'm in a position to fix it right now, and also I can see that this name change broke several cases where Weaver should be error-ing out but now it doesn't. I'm writing tests for them that I can't get to fail.
Are we still going to switch this name back, or has it been too long?

My bad you guys had made changes that covered everything. It's just error logs still using the old name.  Can't test for those :D


Missing demo source and documentation

The demo shown doesn't really have much source code such as the applied CSS, what createBoard() returns? actions? configs? the props passed to the Board component?
It would be great if I could just run the same demo you generated your screenshot with.

Hey!
I made this for one of my personal projects and that's why it doesn't have any documentation. But nice to see that somebody is using (or trying to) it!
I added an example, https://github.com/Hellenic/react-hexgrid/tree/master/examples/basic-board
and also fixed the example code. Hoping to add some documentation at some point as well.

cool, thanks!

Hi!  Fantastic work!  The grid loads up great in my app, and works seamlessly with video backgrounds.
Any advice on how to swap out the coordinates with custom text?  Or the best way to bind actions to the hex tiles?  Would love to use this as a high level menu of sorts, and just add some 'Router.go()' or href links to each tile.

Hey! Thanks, cool if somebody finds it useful :)
That's a good question. It's somewhat possible but that part is still a bit work in progress, though I haven't had a change to work on it for a long time now. So it can be done but it's definitely not pretty yet.
It's possible to pass actions as a props and it will fall down all the way to the tiles. I have another project where I'm using this:
Passing the actions https://github.com/Hellenic/Cardeon/blob/master/game/src/components/Board.js#L20
and the actual actions (Redux actions + reducers): https://github.com/Hellenic/Cardeon/blob/master/game/src/actions/grid.js and
https://github.com/Hellenic/Cardeon/blob/master/game/src/reducers/grid.js
So for example, when mouse is hovered over a tile it calls some action. Hex object is passed on along with the action. That hex object can have props (e.g. text) which is where you could insert your custom text. So you can change the text on each action if you want or already when the grid is generated, by modifying the hexagons list (grid.hexagons): https://github.com/Hellenic/react-hexgrid/blob/master/examples/basic-board/src/App.js#L15
This is the class where the text etc. gets rendered: https://github.com/Hellenic/react-hexgrid/blob/master/src/HexShape.js
So... As I said, not so pretty yet! :D

Hey, that's clever!  I see what you're doing there.
Thanks for documenting this.  Gotta think on this for a bit; but this definitely helps!

Added few examples and updated README. I believe those should be now quite covering for all the functionality that the library current offers.
Feel free to ask if you feel like something is missing! Closing this for now.

Dude.  This new API is awesome.  Total homerun.  Kudos to you.  This is absolutely fantastic work.


ENT-12105: delete build steps with valid argument count no longer fail validation

Thanks for submitting a pull request! Maybe @craigcomstock can review this?


Support for structured Kronecker factors

[ ] Add support for SINGD baseline. This enables structured Kronecker factors, e.g. diag & full, sparse, etc.
[ ] Update KronLaplace and matrix.py to accommodate the above.

Also check this: https://github.com/aleximmer/Laplace/pull/144/files/824a38e0acf832ca6af4ca86c8b558964796d69d#r1508846116


Allow for custom actions on enter/meta-enter

The custom actions may be set using zstyle configuration. Configuration
is set in the following way:
zstyle ':zaw:<source-name>' default "<func-name|action description>"
zstyle ':zaw:<source-name>' alt "<func-name|action description>"

Also add "(Enter)" or "(Meta-enter)" to the description of actions when
selecting an action.
An example:
# Set default action for git-files using the description
zstyle ':zaw:git-files' default 'append to edit buffer'
# Set alternate action for git-files using the name of function
zstyle ':zaw:git-files' alt zaw-callback-edit-file

Now using Enter/Meta-enter will use the actions mentioned above. When tab is hit and an action is being selected, the following will be displayed, highlighting the default/alt actions for future use:
filter:
select action for 'zaw.zsh'
edit file (Meta-enter)
add
add -p
reset
checkout
rm
append to edit buffer (Enter)
[1/7]

I think I've addressed your comments @termoshtt. Thanks for the feedback.

OK, looks good for me. Thanks your contribution!

No worries.


Support Jupyerlab 4.x

I tried to follow this guide from Jupyerlab to upgrade our jupyerlab version from 3.x to 4.x and hopefully fix CI failures like this one: https://github.com/protectai/nbdefense-jupyter/actions/runs/5490860882/job/14871335551?pr=16
Overall I tried to keep all the changes from the upgrade script as-is, but I did remove some boilerplate for testing that the script added and some new GH workflows it tried to introduce. When trying to run make install-dev after using the script, I got the below error that seemed to come from changes to pyproject.toml.
Opening this issue to track progress on upgrading to jupyterlab 4.x. After performing the upgrade, we should test:

[ ] All make targets are working as expected
[ ] All GH workflows are passing (including the release workflow)
[ ] The extension works as expected in a real jupyter notebook (sanity check)

 Full stack trace
make install-dev
pip uninstall nbdefense_jupyter -y
Found existing installation: nbdefense_jupyter 0.dev0
Uninstalling nbdefense_jupyter-0.dev0:
  Successfully uninstalled nbdefense_jupyter-0.dev0
pip install -e .[dev]
Obtaining file:///Users/williamarmiros/open-source/willarmiros/nbdefense-jupyter
  Installing build dependencies ... done
  Checking if build backend supports build_editable ... done
  Getting requirements to build editable ... done
  Installing backend dependencies ... done
  Preparing editable metadata (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Preparing editable metadata (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [245 lines of output]
      INFO:hatch_jupyter_builder.utils:Running jupyter-builder
      INFO:hatch_jupyter_builder.utils:Building with hatch_jupyter_builder.npm_builder
      INFO:hatch_jupyter_builder.utils:With kwargs: {'build_cmd': 'install:extension', 'npm': ['jlpm'], 'source_dir': 'src', 'build_dir': 'nbdefense_jupyter/labextension'}
      INFO:hatch_jupyter_builder.utils:Installing build dependencies with npm.  This may take a while...
      INFO:hatch_jupyter_builder.utils:> /private/var/folders/h_/krvxw1n979352w3lz6kmhpdc0000gn/T/pip-build-env-trp69c37/overlay/bin/jlpm install
      ➤ YN0000: ┌ Resolution step
      ➤ YN0002: │ @jupyterlab/services@npm:7.0.3 doesn't provide react (pc77de), requested by @jupyterlab/settingregistry
      ➤ YN0002: │ @jupyterlab/testutils@npm:4.0.3 doesn't provide typescript (p05ec7), requested by @jupyterlab/testing
      ➤ YN0060: │ nbdefense-jupyter@workspace:. provides jest (pe2690) with version 29.6.1, which doesn't satisfy what ts-jest requests
      ➤ YN0060: │ nbdefense-jupyter@workspace:. provides typescript (p51b1a) with version 5.0.4, which doesn't satisfy what ts-jest requests
      ➤ YN0002: │ nbdefense-jupyter@workspace:. doesn't provide webpack (p82f71), requested by css-loader
      ➤ YN0002: │ nbdefense-jupyter@workspace:. doesn't provide webpack (pced70), requested by source-map-loader
      ➤ YN0002: │ nbdefense-jupyter@workspace:. doesn't provide webpack (p3ef88), requested by style-loader
      ➤ YN0000: │ Some peer dependencies are incorrectly met; run yarn explain peer-requirements <hash> for details, where <hash> is the six-letter p-prefixed code
      ➤ YN0000: └ Completed
      ➤ YN0000: ┌ Fetch step
      ➤ YN0000: └ Completed
      ➤ YN0000: ┌ Link step
      ➤ YN0000: └ Completed in 0s 248ms
      ➤ YN0000: Done with warnings in 0s 622ms
      INFO:hatch_jupyter_builder.utils:> /private/var/folders/h_/krvxw1n979352w3lz6kmhpdc0000gn/T/pip-build-env-trp69c37/overlay/bin/jlpm run install:extension
      node_modules/@types/codemirror/index.d.ts(553,39): error TS2304: Cannot find name 'DocumentAndElementEventHandlersEventMap'.
      node_modules/@types/codemirror/index.d.ts(555,48): error TS2304: Cannot find name 'DocumentAndElementEventHandlersEventMap'.
      node_modules/@types/codemirror/index.d.ts(563,40): error TS2304: Cannot find name 'DocumentAndElementEventHandlersEventMap'.
      node_modules/@types/codemirror/index.d.ts(565,48): error TS2304: Cannot find name 'DocumentAndElementEventHandlersEventMap'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3085,14): error TS2300: Duplicate identifier 'LibraryManagedAttributes'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3096,13): error TS2717: Subsequent property declarations must have the same type.  Property 'a' must be of type 'DetailedHTMLProps<AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>', but here has type 'DetailedHTMLProps<AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3097,13): error TS2717: Subsequent property declarations must have the same type.  Property 'abbr' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3098,13): error TS2717: Subsequent property declarations must have the same type.  Property 'address' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3099,13): error TS2717: Subsequent property declarations must have the same type.  Property 'area' must be of type 'DetailedHTMLProps<AreaHTMLAttributes<HTMLAreaElement>, HTMLAreaElement>', but here has type 'DetailedHTMLProps<AreaHTMLAttributes<HTMLAreaElement>, HTMLAreaElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3100,13): error TS2717: Subsequent property declarations must have the same type.  Property 'article' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3101,13): error TS2717: Subsequent property declarations must have the same type.  Property 'aside' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3102,13): error TS2717: Subsequent property declarations must have the same type.  Property 'audio' must be of type 'DetailedHTMLProps<AudioHTMLAttributes<HTMLAudioElement>, HTMLAudioElement>', but here has type 'DetailedHTMLProps<AudioHTMLAttributes<HTMLAudioElement>, HTMLAudioElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3103,13): error TS2717: Subsequent property declarations must have the same type.  Property 'b' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3104,13): error TS2717: Subsequent property declarations must have the same type.  Property 'base' must be of type 'DetailedHTMLProps<BaseHTMLAttributes<HTMLBaseElement>, HTMLBaseElement>', but here has type 'DetailedHTMLProps<BaseHTMLAttributes<HTMLBaseElement>, HTMLBaseElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3105,13): error TS2717: Subsequent property declarations must have the same type.  Property 'bdi' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3106,13): error TS2717: Subsequent property declarations must have the same type.  Property 'bdo' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3107,13): error TS2717: Subsequent property declarations must have the same type.  Property 'big' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3108,13): error TS2717: Subsequent property declarations must have the same type.  Property 'blockquote' must be of type 'DetailedHTMLProps<BlockquoteHTMLAttributes<HTMLQuoteElement>, HTMLQuoteElement>', but here has type 'DetailedHTMLProps<BlockquoteHTMLAttributes<HTMLQuoteElement>, HTMLQuoteElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3109,13): error TS2717: Subsequent property declarations must have the same type.  Property 'body' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLBodyElement>, HTMLBodyElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLBodyElement>, HTMLBodyElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3110,13): error TS2717: Subsequent property declarations must have the same type.  Property 'br' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLBRElement>, HTMLBRElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLBRElement>, HTMLBRElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3111,13): error TS2717: Subsequent property declarations must have the same type.  Property 'button' must be of type 'DetailedHTMLProps<ButtonHTMLAttributes<HTMLButtonElement>, HTMLButtonElement>', but here has type 'DetailedHTMLProps<ButtonHTMLAttributes<HTMLButtonElement>, HTMLButtonElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3112,13): error TS2717: Subsequent property declarations must have the same type.  Property 'canvas' must be of type 'DetailedHTMLProps<CanvasHTMLAttributes<HTMLCanvasElement>, HTMLCanvasElement>', but here has type 'DetailedHTMLProps<CanvasHTMLAttributes<HTMLCanvasElement>, HTMLCanvasElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3113,13): error TS2717: Subsequent property declarations must have the same type.  Property 'caption' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3114,13): error TS2717: Subsequent property declarations must have the same type.  Property 'cite' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3115,13): error TS2717: Subsequent property declarations must have the same type.  Property 'code' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3116,13): error TS2717: Subsequent property declarations must have the same type.  Property 'col' must be of type 'DetailedHTMLProps<ColHTMLAttributes<HTMLTableColElement>, HTMLTableColElement>', but here has type 'DetailedHTMLProps<ColHTMLAttributes<HTMLTableColElement>, HTMLTableColElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3117,13): error TS2717: Subsequent property declarations must have the same type.  Property 'colgroup' must be of type 'DetailedHTMLProps<ColgroupHTMLAttributes<HTMLTableColElement>, HTMLTableColElement>', but here has type 'DetailedHTMLProps<ColgroupHTMLAttributes<HTMLTableColElement>, HTMLTableColElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3118,13): error TS2717: Subsequent property declarations must have the same type.  Property 'data' must be of type 'DetailedHTMLProps<DataHTMLAttributes<HTMLDataElement>, HTMLDataElement>', but here has type 'DetailedHTMLProps<DataHTMLAttributes<HTMLDataElement>, HTMLDataElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3119,13): error TS2717: Subsequent property declarations must have the same type.  Property 'datalist' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLDataListElement>, HTMLDataListElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLDataListElement>, HTMLDataListElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3120,13): error TS2717: Subsequent property declarations must have the same type.  Property 'dd' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3121,13): error TS2717: Subsequent property declarations must have the same type.  Property 'del' must be of type 'DetailedHTMLProps<DelHTMLAttributes<HTMLModElement>, HTMLModElement>', but here has type 'DetailedHTMLProps<DelHTMLAttributes<HTMLModElement>, HTMLModElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3122,13): error TS2717: Subsequent property declarations must have the same type.  Property 'details' must be of type 'DetailedHTMLProps<DetailsHTMLAttributes<HTMLDetailsElement>, HTMLDetailsElement>', but here has type 'DetailedHTMLProps<DetailsHTMLAttributes<HTMLDetailsElement>, HTMLDetailsElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3123,13): error TS2717: Subsequent property declarations must have the same type.  Property 'dfn' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3124,13): error TS2717: Subsequent property declarations must have the same type.  Property 'dialog' must be of type 'DetailedHTMLProps<DialogHTMLAttributes<HTMLDialogElement>, HTMLDialogElement>', but here has type 'DetailedHTMLProps<DialogHTMLAttributes<HTMLDialogElement>, HTMLDialogElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3125,13): error TS2717: Subsequent property declarations must have the same type.  Property 'div' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLDivElement>, HTMLDivElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLDivElement>, HTMLDivElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3126,13): error TS2717: Subsequent property declarations must have the same type.  Property 'dl' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLDListElement>, HTMLDListElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLDListElement>, HTMLDListElement>'.
      ....
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3268,13): error TS2717: Subsequent property declarations must have the same type.  Property 'symbol' must be of type 'SVGProps<SVGSymbolElement>', but here has type 'SVGProps<SVGSymbolElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3269,13): error TS2717: Subsequent property declarations must have the same type.  Property 'text' must be of type 'SVGTextElementAttributes<SVGTextElement>', but here has type 'SVGProps<SVGTextElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3270,13): error TS2717: Subsequent property declarations must have the same type.  Property 'textPath' must be of type 'SVGProps<SVGTextPathElement>', but here has type 'SVGProps<SVGTextPathElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3271,13): error TS2717: Subsequent property declarations must have the same type.  Property 'tspan' must be of type 'SVGProps<SVGTSpanElement>', but here has type 'SVGProps<SVGTSpanElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3272,13): error TS2717: Subsequent property declarations must have the same type.  Property 'use' must be of type 'SVGProps<SVGUseElement>', but here has type 'SVGProps<SVGUseElement>'.
      node_modules/@types/react-dom/node_modules/@types/react/index.d.ts(3273,13): error TS2717: Subsequent property declarations must have the same type.  Property 'view' must be of type 'SVGProps<SVGViewElement>', but here has type 'SVGProps<SVGViewElement>'.
      node_modules/@types/react/ts5.0/index.d.ts(3194,19): error TS2320: Interface 'ElementClass' cannot simultaneously extend types 'Component<any, {}, any>' and 'Component<any, {}, any>'.
        Named property 'context' of types 'Component<any, {}, any>' and 'Component<any, {}, any>' are not identical.
      node_modules/@types/react/ts5.0/index.d.ts(3194,19): error TS2320: Interface 'ElementClass' cannot simultaneously extend types 'Component<any, {}, any>' and 'Component<any, {}, any>'.
        Named property 'props' of types 'Component<any, {}, any>' and 'Component<any, {}, any>' are not identical.
      node_modules/@types/react/ts5.0/index.d.ts(3194,19): error TS2320: Interface 'ElementClass' cannot simultaneously extend types 'Component<any, {}, any>' and 'Component<any, {}, any>'.
        Named property 'refs' of types 'Component<any, {}, any>' and 'Component<any, {}, any>' are not identical.
      node_modules/@types/react/ts5.0/index.d.ts(3202,14): error TS2300: Duplicate identifier 'LibraryManagedAttributes'.
      src/handler.ts(28,45): error TS2345: Argument of type 'unknown' is not assignable to parameter of type 'TypeError'.
      src/utils/editorErrorsUtils.tsx(106,13): error TS2322: Type 'import("/Users/williamarmiros/open-source/willarmiros/nbdefense-jupyter/node_modules/@types/react-dom/node_modules/@types/react/index").ReactPortal | undefined' is not assignable to type 'React.ReactPortal | undefined'.
        Type 'import("/Users/williamarmiros/open-source/willarmiros/nbdefense-jupyter/node_modules/@types/react-dom/node_modules/@types/react/index").ReactPortal' is not assignable to type 'React.ReactPortal'.
          Types of property 'children' are incompatible.
            Type 'import("/Users/williamarmiros/open-source/willarmiros/nbdefense-jupyter/node_modules/@types/react-dom/node_modules/@types/react/index").ReactNode' is not assignable to type 'React.ReactNode'.
              Type '{}' is not assignable to type 'ReactNode'.
      src/utils/editorErrorsUtils.tsx(148,29): error TS2339: Property 'markText' does not exist on type 'Text'.
      src/widgets/NBDefenseWidget.tsx(23,11): error TS2554: Expected 0 arguments, but got 1.
      Traceback (most recent call last):
        File "/Users/williamarmiros/miniconda/lib/python3.10/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 167, in prepare_metadata_for_build_editable
          hook = backend.prepare_metadata_for_build_editable
      AttributeError: module 'hatchling.build' has no attribute 'prepare_metadata_for_build_editable'

      During handling of the above exception, another exception occurred:

      Traceback (most recent call last):
        File "/Users/williamarmiros/miniconda/lib/python3.10/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
          main()
        File "/Users/williamarmiros/miniconda/lib/python3.10/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
        File "/Users/williamarmiros/miniconda/lib/python3.10/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 176, in prepare_metadata_for_build_editable
          whl_basename = build_hook(metadata_directory, config_settings)
        File "/private/var/folders/h_/krvxw1n979352w3lz6kmhpdc0000gn/T/pip-build-env-trp69c37/overlay/lib/python3.10/site-packages/hatchling/build.py", line 78, in build_editable
          return os.path.basename(next(builder.build(wheel_directory, ['editable'])))
        File "/private/var/folders/h_/krvxw1n979352w3lz6kmhpdc0000gn/T/pip-build-env-trp69c37/overlay/lib/python3.10/site-packages/hatchling/builders/plugin/interface.py", line 150, in build
          build_hook.initialize(version, build_data)
        File "/private/var/folders/h_/krvxw1n979352w3lz6kmhpdc0000gn/T/pip-build-env-trp69c37/normal/lib/python3.10/site-packages/hatch_jupyter_builder/plugin.py", line 87, in initialize
          raise e
        File "/private/var/folders/h_/krvxw1n979352w3lz6kmhpdc0000gn/T/pip-build-env-trp69c37/normal/lib/python3.10/site-packages/hatch_jupyter_builder/plugin.py", line 82, in initialize
          build_func(self.target_name, version, **build_kwargs)
        File "/private/var/folders/h_/krvxw1n979352w3lz6kmhpdc0000gn/T/pip-build-env-trp69c37/normal/lib/python3.10/site-packages/hatch_jupyter_builder/utils.py", line 115, in npm_builder
          run([*npm_cmd, "run", build_cmd], cwd=str(abs_path))
        File "/private/var/folders/h_/krvxw1n979352w3lz6kmhpdc0000gn/T/pip-build-env-trp69c37/normal/lib/python3.10/site-packages/hatch_jupyter_builder/utils.py", line 229, in run
          return subprocess.check_call(cmd, **kwargs)
        File "/Users/williamarmiros/miniconda/lib/python3.10/subprocess.py", line 369, in check_call
          raise CalledProcessError(retcode, cmd)
      subprocess.CalledProcessError: Command '['/private/var/folders/h_/krvxw1n979352w3lz6kmhpdc0000gn/T/pip-build-env-trp69c37/overlay/bin/jlpm', 'run', 'install:extension']' returned non-zero exit status 1.
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
make: *** [install-dev] Error 1

We need to continue to support JL 3 for foreseeable future as most Jupyterlab as a service offerings do not support v4 yet and likely won't for the next 3-6 months. JL 4 support needs to be in addition to JL 3. It might need code in two separate branches.


storage: implement async commit prewrite (initial work)

This PR is ready to land (I hope) but not ready for use. I'm submitting now to get early feedback that the logic is correct, that it is low risk (i.e., if the client is not setting use_async_commit, then we are not doing anything differently, and that it is heading in the right direction.
This PR updates kvproto to a version with the async commit fields. Propagates them to the Prewrite command (optimistic transactions only for now), propagates a pd client through various layers to MvccTxn and uses that to get a timestamp from PD. It saves the secondary keys and timestamp to the lock of the primary key.
PTAL @youjiali1995 @MyonKeminta
Release note

No release note

It's really a lot of effort to add the pd client. 😢

It's really a lot of effort to add the pd client. 😢

Exactly. And that's right my biggest motivation of refactoring...

It's really a lot of effort to add the pd client. 😢

It is. I hope it is useful in the future

We should make sure if the client does not set use_async_commit, there won't be async commit information in the lock. Otherwise, old version TiKV would fail to parse the lock during a rolling update.

And without a memory lock, it is still possible that data is read unexpectedly when we get min_commit_ts from PD. If it's a long time between getting the timestamp from PD and RaftKV apply, a client may use a rather big snapshot timestamp to read. It will still affect the correctness. IMO a FIXME is needed.

Both addressed, PTAL @sticnarf

@MyonKeminta @youjiali1995 PTAL. Thanks!

/merge


Updates translation pt-BR

Do you plan more commits?

Yeah, I plan now but was not planned till yesterday. Lets do this way: you merge this because I feel it is important to be available asap and the next ones I will PR only once a week. Agree, @samdark ?

Still better, wait more some hours because I just saw that instalation guide is completely outdated and wrong.

Ok, @samdark, go ahead!

Merged. Thanks!


Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

I am trying to use VectorDBBench tool for benchmarking my cluster running in AWS. This cluster is SSL enabled. On the new VectorDBbench interface there is no option for supplying client cert, key and cacert. It used to be there on the previous version of the tool. Has it been removed? Are there any other options?

What DB are you testing on? Are you using db client already in the repo?
If it's self deployed Milvus, try to use this url: "https://host:port"

Sorry, it is for benchmarking a Milvus cluster running in AWS. I have a gslb in between via port 443.

Issue is on the benchmarking tool UI I don't have an option to pass the certificates. Is there a way to pass the certs for authentication.

2024-10-11 13:26:21,274 | INFO: generated uuid for the tasks: 59ee8846a56a4720b4b31c0570aed950 (interface.py:66) (61581)
2024-10-11 13:26:22,180 | INFO | DB             | CaseType     Dataset               Filter | task_label (task_runner.py:338)
2024-10-11 13:26:22,180 | INFO | -----------    | ------------ -------------------- ------- | -------    (task_runner.py:338)
2024-10-11 13:26:22,180 | INFO | Milvus-endor_1M | Performance  Cohere-MEDIUM-1M        None |<PHONE_NUMBER>_endor_1M (task_runner.py:338)
2024-10-11 13:26:22,180 | INFO: task submitted: id=59ee8846a56a4720b4b31c0570aed950,<PHONE_NUMBER>_endor_1M, case number: 1 (interface.py:231) (61581)
2024-10-11 13:26:23.776 WARNING streamlit.runtime.scriptrunner_utils.script_run_context: Thread 'MainThread': missing ScriptRunContext! This warning can be ignored when running in bare mode.
2024-10-11 13:26:25,668 | INFO: [1/1] start case: {'label': <CaseLabel.Performance: 2>, 'dataset': {'data': {'name': 'Cohere', 'size': 1000000, 'dim': 768, 'metric_type': <MetricType.COSINE: 'COSINE'>}}, 'db': 'Milvus-endor_1M'}, drop_old=True (interface.py:164) (63512)
2024-10-11 13:26:25,668 | INFO: Starting run (task_runner.py:100) (63512)
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
E0000 00:00:1728633386.551237 2878134 ssl_transport_security.cc:1654] Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
E0000 00:00:1728633386.804475 2878144 ssl_transport_security.cc:1654] Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

I am getting this error: [__internal_register] retry:4, cost: 0.27s, reason: <_InactiveRpcError: StatusCode.INTERNAL, Received http2 header with status: 400>

Looks like pymilvus is unable to connect with Milvus through gslb. I'll seek some help from our devops expertise.

@samjax In the mean time, could you try to pass the certificats like this and connect with Milvus successfully? https://milvus.io/docs/tls.md#Two-way-TLS-connection


Render Text Cache

Adds draw_text to use image-rasters as an intermediate step and avoid recreating the required text and correctly sizing the text.


Area2d area_entered reporting innacurate collisions on Isometric TileMap's Scene Tiles

Godot version
v4.0.1.stable.official [cacf49999]
System information
Windows 10, AMD 6800xt on 22.11.1 Adrenalin drivers, GLES3 & Vulcan
Issue description
Using a TileMap with tile shape set to isometric, and the tiles being a scene tile with a CollisionShape2d matching the shape of one isometric tile, detecting collisions with a circular Area2d node reports collisions that are not actually happening. When compared to the tile shape being square on the TileMap, it seems far less accurate.
Square TileMap:

Isometric TileMap:

For what its worth, I've also notice that skewing the circular collider to match the skew of the isometric tile also give strange results.
Isometric TileMap with skewed circular collider:

Steps to reproduce
If using the minimal repro project, enable Visible Collision Shapes in debug before running
Create a 2d scene for the gridtile, give it a CollisionShape2d and Polygon2d, set the sizes to whatever size the tile size will be.
Skew the CollisionShape and the Polygon by 36 degrees, and rotate them 27 degrees.
Create a new scene with a TileMap, set tile shape to isometric, add the tile scene created earlier, adjust tile size as needed.
Create another new scene with a circular CollisionShape2d, and in the tile scene create a script to change the modulate color of the tile's Polygon2d on area_enetered and area_exit to visualize the collisions.
Turn on show collisions in debug menu for better visualization.
Minimal reproduction project
area2dDebug.zip

For what its worth, I've also notice that skewing the circular collider to match the skew of the isometric tile also give strange results.
Isometric TileMap with skewed circular collider:

Non-uniform scaling of PhysicsBodies or collision shapes is not supported. Use a polygon collider to create a squished circle instead.


add logic to choose default disk

Which issue this PR addresses:
https://msazure.visualstudio.com/AzureRedHatOpenShift/_backlogs/backlog/Chainsaw/Stories/?workitem=14884568

Fixes
What this PR does / why we need it:
The current install config does not pass in a disk type for the OSDisk, which results in it being set to Premium_LRS by default. However, not all supported VM Sizes are able to use premium disks, so creation of the nodes would fail. This PR explicitly sets OSDisk type for all VMs, either to Standard for those that need it or Premium for any others.

Test plan for issue:
Unit tests for disk selection logic created in generateconfig_test.go. Further e2e tests to ensure Standard-type VMs are available after creation are in progress.

Is there any documentation that needs to be updated for this PR?
Updates to customer-facing documentation are part of this story

IMO we shouldn't be hardcoding these values. When azure changes or introduces new instance types which do or do not support premium LRS disk types, we're always going to be changing and updating this file.
Does the VM SKUs API provide anything that will show if it supports a premium disk type?
az vm list-skus --all | jq -r '.[] | .name as $NAME | .capabilities[]? | select(.name == "PremiumIO") | [$NAME, .value]'

It appears it would be possible to do and is similar to what is being done in upstream validation.
That brings up another question. We already have a list of supported VMSizes in pkg/api/openshiftcluster.go, should we have something similar for the OSDisk type, or are we not worried about hard-coding these values as strings?

Refactored code to use existing functions to check for PremiumIO capability.
Since we have no defined list of VM capabilities that I could find I double-checked MSFT documentation to ensure I had the capability name correct.


[TASK] Fix how h is computed

The current version is insecure because the extended witness is reveal in the clear to the King. The correct way to do this can be found at https://github.com/arkworks-rs/groth16/blob/c7e8adec6101f0c51a042fa73f0e31dc344d1ab4/src/r1cs_to_qap.rs#L150.

[x] Cleanup the distributed FFT implementation and implement a coset FFT
[ ] Fix how h is computed as described in the arkworks implemenation of groth16

While I do agree, please keep in mind that we do compute it differently per circom backend, which is defined here: https://github.com/arkworks-rs/circom-compat/blob/170b10fc9ed182b5f72ecf379033dda023d0bf07/src/circom/qap.rs#L23
We should keep both, if they return results differently, should they? The main reason they have two different implementation is that in Circom, the c Matric in the ConstraintMatrices is always empty https://github.com/arkworks-rs/circom-compat/blob/170b10fc9ed182b5f72ecf379033dda023d0bf07/src/zkey.rs#L192
Different format, same thing.
And for the witness reveal to the king, I implemented it that way (knowing it is not the secure way) because we wanted a PoC. Now it is time to make it secure (by adding randomness?)

If the two implementations need to be different due to circom vs arkworks differences, yes let's add both. Simultaneously, yes let's ensure that both preserve privacy.


Added workaround for lost credentials (#4)

not sure which problems you try to fix for me it looks more you should contribute this to converse.js: https://github.com/conversejs/converse.js/

This is related to #4 and is - as said - a workaround until the underlying issues in Franz / electron are solved there. I don't think that it is related to converse because their client does fine and probably they can do nothing about it (a reasonable approach for that would be using the Credential Management API but this isn't available in electron and so it wouldn't help anyway)

@copitz I think doing this in JS saving it into the localstorage will open a huge security issue that somebody can read the credentials. So I would currently not merge this. Also it overwrite the whole page which could break when there are changes in inverse.chat.


PageContext.ViewData and ViewContext.ViewData are different instances in Razor Pages

Original issue was discovered in Identity UI and is linked below:
Details

PageActionInvoker creates a ViewContext instance using PageContext.ViewData. At this point, ViewContext.ViewData = PageContext.ViewData  =ViewData<MyPageModel>.
If the Page has an associated _ViewStart.cshtml,  the page execution results in a ViewContext.ViewData = new ViewDataDictionary<object>(ViewContext.ViewData).
When the page executes, we initialize an instance of RazorPageAdapter to avoid double initialization. RazorPageAdapter does not have a model property and ends up producing yet another ViewContext.ViewData = new ViewDataDictionary<object>(ViewContext.ViewData)
The ViewData property on the actual Page keys off of PageContext:
public global::Microsoft.AspNetCore.Mvc.ViewFeatures.ViewDataDictionary<TestModel> ViewData => (global::Microsoft.AspNetCore.Mvc.ViewFeatures.ViewDataDictionary<TestModel>)PageContext?.ViewData;

To recap, at this point, in cshtml,
this.ViewData  -> ViewData<MyPageModel>
ViewContext.ViewData -> new ViewData<object>(new ViewData<object>(this.ViewData));

ViewContext.ViewData is what gets passed to Layout, partials etc.

Why this works:
The  🎩  ✋ 🐰 magic of CopyOnWriteDictionary. If the _ViewStart or any other component, does not write to ViewData, ViewContext.ViewData has effectively the same backing store as this.ViewData. Any writes to it show up in ViewContext.ViewData. This obviously breaks if something expressly writes to ViewContext.ViewData. In the Identity UI case, this is the filter that we broke detailed in https://github.com/aspnet/Mvc/issues/7665.

Original issue
From @kichalla on April 6, 2018 0:8
For example, when we go to Manage page, we should see the title of the html page to be like Profile - <application-name> but we only get  - <application-name>.
@pranavkm and I debugged through this and think that the cause of this issue could be with how Identity UI uses a model type(abstract) on the view versus the actual type(implementation). Following line of code is a suspect:
https://github.com/aspnet/Mvc/commit/7127bb5dbbb07eb325a2852ac9a91be0cf443205#diff-0901f55a5e636aeef89b9663dafcb625R171
Copied from original issue: aspnet/Identity#1737

Are we planning to do something here for 2.1? Is this a patch candidate?  Is this caused by us writing to the viewdata in the filter? (Will this get fixed as part of the other issue?)

@javiercn, please evaluate how big of a change is this?

I think this warrants further investigation. It wasn't super obvious what a fix for this is and there could be other things that were broken as a result of activating RazorPageAdapter rather than the actual page. I don't feel confident in rushing a fix for this in the next couple of days. My suggestion would be
a) to address this in a patch (or 2.2.0). For the time being, there's a trivial workaround viz to use ViewContext.ViewData in the Razor Page to avoid losing values.
b) Fix Identity to either use HttpContext.Items or use ViewContext.ViewData in the page to workaround the original reported issue - https://github.com/aspnet/Identity/issues/1737

Can we evaluate what identity UI is doing as a feature request?
This is an implementation detail. And there are workarounds.

@rynowak This has nothing to do with Identity UI. According to @pranavkm there is something broken here in a more fundamental level. I just happened to trigger it.
I think this is just a bug and we should look into fixing it, when we deem it appropriate. It does not make sense to me to turn this in into a "feature request".
I can likely workaround this by writing stuff to the HttpContext instance instead of the view data, but that's not the point.

Another scenario listed here - https://github.com/aspnet/Mvc/issues/7408

Fixed in https://github.com/aspnet/Mvc/commit/b62499e02c274db162151556318b0a5fae85360e

@mkArtakMSFT I just hit this issue when writing up aspnet/Razor#2539 and using 2.1.2. One impact is that changing ViewData.TemplateInfo.HtmlFieldPrefix in a Razor Page has no impact on the name, id or for attributes that HTML and tag helpers in the page generate. All of this works fine in MVC views.
Put another way, after applying the aspnet/Razor#2539 workaround, the Razor Page version of the repro still fails to generate correct names while the MVC View version works perfectly.
Suggest we port this fix to 2.1.x.

Per our offline discussion we won't be patching this. The reason is that there is no enough usage of this scenario.


refactor: remove unnecessary checks

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[ ] Feature
[ ] Code style update
[x] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:

[ ] It's submitted to the dev branch for v2.x (or to a previous version branch), not the master branch
[ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[ ] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
[ ] New/updated tests are included

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
Through the processing of the mergeOptions function, the type of vm.$options.data is either a function or undefined. And in the initState function has filtered out the possibility of undefined, so in the initData function vm.$options.data must be a function

Hi, I think these checks are necessary.
For example:
const app = new Vue({
    el: '#app',
    data: {
        name: 'Jooger'
    },
    beforeCreate () {
        this.$options.data = {
            name: 'Jooger2'
        }
    }
})

Because beforeCreate is executed before initData, it is necessary to check the data type in initData if I change vm.$option.data in beforeCreate

@jo0ger They were reverted

learn English


Wrap bin group in conditional for BUILD.gn

This group needs to be wrapped in the if conditional otherwise the deps can't be found.

Simple build change, landing TBR.


Road to cop28

Hi Anna, here is our proposal for Road to COP28 events series (Forum post: https://forum.celo.org/t/proposal-web3-x-sdg-event-proposal-for-road-to-cop28/6225/22).

@juanjgiraldoc , yes this is done. Thank you for your help.

Thank you, @dhruvmalik007 for your amazing support and @juanjgiraldoc


Contrast the current frozen version of ADASilk with the previous evaluation

Since June 2020, various documents have been produced by the domain experts to evaluate very early versions of ADASilk. See this document that also links to other documents.
ADASilk has been greatly improved the last months. I suggest that @ehrhart produces a document that check what is left to be addressed from these previous evaluations.

This was done as part of the deliverable D6.7.


MAPL_GranuleGridFactory draft

Description
GranuleGridFactory is an extension of the LatLonGridFactory where a logically rectangular grid from observation can be read from netCDF. HistoryGridComp can use GranuleGridFactory to output/interpolate fields from cube sphere to this rectilinear grid.
Related Issue

A few initialization methods are not tested and need further work:

initialize_from_file_metadata
initialize_from_esmf_distGrid
GranuleGridFactory_from_parameters

I have not worked on the _RC macro replacement yet.

Motivation and Context

This work is useful for a general interpolation from model to obs grid

How Has This Been Tested?
ExtDataDriver.x is used to test the code.  Thank @bena-nasa for many help!
A non-uniform quasi-rectangular grid as below can be imported to ESFM_grid and output to history.
lons =
2.20069098472595, 23.1008815765381, 47.0075759887695, 68.9785690307617,
1.8676301240921, 22.6600914001465, 46.9890670776367, 67.7191543579102,
1.92321562767029, 22.9546718597412, 45.2667770385742, 67.6193466186523,
1.21984219551086, 24.2904720306396, 46.9641456604004, 69.6375961303711,
0.8646280169487, 23.2427845001221, 45.0278625488281, 67.8411560058594,
1.97048604488373, 23.4698524475098, 45.4552268981934, 69.0879135131836 ;
lats =
-29.5109596252441, -29.8664703369141, -29.5538692474365, -29.6714305877686,
-19.5849704742432, -19.9644241333008, -19.5579853057861, -19.9512977600098,
-9.57261848449707, -9.89896202087402, -9.94071674346924, -9.97347927093506,
0.271076053380966, 0.397882521152496, 0.436476975679398, 0.475021362304688,
10.1921396255493, 10.1650629043579, 10.0061912536621, 10.0758123397827,
20.4378852844238, 20.2155227661133, 20.1011619567871, 20.3528709411621 ;

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Trivial change (affects only documentation or cleanup)

Checklist:

[ ] I have tested this change with a run of GEOSgcm (if non-trivial)
[ ] I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
[ ] I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

@metdyn A couple of things to do (just so you can get used to it).

You need to make an entry in our CHANGELOG.md for this PR. We require it on all but the most trivial PRs (e.g., updated a readme). We follow Keep a Changelog style which is pretty self-explanatory.
You need to add a label letting us know if this is 0-diff or non-zero-diff. What we mean by that is "If you run this PR with a C48 run of GEOSgcm, does it change the state?" Now, I can't see how this could, so "0 diff" is probably the right label.

@mathomp4, thank for explaining the details and it is very helpful!

Ooh. I see another issue. You are making this PR against main. As a new feature it should be against develop. Did you start from main or develop when you made this PR?

Thank you @mathomp4 for letting me know.  I had started from develop, but switched to main later on.  Now I need to make changes and merge to develop. I will rename this branch to Swath, close this PR and resubmit the PR to merge to develop.

On first glance, I'm quite confused, why are there any 1D coordinate arrays being stored at all as part of the class definition? The whole point of this is that that we are going to read in coordinates that do not satisfy the criteria potentially of a lat-lon grid (the lon or lat if fixed as one of the grid indices vary). So I would think that the class itself storing any coordinates is unnecessary, the grid has hooks for the coordinates...

Also if we are supporting corner coordinates in this grid factory (which we should!)
The ESMF_GridCreate needs this added:
            gridEdgeLWidth=[0,0], &
            gridEdgeUWidth=[0,1], &

So I would think that the class itself storing any coordinates is unnecessary, the grid has hooks for the coordinates...

The debate seems to be why we need to have subroutine initialize_from_file_metadata in swath code.  Currently in this swath code, the initialization from this code uses  add_horz_coordinates_from_file, we used allocatable arrays centers(nx,ny), then deallocated them after pass to the ESMF_GridGetCoord via  farrayPtr=fptr.    Then the ESMF data is passed to metadata.    Do we need to get metadata back to this SwathGridFacrtory, maybe for time dependence?
BTW, I realized in the MAPL_TripolarGridFactory.F90, there is no array storage like lat_centers(:) in the class memebers. I copied the code from MAPL_LatLonGridFactory.F90, which is using this array.

@bena-nasa , after our discussion, I deleted gridEdgeLWidth=[0,0], &  gridEdgeUWidth=[0,1], &.  Right now, I think systematically we donot need corners, which removed a layer of complexity.

Another comment,
initialize_from_file_metadata method can easily be tested.
This can be done via ExtDataDriver.x, just take a test case, like case1 and substitute the grid definition in the AGCM1.rc and AGCM2.rc file from being a lat-lon grid to this new grid factory at whatever resolution you want. That is all you should have to do, if that case1 doesn't work after swapping the grid definition, then the factory is broken
The first go-through of ExtDataDriver.x will create the files via History on the granule/swath factory. Then in 2nd go through, it will read these back in via ExtData which uses initialize_from_file_metadata when reading the input files.

@bena-nasa  This is a good suggestion and I will give it a try!


declared(params) - "no implicit conversion of Symbol into Integer" when receiving blank array

I have an optional array parameter. In some cases I want it to be blank, but if the items are passed, they must match the schema inside.

params do
  optional :outline, type: Array do
    requires :x
    requires :y
  end
end

I do a PATCH request and send {"outline": []} payload.
Received params =>{  "outline"=>[""] } - here is the first question - why an empty string inside an array? I have a feeling that I've struggled with that a few years back, but don't remember what was the cause.
declared(params) raises no implicit conversion of Symbol into Integer

What content-type are you using? This should work with content-type: JSON, but if you supply things in multipart or query params Rack can't figure it out.

@dblock thanks for a quick response.
Content-type is JSON.
module API
  class Base < Grape::API
    prefix :api
    content_type :json, 'application/json; charset=utf-8'
    format :json
    formatter :json, Grape::Formatter::ActiveModelSerializers

    ...
end

That defines the response, not the request. How do you PATCH/POST data?


DDS Router Configuration with Forwarding Routes

Do not merge until DDS Router v2.1.0 (with Forwarding Routes feature) is available in Vulcanexus!

@mergifyio backport humble


Improve Documentation

I think that this is a really cool system for mocking objects in typescript but I feel like the documentation is a little bit lacking in explaining how it is used. I have spent a couple of hours trying to figure out how to use your package. It is really hard to understand what your verify and setup functions work and what the parameters to them are. A good way to do that would be to add comments like at the end of #30.

Thanks for the feedback. I realize the current documentation could be a bit challenging to someone not familiar with Moq. Feel free to contribute and improve the documentation.


IPFS Update: 1.4 Goal - Data Exchange

Fixes #273
After the research on data exchange and Bitswap, I've come up with the following subgoals:

1.41 – Understand that Bitswap is a message-oriented protocol to exchange data.
1.42 – Understand how Bitswap works (message types and flow of the messages)
1.43 – Understand what is the session and the ledger in the context of Bitswap
1.44 – Understand the different components of Bitswap at a high level
1.45 – Understand what is Graphsync and what advantages it involves over Bitswap

My final comments are:

I personally don't like the aesthetic of the drawings, I don't like that they look penciled in
The PR is supposed to be merged into feat/ipfs-update so we can merge everything all together when we are done with this module

About the drawings, I don't hate them. I think we agreed to use Excalidraw because other DevRel and Docs people were using it

I think excalidraw is the way to go, the outercore team/ dev rels are using
this and it's becoming the most widely accepted diagram drawing software
amongst many of the outercore & engineering teams

Lindsay Walker
https://ovou.me/lindz

On Fri, Oct 14, 2022 at 2:04 AM Enol @.***> wrote:

About the drawings, I don't hate them. I think we agreed to use Excalidraw
because other DevRel and Docs people were using it
—
Reply to this email directly, view it on GitHub
https://github.com/protocol/launchpad/pull/282#issuecomment-1278575119,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AP7AGKSABEMI3SO77EJP5LDWDEAX7ANCNFSM6AAAAAAQWS6JF4
.
You are receiving this because you commented.Message ID:
@.***>

Yes but my follow up question is, what setting are people using it with? Is it with little, mid, or more "sloppiness"? I like the "little sloppiness" line style. I think it looks most professional and that's my only concern.

Its okay. I say merge it, and we keep an ear out for opinions on it later. I just wanted to express my feelings for it. @enoldev I leave you the honors of merging to feat/ipfs-update branch :thumbsup:


Document import/recommended

I learned about the ruleset import/recommended from reading the CHANGELOG, but it's not in the README.  Presumably it should replace all the examples that use import/errors and import/warnings? (though those rulesets should also be mentioned once)

Unfortunately recommended rulesets in plugins aren’t often up to date with what’s recommended, because of semver constraints. It should be mentioned, but not encouraged.

@ljharb Is there a different source for "what's recommended"? I couldn't find anything in the documentation besides import/errors and import/warnings.

Not really, no - but I’d suggest the Airbnb config.


Add Surface.Components.Dynamic.LiveComponent

This PR is related to issue #516 and #519

added new component to support dynamic stateful components

:heart:


fix: drop None

This list comprehension is throwing errors, per Matrix chat, because there are attempted string methods on Nonetype objects. This adds a conditional to stop that, as well as using Dict.get() to return a default empty string.
Could fix #6

Upon testing with one of the users, it looks like there are other issues at play, but I can't troubleshoot them since I don't have a Hubitat device. Hoping this gets you closer to a solution!

Update: fromport confirmed that with a little shifting around to accommodate my fork vs the real skill, this does fix the problem and he can set a level for his lights. More testing is obviously needed but it should resolve the issue!


chore: delete owlbot.py

Now that googleapis/synthtool#1244 is merged, owlbot.py is no longer required in this repo. We can add owlbot.py back in the future if repository specific customizations are needed.

Wait for next release of gapic generator python


i can't play animated cutscenes or dialogue cutscenes on mac

Describe your bug here.
do i have to explain again?
its all in the title
well not really
so basically when i try to open a week with cutscenes the game just crashes
i did try the haxelib install hxCodec
it didn't work
is there something im doing wrong?
Command Prompt/Terminal logs (if existing)
No response
Are you modding a build from source or with Lua?
Source
What is your build target?
Mac
Did you edit anything in this build? If so, mention or summarize your changes.
well all i did was put cutscene.lua in the data/songnamehere folder and did nothing with the haxe coding

Animated cutscenes aren't supported in Mac and there's no estimated date on when will support be added (if it even gets added at all).


regexpbuilder-php?

Any potential for a regexpbuilder php version?

just started a port: https://github.com/gherkins/regexpbuilderphp

Awesome!


Installed using pip but still not available

Greetings!
I've installed this package using pip3. It is listed in the installed packages but, when I try to import it polylearn, I get ModuleNotFoundError: No module named 'polylearn'

So, it seems that I need to download this package and install it manually. I got it wrong.

I'm happy to hear it worked for you, but pip install is supposed to work too. Make sure that the pip3 and python3 binaries you are using correspond to one another; ideally use a virtualenv.


Times out long-running workers

I woke up this morning to find that very few jobs had run overnight because
something weird happened with our hadoop cluster that caused all of our jobs to
hang permanently. When I checked in the morning, all workers were busy running
jobs that had been going for about 10 hours, and thousands of pending jobs that
would normally have been run overnight had piled up.
After killing and restarting all of my workers, everything started running fine
again because whatever weird issue had caused everything to hang was over. In
order to automate this fix, I've added a worker_timeout property to tasks that
tells the worker how long to attempt to run the task before killing it.
This property defaults to 0, meaning do not time tasks out. It can be changed
individually for a task by override or globally for all non-overridden tasks
via client.cfg. This only applies when running with more than 1 worker process,
as we need to run the task in a separate process in order to be able to kill it
after the timeout.

Can I get an example of how to use this? I'd like a particular task to time out after 5 seconds.
I've tried these:
    class TimeoutTask(luigi.Task):
        worker_timeout = 5

    class TimeoutTask(luigi.Task):
        worker_timeout = luigi.IntParameter(default=5)

I've also tried setting the timeout downstream:
    class DownstreamTask(luigi.Task):
        def requires(self):
            return TimeoutTask(worker_timeout=5)

in any case though, the task seems to just run perpetually. I'm using the centralized scheduler and TimeoutTask continously shows under Running Tasks and the downtstream tasks show as Pending.

You need to run with multiple workers for timeouts to be enabled. Add --workers 2 or some higher number to get the behavior you expect. Either method should work, but I usually use the first one of just setting worker_timeout to a constant.

Thanks! PR above should help clarify the situation for the next person coming along.


Lazy evaluation.

Score of 4ku vs master: 531 - 399 - 648  [0.542] 1578
...      4ku playing White: 294 - 169 - 327  [0.579] 790
...      4ku playing Black: 237 - 230 - 321  [0.504] 788
...      White vs Black: 524 - 406 - 648  [0.537] 1578
Elo difference: 29.1 +/- 13.2, LOS: 100.0 %, DrawRatio: 41.1 %
SPRT: llr 2.96 (100.7%), lbound -2.94, ubound 2.94 - H1 was accepted

Elo difference is wrong because the futility_movecount patch was still applied. Likely around 8-10 Elo.

ELO   | 5.57 +- 4.37 (95%)
SPRT  | 8.0+0.08s Threads=1 Hash=64MB
LLR   | 2.95 (-2.94, 2.94) [0.00, 5.00]
GAMES | N: 15104 W: 4830 L: 4588 D: 5686
For ~46 bytes this isn't strong enough to make it into the engine at the moment. It may however be temporarily added before a tournament if we need to maximise strength and there's room to spare. Thanks.

Let's not take this before it's retested.


Api adjustments for dashboard

Fixes https://github.com/saleor/saleor-dashboard/issues/2407
Two adjustments for flat rates API:

ignore input items with null rates in taxCountryConfigurationUpdate mutation
allow deleting individual tax rates for specific countries in taxClassUpdate mutation

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations
[ ] Documentation needs to be updated

Pull Request Checklist

[ ] Privileged queries and mutations are guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migration files are up to date
[ ] The changes are tested
[ ] GraphQL schema and type definitions are up to date
[ ] Changes are mentioned in the changelog

Task linked: SALEOR-6391 Simple taxes


[$500] Assign task - Task report appears and disappears in LHN when log in as user B

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

Action Performed:

Go to https://staging.new.expensify.com/
Log in with any Gmail account (User A)
On LHN, click on the FAB button and Assign Task
Enter a title or description and Assign the task to yourself
On Share Somewhere, select a conversation with another user you have access to (User B)
Send a message in the Task Report
Log in as the user that the task was shared with (User B)
Click on the "# Replies" link in the task
Open any other conversation in LHN

Expected Result:
You can see the task report in LHN
Actual Result:
Task report disappears in LHN and appears again when open the Task
Workaround:
Unknown
Platforms:

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

[ ] Android / native
[x] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] Windows / Chrome
[ ] MacOS / Desktop

Version Number: 1.3.74-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/78819774/3831f198-487e-4df0-ae89-55ab729c309b
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01e489eb74081df51b
Upwork Job ID:<PHONE_NUMBER>873100800
Last Price Increase: 2023-10-17

Sorry what's the bug here? If you leave the task report is shouldn't show up in the LHN in focus mode.

@lanitochka17 @JmillsExpensify Could you confirm what's the expected result here: should the task report appear in LHN or not? Because now it appears only for the user that created the task - is it expected behavior?

@lanitochka17 @JmillsExpensify Could you confirm what's the expected result here: should the task report appear in LHN or not? Because now it appears only for the user that created the task - is it expected behavior?

The task report should appear in the LHN for user B because there is an unread message

So, after the investigation I found the root cause of this behaviour. I think it is a backend issue.
Basically, the app have a few levels of checks to show/hide a report within the LHN. One of them verifies that the report's notificationPreference is not hidden.
https://github.com/Expensify/App/blob/4d75c0c192b21f83814918ebc46f9045b0be9def/src/components/LHNOptionsList/OptionRowLHN.js#L93-L96
However, B user's tasks are hidden until A user posts a message to those tasks. Since, the Pusher takes responsibilities to deliver updates, when B user sends a message, it should take into account that notificationPreference must be updated for the task report for A user.
In short, the backend should update notificationPreference and send the update property.
Example when "notificationPreference" equals "always"

cc @JmillsExpensify, @lanitochka17

Also, I have to inform that starting tomorrow I have a short vocation until next Monday (6.11.2023). Feel free to left any comments, I will address them. See you soon 😉

Melvin, no "overdue" here.

@thienlnam I wanted to get your thoughts on this comment? Do you agree with that? If so, I'll triage internally so someone internal can work on it.

This actually looks expected due to the new way we are handling threaded reports by 'hiding' them if you don't comment on it.
So, if a task is created unless User B actively participates in the task then it will not be shown in the LHN. If User B is assigned to the task, they should see the task in the LHN (that is getting updated in a different PR).

@thienlnam, yes, it looks like that. Therefore no bug?
cc @JmillsExpensify

Yup correct - closing this out


RFE: Make the description of the Nexus staging repo configurable

It would be handy to be able to provide a custom description for the staging repo instead of just a string saying which plugin created it.
Additionally, can you mention the groupId+artifactId+version in the default description of the staging repo?

It would be handy to be able to provide a custom description for the staging repo instead of just a string saying which plugin created it.

Agreed.

Additionally, can you mention the groupId+artifactId+version in the default description of the staging repo?

Since a staging repo can have more than one group id, artifact id, and version, it's not clear which should be used. That of the root project?

@szpak We currently replace the description when closing/releasing the staging repo. Is passing a new description mandatory for these operations?

Most likely not and some default comment would be assigned by Nexus. However, I've always passed my own comment, so I'm not sure.

Since a staging repo can have more than one group id, artifact id, and version, it's not clear which should be used. That of the root project?

Oh, right, you can have more than one "coordinate". Think, it doesn't really matter which artifact's used to create the description, as long it allows to distinguish different staging repos when you look into the list of staging repos in the Nexus UI. Maybe just the first artifact in a publication or so. If people really care, they can set their own description.


ampslice: start playing nicol on load in first tab

it seems a wrong file has been pushed to dev:
-the said nicol playing issue

threshold attrui is grey
window doesn't fit (we need to scroll right)
there is a buf onsetslice in the middle of the window

it seems a wrong file has been pushed to dev:
-the said nicol playing issue

threshold attrui is grey
window doesn't fit (we need to scroll right)
there is a buf onsetslice in the middle of the window

I got bitten by the two-windows-of-the-same-patch-open-in-Max-save-badness...
Fixes applied in #204.

bufampslice still plays on opening. and so does bufnovelty. How to reproduce:
open the helpfile
switch the audio
it plays the whole file
prefered behaviour: it plays only when we give an int to the player, no?

bufonsetslice does it too.
maybe we should not use groove and instead use play~ - so the poor user is not bombarded with sounds right away.

All fixed in #210.
Thanks


Are there instructions for vector reverse?

I want to implement a function for vector reverse, keeping the type of vector unchanged, only reordering vector elements. But I didn't find instructions for this. Are there Instructions working for it? Or some simple instruction combination for it?

Use vid to generate element indices, then subtract id from vl to obtain reversed indices, then use vrgather to reverse elements.


Incorrect Xml docs when hovering over attributes

Steps:

Create a csx file in VSCode
Add a property/variable as follows:

[ThreadStatic]
string Foo;

Hover the mouse over the ThreadStatic attribute

Expected result:
The documentation of the type "ThreadStaticAttribute" is displayed
Actual result:
The documentation of the constructor of the type "ThreadStaticAttribute" is displayed.
Minor issue

This is a duplicate of "Scenario 1 for desktop .NET" from issue https://github.com/OmniSharp/omnisharp-roslyn/issues/685


[Hub Generated] Review request for Microsoft.VMwareCloudSimple to add version stable/2019-04-01

If you are a MSFT employee you can view your work branch via this link.
Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

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

Automation for azure-sdk-for-python

Automation for azure-sdk-for-js

Automation for azure-sdk-for-java

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-go

Can one of the admins verify this patch?

@sarangan12 , @shahabhijeet @jhendrixMSFT , @lmazuel, @anuchandy  - Please take a look at the readme.md and readme.lang.md files and make sure the settings are correct.

@openapi sdkautomation rebuild

@openapi sdkautomation rebuild

@openapi sdkautomation rebuild

@openapi sdkautomation rebuild


Object disappears from promise result

I am sure there is some reason for this -- but need some help understanding.   I think the best way to see the flow that is happening here is to loo at a screenshot with Atom showing the inferred type at each step.

interface $Chain<A = any, B = any, C = any, D = any> {
  results: Array<A | B | C | D>;
  num: () => $Chain<1, A, B, C>;
  str: () => $Chain<'1', A, B, C>;
  obj: () => $Chain<{}, A, B, C>;
  anyobj: () => $Chain<Object, A, B, C>;
  arr: () => $Chain<[], A, B, C>;
  exec: () => Promise<Array<A | B | C | D>>;
}

class Chain implements $Chain<> {
  results = [];
  num = () => {
    this.results.push(1);
    return this;
  };
  str = () => {
    this.results.push('1');
    return this;
  };
  obj = () => {
    this.results.push({});
    return this;
  };
  anyobj = () => {
    this.results.push(Object.create(null));
    return this;
  };
  arr = () => {
    this.results.push([]);
    return this;
  };
  exec = async (): Promise<*> => this.results;
}

const c = new Chain();

// eslint-disable-next-line
const prom = c
  .num()
  .str()
  .anyobj()
  .exec()
  .then(results => {
    const result = results[1];
    const final = typeof result === 'object' ? result : undefined;
    return final;
  });

So in this case it is absolutely inferring everything properly.  It does exactly what I want it to for the most part... For example:

However, when I want it to return either void or Object (it could be null, an array, or object literal of any shape in the actual use-case) it just completely ignores it even when a type check is conducted.

I would also note that in this case the original goal was to use tuple unions then check the length in the .then to discover which is correct - however that does not currently work :(.  If it did then it would even know the exact return type which would be pretty awesome.
Sucks that it only allows the set number of types as well but definitely all understandable!
it's amazing that Flow can already infer this much!

My "solution" to this was to just manually type them out.  It appears the Object type is mistaken at some point and removed.
type ObjOrArray = { [key: string]: mixed } | Array<mixed>;


Remote providers web UI link

Resolves https://issues.redhat.com/browse/MTV-1145 by adding instructions about how to connect to a remote provider's UI.
Applies to all providers except OVA.

@sgratch Please review this PR.


Order of source files affects @import

paths = [
	'assets/stylus/fonts.styl'
	'assets/stylus/main.styl'
]

gulp.task 'stylus', ->
	gulp.src(paths)
		.pipe(stylus(
			use: nib()
		))
		.pipe(gulp.dest('public/css/app'))

Seeing an issue where main.styl requests @import 'fonts' but it doesn't work unless fonts.styl appears after main.styl in the list given to gulp.src. It seems like the import should work regardless of the order? In the case were it doesn't work, there is no error. Am I doing something wrong?

Fixed if I revert Stylus to 0.37.0. I guess this is a Stylus issue, sorry!

Can you open an issue on stylus to confirm that the version no longer supports that particular order?

Yes, I will. Looks like the bug was introduced between .48 and .49

This is a known issue in Stylus. Setting the option cache: false is a temporary workaround.

Ah, thanks for the research!


Fix Dockerfile resolve

$(params.CONTEXT)/$(params.DOCKERFILE) can cover most cases that build context is current directory ".". However, it can't cover a special case that a context directory is different. For example, ./app is the build context directory, and ./dockerfiles/Dockerfile-app is the Dockerfile or even ./app/Dockerfile, that will cause the result of $(params.CONTEXT)/$(params.DOCKERFILE) is invalid.
Signed-off-by: Chenxiong Qi<EMAIL_ADDRESS>

/retest


Bad link from maturity indicator images to maturity indicator page

For example, if you click the maturity indicator on https://oboacademy.github.io/obook/lesson/contributing-to-obo-ontologies/, it goes to https://oboacademy.github.io/obook/lesson/reference/obook-maturity-indicator
but should go to
https://oboacademy.github.io/obook/reference/obook-maturity-indicator/
The html has
href="../../reference/obook-maturity-indicator/"
I guess it should be
href="../../../reference/obook-maturity-indicator/"
(or change to an absolute URL, but hat also has disadvantages)

Thank you @nlharris
Due to the problem that you can never know for sure which level in the page you are, I updated the link (and the example snippet) to use an absolute URL..


Additional options for user email so it's not displayed in a public repository

I want to encourage users to leave their email when submitting an issue so that we can follow up with them, but I don't think they will be comfortable with the fact that their email will then be listed with the issue in a public repository.  I am not familiar enough with GitHub issues to know what other options would be, but it would be nice to have some.

+1
In France it's illegal to expose publicly email address unless the user explicitly grants it's permissions.
I suggest to not publish email to issue but sending it by email only

I do believe that this is a good change, but unfortunately it has left us with the problem that often we are not able to contact users because they forget to check the box. A lot of our users are not very tech-savvy so even if we encourage users to check the box.
A possible soulution could be to either make it an option to check the box by default or to include the title of the submitted issue and the email adress of the submitter in the notification email.

@sebastianskejoe the email is still sent in the notification email to the repo owner


Invalid argument supplied for foreach()

Hey folks,
When calling Steam::app()->appDetails(1444140) I get the error:
ErrorException

 Invalid argument supplied for foreach()

 at vendor/syntax/steam-api/src/Syntax/SteamApi/Steam/App.php:79
   75|     protected function convertGames($apps)
   76|     {
   77|         $convertedApps = new Collection();
   78|
 > 79|         foreach ($apps as $app) {
   80|             if (isset($app->data)) {
   81|                 $convertedApps->add(new AppContainer($app->data));
   82|             }
   83|         }

I expect this is because Steam's API is returning an empty response with HTTP 200 OK.
Would it be appropriate to check for an empty response in setUpClient and if one is found, throw an ApiCallFailedException?
If so I will submit a PR.
Thank you for your great library!

Looks like other endpoints sometimes return empty responses too:
https://github.com/syntaxerrors/Steam/pull/121
Where would be a good place to check for an empty response and throw an exception?

I think this is covered in 3.0.0 release, will reopen if it keep happening.


Fixed link to "Latest Amazon Linux 2 AMIs"

Fixed link to "Latest Amazon Linux 2 AMIs"
The link took me to the wrong page, I used the outdated AMI and then I spent about an hour wondering how come DynamoDB is not supported etc.

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement
Learn more about why HashiCorp requires a CLA and what the CLA includes
Have you signed the CLA already but the status is still pending? Recheck it.

Thanks for the fix! Note that as of https://github.com/hashicorp/terraform-aws-vault/pull/224, we are actually going to stop updating these Markdown files with AMI lists, so I'm going to close this PR. Note that we will continue publishing the AMIs themselves; it's just the Markdown files that are going away. You can still find the AMI IDs by doing a search in the AWS Marketplace or programmatically using tools like the aws_ami data source in Terraform.