Error 500

Won't work for me
I am a Windows user
Message inside the web-user.bat
Traceback (most recent call last):
File "C:\Users\Heimann David\stable-diffusion-webui\venv\lib\site-packages\gradio\routes.py", line 273, in run_predict    output = await app.blocks.process_api(
File "C:\Users\Heimann David\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 739, in process_api    inputs = self.preprocess_data(fn_index, inputs, state)
File "C:\Users\Heimann David\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 638, in preprocess_data
processed_input.append(block.preprocess(raw_input[i]))
File "C:\Users\Heimann David\stable-diffusion-webui\venv\lib\site-packages\gradio\components.py", line 2118, in preprocess
return process_single_file(x)
File "C:\Users\Heimann David\stable-diffusion-webui\venv\lib\site-packages\gradio\components.py", line 2088, in process_single_file
f["name"],
TypeError: 'bool' object is not subscriptable
have tried using git fetch origin pull/1276/head and git checkout FETCH_HEAD
Used the Automatic1111 sorted option and localhost is http://localhost:7860/
And i used the most recent version

Thanks for your detailled issue.
Could you please try this:

open the left panel in diffusionui.com
Be sure to have "Automatic1111 sorted" selected in the dropdown
click on the ⓘ icon to go to the model info tab
click on the "Reset to default values" button
click Yes to confirm

If that does not solve your problem, please copy-paste the beginning of the text in the webui.bat console.
It should look something like:
venv "E:\Development\git-repos\stable-diffusion-webui\venv\Scripts\Python.exe"
Python 3.10.7 (tags/v3.10.7:6cc6b13, Sep  5 2022, 14:08:36) [MSC v.1933 64 bit (AMD64)
Commit hash: 938c83c388208b9cc48acb2842dc453c33c82a95
Installing requirements for Web UI
Launching Web UI with arguments:

I think found know my problem.
It is recommended by in the instalation guide of the Automatic repo to use the "webui-user.bat" to start up the programm.
But your webui wants me to use the "webui.bat".
Now that i used the "webui.bat" it works and i now longer get error 500. its probably the same with other people.

Thanks again for your feedback. I've added an explanation on how to make it work in the docs


Going into WYSIWYG mode breaks insert link functionality for split view

Stable/Insiders/RC1 (not regression from 1.27)

Create new text cell in Notebook (helps to have "default to WYSIWYG" mode turned off)
Click link icon to insert new link - works as expected
Switch to "Rich Text View"
Switch back to Split View
Click link icon to insert new link

Expected :
Link is inserted
Actual :
Nothing added
This error is in console :
ERR Cannot read property '0' of null: TypeError: Cannot read property '0' of null
    at Object.t.insertFormattedMarkdown (file:///C:/Users/chgagnon/AppData/Local/Programs/Azure Data Studio/resources/app/out/vs/workbench/workbench.desktop.main.js:2010:314)
    at b.onInsertButtonClick (file:///C:/Users/chgagnon/AppData/Local/Programs/Azure Data Studio/resources/app/out/vs/workbench/workbench.desktop.main.js:4313:79)
    at async HTMLLIElement.<anonymous> (file:///C:/Users/chgagnon/AppData/Local/Programs/Azure Data Studio/resources/app/out/vs/workbench/workbench.desktop.main.js:4307:406)

Given that this isn't a regression and we haven't heard any customers talk about it, I'm less likely to try to push this in unless the fix really is quite targeted. I've asked @VasuBhog to do a quick investigation here.

@VasuBhog is this related to your outstanding PRs, or is this a different problem?

My current open PRs are focused on run parameters action. I had worked on ensuring the selected link for markdown/split-view work properly as well (which is fixed). This issue is entirely different as we were having issues with the editorControl being undefined when setting the link.
(can look into this further later this week)

@VasuBhog thanks for clarifying. Ah yes, I remember now. If you realistically think it can get done this week, great, and if not, no problem at all. I'm just trying to figure out which milestone to put it in (May or Backlog)


Zend\Paginator\Adapter\DbSelect's count() is wasting resources

I think the way count() calculates the result set total is a waste of resources.
If you have many rows/columns in the resultset having a query in the form of:
SELECT COUNT(1) FROM (SELECT .... FROM) x
is way slower that having just a :
SELECT COUNT(1) FROM ....
since you force the database to return all the results and count them.
Wouldn't it make more sense to have something along the lines:
$select = clone $this->select;
$select->reset(Select::LIMIT);
$select->reset(Select::OFFSET);
$select->reset(Select::ORDER);

$select->columns(array('c' => new Expression('COUNT(1)')));

This issue has been closed as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html


Update AstroNvim Configuration Source

Issue:
This repository is not meant to be used as a direct Neovim configuration

Change:
The old repository (https://github.com/AstroNvim/AstroNvim) is no longer in use for configuration purposes. The new repository (https://github.com/AstroNvim/template) will now be used for starting the AstroNvim configuration.

@xbklairith - I pushed a change to  neovim_distros making default the first choice.  You'll need to merge my changes with yours to complete this pull request.

@Traap   I update from the latest master.


TestWorkflowService: Make tokens unique across retries

Currently real service doesn't accepts activity and workflow task tokens across retries. But the TestWorkflowService includes only workflow and activity id in it.

We don't include retry count into the token, which is why previous activity retry can complete next one in the test service. To be consistent with the real service we want to fix this.


Add basic configuration for TravisCI

Howdy!  Having tests is awesome!  Having tests run automatically after a branch or PR change is even more awesome!  This PR adds a basic configuration for TravisCI to do so, specifically it:

Adds a dummy Kube config for use during test setup (example taken from a pykube test fixture.)
Fixes an issue where the region not being set in the Boto autoscaling client setup caused tests to fail in test_cluster.py.
Adds a config following the TravisCI docs for Python.
Note: Gym, Universe, and rllab all use slightly different CI setups, but tend towards running tests inside of a Docker container, where this PR currently uses the TravisCI container+virtualenv setup.  This may or may not be preferred.
Adds a small "tests passing" badge to the README.

Here's an example of TravisCI passing tests with this config: https://travis-ci.org/esigler/kubernetes-ec2-autoscaler/builds/200817840
(To enable TravisCI to use this config, someone with admin privs for this repo in Github will need to go to https://travis-ci.org/profile/openai and toggle the repo.)

thank you!


Switch component breaks with fragments

About
Hey there! Thanks for the awesome library!
There seems to be an issue with the switch component when fragments are used.
Reproduction

Create a switch component with some child routes.
Wrap some of the child routes in a fragment (code below)
Add more routes outside of the fragment
Load the page on a route that doesn't match any of the routes in the fragment

<Switch>
  <>
    {literalRoutes.map((route) => (
        <Route key={route.url} path={route.url}>
          <AppRoute {...route} />
        </Route>
     ))}
  </>
  <Route key={'fallback'}>
    <Redirect to={'/'} />
   </Route>,
</Switch>

Expected result
Wouter renders the first matching route (or fallback route)
Actual result
Wouter gives up parsing Switch child components after parsing the fragment and renders nothing.
Additional info
The following example is what I'm using as a workaround for now
<Switch>
  {[
    ...literalRoutes.map((route) => (
      <Route key={route.url} path={route.url}>
        <AppRoute {...route} />
      </Route>
    )),
    <Route key={'fallback'}>
      <Redirect to={'/'} />
    </Route>,
  ]}
</Switch>

Hi @andyrichardson! Appreciate the kind words:

Hey there! Thanks for the awesome library!

I'm afraid Switch component will only work with routes that are direct children of the component. This is due to the fact that Switch iterates over its children and checks their path prop. This also means that Switch won't work with components that render routes internally. React-router is no different https://github.com/ReactTraining/react-router/blob/master/packages/react-router/docs/api/Switch.md#children-node
I don't think there is a simple and reliable solution of this problem. Even if we use context for that: say a switch could create a special object in the context that will be visible to all internal routes, and then a nested route could use that object to detect that it's being rendered inside a switch. But I think it's nearly impossible to achieve the "render the first match" functionality, since the render order of child components isn't something we can rely on (especially with concurrent mode).

This looks more like an implementation constraint, rather than an issue.
What you're using as a workaround seems completely legit to me!

Hi, continuing the discussion here instead of #155 (sorry for the duplicate), it seems to me that we could handle dynamic arrays, when they are not wrapped inside a Fragment. In @andyrichardson sample, it would then simply become:
<Switch>
  {literalRoutes.map((route) => (
      <Route key={route.url} path={route.url}>
        <AppRoute {...route} />
      </Route>
  ))}
  <Route key={'fallback'}>
    <Redirect to={'/'} />
  </Route>,
</Switch>

(Notice, only the fragment has been removed, but the static route does not have to live in the array)
This does not work at the moment in Wouter, as neither Fragment nor arrays are handled by the Switch.
But where Fragment are actual JSX elements and therefore are a bit tricky to handle, simple arrays could work just fine in both React and Preact implementation, by using React.Children.toArray in React, and toChildArray in Preact.
Both functions work the same way: they flatten any nested array, and do not flatten Fragments.
So maybe it is worth it after all to handle this case, simply add toChildArray to the react-deps.js exports, and have it be equal to React.Children.toArray in the React version. What do you think @molefrog ? Is it something you would be interested in supporting, or should we rely on the workaround proposed by @andyrichardson ?
If it's something that we could handle, I'm happy to open a PR with this modification and associated tests.

My two cents on this!
It's a confusing bug - took me a while to realize that a fragment was the issue. This is the first library I've come across that doesn't treat fragments as transparent elements (i.e. if fragment -> traverse children).
The cost to fix this bug is basically 0.

That's what Switch does: it only renders the first matching route.

If this isn't a bug, maybe it's worth updating the README to explain that it only renders the first matching direct child route.
If you're open to a PR fix, I'm happy to open one!

@andyrichardson
As you can see here: https://codesandbox.io/s/gifted-bell-pgvvs
React-Router itself does not correctly handle Fragments, albeit not with the same result. When using a Fragment anywhere inside a Switch, following children are ignored. In my fiddle you can see that /page1 correctly matches the route outside the Fragment (ignoring the one inside), /page2 correctly matches the route inside the Fragment (ignoring the one outside), but /page3 does not match anything.
This is not to say that Wouter should not try to handle Fragments (this is for @molefrog to decide), but to point out that not all libraries handle Fragments correctly.
In the case of Wouter, handling Fragments is not a 0-cost fix unfortunately, as it means that it needs to implement a recursive matching, where right now it only have a single loop. This would negatively impact the size of the bundle I guess. But at least detecting Fragments is easily down with child.type === Fragment both in React and Preact :)

For what it's worth, here is a flattenChildren method that works both in React and Preact, and that allows us to keep the current loop structure:
const flattenChildren = (children) => {
  return Array.isArray(children)
    ? children.flatMap((c) =>
        c.type === Fragment
          ? flattenChildren(c.props.children)
          : flattenChildren(c)
      )
    : children;
};

And here is a variant only handling Arrays:
const flattenChildren = (children) => {
  return Array.isArray(children)
    ? children.flatMap((c) => flattenChildren(c))
    : children;
};```

Both also handles the isArray check, so that is not needed anymore in the Switch component.

The Fragment+Array variant bumps the size by 34 Bytes, from `1.31kB` to `1.34kB`, and obviously leaves the `use-location.js` size untouched at `380B`.
The Array-only variant bumps the size by 15 Bytes, from `1.31kB` to `1.32kB`.

IMHO, 34 bytes is worth it to handle both Arrays and Fragments in this situation. It would actually make Wouter handle this simple case better than React-Router!

@molefrog
Since #156 has been merged fixing this, any idea when we can expect a v2.7.1 to drop? 🙂

@molefrog
Since #156 has been merged fixing this, any idea when we can expect a v2.7.1 to drop? 🙂

@jvdsande Sorry, was busy because of the Christmas holidays 😄 I have just published the release!

@jvdsande Sorry, was busy because of the Christmas holidays 😄 I have just published the release!

@molefrog No problem, I was just wondering :)
Thanks for the release, that's awesome!

@molefrog No problem, I was just wondering :)
Thanks for the release, that's awesome!

ihave the last version and still have the problem metioned here, i missing something?

@Bonfims well, you are right, this won't work unless there is a path prop explicitly defined on a direct child of Switch. The reason is that Switch simply iterates over it's children (as a JSX) and it can't get the path prop unless App component is rendered first.


UI on Mobile Needs to be Adjusted

The UI isn't properly formatted on mobile. Need to adjust CSS for proper mobile formatting.

Duplicate of #16


Add resettable DistributionSummary and Timer instruments for Dynatrace exporters

I rebased on 1.9.x and force pushed the branch (and the base branch) again, so the tests would pass.


Problems with Cart::associate()

Hello!
I'm trying to associate a model to a cart item like this:
Cart::associate('Produtos', 'App')->add(...);
However, the associate method throws an InvalidRowIDException, with the message "The cart does not contain rowId Produtos."
Is this a bug? Or I'm doing something wrong in my code?

Which version are you on?

I'm on version 2.0

Okay, that sorry on my behalf, the documentation must be updated. In v2.0 the functionality was changes. You can either associate a model to the cartitem by making the model implement Buyable and use the model to add the item Cart::add(Product::find(1), 1); Or you can use the associate method where you first specify the rowId of the item and then the full FQN of the model, so something like:
$cartItem = Cart::add('123abc', 'Product1', 1, 10.00);
Cart:associate($cartItem->rowId, \App\Product::class); // Or just Cart:associate($cartItem->rowId, 'App\Product');


Copy and paste file from navigator window doesn't work

Hello!
I often use PHPStorm and there I can ctrl+c on file in the Project window and then ctrl+v ibid and a new file will be created with content of the copied file. Is it possible to bring the same behavior to Consul?
For now it just copies file name as string

C# ?

Any file. Or what do you mean?

I checked and its work for Java classes and simple files

Need more info

Oh, you're right. Only C# files don't copy. Why?

Its a problem class node. If C# file showed as C# file - copy is worked

And there are no ways to fix it?

It will be fixed in a few days

Great, thank you a lot!

I restored default action - later i will add class rename(to correct name)

New issue https://github.com/consulo/consulo-csharp/issues/new


Ct 830 add parameter allow truncate if filter is empty

Jira: CT-XXX
KBC: XXX
Before asking for review make sure that:
Checklist

[x] New client method(s) has tests
[x] Apiary file is updated

Release

[x] I gave the PR a proper label:

major (BC break)
minor (new feature)
patch (backwards compatible fix)
no release (just test changes)

Tady to imho není major, přidala sa jedna option do klienta to je minor max.


kubeadm-token-create: fix wrong flag name for ttl

Fixes https://github.com/kubernetes/website/issues/9757
the kubeadm token create --token-ttl flag was renamed to --ttl possibly right after the docs were generated.
we had some pending PRs which got in quite late in k/k.
the kubeadm_token_create.md file looks like this right now:
...
      --ttl duration         The duration before the token is automatically deleted (e.g. 1s, 2m, 3h). If set to '0', the token will never expire (default 24h0m0s)
...

proof in the source code:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/cmd/token.go#L141
manually rename the flag in the generated docs.
/assign @tengqm
/sig cluster-lifecycle
/area kubeadm

/lgtm
:)

@neolit123 I think this is in a generated doc folder, so the best place to make this change would be in kubernetes/kubernetes, but you can totally correct me if I'm wrong.

@zparnold
the generation of docs only happens near a release, so i'm manually fixing it until then (as a bug).
but yes, i do agree that the generated folder is for the generated docs only.
@tengqm are the HTML styling tools for the generated docs now available publicly?
last cycle we had a bit of an issue with that.

/lgtm
/approve


Serialization of RPC between main process and the compiler

Motivation
Currently, we have:

Main process and compiler process communicating over Unix socket
The protocol uses pickle as serialization
Compiler process connects to Postgres on its own

This isn't going to work for the main process in Rust and supporting cloud:

While it's possible to work with Pickle in Rust it isn't a good idea
We want a many-to-many relationship between the processes in the cloud
Holding by a compiler onto a Postgres connection is inefficient (connections are costly in Postgres)

The Proposed Protocol
Framing
@tailhook is used to use WebSocket framing for everything nowadays:

It's standard, ubiquitously supported
Sufficiently extensible
Exposing (Prometheus?) metrics over HTTP on the same port is a plus
It has a standard connection liveness protocol (Ping/Pong packets)

Alternative Framing

We could use HTTP for most things, but being able to find out connection liveness reliably is a very big advantage. And we'll probably need some non-RPC messages, see below
Roll-your-own will require provisioning ping/pong and future extensions. While it isn't particularly complex, I don't think it's justified.
Use postgres framing. The downsides are:

It's just framing, we still need to specify how actual request/response, ping/pong and other packets look like
We still need to decide how to serialize or own data

Serialization
@tailhook is used to CBOR:

It's standard
There is Concise data definition language (CDDL) to describe CBOR structures
It's binary, fast and sufficiently extensible
It's relatively compact. While preserving field names it's still comparable to protobuf after gzipping (there is a standard compression extension in websocket protocol when we need one). We can also replace field names with 1-byte numbers or use arrays if we have lots of small objects.
There are fast encoders for every language including Python and Rust

Alternative Serialization
Lots of them:

Protobuf is not a starter.
Cap'n'proto is unnecessarily complex and bad at backward compatibility
JSON is bad at binary data and not compact enough
Postgres protocol: there are two different protocol serializations there: one for message structure and one for the data. The latter one requires describing types upfront and is suited only for tabular data, and also is not very compact. The former is not self-descriptive. Which makes debugging harder.

Can go over and over, have to just pick one.
Semantics
To make complier completely stateless, we move all communication to Postgres into the main process.
Compile To SQL
There are perhaps two API calls:
compile_to_sql(query_text, schema_hash) -> (compiled_query, Option<changes_to_schema>)
compile_to_sql_given_schema(query, schema) -> (compiled_query, Option<changes_to_schema>)

Note:

It's stateless. If there is no schema with that hash compiler returns an error and the main process calls the second method.
The slow path here is when the actual schema changes, which is fine.
❓ The DDLs probably don't need any dedicated processes with these semantics
❓ Schemas might not need to be tied to a user or a database. So multiple tutorial users can share the same schema if the hash matches.

There are few performance optimizations can be done on top:

The main process keeping track of which schemas are cached (i.e. compiler publishes hashes as it receives schemas)
Forcing preload of specific schemas when connecting to a compiler (this is probably only justified in the paid tier).

The obvious question here is: Is it fast enough to transfer schema like this?

Well, obviously we need to do it one way or another
For paid tier, it will always be preloaded anyway (but asserting on a hash is still useful)
For free tiers (i.e. try.edgedb.com) we should have a small limit on the schema size to avoid DoS (and hopefully we can reuse the same schema for most users)

Alternative Semantics
Well, there are a lot of different approaches and combinations on them. Please comment!

@tailhook: I've marked by "❓" my pure speculations that need more research.
Update 1: added notes about using postgres protocol
Update 2: mention CDDL

Well, there are a lot of different approaches and combinations on them. Please comment!

Yes, I was going to build a small protocol on top of Postgres framing. Then the Rust infrastructure built for EdgeDB binary protocol and for Postgres protocol can be reused. This is also super straightforward, simple, and requires almost zero new code to be written / zero third-party deps.
I'm -1 on using protobuf, pickle, cbor, websockets etc simply because that complexity is unwarranted.

Yes, I was going to build a small protocol on top of Postgres framing. Then the Rust infrastructure built for EdgeDB binary protocol and for Postgres protocol can be reused. This is also super straightforward, simple, and requires almost zero new code to be written / zero third-party deps.

Well, while there is "postgres-like framing" there is no common "Postgres protocol" between edgedb protocol and real postgres protocol. So it will require more new code to be written. With CBOR (or any other generic serializer) it a matter just defining structures (derive does all the work):
#[derive(Deserialize)]
struct Request {
    query_text: String,
}

Compare that to the chunk of code in rust or python to handle our current protocol.
I've listed Postgres protocol's downsides in the alternatives above, which boils down to:

We need to define structure of each message anyway, only reusing 4-byte framing. Every message of this protocol and other two (except perhaps error and log messages) are different.
We need to define even ones already defined in websockets: ping/pong (and perhaps a handshake).
The messages aren't self-descriptive as in CBOR. Self-descriptiveness means you can copy your binary chunk of data to import cbor; cbor.decode(b'data') and decode the thing (without the context of where this message comes from).
My experience says that it will be less compact even with self-descriptive CBOR (but I don't have the proof right now)
We already talked about gzipping, it's defined for websockets, but we need to define it for our protocol themselves (Also TLS, but that might be straightforward).

So at the end of the day, I think WebSocket+CBOR is a lot less work than adopting edgedb protocol's approach.

there is no common "Postgres protocol" between edgedb protocol and real postgres protocol

There is. Actual data is serialized using PostgreSQL binary encoding, and this is the main issue here.

it took me about two weeks in total and 11 documentation fixes to implement the current protocol in Rust so far

OK, so we already have the implementation both in Python and in Rust. I don't see how the protocol issue is relevant now. I doubt we will introduce any other language to the server anytime soon, and if we do, it is highly likely that we would have the protocol implemented there as well.

The messages aren't self-descriptive as in CBOR

The Type Descriptor is exactly the description of a message, is it not?
The main reason why we want to go with Postgres data serialization is that the schema and other state are in Postgres and so, by definition, are encoded using that.  Going with alternative serialization formats, no matter how nice they are, will introduce a requirement to re-serialize such data after it is extracted from Postgres. Given that schemas may be very large, this is a non-trivial performance cost.
Lastly, the RPC/IPC here is fairly small in scope, and will likely stay that way, so I don't see a real value in bringing in a full-blown RPC system given the downsides of doing so, and the context in which we operate.
To clarify, I don't think CBOR is bad, and we can certainly look into adopting it for RPC between services outside of the server core.

Holding by a compiler onto a Postgres connection is inefficient (connections are costly in Postgres)

The compiler process does not need to hold onto the connection. It only needs it to read the current schema, and that will likely be a single query or a few of them. It's not clear if serializing and passing the schema via RPC would more efficient than re-reading the schema. That said, not doing it in the compiler process is technically cleaner, so it's worth exploring.

The compiler process does not need to hold onto the connection. It only needs it to read the current schema, and that will likely be a single query or a few of them. It's not clear if serializing and passing the schema via RPC would more efficient than re-reading the schema

I don't think it's more efficient. It may be less efficient. But my considerations are:

We eliminate race conditions when we send a request with one schema but Postgres already contains another one.
We eliminate the network time from the compiler, it's now pure CPU resource. The important use case here is when the compiler tries to fetch the schema and Postgres is holding locks on some of the data because another upgrade is in progress.
When spreading the load over compiler processes we don't need to think of how many connections compiler will open simultaneously to fetch the schema (especially it's important when request cache is clean, i.e. on application start or after schema change). It may exhaust Postgres limits in the other case.
We don't need to give the database address to compilers
We improve security by not letting compiler processes access the data and credentials
I think it's clearer to compute the hash on the received schema than storing the hash in Postgres (and then if the main process already has a schema, why not just send it)

The main reason why we want to go with Postgres data serialization is that the schema and other state are in Postgres and so, by definition, are encoded using that.

You're right at everything with one assumption: you're going to store schema as rows received from postgres. Which I'm sure isn't true. We should make dicts from lists of rows and build all kinds of auxiliary structures. So I propose to serialize the schema in more robust and easily hashable form than that.

OK, so we already have the implementation both in Python and in Rust. I don't see how the protocol issue is relevant now.

Yes, but we also eventually might need a Wireshark plugin to debug production issues. Using CBOR over websocket (both of which already have decoders in Wireshark) is going to be so much easier and little-maintenance than our own protocol. This is just an example that easy implementation still makes sense, though.

You're going to store schema as rows received from postgres.

Store where? Isn't the idea that we only store state in Postgres?

Which I'm sure isn't true. We should make dicts from lists of rows and build all kinds of auxiliary structures.

This isn't how this is going to work.  The new version of schema introspection code will use EdgeQL and will return a properly shaped data block.  Yes, you would still need to parse that into whatever structures the in-process schema representation is using, but that parsing would happen in the compiler process.
So, if I understand your proposal correctly, the introspection flow would look roughly like this:
Postgres --> Custom unpacking code (a-la current intromech) --> CBOR --> RPC --> CBOR unpack --> Unpacking code to get from CBOR to schema.Schema
What I propose:
Postgres -> RPC -> Unpacking code to get from typedesc/data to schema.Schema

We eliminate race conditions when we send a request with one schema but Postgres already contains another one.

Not sure I understand this point.  Outside of transactions we make no guarantees as to what schema your query would be compiled against (just like Postgres BTW).  It is fundamentally wrong for the caller to make any other assumptions,

The important use case here is when the compiler tries to fetch the schema and Postgres is holding locks on some of the data because another upgrade is in progress.

I don't see a scenario where an ACCESS_EXCLUSIVE lock would be held on an internal schema metadata table. Migrations only lock user tables.

We don't need to give the database address to compilers
We improve security by not letting compiler processes access the data and credentials

I don't disagree here. The discussion here assumes that we pass the schema via RPC.

You're going to store schema as rows received from postgres.

Store where? Isn't the idea that we only store state in Postgres?

In-memory

So, if I understand your proposal correctly, the introspection flow would look roughly like this:
Postgres --> Custom unpacking code (a-la current intromech) --> CBOR --> RPC --> CBOR unpack --> Unpacking code to get from unpacked CBOR to schema.Schema
What I propose:
Postgres -> RPC -> Unpacking code to get from typedesc/data to schema.Schema

That's correct. My point of view on this:

Unpacking from CBOR is much easier (I think we can perhaps leverage CBOR hooks to deserialize directly into schema, without intermediate representation, but I'm not sure)
Understanding schema by main process is nice, at least recomputing hash is useful (I don't think we can get a hash right from the rows for many reasons). It's also future-proof for moving more features to the main process in the perspective
Even if we keep serialization of the schema via postgres protocol the outer protocol is different (we don't need to send prepare + describe requests from compiler). So we still need to invent that protocol.

Other than that, yes, me might consider passing just a chunk of data from the postgres without repacking.

We eliminate race conditions when we send a request with one schema but Postgres already contains another one.

Not sure I understand this point. Outside of transactions we make no guarantees as to what schema your query would be compiled against (just like Postgres BTW). It is fundamentally wrong for the caller to make any other assumptions,

In the proposed implementation, it's no different whether it's outside or inside a transaction. The compiler works the same. We don't allocate a special compiler process for a transaction.
When we were discussing compiler fetching the schema on its own, how it could fetch the schema inside the same transaction?
But anyway, you seemed to agree that passing schema via RPC makes sense.

The important use case here is when the compiler tries to fetch the schema and Postgres is holding locks on some of the data because another upgrade is in progress.

I don't see a scenario where an ACCESS_EXCLUSIVE lock would be held on an internal schema metadata table. Migrations only lock user tables.

I may be misunderstanding how it works. But I used to think that we upgrade metadata and altering tables in the same transaction. So locking is still possible.
Actually, it's pretty hard to prove that locking of metadata is not possible, so assuming the worst is a safe bet for me.

We don't need to give the database address to compilers
We improve security by not letting compiler processes access the data and credentials

I don't disagree here. The discussion here assumes that we pass the schema via RPC.

So if we agree that passing schema via RPC makes sense. Then regardless of the serialization format of the schema itself, the outer protocol is different: we don't need to send prepare + describe requests from compiler; even if we were doing that it would be the other way around (from server to client, because I'm assuming the main process is the client here). So we still need a different protocol here.

Understanding schema by main process, at least recomputing hash is useful

There is no need to hash the schema at all.  Maintaining a monotonous version counter per-database is sufficient.

I may be misunderstanding how it works. But I used to think that we upgrade metadata and altering tables in the same transaction. So locking is still possible.

It is only possible if you ALTER or DROP the metadata tables themselves, which we don't do. Postgres locks are per-relation (and sometimes per-row).

So we still need a different protocol here.

I'm not convinced. Using the existing framing and encoding conventions of our main protocol means that we have to maintain and reuse just one implementation. We must continue to improve and enhance it with tooling anyway, so the argument that it's new or badly documented or lacks Wireshark support does not hold in perspective. I do not think that the introduction of CBOR and WebSockets will lower the overall complexity and maintenance burden in this context.

I do not think that the introduction of CBOR and WebSockets will lower the overall complexity and maintenance burden in this context.

+1.
My view on this is that we shouldn't approach this in breadth-first fashion. Right now we have a working compiler<>IO infrastructure written in Python. We want to replace the IO part with Rust code. For that we need to replace pickle with something more sensible. Because we don't need to encode complicated structures (QueryUnit and Error are the two we need) using existing Postgres framing would be sufficient.
The Rust implementation won't happen overnight. And I don't want to mess with WebSockets/CBOR in our current Python code. I want a solution that we can code in a day or two and not depend on HTTP/WebSockets and other third-party libraries.
And maybe once we switch to Rust server we want to explore CBOR and WebSockets -- it just doesn't seem to be a good idea right now.

Understanding schema by main process, at least recomputing hash is useful

There is no need to hash the schema at all. Maintaining a monotonic version counter per-database is sufficient.

Well, hashes are much more reliable and informative. Especially if you consider recovering from a backup a possible scenario.
Also, as I've already said, reusing the same schema for multiple tutorial databases should be possible if using hashes.

So we still need a different protocol here.

I'm not convinced. Using the existing framing and encoding conventions of our main protocol means that we have to maintain and reuse just one implementation.

We already have two: one for postgres and one for edgedb. Which one is main? (Well, the question is rhetorical, but I guess you understand the irony)

We must continue to improve and enhance it with tooling anyway, so the argument that it's new, or badly documented, or lacks Wireshark support does not hold in perspective.

Well, from my perspective it sounds like: we already made a mistake let's hold on it as long as possible (I don't mean to sound insulting if it sounds like that, just show that opinion from a different perspective).

The Rust implementation won't happen overnight. And I don't want to mess with WebSockets/CBOR in our current Python code. I want a solution that we can code in a day or two and not depend on HTTP/WebSockets and other third-party libraries.

This just increases the amount of work on the rust side. I've already shown that this kind of protocol construction is substantially more work in rust (I believe it's the same in python too, BTW). But...

And maybe once we switch to Rust server we want to explore CBOR and WebSockets -- it just doesn't seem to be a good idea right now.

I would approach this from a different perspective: let's make the whole networking part of the compiler in Rust. It means we need only a single implementation of the protocol (and will also allow to send and receive data while compiler holds GIL as a nice bonus). It shouldn't be hard.
I.e. don't upgrade python implementation from IPC/Pickle to RPC/something. Just refactor internals a bit to allow multiple schemas and plugging in the networking in rust.

We already have two: one for postgres and one for edgedb. Which one is main?

They are substantially similar, so can be considered a single protocol.

we already made a mistake let's hold on it as long as possible

I'm not sure what mistake you're trying to point out and based on what evidence.  I have enough experience working with systems based on Protobuf and Thrift to say that they're very far from being a perfect solution, especially from the standpoint of expressiveness (the type system), performance, and ability to extend them. Specific implementations are not stellar (at least for Python). As for CBOR: yeah it has an RFC, but who's actually using it? The combined download monthly total of cbor and cbor2 on PyPI is around 100k (compare to 28M for protobuf and 3M for thrift, 3M for msgpack).  Given this, I don't have much confidence that we would not have to spend time debugging an issue in the third party cbor module or crate, or writing feature PRs against them to support our use cases.

I've already shown that this kind of protocol construction is substantially more work in rust

I thought you liked writing Rust ;-) As far as I can tell, the RPC implementation would require two new protocol envelopes: RPCRequest and RPCResponse, all the hard work of implementing SerDe is done (and, come on, it's not that bad).

Also, @tailhook, please remember that we are discussing an implementation of a single RPC interface with a handful of methods, which is not public, has a single client, and no requirement to be backward compatible.

I would approach this from a different perspective: let's make the whole networking part of the compiler in Rust.

Paul, sorry, but I don't think that I can buy this approach. We'll rewrite edb.server.edgecon, .pgcon, and http/graphql ports first, leaving edb.server.compiler as is. This is big enough task as there's quite a lot of complexity and intricate code in edgecon etc. After we get the new IO working we can discuss rewriting the edb.server.compiler package and the rest of them.  Let's put this issue on hold.

Yes, I don't think the particular framing/serialization of the RPC messages is the most important (or difficult) issue here.  @tailhook raised other concerns in the top post, I suggest breaking them out into another issue (and not discuss the wire formats there).

The combined download monthly total of cbor and cbor2 on PyPI is around 100k (compare to 28M for protobuf and 3M for thrift, 3M for msgpack).

In rust, the situation is different. There is almost no msgpack (because CBOR is basically a nicer and standarized msgpack). And 0.7M downloads (50K monthly). It quite a lot for rust crate. And yes, writing both sides in rust should be easier and faster. (on the other hand, I've never measure the quality of a product by the number of downloads).

As far as I can tell, the RPC implementation would require two new protocol envelopes: RPCRequest and RPCResponse,

No, we need:

A handshake. A really new one, because we aren't going to have the same protocol version for our "main protocol" and this one (well, yes the kinda same one with a different version is usually worse)
In the way that current protocol is written:

Request for compilation with schema, Response
Request for compilation without schema, Response

Ping/Pong packets (load balancing will be very bad if we don't know liveness of the connections)
Preload the schema notifications (or request/reply)
Some metrics interface (with this protocol on a different port)
Graceful shutdown message

This is just from the top of my head. I looks like you really underestimate what is needed there.

all the hard work of implementing SerDe is done (and, come on, it's not that bad).

It's really bad:

There are a bunch of ensure!(.., Underflow) statements which are subject of off by one and copy-pasting issues (yes I've already caught some)
There are a bunch of "slice the buffer then advance the pointer" which is also easy to mess up
Mixing up with any offsets is reported in a very unreadable way (because something next is misinterpreted, and we can't do anything about that)
Ints are handled inconsistently within the protocol, and also different size of strings...

And yes, I also want to stop discussing serialization here.

To clarify, what I propose for the initial Rust rewrite:

Process pool logic server/procpool -- Rust will spawn CPython processes and communicate with them either via TCP or Unix sockets.  The communication protocol is now using pickle -- we want to switch it to use Postgres framing. There would be only two messages in that new protocol -- QueryUnit and Error.

server/mng_port/edgecon -- this is the server-side EdgeDB proto implementation.

server/pgcon -- implementation of the necessary low-level bits of Postgres protocol.

server/http_edgeql_port, server/http_graphql_port -- EdgeQL and GraphQL HTTP endpoints.

server/dbview -- tracks db state

server/main -- edgedb server

server/cluster -- bits and pieces to run & control Postgres instance

server/compiler won't be rewritten as part of this initial Rust effort.  I don't want to use HTTP/WebSockers/CBOR or anything else in that code right now.

This is just from the top of my head. I looks like you really underestimate what is needed there.

Elvis and I both understand that it isn't going to be a 2 liner. Using an HTTP/WebSocket/CBOR layer while looks easier also introduces third-party deps and frankly, the state of HTTP support in Python is so so. We both have extensive experience working with protocol buffers and thirft and their quality in Python is very questionable.
If you really had experience with CBOR in Python we can try using it instead of Postgres framing (@elprans would you be OK with that?), but I'm still -1 on using websockets or http for communicating with Python.

To clarify, what I propose for the initial Rust rewrite:

I still don't understand higher-level architecture. Here is my take on it. We have:
client -> main process -> compiler -> postgres

As long as I understand we want to rewrite the whole "main process" in rust. Am I wrong? Are there any really huge and complicated things in the main process?
Also, we drop the connection between compiler and Postgres, right? (it looks like @elprans somewhat agreed with that, but that agreement looks vague).

Rust will spawn CPython processes and communicate with them either via TCP or Unix sockets

I expect to skip this. We can have a tiny script that spawns rust, compiler, and Postgres (for me vagga solves that, but nevermind). And for production, there are tons of supervisors that can do that job (for the cloud we're going to run them on different VMs anyway).
I kinda have a lot of experience in writing supervisors and it's quite a bit of work. Also, spawning processes and async code is not a great combination.

If you really had experience with CBOR in Python

Yes, albeit 5 years ago or so.

Here is another complication of the protocol: https://github.com/edgedb/edgedb/issues/1023

I still don't understand higher-level architecture.

Currently, it's more like this:
client -> main process <-> compiler
               | # queries    | # load schema
               v              |
             postgres <-------/

Also, we drop the connection between compiler and Postgres, right? (it looks like @elprans somewhat agreed with that, but that agreement looks vague).

I said I agree that this makes a cleaner separation, but we need to think this through to see if possible downsides outweigh the upside.

I expect to skip this. We can have a tiny script that spawns rust, compiler

NAK. This will make development and testing a mess with stray processes.  I still want my server process to be attached to a TTY, and I want ^C to do the right thing.

Also, we drop the connection between compiler and Postgres, right? (it looks like @elprans somewhat agreed with that, but that agreement looks vague).

I said I agree that this makes a cleaner separation, but we need to think this through to see if possible downsides outweigh the upside.

Sure. This is why I'm bringing it in advance. Please keep us updated if you find any.

I expect to skip this. We can have a tiny script that spawns rust, compiler

NAK. This will make development and testing a mess with stray processes. I still want my server process to be attached to a TTY, and I want ^C to do the right thing.

So what is a problem with that:
-+= python -m edb.supervisor_for_elvis
 |--- rustish_server
 |--- python -m edb.server.protocol.worker
 \--- postgres

Even if, for whatever reason, we want to rewrite that in rust, it still doesn't have to be the same process/codebase. And also there are few things that do that including Ctrl+C handling: supervisord, docker-compose and vagga to name a few.

So what is a problem with that

As long as it's not worse than what we currently have, I'm fine with whatever approach.  I'm NOT fine with having to hunt and kill orphaned subprocesses.  In my workflow I restart the server very often, so it needs to start quickly and shut down cleanly.  Docker and other virtualization/containerization is a non-starter for me due to long startup time.

Docker and other virtualization/containerization is a non-starter for me due to long startup time.

Just FYI: Vagga starts in < 100ms per container for most containers. And containers (not docker though) is the most reliable way to kill process subtree on linux (killing pid 1 kills everything in the container).
All of that is not true when running (docker) from MacOS, though.

Vagga starts in < 100ms per container

Does that include the time needed to rebuild the container image?

Does that include the time needed to rebuild the container image?

No. But it includes (some) versioning. I.e. it checks whether the image needs to be rebuild. And with vagga you only need to rebuild the image if dependencies change (that's a very coarse description, but this is offtopic here).

Is there still something here?

Nothing that is going to implemented soon.


Corrected Design and added formulae

Related Issue

Design of statistics table and formulae

Fixes: #331
Describe the changes you've made
Improved design
Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.

Screenshots

Original
Updated

original screenshot
updated screenshot

Original =>

changed =>

@Kaggrov attach the SS of ur changes

Attached SS


abortible request as separate status

if request is aborted, query.$status value is failed
can you create new status, like aborted for this case?

The first step (adding Event .aborted) is done and will be released in #312. Complete migration will be finished in v0.10 since we cannot change library behavior without prior warning.

Done in https://github.com/igorkamyshev/farfetched/pull/357, will be released in 0.10


insights - cspell found spelling errors in public API surface

Investigation for this PR: https://github.com/Azure/azure-sdk-for-net/pull/23150 found spelling errors. When the linked PR merges this service will be opted out of public API surface spell checking to keep other PRs unblocked. This issue describes how to opt back in.
If the above linked PR has not merged this service is still opted out and not blocked by the detection of spelling errors in the public API surface.
What to do

Correct spelling errors or check in fixes for the false positives
Opt back into Public API surafe spell checking

Correct errors
To correct false positives or learn about spell checking see: https://aka.ms/azsdk/engsys/spellcheck
Spell Check Output
1/1 .\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs 1117.59ms X
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:267:87 - Unknown word (Itsm)
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:267:101 - Unknown word (Itsm)
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:322:70 - Unknown word (Azns)
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:766:26 - Unknown word (Itsm)
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:768:16 - Unknown word (Itsm)
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:1102:36 - Unknown word (Odatatype)
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:1102:104 - Unknown word (Odatatype)
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:1106:16 - Unknown word (Odatatype)
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:1107:61 - Unknown word (Odatatype)
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:1126:81 - Unknown word (Onboarded)
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:1127:78 - Unknown word (Onboarded)
D:\code\azure-sdk-for-net\sdk\insights\Azure.ResourceManager.Insights\api\Azure.ResourceManager.Insights.netstandard2.0.cs:1526:9 - Unknown word (Milli)
CSpell: Files checked: 1, Issues found: 12 in 1 files

To check the public API surface locally, in the root of the repo run:
eng/scripts/Export-API.ps1 -ServiceDirectory insights -SpellCheckPublicApiSurface

You may also need to set -SDKType if the appropriate value of SDKType is not all for the service.
Opt back in
NEW INSTRUCTIONS: In the .vscode/cspell.json file remove the line for your service (of the form "sdk/<service>/*/api/*.cs") from the ignorePaths section and check in the change.
OLD INSTRUCTIONS: In the ci.yml file for this service, remove the line: SpellCheckPublicApiSurface: false

same issue with #23188

This has been fixed by https://github.com/Azure/azure-sdk-for-net/pull/25204


Glass shards are OP

You can break glass by throwing them three times, they can break chairs in two throws, I'm sure you can do it with other furniture too haha.

shards should probably break as well, just into dust or something

Worth to mention that you can kill people with them by spamming throw and grab.

Sounds like they need a throw do after then to stop spam throwing.

I count 25 throws to break a normal window tile. That seems fine? Seems like it was already fixed.

yes this was already fixed


Gangsters Organized Crime, Menu not rendering correctly

Hi, I'm currently trying to get Gangsters Organized Crime running on Windows 10.
But with a catch:
I'm trying to get it run based on the Version on "Computer Bild Spiele"
I Used your patch but the Main Menu is flickering, sometimes not rendering completely, unless I click on a Button, hold the mouse and drag it outside the button (so I don't actually click it)
This could be difficult for you to test, as I don't know in which ways the GOG version differs from the CBS Version. Is there a way in which I could assist you, so we can get this issue fixed?

The issue with this game is that certain controls (labels, buttons, etc.) will be pushed to the back so they are hidden.  My "fix" simply activates the main window which will reorder the controls so that you can see them.  However, each time I reactive the main window it causes all the controls to flash.  So I try to detect when the screen is redrawn and and only active this once when the screen is redrawn.  But I changed this code in one of the latest releases.  Try using an older release and see if that works.

This issue looks like it is related to issue #69

I just posted an update patch that should address this issue.  You can see the update here:  Gangsters Organized Crime patch

This should be fixed with the latest update:  https://github.com/elishacloud/dxwrapper/wiki/Gangsters-Organized-Crime


Is this a bug?

Challenge Waypoint: Set the Font Family of an Element has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/601.3.9 (KHTML, like Gecko) Version/9.0.2 Safari/601.3.9.
Please describe how to reproduce this issue, and include links to screenshots if possible.

I am unable to reproduce this on
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Have you tried refreshing the page and/or restarting your browser?
If that doesn't work try resetting the waypoint and redoing it or trying in a different browser.
Please let us know if this issue persists so we can try to get more information from you.

I tried in Chrome, and it works.^^
My previous browser is Safari version 9.0.2 on Mac OS X EI Captian version 10.11.2.
Thank you.

On Jan 11, 2016, at 4:16 PM, Brian<EMAIL_ADDRESS>wrote:
I am unable to reproduce this on
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Have you tried refreshing the page and/or restarting your browser?
If that doesn't work try resetting the waypoint and redoing it or trying in a different browser.
Please let us know if this issue persists so we can try to get more information from you.
—
Reply to this email directly or view it on GitHub https://github.com/FreeCodeCamp/FreeCodeCamp/issues/6049#issuecomment-170451657.


[BUG] Web: Editor area's focus is always on top, can not select any dropdown elements when it overlaps the HTML editor

Describe the bug
Web: Editor area's focus is always on top, can not select any dropdown elements when it overlaps the HTML editor
To Reproduce
Steps to reproduce the behavior:

Create a form
Add a form fields (HTML editor, dropdown menu)
Add multiple items in the dropdown list to overlap into the HTML editor
Elements from the dropdown fields that overlaps with the HTML editor area cannot be selected. The focus is always in the HTML editor

Expected behavior
Element from the dropdown list should be selectable regardless if it appears over the HTML editor
Screenshots
See screenshots below:

Device:
Web - Chrome.
Additional context
None.

I also found like that

Having the same issue.


[FORK] GitHub Billing

The GitHub organisation is currently on GitHub Free, which has a number of limitations (including limited actions minutes). https://github.com/organizations/scikit-time/settings/billing
How did sktime deal with this issue? I assume we can leverage our academic links i.e. https://docs.github.com/en/billing/managing-billing-for-your-github-account/discounted-subscriptions-for-github-accounts

I'm bumping this to remind me to do it once I've completed my move

Done


Repo is not publishing artifacts

Seems something is off with this repo in some way.
cc @beckermr

I stumbled upon the errors from this while fixing https://github.com/conda-forge/r-plnmodels-feedstock/issues/1
It's now fixed.


Forceclose on import of source if Crop Filter on AVS Filters is selected

-------------------------- System Environment --------------------------
StaxRip    : 2.0 Beta 2 NET 4.7
Windows    : Windows 10 Pro 1803
Language   : German (Germany)
CPU        : AMD Ryzen Threadripper 2950X 16-Core Processor
GPU        : NVIDIA GeForce GTX 1050 Ti
Resolution : 1920 x 1200
DPI        : 96
-----------------------------------------------------------------------------

If CROP Filter in AVS Filters is selected StaxRip closes without any error on importing source.

If i disable that switch, importing source is fine, i can also enable it after importing the source and crop without any problems.
I would like to provide a debug log, but the debug switch seems to do nothing, can't find any new log file in any folder.

and crop

Debug logger is a listener for the Encoders.
I suggest fixing all your other issues first, That's where all your issues are located at.
Trying to use two different Versions with two different Setting keys & Switches is not going to work.

Closing all my Issues isn't fixing anything.
I can confirm, that all the other issues that i had, came from this one.
As all works fine with the described procedure.
I think you mixed this one with the other issues, because i've not used different versions.
And please stop closing my issues after one day, this is not enough time to answer, this is rediculous!

Not sure your understanding what I'm saying or it's a Language barrier problem. Since it's unclear whats going on. It might try a forum that speaks your Language Since something is getting lost in translation.
Automation System Closes the Issues after inactive after X amount of Time.


A single questing about the generation of the ego-vehicle

Hello,thanks for this great project!! I encountered some problems when I was learning.
I noticed that during the generation of the ego-vehicle, its heading angles were randomly generated, and I wondered how I can set them to 0.
Thanks!!!

https://github.com/eleurent/highway-env/blob/1d2f281ef0f970afb380b15dbec9da40cc0ba432/highway_env/vehicle/kinematics.py#L84
from here you can find that the heading angle is always along the lane

Thanks!!! In addition, I would like to ask how to delete vehicles other than ego-vehicle？

do you mean just create ego-vehicle at the very beginning?

yes

import gym
import highway_env

env = gym.make("highway-fast-v0")
env.configure(
    {
        "vehicles_count": 0,
    }
)
obs = env.reset()
print(obs)

Thanks！！！


Lists as input for the set_x_fields methods?

Right now all of the setting methods (set_place_fields, set_polls_fields, etc.) all take a string. What do we think about changing this to take a list of strings? We can handle the "stringification" within the method easily with a join. This seems more straight forward and less likely to lead to errors, IMO.
For example, we are assuming that people are going to build the url string correctly, but maybe it's best to do this for them to ensure it's correct?
If you guys are okay with this, I am happy to make these changes and can take care of #12 at the same time.

Lists seem to be better!

Lists seem to be better!

Closing this because we are phasing these methods out. See #28 for the new approach.

Closing this because we are phasing these methods out. See #28 for the new approach.


temporarily remove parse WSO access log

@GraceRuan Change would not stop logs from being sent. Needs to be done in Funbucks.


Prevent JRuby build failure by sending to Kernel.require (4-0-dev)

Reflection of https://github.com/rspec/rspec-support/pull/492 on 4-0-dev

@JonRowe @benoittgt I'll merge right in as it is green.

@JonRowe @benoittgt I'll merge right in as it is green.


Implement Projects and Project Page Components

Description
Implement the new components made for the project page update and the new project page.
These are the new components:

[x]  Search Bar
[x]  Pagination
[ ]  Iframe Container

The SearchBar functionality is completely implemented as of now.

The Pagination component has been fully implemented and all its related components.
Changes were made to the IconButton a disabled state has been added and stylized. These changes were needed because of the Pagination component.
The arrows icons were added to the project

The iframe container is implemented quickly as this is the least complex component of this issue.


Support Form JSON configuration

Closes https://github.com/bpmn-io/properties-panel-next/issues/49

I've tested this manually and it works as supposed. The code looks clean too. Great job!


Sync eng/common directory with azure-sdk-tools for PR 8413

Sync eng/common directory with azure-sdk-tools for PR https://github.com/Azure/azure-sdk-tools/pull/8413  See eng/common workflow

This is indeed a breaking change. I will take action to update the two recordings that were affected by this change.


Update contexts.

This includes the updated VC context.

Just want to note that the Travis builds are failing.

Just want to note that the Travis builds are failing.

failure is
     TypeError: Cannot read property 'should' of undefined

issue is actually this:
  104     verifiedCredential.proof.should.exist;

proof on verifiedCredential is no longer there in the text.
is this intentional?
@gannan08

Ok, so, the reason the 'vc should have a proof property' tests are failing, is that the resulting VC is now of the form:
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/1872",
  "type": [
    "VerifiableCredential",
    "AlumniCredential"
  ],
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": "Example University"
  },
  "https://w3id.org/security#proof": {
    "@graph": {
      "type": "https://w3id.org/security#Ed25519Signature2018",
      "dct:created": {
        "type": "xsd:dateTime",
        "@value": "2019-05-22T15:46:58Z"
      },
      "https://w3id.org/security#jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..Ig23C6iL_9VKBph2Z03nq5LgNxFFdLWVGaJYVJy6y_EzQcqhejmpqWvsuaOLsZq-0GbTWyJ85Fhnvc_yqcFfBA",
      "https://w3id.org/security#proofPurpose": {
        "id": "https://w3id.org/security#assertionMethod"
      },
      "https://w3id.org/security#verificationMethod": {
        "id": "https://example.edu/issuers/keys/1"
      }
    }
  }
}

(meaning, needs to be compacted?)

@dmitrizagidulin, tests passing now.


Accesibility milestone to portfolio

Dear Code Review team,
Could you please help us to review the following changes made to the Porfolio project related to Accessibility features, which are the following:
Report

[x] Page titles -no issues found.
[x] Image text alternatives -no issues found.
[x] Text headings -no issues found.
[x] Color contrast -change the font color from white to black on all buttons. line 392 on styles.css and
line 770 on styles.css
[x] Resize -no issues found.
[x] Interaction -add a label to all form elements (name, email, message). line 287-304 on index.html
[x] Moving content -set animation duration to 4s and delete infinite iteration. line 143-145 on styles.css
[x] Multimedia -no issues found.
[x] The basic structure of the page -no issues found.

Some of these changes were done as suggested by Wave Accessibility Evaluation Tool Report.
We really appreciate your kindly support.
Cheers,
Glenda / Luis

Dear Code Review Team,
The required changes were applied.
Could you help us with your review.
Thanks in advance.
Cheers,
Glenda / Luis

Please submit for another review.


Allow an ExpressionDeParser instance to be injected into StatementDeParser

Is there a reason why, unlike other DeParser s like InsertDeParser and SelectDeParser, you aren't allowed to inject an ExpressionDeParser instance?  I could see this being useful, for example, when you want to create a translator from one SQL dialect to another.  You would code the translation of, for example, string concatenation from || to concat(...) in the visit(Concat) method of an ExpressionDeParser.  Then in order to apply this translation to all statements where it could occur, you would use the proposed enhanced StatementDeParser and then pass your ExpressionDeParser instance.  This appears to be a straightforward enough change so I think I can manage a pull request if approved.

You know,  JSqlParser is feature request driven. That's why it is not there. I can follow your argumentation. Looking forward to your pr.

Of course.  I wanted to create an issue first so we could take about it if necessary.  Working on the PR now.

Would it be acceptable to you if I picked only one ExpressionDeParser method to verify to have been called in the test?  Also, would it be OK if I use Mockito in the test?

Sorry about that.  Clicked the wrong button.  It seems I don't have privileges to assign myself the issue.  Could you do that for me please?

Assigned you ... , I have no problem including some kind of mocking framework, as long as it is only a test dependency.
I am not quit sure if I understand your question about the method called once. Could you make an example, what do you want to test.

Of course.  I will make sure that the Mockito dependency is added only within the test scope.
Please refer to StatementDeParserTest for the following paragraphs.
The shouldUseProvidedExpressionDeparserWhenDeParsingInsert test is what I meant in my previous comment.  I give a concrete SQL statement as input and then verify that the ExpressionDeParser is interacted with as expected.  However, I only checked the interaction through one visit overload.  I think it would be too cumbersome to test for all the visit overloads in this style.
On the other hand, the shouldUseProvidedExpressionDeparserWhenDeParsingDelete test does not need to verify interaction with each visit overload in ExpressionDeParser.  Instead I only need to verify that the ExpressionDeParser is used to visit each of the statement parts where an expression could occur.
The first style is black-box testing but doesn't seem as comprehensive as the second style.  I myself prefer the latter but I would like to consider your opinion on the matter.

I would go with the latter one as well.
By the way you are instaniating a CCJSqlParserManager. You could use CCJSqlParserUtil to avoid all that boiler plate stuff (new, StringReader, ..).

Just pushed more new commits.  It seems evident to me now that we should also inject the SelectDeParser.  The assertions in the tests for insert and replace seems to me to indicate that the Law of Demeter are being violated.  Would you have any concerns if I update the issue to include SelectDeParser?  InsertDeParser and UpdateDeParser are two other DeParsers that can accept SelectDeParsers in their constructors.

@chrycheng: no concerns here

ExecuteDeParser doesn't use the ExpressionVisitor passed.  Is this intentional or may I go ahead and file a separate issue for this?  It would block this issue so I can assign it to myself as well.

No it isnt. It's legacy code.

Created issue #446.  Please assign it to me.

Fixed by 9d680a6.


Document the action inputs and their default values

https://github.com/shogo82148/actions-setup-perl/issues/321

Thanks!


cppPart.pointee: Cannot use mutating member on immutable value: 'pointee' is a get-only property

i'm using
"react": "18.3.1",
"react-native": "0.75.4",
"react-native-nitro-modules": "^0.19.0",
"@baronha/react-native-multiple-image-picker": "^2.1.0",
after setting up, when i build on xcode got this

You should use Nitro 0.18.2.
The latest version of Nitro Module is corrupted.


Add support for browser contexts

Description
Thanks for this awesome project! Just laying this issue here as a request when you get around to it to implement browser contexts (added to puppeteer in v1.5.0 a few days ago).

We'll get there @robertmiles3  :)

No doubt. Again, thanks for the work. I've got a PoC going for a docker container hosting a .NET Core api with puppeteer that you can send html to and get back a pdf byte stream for reporting.

That's awesome man! I'm so glad to hear that.
You are running docker on windows, aren't you?

Nope. Docker on macOS (using microsoft/dotnet:2.1-aspnetcore-runtime image).


Comment to a link without title fails

When linking to an image, linkser does not fill the title field. Notifications fail to truncate the title, which is nil

I assigned this bug to myself since my notification code is to blame

Evil monkey blames @rafaelgg code!

I moved a lot of common code to the helper, but barely rewrite anything. Just a couple of nil? checks and add url as a last resort to determine title.
This is not, however, the best solution for the problem at hand: as discussed yesterday, we should probably write wrapper title and description methods for models that don't have those fields and just use that.


Eq instance?

I think it wouldn't be hard to do an Eq instance for Ref right? Would you be open to a pull request?

I think such an instance would be necessarily unsafe. Depending on what sort of equality you want, maybe something like refEq :: forall a eff. (Eq a) => Ref a -> Ref a -> Eff (ref :: REF | eff) Boolean would work?

Ahh, I wasn't clear. I mean reference equality, not dispatching to equality of the contained item.

It turns out I don't think I'll need it for what I'm doing, but I still think it could be useful and would be happy to do the typing.

Perhaps it could go into Unsafe as a function then?
refEq :: forall a. (Eq a) => Ref a -> Ref a -> Eff Boolean

I'm not clear on what's unsafe about it? Do I misunderstand javascript's reference equality semantics?

And actually it would be more like:
forall a b. Ref a -> Ref b -> Boolean

ala https://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/System-Mem-StableName.html

Reference equality would be perfectly safe.

Any new thoughts on this?

Referential equality is available through purescript-unsafe-reference - I think that probably solves this? An Eq instance still seems pretty suspect to me.


feat: Improve reaction, metabolite, and gene annotations

Description of the issue:
Human-GEM reactions, metabolites, and genes are associated to many external identifiers from databases such as KEGG, BiGG, ChEBI, and MetaNetX. However, many associations are outdated or missing. It would be great to not only update old IDs, add missing IDs, and correct any erroneous IDs, but to do so in an automated manner such that we can simply re-run the pipeline again in the future to ensure that the IDs remain current.
Expected feature/value/output:
An automated or semi-automated pipeline/script that updates old/missing/incorrect reaction, metabolite, and gene identifiers present in the reactions.tsv, metabolites.tsv, and genes.tsv annotation files. It may be beneficial to develop this in python so it can be implemented as a GitHub action.
Current feature/value/output:
Many model components are missing annotation information and/or may have outdated or incorrect annotation information.
I hereby confirm that I have:

[X] Checked that a similar issue does not exist already

This is certainly an important issue.
However, it appears that there is no readily acceesbile pipeline(s) that are tuned for GEM curation. We thus welcome the contributions and collaborations from, as well as serve for, the research community toward such a (semi-)automated pipeline.

This is certainly an important issue.
However, it appears that there is no readily acceesbile pipeline(s) that are tuned for GEM curation. We thus welcome the contributions and collaborations from, as well as serve for, the research community toward such a (semi-)automated pipeline.

update old IDs, add missing IDs, and correct any erroneous IDs

Intuitively, these look like different problems requiring independent solutions. Based on how the curation progress so far, it would look to me like adding missing IDs has do be done manually. A script (GH Action) could be set up to cross-reference IDs to highlight the erroneous ones, but resolving the conflicts manually might be more straightforward, at least in the near future.

re-run the pipeline again in the future to ensure that the IDs remain current

Once there is an ID that gets outdated perhaps a new one can be provided by the reference database.

update old IDs, add missing IDs, and correct any erroneous IDs

Intuitively, these look like different problems requiring independent solutions. Based on how the curation progress so far, it would look to me like adding missing IDs has do be done manually. A script (GH Action) could be set up to cross-reference IDs to highlight the erroneous ones, but resolving the conflicts manually might be more straightforward, at least in the near future.

re-run the pipeline again in the future to ensure that the IDs remain current

Once there is an ID that gets outdated perhaps a new one can be provided by the reference database.

Hello. Don't know if this is the right way to do this, but since in this thread is about annotations, both m01778c (elaidate) and m02646c (oleic acid, oleate) share the same pubchem.compound ID (445639), whereas m01778c should be 5461071 and m02646c should be 445639. If it is necessary to open a new thread, I'll do it. I'd be a good idea to open an issue where people could report this kind of issues when dectected, and be integrated into the pipeline.
Best regards

@jorgemlferreira please open an issue for this, and very welcome for the contribution!

I'll do it, thanks and keep up the good work!

In order to improve the annotations, Hao and I have mapped Human-GEM reactions to Rhea. The mapping was done using 2 methods:

Using UniProt. Only the reactions with a single Ensembl gene ID  associated to only one UniProt ID were considered. From that list of UniProt only entries having a single catalytic site reaction were selected. The Rhea ID provided by UniProt was then mapped to MetaNetX (4.1) xref file. There is association if the MNX ID retrieved is identical to the MNX stored in the reactions.tsv annotation file.
Using the equation. All the reaction from Rhea that are not undirected (i.e. the equation with the '=' sign where excluded) were mapped to the reaction equation of Human-GEM by comparing the metabolite names, the stoichiometry and the equation sign (<=, =>, <=>). Only perfect hits were retained. In Order to improve the mapping a few metabolite synonyms, manually verified were added considered by algorithm, see attached file.
met_synonyms.txt

The IDs mapped and the corresponding reaction equations are described here
Only 570 Rhea IDs could be added, but the aim was to avoid False positive hits.

@pecholleyc nice addition to reaction annotation. The provided equation comparison looks promising and enables easy reviewing. Excellent work!
Some comments:

Rhea is a reliable curated source and with built-in UniProt links. Though it always assign reaction with 4 directions: a master one in undefined direction and three others (<=, =>, <=>). So the mapping to Rhea is actually an association to a group 4 reactions, while the members often are mapped to different databases (e.g. one to KEGG, another to Reactome) via master id. Then it might be good also include another column rxnRheaMasterID, through which the advantage of Rhea can thus be fully utilised, toward a more comprehensive coverage in annotation.
Please also include met_synonyms.txt to this branch but in tsv format. It hosts useful information of met names mapping, which seems to be something we should start to build up.

Expected feature/value/output:
An automated or semi-automated pipeline/script that updates old/missing/incorrect reaction, metabolite, and gene identifiers present in the reactions.tsv, metabolites.tsv, and genes.tsv annotation files. It may be beneficial to develop this in python so it can be implemented as a GitHub action.

@pecholleyc if there code to share as well that would be great.

Regarding MetaNetX, know that since version 4.0 there is a dataset with deprecated MetaNetX IDs and their replacement (e.g. chem_depr.tsv):
#deprecated_ID	ID		version
MNXM1000	MNXM8962	3.*

while the xref dataset (e.g. [chem_xref.tsv](https://www.metanetx.org/cgi-bin/mnxget/mnxref/chem_xref.tsv)) now contains entries in the description column stating "secondary/obsolete/fantasy identifier", for instance as:
biggR:EX_sel_e		MNXR104327	Selenate exchange||1 biggM:sel@BOUNDARY = 1 biggM:sel@biggC:e
biggR:R_EX_sel_e	MNXR104327	secondary/obsolete/fantasy identifier

@Hao, good suggestions, I have added this information in the branch. Note that for Rhea IDs mapped using only the UniProt strategy rnxRheaID = rxnRheaMasterID.
@mihai-sysbio, unfortunately there is no working pipeline yet to close this issue, but we aim for that direction. I will put the 'pipeline' (it is more a collections of python scripts) in the Sandbox repository in the following days. Maybe it can be then used as precursor to build the pipeline. Actually I think it would be beneficial to discuss the content of this pipeline in details.
@edkerk Indeed, the secondary/obsolete/fantasy identifiers were discarded when parsing the xref file. But I understand that relying on MNX IDs to map back Reaction ID in human-GEM is a weak point in the algorithm. External databases might bring invalid information/mapping so I would imagine the pipeline to cross-validate each current or new Identifiers with the existing ones. And I would also imagine the pipeline would store a list of manually curated IDs that would resolve any contradictions between the databases.

@pecholleyc look forward to the PR

A few PRs have been merged since the last comment - what is the status of this issue?

A few PRs have been merged since the last comment - what is the status of this issue?

my view is this is an ongoing process still.

Indeed, but I don't see immediate actionable points. Perhaps it's time to turn this into a discussion?

agree!

Closing this issue now. The discussion should continue under https://github.com/SysBioChalmers/Human-GEM/discussions/253, or maybe a new thread.


feat: replace windows log to use winevtlog

Hi!
This change is related to https://github.com/newrelic/infrastructure-agent/pull/1125
Fluent-bit has a new input plugin for windows logs that come to "replace" winlog, by now we're updating the infrastructure-agent to accept this new plugin type and the next step will be to set it as the default plugin when installing logging for windows.
We thought on make this change transparent to the users by replacing winlog > winevtlog directly when generating the fluent-bit configuration, but the output generated by those plugins have different attribute names and so on, so we discard that option.
Regards!
https://docs.fluentbit.io/manual/pipeline/inputs/windows-event-log-winevtlog
https://fluentbit.io/announcements/v1.9.0/
Related to PR https://github.com/newrelic/open-install-library/pull/678 but created on the repo for regression tests to run.

Tested manually with test/manual/definitions/logging/w19-logs.json and install -c https://raw.githubusercontent.com/newrelic/open-install-library/feat/winevtlog/recipes/newrelic/infrastructure/windows.yml,https://raw.githubusercontent.com/newrelic/open-install-library/feat/winevtlog/recipes/newrelic/infrastructure/logs/windows-logs.yml


How to keep the data persistent for the dashy deployed in the kubernetes via Helm

Question
As I have seen the Helm charts, in the templates I don't see any PV & PVC files. Would like to understand more on maintaing the persistent data
Category
Setup and Deployment
Please tick the boxes

[X] You are using a supported version of Dashy (check the first two digits of the version number)
[X] You've checked that this question hasn't already been raised
[X] You've checked the docs and troubleshooting guide
[X] You agree to the code of conduct

@Lissy93 , Kindly share the requested information

Hi @Lissy93 , can you provide us more information on this


Use custom node key also when isVirtualized=true

We had plenty of state issues while dynamically adding/removing nodes from the tree and noticed that it's caused by the key prop. Adding a custom getNodeKey method works fine when isVirtualized=false but isn't honored when isVirtualized=true.

Thanks for bringing my attention to this. I thought I had had some issues with using the nodeKeys instead of react-virtualized's keys, but I couldn't produce any unusual behavior in my environment.


Refactor space layout

Looks very nice 👌
I have few thoughts:

Strategies list can be hyperlinked to a particular strategy page or would be cool if we can display the strategy model on the proposal page

Would be nice to add Twitter, Github links in the about section (maybe Network and plugins too? 🤔)

Core and Comunity are not needed anymore?

if yes we can remove this field?

No description provided.

Awesome! I think this is a good base that we can start improving more in follow up PR's. One thing that is a little confusing is that when you click back on delegate it goes back to the home page.

@ChaituVR "Show only member proposals" field is still being used. When it's "on", only members can post a proposal, if "off" anyone can post (if they have minScore)


Add url-unshortener extension

Description
See readme.
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

@pernielsentikaer awesome idea about the accessories. Cleaned up the UI a bit, hope you like it. I also added throttle to the list.
Not sure why you see the globe so often, it's only supposed to show up if there is no favicon for that domain. Do you have some example links I can look into?

Just found some bugs. I'll get back when I've fixed them.

Nice addition of colors btw!🤩
Short summary of the latest changes:

Updated fetchFavicons to fetch favicons when typing in a URL manually in the search bar.
Stricter URL validation
If text selection or clipboard doesn't match a valid url (dr.dk), try to add https:// before it and retry in the same order.
 For example: dr.dkk

Do you know why https://raycast.com doesn't end up with a 200?

Doing the same from a terminal seems to catch it
❯ wget https://raycast.com 2>&1 | grep Location:
Location: https://www.raycast.com/ [following]

Seems like favicon is found for the first element but not for the second, is that because of looking up with www too and it fails?

However, if I select bt.dk from a input field it seems to work better

@pernielsentikaer I will look up why the favicon doesn't work consistently.
I just ran curl on https://raycast.com and received a 308 response, so it appears that is how Vercel has configured their proxy.
curl -I https://raycast.com
HTTP/2 308
cache-control: public, max-age=0, must-revalidate
content-type: text/plain
date: Wed, 29 Nov 2023 15:06:57 GMT
location: https://www.raycast.com/
refresh: 0;url=https://www.raycast.com/
server: Vercel
strict-transport-security: max-age=63072000
x-vercel-id: arn1::6dr8m-1701270417089-401484437296

Okay, so here is some of the changes made:

Handle all types of 3xx redirects
Rework favicon fetching to fix missing favicons
Favicon is now using the same data structure as the redirectionSteps
Show icons in accessory for more http status codes
Show error messages in a list item instead of a toast for improved visibility

Wow what a nice update again 🔥 It works much better! Would it be possible to support bt.dk without https:// in interactive view, or doesn't that make sense?

Could you give it another spin to check that I didn't break anything

Thanks! It's working great on my end. One question since I'm still learning. What is props.fallback for?

It's when you add the command as a fallback command, check this video 🙂
https://github.com/raycast/extensions/assets/38033107/2debba09-c696-43e5-a8ee-3f73dfa99665
Do you think we have anything outstanding still?

Got it! No I'm happy with it if you are😃


Response adding "print"

Hello! I really don't think you want to work on this package anymore, but I've recently found it, and it's fitting my need perfectly. However, I have a small issue with responses inserting "print" at the start of the response, and then every 1000 characters or so.
Any idea what would be causing this, or what I could do to work around it?  If you're able to help, it would be appreciated.
Examples
rcon serverinfo
print <------
Server info settings:
sv_maxclients        30
version              CoD4 X - linux-i386 build 962 Mar 12 2019
shortversion         -
build                962
branch               dev_newarch
rcon status (in bold)
print
map: mp_crash
num score ping guid                             name            lastmsg address               qport rate

2    47<PHONE_NUMBER>617288258243              BockLandes^7            0 9<IP_ADDRESS>:28960  27080 100000
4    30<PHONE_NUMBER>615351783804              Satan^7                50 9<IP_ADDRESS>:62100  45177 100000
6    47   64<PHONE_NUMBER>751016972              RitZz JD-I^7         50 9<IP_ADDRESS>:60773  34240 100000
8   119   72<PHONE_NUMBER>055939769              FaNaT^7                 0 9<IP_ADDRESS>:28960  17643 100000
9    69   56<PHONE_NUMBER>459929248              Morcegam^7             50 9<IP_ADDRESS>:28960    54339 100000
10    54<PHONE_NUMBER>615138301380              Cuervo^7                0 9<IP_ADDRESS>:18078  27741 100000
11    27<PHONE_NUMBER>614342378295              Johnny^7               50 9<IP_ADDRESS>:28960  34188 100000
13    46  151print
2310346613553464866              Talha^7                50 9<IP_ADDRESS>:14289  45413 100000
14    45   67<PHONE_NUMBER>254859697              enFF^7                  0 9<IP_ADDRESS>:11650   60249 100000
15   107   43<PHONE_NUMBER>823883199              LEGz AIMBOTTT^7         0 9<IP_ADDRESS>:28960    42668 100000
16    37   46<PHONE_NUMBER>514424766              Fox1Lead^7            900 9<IP_ADDRESS>:38080    44720 100000
17    72   32<PHONE_NUMBER>501231356              wayne^7                50 9<IP_ADDRESS>:28960   36618 100000
19    34<PHONE_NUMBER>614053634727              |LI|RussianPooH^7      50 9<IP_ADDRESS>:28960    43288 100000

You could just replace the print string with an empty one.
Example:
'use strict';
const Rcon = require("quake3-rcon")
let r = Rcon({...})
r.send("serverinfo", function(response) {
   let actual_response = response.replace("print ", "")
   console.log(actual_response)
})
// output should have everything besides that print str

👀


feat: auto select parent of the removed component

Description
https://github.com/user-attachments/assets/764917aa-74ea-4c1b-8361-6441344227fd
Fixes #36281
or
Fixes Issue URL

[!WARNING]
If no issue exists, please create an issue first, and check with the maintainers if the issue is valid.

Automation
/ok-to-test tags=""
:mag: Cypress test results

[!WARNING]
Tests have not run on the HEAD 88d0b70bec732e804919a056cb0f350ae8580aa0 yet
Fri, 13 Sep 2024 07:46:13 UTC

Communication
Should the DevRel and Marketing teams inform users about this change?

[ ] Yes
[ ] No

Summary by CodeRabbit

New Features

Introduced a new optional parentId property for enhanced widget selection, allowing for hierarchical management.
Updated widget selection and deletion processes to utilize the parentId for improved contextual handling based on layout type.

Bug Fixes

Enhanced logic in widget selection to ensure the correct parent ID is used, improving overall selection accuracy.

Documentation

Updated documentation to reflect changes in widget selection and deletion functionalities.

@znamenskii-ilia The sagas edited in  this PR might effect Fixed mode and Auto Layout as well. Please test this once to make sure it works the same way or doesn't break anything in Fixed mode and Auto Layout.
Other than that the changes look good to me.

@riodeuno I've added and extra isAnvilLayout check, pls review again


Minor fixes

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/gazayas/bullet_train_testing?version=dev:7bef99ae73e08e796ad58ed4189426be104784f9

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/gazayas/bullet_train_testing?version=dev:fc6afeba34fd4b977c90fbc18ec0751cab7bdb77


DllExportOurILAsm causes project to always appear dirty and require build

Steps to reproduce:

Download attached solution, extract, open.
Issue build solution command to get fresh builds of all projects.
Issue build solution command again, observe behavior.

DllExport -version: v<IP_ADDRESS>858+c1cc52f
Used Visual Studio / MSBuild: MSVS 17.1.0 / MSBuild 15.9.21+g9802d43bc3

Information from Data tab for LibFoo:
Installed: True; 1.7.4+c1cc52f; invoked: 1.7.4
Project type: CsSdk
Storage: ProjectFiles
Compiler.Platform: Auto
Compiler.ordinalsBase: 1
Compiler.rSysObj: False
Compiler.ourILAsm: True
Compiler.customILAsm:
Compiler.genExpLib: False
Compiler.peCheck: PeIl
Compiler.patches: None
PreProc.Type: None
PreProc.Cmd:
PostProc.Type: None
PostProc.ProcEnv: $(SolutionPath);$(MSBuildThisFileFullPath)
PostProc.Cmd:
SignAssembly:
Identifier: B2B68504-BE59-4B4A-8CEA-9C3E3A6C51F6
Instance: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\MSBuild.exe
Project path: C:\Users\cmd\source\repos\AlwaysDirtyIssue\LibFoo\LibFoo.csproj
Action: Configure
PlatformTarget: x64
TargetFramework: netstandard2.0
TargetFrameworks:
TargetFrameworkVersion:
RootNamespace:
AssemblyName:
MgrArgs:
MetaLib: tools\raw\lib\net20\DllExport.dll
MetaCor: tools\raw\lib\netstd\DllExport.dll
Proxy:
StoragePath: .net.dllexport.targets
ddNS: LibFoo
ddNS max buffer: 500
UseCecil: True
intermediateFiles: False
timeout: 30000
Options: None
RootPath: C:\Users\cmd\source\repos\AlwaysDirtyIssue\
PkgPath: C:\Users\cmd\source\repos\AlwaysDirtyIssue\packages\\DllExport.1.7.4\
SlnFile:
SlnDir: C:\Users\cmd\source\repos\AlwaysDirtyIssue\
DxpTarget: tools\net.r_eg.DllExport.targets
MsgGuiLevel: -1
LockIfError:

Information from Data tab for LibBar:
Installed: True; 1.7.4+c1cc52f; invoked: 1.7.4
Project type: CsSdk
Storage: ProjectFiles
Compiler.Platform: Auto
Compiler.ordinalsBase: 1
Compiler.rSysObj: False
Compiler.ourILAsm: False
Compiler.customILAsm:
Compiler.genExpLib: False
Compiler.peCheck: PeIl
Compiler.patches: None
PreProc.Type: None
PreProc.Cmd:
PostProc.Type: None
PostProc.ProcEnv: $(SolutionPath);$(MSBuildThisFileFullPath)
PostProc.Cmd:
SignAssembly:
Identifier: D0933B3C-5336-4CFD-B255-303678C9FCE1
Instance: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\MSBuild.exe
Project path: C:\Users\cmd\source\repos\AlwaysDirtyIssue\LibBar\LibBar.csproj
Action: Configure
PlatformTarget:
TargetFramework: netstandard2.0
TargetFrameworks:
TargetFrameworkVersion:
RootNamespace:
AssemblyName:
MgrArgs:
MetaLib: tools\raw\lib\net20\DllExport.dll
MetaCor: tools\raw\lib\netstd\DllExport.dll
Proxy:
StoragePath: .net.dllexport.targets
ddNS: LibBar
ddNS max buffer: 500
UseCecil: True
intermediateFiles: False
timeout: 30000
Options: None
RootPath: C:\Users\cmd\source\repos\AlwaysDirtyIssue\
PkgPath: C:\Users\cmd\source\repos\AlwaysDirtyIssue\packages\\DllExport.1.7.4\
SlnFile:
SlnDir: C:\Users\cmd\source\repos\AlwaysDirtyIssue\
DxpTarget: tools\net.r_eg.DllExport.targets
MsgGuiLevel: -1
LockIfError:

Project Sample
AlwaysDirtyIssue.zip - Reproduction solution w/3 projects:

LibMain: A class library that references the other two libraries. (To show that dirty rebuilds causes cascades.)
LibFoo: A class library with DllExports using "ourILAsm".
LibBar: A class library with DllExports not using "ourILAsm".

Details
The only difference between LibFoo and LibBar should be the setting of DllExportOurILAsm. When issuing "build solution", LibBar behaves as expected, only building & running build events when changes are made. By comparison, LibFoo invokes a portion of the build process (including post build events, DllExport, etc.) every time.
Comparing the output from msbuild between the two projects, LibFoo's output has only a single line of output that LibBar's doesn't:
Copying file from "<sln dir>\LibFoo\obj\x64\Debug\netstandard2.0\LibFoo.pdb" to "<sln dir>\AlwaysDirtyIssue\LibFoo\bin\x64\Debug\netstandard2.0\LibFoo.pdb".

My guess is that, because DllExport deletes the PDB when using "Our IL Asm" since it isn't valid, msbuild thinks the project needs to build because the expected output file is missing.
If one day "Our IL Asm" ever does re-gain the feature of being able to produce PDBs, this issue would be solved. In the meantime, perhaps there's someway to indicate to msbuild that it shouldn't expect to find the PDB?
Cheers!

Thanks for the detailed report!

My guess is that, because DllExport deletes the PDB when using "Our IL Asm"

Yes, I remember this logic programmed due to possible incorrect ISymUnmanagedWriter for non-modified asm.
And more like, yes, this can really invalidate some nodes in msbuild -_-
Good catch! Need to check it but I literally don't even know how to live in the coming months at all, thus no ETA. Sorry.

I literally don't even know how to live in the coming months at all, thus no ETA. Sorry.

No worries; this is just something I wanted to get on the books with details before I forgot, and more than that it's a totally non blocking issue! Life always takes priority. Please take care of yourself!

@crusader-mike

Any progress/luck wrt this issue?

My luck is gone when my opensource activities was stopped/paused. Yet no opportunity to review the issue somehow, later or not I don't know either. Sorry. But who cares.

for some unknown reason

Above,
Stub was programmed due to ISymUnmanagedWriter because it produces incompatible format anyway
https://github.com/3F/coreclr/blob/05afa4f81fdf671429b54467c64d65cde6b5fadc/src/debug/ildbsymlib/symwrite.cpp#L308
while adding a bunch of other problems together with modified modules at runtime, as far as I remember.

So, I finally looked into this issue.

My guess is that, because DllExport deletes the PDB when using "Our IL Asm" since it isn't valid

No. MSBuild invalidates the target module because it is literally not relevant to the intermediate (obj); because it was modified (DllExport) because you decided to do it. And here is very important point,
Today's DllExport provides 4 possible options to configure target platform for your projects:
1. x86
2. x64
3. x86+x64
4. Auto - relies on user configuration
While x86+x64 option generates final modified modules inside separate subfolders (x86 and x64 respectively), x86 and x64 replaces the original; yes, that's it.
After that, take a look closer CoreCompile target:

LibFoo: Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
LibBar: Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
LibMain:

Building target "CoreCompile" completely. Input file "<...>\LibFoo.dll" is newer than output file "obj<...>\LibMain.dll".
(or*) Building target "CoreCompile" completely. Input file "<...>\LibBar.dll" is newer than output file "obj<...>\LibMain.dll".
*depending on build priorities and/or configurations since one of the invalidation is enough to run related targets.

Well, I added a new option to refresh intermediate module (obj) using modified, i.e. vice versa. That is, in future versions you will be able to configure it like:

Check this out using related CI build until public release.
But here it is also important to understand that we are validating this vice versa, as I noted above. That's why I recommend x86+x64 (moreover, it should work in in current versions) in order to get the most well known behavior.
Let me know if the problem is still not solved.


feat(ver): version 0.0.14

Coverage remained the same at 100.0% when pulling e44b3c599fefaea10f5ae5192ed82e1c9134b481 on ng-dep-version-change into ea7799dbc62343b0c6845ffc8a605c6794b4bc19 on master.


Add app//* and config//* to gemspec

When installing latest release v0.1.7 from ruby gems, files from those two directories are missing, thus mounting Ember tests does not work.

Oops! That's embarassing. I've tested everything locally with Gemfile pointing to a local dir and totally forgot about gemspec. Thanks for the fix!

Released 0.1.8


use pytest rather than python -m pytest

part of changes discussed in #738

Do we also need to discuss adding a "python" or "src" folder to avoid importing the local files rather than using the installed package?

this PR already prevents importing the local files when testing in the
CI. adding a src folder would be an extra safety net to catch this kind
of mistake in case we mess up the CI in the future, so it is not
strictly necessary if the CI remains configured correctly. I still think
it could be marginally useful because a misconfigured CI that passes
when it should fail can be hard to detect before users report defects
after a release. However, Gaël was not a fan because it would make the
layout of skrub more different from scikit-learn. I don't have a very
strong opinion, happy to discuss it some more.
Locally during development, the package is likely to be installed in
editable mode so the files in the repo will be imported during tests
anyway, unless we use something like tox. It could be useful to add a
tox config file for contributors who wish to run the tests in isolated
virtual envs (with different python and dependencies versions) and empty
test directories locally (contributors who don't install or run tox
wouldn't be affected). Here also I don't think it is strictly necessary
nor have a strong opinion about it.

Sounds fair! Thank you for these insights. I guess we can safely merge this.