Make output report customizable

In TSTyche repo I have 98 test files. If I run them locally in VS Code terminal, the output rendered by first test files cannot be reached any more. If there are any errors or failures, because the output is outside of scroll back buffer of the terminal.
The only way to see the output of a failing test, is to rerun a particular file.
Perhaps in a multi file run it would be better to emit only errors and file names. (Instead of printing out the whole test tree). Like this:
  ✔ tests/config-install.test.js › 9020.904792ms
  ✔ tests/config-target.test.js › 14780.683209ms
  ✔ tests/config-typescriptPath.test.js › 2426.265125ms
  ✔ tests/config-update.test.js › 2459.254291ms
  ✔ tests/feature-store.test.js › 16204.369208ms
  ✔ tests/feature-typescript-versions.test.js › 39605.810250ms
  ✔ tests/feature-watch.test.js › 70000.974792ms
  ✔ tests/validation-store.test.js › 5521.964250ms
  ✔ tests/validation-target.test.js › 5053.783042ms
  ✔ tests/validation-update.test.js › 231.104250ms
  ✔ tests/validation-watch.test.js › 197.263041ms

If a test file is passing, it isn’t important to see its structure. Keeping focus on errors and failures is most important.
(I would love to have dot reporter, of course. But that’s another story.)

To clarify more, output for a single file looks right. Very useful to see all the details. I try to point out that it becomes overwhelming in multi file runs.

To clarify more, output for a single file looks right. Very useful to see all the details. I try to point out that it becomes overwhelming in multi file runs.

Do you think we could impose a limit value to decide whether or not to display the successes?

Hard to say how verbose a single file can be. So probably keep it verbose for a single file run and make it silent for a multi file run. Optionally, --verbose option could be added to enable / disable verbosity.
What you think?

A --reporter option would be great. @mrazauskas, I've adapted the PR title 🙋🏻♂

A --reporter option would be great. @mrazauskas, I've adapted the issue title 🙋🏻♂

By the way, that would be good solution. --reporter dot is all what I need ;D

Just an idea, the --reporter option could allow adjusting verbosity of the reporter. For instance, --quiet can be replaced with --reporter=quiet.
I was running tests today and thinking that information like “Running tests in parallel” or “Fail fast is enabled” are useful for debugging. Something like --log=debug, --log=info, --log=error, --log=quiet could make sense.

--quiet can be replaced with --reporter=quiet

About --debug and --quiet, I like the idea of having them as a direct flag due to familiar commands in CLI apps. The idea is that --quiet overrides any debug or reporter options.
For example:
{
  "test": "poku --reporter=dot"
}

npm run test -- --quiet

In addiction, I wondered how other test runners deal with multiple reporters, I intend to create this functionality in a way that makes it easy to implement new alternatives 🙋🏻♂

I wondered how other test runners deal with multiple reporters

Jest loops through the list of reporters. A reporter must be an object with a set of callbacks like onRunComplete() (all are optional). There are several callbacks and they are call with various data during the test run. The object passed to onRunComplete() includes data of the whole test run.
In node:test custom reporters are based on a stream of events. That’s lovely pattern!
Inspired by that, I adopted an event emitter for TSTyche. Not only reporters are handle through events, but also the exit code or failFast logic (it handles a cancelation token passed to the runner).

Reporters' Ideas:

mini (probably the default)
full
dot (inspired by Mocha)

The names may not be exactly that.

[!IMPORTANT]
Both --debug and --quiet aren't reporters and should be complementary to all reporters.

Assert
Based on Deno's output, filter and highlight different lines when there is more than one line (regardless of whether it's a string, objects, etc.).

The default reporter could be named poku. This came to my mind as a joke, but why not? ;D


If I have to be on the web for extended periods of time, why make that experience miserable with minimalism ?  Circa 2012 a Firefox with plenty of superb extensions was a thing of beauty.  Now, it and the rest like Brave or Vivaldi are just tin cans.
I've installed plenty of browsers ( currently on Mint ) all up-to-date, but I use the good-looking ones of the past.  And even this Fx 45 has to have Classic Theme Restorer to undo the damage Mozilla did to copy Google.

I'm sorry that you don't like the look of the newer browsers.
However, some sites only work in newer browsers and old browser versions
are insecure. That is all we are informing you about.
We now habe the option to disable to show the notification permanently.
If I have to be on the web for extended periods of time, why make that
experience miserable with minimalism ? Circa 2012 a Firefox with plenty of
superb extensions was a thing of beauty. Now, it and the rest like Brave or
Vivaldi are just tin cans.
I've installed plenty of browsers ( currently on Mint ) all up-to-date,
but I use the good-looking ones of the past. And even this Fx 45 has to
have Classic Theme Restorer to undo the damage Mozilla did to copy Google.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/browser-update/browser-update/issues/394, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIErKrqWe5MhVvy7dRpjP-hpTkjgrGOmks5tw7vPgaJpZM4T5VIW
.


Update checking

Instead of applying the update automatically, we should just notify the user that an update is available. We could do this by using the GitHub API; then we wouldn't need to update the linode for each version.

I believe this is resolved?

well, SIa-UI now has this behavior. But this issue was more about using the GitHub API rather than the linode.
In theory we could even auto-update by fetching the GitHub download URL, unpacking the archive, etc.

I'm considering removing the update code + API calls, which would make this entirely a Sia-UI issue. In that case it would definitely have to use the GitHub API though.

Right now updating is something of a PITA for the users. I think we're also nearing the point where it actually makes sense to use in-client updating.  Then we can implement an update process that's more than just refreshing the binary, we can migrate all the files and stuff too.
Maybe we are too quick to throw the code away. Should probably start getting regular use as of 0.5.0.

Rolling this into the general 'update is not a supported feature' bucket. Hopefully we can have support soon.


Use action parameter as the model state key when validation fails on the top level object.

        [HttpPut("ModelBinding/Validations")]
        public IActionResult Validations([FromBody]Validations value){
            if (!ModelState.IsValid)
            {
                return BadRequest(ModelState);
            }

            return Ok(value);
        }
    }

    public class Validations : IValidatableObject
    {
        public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
        {
            yield return new ValidationResult("Not cool");
        }
    }

The json that comes back is:
{"":["Not cool"]} which is not very descriptive. We could make it {"value":["Not cool"]}

This would be a breaking change, so it is doubtful we would take this.
Also, are there other cases where the parameter name is the sole determiner of what gets put into model state? Often with model binding the parameter name matches the posted data, but the essence is really the structure of the posted data, not the action method's parameter's name.
In other words: should changing the parameter name of the method affect the contents of model state? (I'm thinking the answer is a definite "no".)
@dougbu @rynowak thoughts on this?

The default is what it is (string.Empty unless the parameter name was used to find the data) for back-compat reasons.
Use [Bind(Prefix = "...")] to get a different top-level key for a [FromBody] parameter. For most other binding sources, use the Name property of the controlling attribute e.g. [FromForm(Name = "...")].
PS.

should changing the parameter name of the method affect the contents of model state?

Change the parameter name from something that matches the submitted data and you'll get lots of new errors in the model state dictionary 😈

I'm aware what I'm proposing is a behavior change, but I think of it from the point of view of technologies like swagger where the requests have parameters with names it provides for a more consistent experience.
If I have a parameter in my API named "customer" that comes from the body and another parameter "bar" that comes from the query, I would expect any top level error for that parameter to show up under the parameter name key.

@javiercn - a lot of things about our strategy in this area just aren't that useful for API authors. We haven't solved it.
{"value":["Not cool"]} - doesn't solve the problem either. Nothing about the name value is significant to the client.

Closing this issue because we don't plan to make the change proposed here. But if there's some alternative proposal, we can certainly log a new issue for that.


🩹 🪣  Loading Patch: Update Container Name

I was experiencing failure when trying to load data in from my mongo dump, this is the patch for the error I was experiencing, as mentioned in #88, load worked after this change

Adding some troubleshooting tips to this PR as well, to help mitigate issues like the ones I was encountering while trying to get started with this, also spoke to @achasmita who had similar advice.


Group ESLint updates in ts-model-api

This PR needs a manual rebase now.

:tada: This PR is included in version 7.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Update userlist.js

Added Djstearns for NebraskaJS @ hack night/bug fix night!

Bump @djstearns

Just checked this out and realized that the homepage that was broken was reverted so this is good to go.


Adding Documentation

This gem looks wonderful thank you for this effort @tzaid and @bouk. I believe it will be great to add some usage of this gem in the README.md or docs files :smile_cat:

Thanks for feedback.
We will be looking to extend this section of documentation further.


Cannot create model

Does this SDK work at all? Seems like its broken
Tried to create a model using a simple SQL query "select * from prices" and looks like its introducing parens or something.

Python version: 3.10.12

Operating system: Pop!_OS(Ubuntu) 22.04

Mindsdb Python SDK version:
mindsdb-sdk==1.0.4
mindsdb-sql==0.6.7

Additional info if applicable:

Please describe your issue and how we can replicate it
File "/home/darren/PycharmProjects/pyfi/pyfi/server/api.py", line 1747, in create_model
project.create_model(name=model, predict=data["column"], query=data['query'])
File "/home/darren/PycharmProjects/pyfi/venv/lib/python3.10/site-packages/mindsdb_sdk/project.py", line 410, in create_model
df = self.query(ast_query.to_string()).fetch()
File "/home/darren/PycharmProjects/pyfi/venv/lib/python3.10/site-packages/mindsdb_sdk/query.py", line 29, in fetch
return self.api.sql_query(self.sql, self.database)
File "/home/darren/PycharmProjects/pyfi/venv/lib/python3.10/site-packages/mindsdb_sdk/connectors/rest_api.py", line 11, in wrapper
return fnc(self, *args, **kwargs)
File "/home/darren/PycharmProjects/pyfi/venv/lib/python3.10/site-packages/mindsdb_sdk/connectors/rest_api.py", line 82, in sql_query
raise RuntimeError(data['error_message'])
RuntimeError: SQL statement cannot be parsed by mindsdb_sql - CREATE PREDICTOR modeltest (select * from prices) PREDICT prices: Syntax error at token LPAREN: "("

Can you share the code example please?

Let's close it and open again when we have more information

Let's close it and open again when we have more information
@ea-rus

Hi sir, I can't create a model either, I get an error after using models.create.
>CREATE PREDICTOR my_project.my_model (SELECT * FROM my_db.my_article) PREDICT id----------------------------------------^ Expected symbol: "PREDICT"
I've looked for a lot of examples and issues that can't solve my problem.
Here's my code:
I want to use the default engine and insert my data to create a model.
Is the following usage correct? Or are there other steps?
Can you please help me see where the error is? Thank you sosososososososo much.
project = server.get_project('my_project') table = mysql_db.tables.get('my_article') model = project.models.create(             'my_model',             predict='id',             query=table,         )

@kiuyaku, please try to update mindsdb_sql to the latest version

This could be the cause: https://github.com/mindsdb/mindsdb_python_sdk/pull/129

@kiuyaku, please try to update mindsdb_sql to the latest version

OK! I'm just going to give it a try! thank you very much!


refactoring MessageType and MessageTypeUtils classes

Why can't we use framework wide DataTypes instead of defining them at multiple places?
edu.iu.dsc.tws.data.api.DataType
edu.iu.dsc.tws.comms.api.MessageType
edu.iu.dsc.tws.data.memory.utils.DataMessageType (This will be removed as per @pulasthi)

Can't we move edu.iu.dsc.tws.data.api.DataType to edu.iu.dsc.tws.api?

Wouldn't it be more cleaner to use concrete classes for MessageTypes instead of Enums? That will be generics friendly too.
Spark sql is doing that. However changes might be significant since this is widely used throughout the framework.


Some bug fixes and improvements for Opta serializer

Hi,

fixed a bug where for incomplete passes end coordinates got ignored (within serializer and when converting events to_pandas)
added a result type "OWN_GOAL" for own goals - before these were just counted as normal goals for a team. I am wondering whether it would make sense to set BALL_OWNING_TEAM for this shot event to the opponent.
for all shot events the event timestamp will correspond to the moment when the ball leaves the foot. However for goal events opta's event timestamp is the moment when the ball crosses the goal line and the timestamp when the ball leaves the foot is stored in a qualifier. I adjusted the code s.t. it'll take always the moment when the ball leaves the foot consistently. This might not be a big deal when working with event data only, but a big improvement when working with merged tracking data.
added a parser for card events with event_type = "card" and column card_type = ["RED", "FIRST_YELLOW", "SECOND_YELLOW"]
starting player information will now get parsed

Cheers
Thomas

This look great @ThomasSeidl !
Please make sure you also run code formatting: https://github.com/PySport/kloppy/blob/master/CONTRIBUTING.md#how-to-contribute item 5. If you have questions let me know.


Wikidata items list is not padded

The text is 1 pixel from the left side.
A bit more padding would probably be good.

@nicolas-raoul is this okay?

Yes it looks great!

okay, I have added this in my code. Will be pushed along with the next commit

@nicolas-raoul I have resolved this issue here.
Please check :-)


Fix EGL OpenGLControlBase on Win32

Fixed issues
Fixes #12051

You can test this PR using the following package version. 11.0.999-cibuild0037413-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0037440-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]


lxd/instance/drivers/driver/common: Improve error logging in restartC…

…ommon
Signed-off-by: Thomas Parrott<EMAIL_ADDRESS>

Testsuite passed

jenkins: test this please

Testsuite passed

Testsuite passed

Testsuite passed


plan to release code?

Thank you for your attention to our work. We will publish our code after the paper is received. Hope to keep your attention.


SpriteBundle background color randomly not rendererd

Bevy version
v0.10.1
Relevant system information
`AdapterInfo { name: "NVIDIA GeForce 920M", vendor: 4318, device: 4761, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "470.182.03", backend: Vulkan }`

What you did
Simply run the breakout example.
What went wrong
Expected behavior:
The background color of the bricks and walls are visible on every execution of the application.
Actual behavior:
The background color of the bricks and walls are not visible on some executions of the application.
Additional information
My system is a laptop with hybrid graphics Intel + NVIDIA, configured for PRIME offloading.
I am running the application under SwayWM XWayland.
I have already tested this under the Intel GPU too but the issue is not there.
Diving deeper with RenderDoc, it seems to be a problem with rendering consecutive frames after the first one.
I can confirm that the vertices are still there, its just the colors are not being rendered.
Frame 0

Frame 1

Side note: This also happens for the NodeBundle background color when I ran the other examples.

I have setup a dynamic scene to test colors when I encounter the issue.
Sometimes the background becomes like below.

Closing as it was a GPU specific issue that is not worth creating a workaround for.


🤖 feat: Private Assistants

Originally #2831
Thank you @leon-juenemann
Summary
Closes #1926
Adds the option to only see assistants that you (the user) created or that don't have an author. This is important for privacy reasons when multiple users are sharing the same API-Key. Otherwise a user could get personal information from e.g. a file that another user uploaded.
The specific use case that led to this PR:

we don't want users to see other users assistants
we still want to make some assistants available to all users (assistants without a metadata.author field)

Change Type

[x] New feature (non-breaking change which adds functionality)
[x] This change requires a documentation update

Testing
In librechat.yaml:
endpoints:
  assistants:
    privateAssistants: true

Login User1 and create an assistant.
Login User2 and does not have access to the assistant.

Test Configuration:
Checklist

[x] My code adheres to this project's style guidelines
[x] I have performed a self-review of my own code
[x] Local unit tests pass with my changes
[x] A pull request for updating the documentation has been submitted. (https://github.com/LibreChat-AI/librechat.ai/pull/37)

@leon-juenemann I noticed you are including assistants without any author metadata as "private."
In my opinion, these should only be visible by the admin, since they are likely created outside of LibreChat, or before LibreChat was used for Assistants.
I'll be adjusting that, and then wrap up this PR.

@leon-juenemann I noticed you are including assistants without any author metadata as "private."
In my opinion, these should only be visible by the admin, since they are likely created outside of LibreChat, or before LibreChat was used for Assistants.
I'll be adjusting that, and then wrap up this PR.

Yes, this was intentional.
For our use-case we want a way to have some assistants (created outside of LibreChat, e.g. in the Assistants Playground) public to all our users, but assistants that the user created themselves should be private. It's not important were these shared public assistants are created. Just to have some way to do this.
But I agree that it is maybe not the best solution and could be misunderstood my others with a different usecase.
Perhaps in the future only the admin could see all assistants and could make them public via a toggle button in the UI.

@leon-juenemann I noticed you are including assistants without any author metadata as "private."
In my opinion, these should only be visible by the admin, since they are likely created outside of LibreChat, or before LibreChat was used for Assistants.
I'll be adjusting that, and then wrap up this PR.

Yes, this was intentional. For our use-case we want a way to have some assistants (created outside of LibreChat, e.g. in the Assistants Playground) public to all our users, but assistants that the user created themselves should be private. It's not important where these shared public assistants are created. Just to have a way to achieve this distinction. But I agree that it is maybe not the best solution and could be misunderstood my others with a different usecase. Perhaps in the future only the admin could see all assistants and could make them public via a toggle button in the UI.

That use case makes a lot of sense. I have a way to "share" them in mind already, but in the immediate-term, adding back the "undefined" author condition should be simple for you

I have a way to "share" them in mind already

@danny-avila could you put that in an issue so that we can track the progress? Can we support here?


Support binary files if templating is disabled.

This PR allows processing of non-UTF-8 files when they match templating_disabled.

Thanks ! Published on 0.8.10


i2c.scan

From https://github.com/bbcmicrobit/micropython/issues/699#issuecomment-753816394 (thanks @xmeow!):

@carlosperate Thanks for advise the correct repo for micropython firmware. The only issue is that the latest beta.3 firmware may output unambiguous devices that don't exist.
MicroPython v1.13 on 2020-12-21; micro:bit v2.0.0-beta.3 with nRF52833
Type "help()" for more information.
>>> i2c.scan()
[9, 12, 15, 17, 19, 21, 23, 26, 29, 31, 33, 35, 37, 39, 42, 44, 47, 49, 51, 53, 55, 58, 60, 63, 65, 66, 68, 71, 73, 75, 77, 79, 81, 83, 86, 88, 91, 93, 96, 98, 100, 102, 104, 107, 109, 111, 113, 114, 117, 119]
>>>

I tried to build the firmware locally and change the last stop flag to false and got the correct output.
>>> MicroPython v1.13-dirty on 2021-01-04; micro:bit v2.0.0-beta.3 with nRF52833
Type "help()" for more information.
>>>
>>> i2c.scan()
[64, 112]

It looks like the last param should be named repeat instead of stop.
STATIC mp_obj_t microbit_i2c_scan(mp_obj_t self_in) {
    mp_obj_t list = mp_obj_new_list(0, NULL);
    // 7-bit addresses 0b0000xxx and 0b1111xxx are reserved
    for (int addr = 0x08; addr < 0x78; ++addr) {
        int ret = microbit_hal_i2c_writeto(addr, NULL, 0, false); // true to flase

It looks like the last param should be named repeat instead of stop.

I'm quite sure the last parameter to microbit_hal_i2c_writeto() is "stop" -- this value is actually inverted in the implementation of this function, when calling the corresponding CODAL function which names it "repeated".
Maybe we should try to write an I2C scan implementation in pure C++ using the CODAL directly, to see how that would work.

It looks like the last param should be named repeat instead of stop.

I'm quite sure the last parameter to microbit_hal_i2c_writeto() is "stop" -- this value is actually inverted in the implementation of this function, when calling the corresponding CODAL function which names it "repeated".
Maybe we should try to write an I2C scan implementation in pure C++ using the CODAL directly, to see how that would work.

This has also been raised by another person in micro:bit support https://support.microbit.org/a/tickets/42809

This has also been raised by another person in micro:bit support https://support.microbit.org/a/tickets/42809

The detected addresses are not constant:
>>> i2c.scan()
[9, 12, 14, 16, 18, 20, 23, 25, 28, 30, 33, 34, 36, 38, 41, 43, 45, 47, 49, 51, 53, 56, 58, 60, 62, 64, 66, 69, 71, 74, 76, 78, 80, 82, 84, 86, 89, 91, 93, 96, 98, 101, 103, 105, 108, 110, 112, 114, 116, 118]
>>> i2c.scan()
[9, 12, 14, 16, 18, 21, 23, 25, 27, 29, 31, 34, 36, 38, 41, 43, 45, 48, 51, 53, 55, 57, 59, 61, 64, 66, 69, 71, 74, 77, 79, 81, 83, 85, 87, 89, 91, 94, 96, 99, 101, 103, 105, 108, 110, 112, 114, 117, 119]
>>> i2c.scan()
[9, 11, 14, 17, 19, 21, 23, 26, 29, 31, 33, 35, 37, 40, 43, 45, 48, 50, 53, 56, 58, 60, 62, 64, 66, 69, 71, 74, 76, 78, 81, 83, 86, 88, 90, 92, 95, 97, 99, 101, 103, 106, 108, 110, 112, 115, 117, 119]
>>> i2c.scan()
[9, 11, 14, 16, 18, 20, 22, 24, 26, 28, 30, 33, 35, 37, 39, 42, 44, 46, 48, 51, 53, 56, 59, 61, 64, 66, 69, 71, 73, 75, 78, 80, 82, 84, 87, 89, 91, 94, 96, 98, 101, 103, 106, 108, 110, 113, 115, 118]
>>> i2c.scan()
[9, 12, 14, 16, 18, 21, 23, 26, 28, 30, 32, 35, 37, 40, 43, 45, 48, 50, 53, 55, 58, 60, 62, 64, 66, 68, 70, 73, 75, 78, 80, 82, 84, 87, 89, 91, 93, 96, 99, 101, 104, 107, 109, 112, 114, 117]

This ticket in the codal repo contains more info: https://github.com/lancaster-university/codal-microbit-v2/issues/49

The detected addresses are not constant:
>>> i2c.scan()
[9, 12, 14, 16, 18, 20, 23, 25, 28, 30, 33, 34, 36, 38, 41, 43, 45, 47, 49, 51, 53, 56, 58, 60, 62, 64, 66, 69, 71, 74, 76, 78, 80, 82, 84, 86, 89, 91, 93, 96, 98, 101, 103, 105, 108, 110, 112, 114, 116, 118]
>>> i2c.scan()
[9, 12, 14, 16, 18, 21, 23, 25, 27, 29, 31, 34, 36, 38, 41, 43, 45, 48, 51, 53, 55, 57, 59, 61, 64, 66, 69, 71, 74, 77, 79, 81, 83, 85, 87, 89, 91, 94, 96, 99, 101, 103, 105, 108, 110, 112, 114, 117, 119]
>>> i2c.scan()
[9, 11, 14, 17, 19, 21, 23, 26, 29, 31, 33, 35, 37, 40, 43, 45, 48, 50, 53, 56, 58, 60, 62, 64, 66, 69, 71, 74, 76, 78, 81, 83, 86, 88, 90, 92, 95, 97, 99, 101, 103, 106, 108, 110, 112, 115, 117, 119]
>>> i2c.scan()
[9, 11, 14, 16, 18, 20, 22, 24, 26, 28, 30, 33, 35, 37, 39, 42, 44, 46, 48, 51, 53, 56, 59, 61, 64, 66, 69, 71, 73, 75, 78, 80, 82, 84, 87, 89, 91, 94, 96, 98, 101, 103, 106, 108, 110, 113, 115, 118]
>>> i2c.scan()
[9, 12, 14, 16, 18, 21, 23, 26, 28, 30, 32, 35, 37, 40, 43, 45, 48, 50, 53, 55, 58, 60, 62, 64, 66, 68, 70, 73, 75, 78, 80, 82, 84, 87, 89, 91, 93, 96, 99, 101, 104, 107, 109, 112, 114, 117]

This ticket in the codal repo contains more info: https://github.com/lancaster-university/codal-microbit-v2/issues/49

As mentioned over at https://github.com/lancaster-university/codal-microbit-v2/issues/49 I can work around this issue by adding a small delay (50us) after the uBit.i2c.write() call.  But otherwise I suspect this is a problem with the CODAL.

There's a new build of the DAL that fixes scan behavior, so we should test this against that (de856f2 has the fix in)

There's a new build of the DAL that fixes scan behavior, so we should test this against that (de856f2 has the fix in)

I tried to test it but didn't see any change in I2C behaviour, an i2c.scan() still returns a list of many random values.
I looks like the only relevant change for I2C is the commit which enables NRF52I2C_ERRATA_219 in target.json.  But when I builds for me it uses target-locked.json so I added that errata config to target-locked.json as well.  Still it did not do anything (I did a clean build with this change but not sure it actually applied it... hard to tell).
If someone else can confirm this (maybe try the C++ example) that would be great.

Yeah, the main changes ended up in the codal-nrf52 repo.
Testing a build from the current MicroPython master branch and I can still replicate the issue. Then git pulling the latest codal-nrf52 (https://github.com/lancaster-university/codal-nrf52/commit/86be5f29342b2bac245d42ad26f81a4e7fde2c69 )and codal-microbit-v2 (https://github.com/lancaster-university/codal-microbit-v2/commit/de856f22f7fbea1145c24fff7933dd12fc30b2ae):
$ cd lib/codal/libraries/codal-nrf52
$ git pull origin master
$ cd ../codal-microbit-v2
$ git pull origin master

And the resulting hex i2c.scan works (tested with and without I2C devices on the edge connector) 🎉
MICROBIT-i2c.hex.zip

Then git pulling the latest codal-nrf52 and codal-microbit-v2 ...

Yes, doing this I can now confirm the fix, great!
I guess we just need to wait now for a tag on codal-microbit-v2?

CODAL was updated in 76054c2e9445d8eea285132c2374a18ddc690514 so hopefully this is fixed now.

Can confirm this is fixed and will be present in the beta.5 release, thanks Damien!


Feature: detect the number of physical cores and / or add option to set it

Slow image generation with only cpu.
Missing parameter from sd_params.
Example from sd.cpp: utli.cpp
See comment  here 2. question

The feature add in https://github.com/fszontagh/sd.cpp.gui.wx/commit/a3e3bcb2effa79d1c4ae928b53ada6cadb6f5e21 commit


fix(alerts/reports): removing duplicate notification method options

SUMMARY

When adding notification methods to an alert or report, a user can select duplicate methods (select email twice or slack twice). This PR updates the behavior to exclude notification methods that are already being used.
Additionally, the delete notification method for additional methods only appears after a user has selected a notification method. This PR changes this so that the ability to delete additional notification methods is always available, even if the method has not yet been selected.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before:
https://www.loom.com/share/7bb024ba1d2a483eb6db44be6c137e32?sid=5620dc39-24aa-4165-8b12-39dddf6b48b5
After:
https://www.loom.com/share/c4c9c68f4f0446f18f5e4cbf1064d052?sid=3caccb4a-e2ec-4cd4-989e-d34ec31e6b7e
TESTING INSTRUCTIONS

Ensure that within either your local superset_config.py or docker/pythonpath_dev/superset_config_docker.py files, you have a SLACK_API_TOKEN string filled in. It doesn't need to be an active api token, just any string.
Open superset and navigate to the alerts and reports section.
Create an alert or report and open the Notification method collapse section.
Observe that there are two options for notification method.
Add a new notification method.
Check the options of the newly added notification method which should exclude the previously added option.
Update the method of the first notification setting, and ensure that subsequent notification settings are being removed, and the add notification method button reappears.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[x] Required feature flags: "ALERT_REPORTS": True
[x] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

/testenv up FEATURE_ALERT_REPORTS=true

Let's rebase this with master to unstuck CI

@fisjac I think you're going to need to rebase to bring in the other required CI checks.


Problem with starting code markers that follow directly after a bracket

I have an AsciiDoc file that contains a code enclosed in code markers (`). Directly before the starting code marker there is a bracket which causes your AsciiDoc package to mark it as an error:

I just noticed that AsciiDoctor also has problems with this and also does not interpret the starting code marker as such. Then everything is correct and this issue can be closed. But it is still good to have mentioned it here, I think.

The idea of marking the error with a red line is based on the assumption that inline quotes should be on a same line (i.e. not wrapping text in the middle of quote markup), which makes sense since idiomatic AsciiDoc should be wrapped one-sentence-per-line.
But the problem here is that you should be using constrained quotes, due to the special * char:
{nbsp}``*``

which is then parsed correctly by the syntax.
Defintely, in the future the syntax should be able to handle better some edge cases and errors, but right now it's too early for some of these, because it's already entangled enough, and too many syntax elements are still either suppressed or not implemented.
The switch from the original ST2 syntax to the new ST3 format is not all that easy, because the new format allows more powerful handling of states, so each element should be basically re-written almost from scratch (although we can salvage most of the original RegExs definitions and scopes namings).

P.S. don't forget that AsciiDoc allows quote markup inside line-code, so unless you use the double ticks (unconstrained) AsciiDoc will assume that the * is for marking contents as stong.
See:

Asciidoctor Manual » §9.2. Unconstrained quotes

Okay, thanks. I will use the double ticks.


Adding magic technology and setup files and the netgen setup file

Per request from Tim Ansell, current versions of the open_pdks setups and technology files for magic and netgen copied and pushed to the gf180mcu_fd_pr/tech/ directory.

Thanks for adding those!
@RTimothyEdwards is there any regression testing in place in open_pdks for those rules that we can import, or should we log an issue to create a setup similar to what's currently in https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/rules/klayout/drc/testing?

Fixes #31

@QuantamHD This is another important PR,  Do you think we can merge it also?

@RTimothyEdwards Still need to the license headers before this can be merged.
Also are there any CI tests available today? If not that's fine I'll still merge it

Stick a licence header on whatever needs a license header, then.  Netgen and magic scripts are all Tcl and can use # as a comment line header.  The magic .tech file will also take # as a comment line header.

I was working on CI tests with Sai Charan, but the ball's still in my court for creating repositories for the CI tests.

Alright, is it Efabless' or Tim Edward's copyright?

I usually copyright things I wrote myself to me, but I guess it doesn't really matter.


harden SSH: kex/ciphers/MACS + disable X11 forwarding

What this PR does / why we need it: harden SSH. specifically, it implements best practices for SSH key exchange, ciphers, and MACs. Also disables X11 forwarding.
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
If applicable:

[ ] documentation
[ ] unit tests
[ ] tested backward compatibility (ie. deploy with previous version, upgrade with this branch)

Release note:

@seanknox kindly confirm this is what we want (from a master vm built from one of the E2E tests run against this PR):
azureuser@k8s-master-24722381-0:~$ cat /etc/ssh/sshd_config
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress <IP_ADDRESS>
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

KexAlgorithms<EMAIL_ADDRESS>Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm<EMAIL_ADDRESS>
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin prohibit-password
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

# CLOUD_IMG: This file was created/modified by the Cloud Image build process
ClientAliveInterval 120```

As a reference, this is the sshd_config pulled from a vm built against the master branch as of now:
azureuser@k8s-master-41481510-0:~$ cat /etc/ssh/sshd_config
# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress <IP_ADDRESS>
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin prohibit-password
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

# CLOUD_IMG: This file was created/modified by the Cloud Image build process
ClientAliveInterval 120```

@seanknox here's a diff for our convenience:
$ diff before after
1,3d0
< # Package generated configuration file
< # See the sshd_config(5) manpage for details
<
14a12,16
>
> KexAlgorithms<EMAIL_ADDRESS>> Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
> MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm<EMAIL_ADDRESS>>
33d34
< #AuthorizedKeysFile	%h/.ssh/authorized_keys
41,42d41
< # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
< #IgnoreUserKnownHosts yes
54,64c53
< # Kerberos options
< #KerberosAuthentication no
< #KerberosGetAFSToken no
< #KerberosOrLocalPasswd yes
< #KerberosTicketCleanup yes
<
< # GSSAPI options
< #GSSAPIAuthentication no
< #GSSAPICleanupCredentials yes
<
< X11Forwarding yes
---
> X11Forwarding no
71,73d59
< #MaxStartups 10:30:60
< #Banner /etc/issue.net
<

@seanknox kindly confirm this is what we want (from a master vm built from one of the E2E tests run against this PR)

yep! looks good.

/lgtm thanks @seanknox!


Pypi package update?

Any chance you could publish an update with the latest components on pypi?
Enjoying the latest version! Thanks @chriskiehl @jamesdbrock

The work was all @jamesdbrock!
Latest is now on PyPi: https://pypi.org/manage/project/re-wx/releases/


What's the story with the sudden burst of release tags?

Dogecoin.com hasn't been updated, what is the expected stable version? Also no release notes?

Thank you for letting us know!
Those were bitcoin tags, I have removed them now.
The next version will be v1.8.3, release notes are being drafted.

Thanks.


Section 5 of Community page

Description
Fixes #1271
Added Section 5 of the Community page
Notes for Reviewers
link to the preview:
https://master--peppy-otter-ff5ecf.netlify.app/community/

Signed commits

[x] Yes, I signed my commits.

@lanzkrish Let's discuss it on the websites call. Please add this as an agenda item in the meeting minutes, if you would :)

merge conflicts... @lanzkrish

Big thanks for this PR @lanzkrish! Your commitment to our project is remarkable, and we're grateful for all your efforts.
Just a quick update: Another pull request with similar changes has been merged, so we'll be closing yours. Please know that it doesn't undermine the significance of what you've done.
We admire your involvement in our community. Keep shining bright with more incredible contributions down the line!


Form field Slider don't work since laravel-admin 1.8.2

Laravel Version: 6.18.37
PHP Version: 7.2.19
Laravel-admin: 1.8.3

Description:
Form field Slider don't work since laravel-admin 1.8.2(some error printed at Google console)，and I try to use it in laravel-admin 1.8.0 and 1.8.1 it works well.
Steps To Reproduce:
(1) Create a table that has a field named "age";
(2) Add "$form->slider('age', 'age')->options(['max' => 100, 'min' => 1, 'step' => 1, 'postfix' => 'years old']);" to form method in the corresponding controller;
(3) The issue occurs

Laravel-admin 1.8.4已经修复这个问题了，关闭中...


Fix #10: add clang-9, clang-10 and gcc-10

Codecov Report

Merging #16 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #16   +/-   ##
=======================================
  Coverage   37.22%   37.22%
=======================================
  Files          11       11
  Lines         462      462
=======================================
  Hits          172      172
  Misses        290      290

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 44915e2...abb6f62. Read the comment docs.


[Bug]: app.removeUser does not logout the user

What happened?
When calling
await app.removeUser(user);
the user is supposed to be logged out in the process. This does however not happen.
await user.logOut();
needs to be called afterwards to logout the user.
Repro steps
1.) Login with any provider
2.) Call app.remoteUser(user)
3.) The user is still logged in but removed from the device
Version
Flutter (Channel stable, 3.3.0, on macOS 12.5.1 21G83 darwin-x64, locale en-GB)
What Realm SDK flavor are you using?
MongoDB Atlas (i.e. Sync, auth, functions)
What type of application is this?
Flutter Application
Client OS and version
0.4.0+beta
Code snippets
logout(bool? deleteUser) async {
    if (user == null) {
      return;
    }
    if (deleteUser == true) {
      await app.removeUser(user!);
    }
    /*
    This line belongs in the else-block, is however needed as removeUser does
    not properly sign out.
    */
    await user?.logOut();

    //Logout from Firebase, as JWT login is being used (JWT token from Firebase).
    await firebase.FirebaseAuth.instance.signOut();
    user = null;
    notifyListeners();
  }

Stacktrace of the exception/crash you're getting
No response
Relevant log output
[ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: RealmException: User has already been removed

I suggest rearranging the code as follows:
logout(bool? deleteUser) async {
    final u = user; // <-- use a local final to allow compiler to promote correctly after null check
    if (u == null) {
      return;
    }

    await u.logOut(); // <-- log out before you remove

    if (deleteUser == true) {
      await app.removeUser(u);
    }

    //Logout from Firebase, as JWT login is being used (JWT token from Firebase).
    await firebase.FirebaseAuth.instance.signOut();
    user = null;
    notifyListeners();
  }

But I do see what the documentation say, so I will get back on this

Calling app.removeUser will log the user out. Can you clarify what you mean by

The user is still logged in but removed from the device

How do you determine that the user is logged in?

Calling app.removeUser will log the user out. Can you clarify what you mean by

The user is still logged in but removed from the device

How do you determine that the user is logged in?

Maybe it is a messup on my end.
Am am also calling deleteUser. What is the correct order of calling deleteUser and removeUser?
Maybe I got confused there.

I don't think you need to call both. If you call deleteUser, that should remove the user from the local device on top of deleting them on the server.

I don't think you need to call both. If you call deleteUser, that should remove the user from the local device on top of deleting them on the server.

Maybe this was the reason for my issue. Eould maybe be good do mention that in the function documentation.


Feature Request: Support remote blackd server

Our team is using a remote blackd server, that's kept in sync with the version in CI. Some of our team members use VS Code, others use PyCharm. The latter has a plugin that let's the users set the path to a remote version of black, so that not everyone has to have a running version of the black server running and needs to keep track of that when we do a version bump on CI. It'd be great if this extension could add support for remote servers, since it's the biggest one for formatting with black.
I'm not sure how this extension currently handles black interaction (with blackd, it would look something like curl -s -XPOST "<HOST>:<PORT>" -d "<YOUR_PYTHON_CODE>") and configuration (like line-length). Is the configuration passed with every request as with blackd or covered somehow differently? If that could be reused, that would be of course very nice.

The extension runs Black locally via LSP for performance reasons. This would be a feature request to use blackd as well as allow for somehow forwarding the connection to a server.

Hi @karthiknadig, is there anything in particular you're looking for from me, or are you waiting to see if others share this need?

We usually leave feature requests open for some time to see if there is any community interest. Since this is a large change and we want to make sure there is demand for this.


hmset of 25mb object gives - Error 32 while writing to socket. Broken pipe.

I have
data = {} # 25mb dict
test = redis.Redis(host='<IP_ADDRESS>', port=6379, db=15, decode_responses=True)
test.hmset('usage', data)

But get
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/redis/connection.py", line 590, in send_packed_command
    self._sock.sendall(item)
BrokenPipeError: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/redis/client.py", line 667, in execute_command
    connection.send_command(*args)
  File "/usr/local/lib/python3.5/dist-packages/redis/connection.py", line 610, in send_command
    self.send_packed_command(self.pack_command(*args))
  File "/usr/local/lib/python3.5/dist-packages/redis/connection.py", line 603, in send_packed_command
    (errno, errmsg))
redis.exceptions.ConnectionError: Error 32 while writing to socket. Broken pipe.

@andymccurdy I still have this issue, hmset fails with a dict of any significant size eg. 400k

I'm going to close this as there are reasonable work arounds by batch loading data. If someone authors a patch to improves redis-py's ability to handle larger amounts of data, I'll gladly take a look at it.


Split Jdifference in dDifference_dq<0> and dDifference_dq<1>

Thanks for this contribution. I think I will merge it after version 2.0.0 because I don't how much this PR is in conflict with the next release.

But I have always found difference(q0,q1) unclear and I always have to check the doc or the code.

I think I will merge it after version 2.0.0 because I don't how much this PR is in conflict with the next release.

I would be happy to put it myself within the beta version. Why isn't there a branch in the main repo containing the content of this release ?
This way, we can actually contribute to the latest point rather than being replied that either:

you already added it in the next release so the same work was done twice,
we should wait for your release and someone must make the fix compatible...
There are 4-5 people actively working on Pinocchio and this work would gain from more cooperation.

By that, I do not ask you to merge it if it makes things more complicated.

I do understand, but I'm not full time on it, and the current version is not passing all the tests, and I don't think that someone else would like to handle it.

Concerning the choice of template naming, I do not think that putting an int is helpful neither.
You will have to in the documentation too, so far and so on.
I was just suggesting a convenient naming, and I suggest to think about it now.
Why not to use something like WITH_RESPECT_TO_FIRST_ARGUMENT, WITH_RESPECT_TO_SECOND_ARGUMENT, etc.

I'm not full time on it

I understand this and you already do a lot.

the current version is not passing all the tests

This is not important for a branch made for elaborating a new release. It is still in beta version so, yes, it is not ready. An appropriate branch name is sufficient to make people understand they should not take it as a stable version. But if you want a patch to be included in the next release, it is the branch you must use.

You will have to in the documentation too, so far and so on.

I think I documented it.

I suggest to think about it now.

Agreed. For clarity, it should be rather short. ARG0, ARG1... ?

The other more important issue is that this branch is not yet aligned with Pinocchio 1.3.0 and further.
This is a tedious work. I will try to do my best to make it available by the end of the next week as I mentioned in #547.

Yes, it should be short, but also explaining the argument. WRT_ARG0?

Is there other places where this problem occurs ?
Otherwise, I can make two functions (like dDifference_darg0 and  dDifference_darg1 or  dDifference_dq0 and  dDifference_dq1).

I like dDifference_dq0 and dDifference_dq1. Much better than having a silly enum which is only used for this single method.

Cherry-picked ont topic/release-2.0.0 branch. See https://github.com/jcarpent/pinocchio/pull/2


Update index.html

closed the last PR and using this instead bc it failed all the checks

This PR is not needed. It was already merged in with PR: https://github.com/nathandh/mywebclass-simulation/pull/68


Address remaining first-round feedback from Natalie

I need to go through the video one more time and identify anything we are missing before we show the interface to Natalie again.

Made more specific in #115


EVENSUM Problem

Problem Link
https://www.codechef.com/problems/EVENGAME
Coding platform
CodeChef
Programming language

[ ] C
[ ] C++
[ ] Java
[ ] Python

Additional context (OPTIONAL)
Add any other context or screenshots about the feature request here.

I would like to work on this in C++

I will do it in C


Error: Compile Error: eq is not a helper

The ember-attacher-inner template calls an eq helper, this results in the error "Error: Compile Error: eq is not a helper" on a plain ember-cli project.
Adding "ember-truth-helpers" as project dependency resolved the issue.

Good catch. I'm baffled as to how this worked at all in the example/dummy app. Fixing now


Java unchecked: unchecked generic array creation for varargs parameter for Cute.blackBoxTest().given().processors(

Hi @tobiasstamann,
This project is really cute and awesome!
I just started to use but I feel we will get friendships.
The above warning is coming when I declare the processor as
BlackBoxTestSourceFilesInterface processors(@FluentApiBackingBeanMapping("processors") @NotNull Class<? extends Processor>... var1);
in CuteApi.java
I am going to give a fix with the @SafeVarargs annotation. Do you agree it is used in the "safe" mode?
Best regards,
István

Hi István,
Thanks for the feedback. It's always nice to hear if the library works for others as well :)
I had replaced the fluent api about 2 months ago and forgot to address the @SafeVarags annotation for the varargs parameters.
I just did a quick check: Unfortunately it cannot be fixed that easily. The SafeVarargs annotation can just be placed on static or final methods and therefore not on interfaces.
I am going to check if there is another way to fix this on api side  rather then just suppressing the warning when it is used.
Please file issues when you miss something else in the tool.
Thanks in advance
Tobias

I came to the conclusion that I will add another method there that allows to use one single processor.
Usually this should be the normal case for most tests since testing of two or more processors is more or less an edge case.
The method will look like:
BlackBoxTestSourceFilesInterface processor(@FluentApiBackingBeanMapping("processors") @NotNull Class<? extends Processor> var1)
I will add it later today and do a release right afterwards.
Does the solution fit for you?
Best regards
Tobias

I have added another method:
BlackBoxTestSourceFilesInterface processors(@FluentApiBackingBeanMapping(value = "processors")  @NotNull Collection<Class<? extends Processor>> processors);
And have marked the varargs processor method to deprectated.

Hi @verhasi,
the change is released with version 1.1.0 and will be available in maven central in approx 8 hours.
Please check if the solution is ok for you.
You can file issues if you think that something is missing in the library.
I will close the ticket for now.
Thanks again for the feedback.
Tobias

Hi Tobias,
What a high-speed feedback! :) Actually, I started to fix it yesterday and found the very same conclusion. What's more, my work in progress is almost the same. I have two notices on your solution.

The newly introduced parameter with type Collection<Class<? extends Processor>> got the @NotNull annotation and you added the unit test as well. However, this annotation does not check the Collection elements for nullity. It should be added similarly as a feature to the Fluent API validator as it validates the array elements. Of course, after that, the unit test could extended as well.
In the case of the processor(Class<? extends Processor> processor) I would introduce a new Interface that extends the BlackBoxTestSourceFilesInterface adding again the
BlackBoxTestSourceFilesInterface processors(@FluentApiBackingBeanMapping("processors") @NotNull Class<? extends Processor>... var1);
I think it would be more "fluent" to add one processor after another.

If you can wait for it, I would play with it and give it as a PR.
By the way, one more question. Why do we need Collection<Class<? extends Processor>>? As far as I can figure out we only want to iterate over the processor classes to validate and later instantiate them. I propose to define it as Iterable<Class<? extends Processor>>.
Regards,
István

Hi,

Yes you are right. The validator doesn't catch null valued elements of collections. Best way to fix it by adding another validator to FluApiGen like NonNullableElements or something like that. This should be quite easy to implement there.
I thought about that as well and i am completely open to it.

You are right about the Iterable interface, it would be totally fine to use it since we are just looping over the passed processors and don't use anything that the Collection interface offers. I will change it.
If you want to provide a PR i will be totally happy. If you need help to understand the FluApiGen or APTK stuff don't hesitate to write me.
Best regards
Tobias

I just tried to change the Collection based parameter to Iterator.
Unfortunately, this would require some changes in  the  FluApiGen library.
Currently, the library can only handle arrays and Collections mappings to backing beans.
This is due to the fact that it uses target types addAll method for mapping which takes a Collection as parameter.
I don't know if i am able to change that soon, because i am currently adding a huge extension for the APTK framework.

No issue. I am going on the same path to discover both the Fluent API generator and the APTK as well. We also need support from the aptk for the Iterable. I will give the PRs in aptk, Fluent and cute.

Ok, sounds good. But drop it if's too complicated to achieve. The benefit isn't that huge, most people could probably live with just Collections as well.

I will check the merge later today.


Automatic configuration of PS_WORDSIZE

See #2 .
We should auto-configure PS_WORDSIZE upon building the system, or at least error out if it is not set correctly for your architecture.

Solved in #4
Added a new architecture for x86_64


Add support for storing non-CLP-encodable values in a separate column; Replace CLP row value that are too large to store in FixedByteMVMutableForwardIndex with an error message.

The dictVar and encodedVar columns in CLP are stored in multi-value forward indexes, which require users to specify the maximum number of values per row at index creation time. However, this is impractical because the number of values per row is only determined during ingestion. To prevent ingestion errors when the number of values in a row exceeds the allowed limit for a multi-value row, the encoded value is replaced with an error message. To preserve the original content, the raw value is stored in a separate field.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 0.00%. Comparing base (59551e4) to head (03edc2a).
Report is 1277 commits behind head on master.

:exclamation:  There is a different number of reports uploaded between BASE (59551e4) and HEAD (03edc2a). Click for more details.
HEAD has 53 uploads less than BASE

Flag
BASE (59551e4)
HEAD (03edc2a)

integration
7
1

integration2
3
1

temurin
12
1

java-21
7
1

skip-bytebuffers-true
3
1

skip-bytebuffers-false
7
0

unittests
5
0

unittests1
2
0

java-11
5
0

unittests2
3
0

integration1
2
0

custom-integration1
2
0

Additional details and impacted files
@@              Coverage Diff              @@
##             master   #14365       +/-   ##
=============================================
- Coverage     61.75%    0.00%   -61.76%
=============================================
  Files          2436        3     -2433
  Lines        133233        6   -133227
  Branches      20636        0    -20636
=============================================
- Hits          82274        0    -82274
+ Misses        44911        6    -44905
+ Partials       6048        0     -6048

Flag
Coverage Δ

custom-integration1
?

integration
0.00% <ø> (-0.01%)
:arrow_down:

integration1
?

integration2
0.00% <ø> (ø)

java-11
?

java-21
0.00% <ø> (-61.63%)
:arrow_down:

skip-bytebuffers-false
?

skip-bytebuffers-true
0.00% <ø> (-27.73%)
:arrow_down:

temurin
0.00% <ø> (-61.76%)
:arrow_down:

unittests
?

unittests1
?

unittests2
?

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

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


Release v3.28.1

Thanks, in the future just note HISTORY should only include things relevant to library users downstream


Unique Operator.

Skeletal code.. not ready yet.

Unique Operator: the dynamic data case works, with zeros paddeding: The reference test checks for the expected (zero-padded) results. Static data case: const-folding test cases -- no zero padding is required.

I have a question for the reviewers:  How should one demarcate the zero-filled results of an operator like unique where the dynamic output size/shape isn't known in advance -- its shape is a subset of the input shape. We zero-fill our results, yes, but zero is part of a valid output, so it is a bit unclear how do we demarcate.
We do have one way out of this here, specifically for the unique operator. One of the resulting output -- it is always non-zero: the count. So, I can use that as an OOB signal.
@pfultz2, @umangyadav, @TedThemistokleous

I have a question for the reviewers: How should one demarcate the zero-filled results of an operator like unique where the dynamic output size/shape isn't known in advance -- its shape is a subset of the input shape.

Does the operator require us to demarcate the zero-filled results? If not, it should just have a padded output. Keep in mind that we probably won't be using this operator with zero padding later, but rather dynamic shapes.

I have a question for the reviewers: How should one demarcate the zero-filled results of an operator like unique where the dynamic output size/shape isn't known in advance -- its shape is a subset of the input shape.

@lakhinderwalia Does the operator require us to demarcate the zero-filled results? If not, it should just have a padded output. Keep in mind that we probably won't be using this operator with zero padding later, but rather dynamic shapes.

Zero-filled results is our current (I think intermediate) approach; But zero-filled (demarcation) isn't blessed by the operator (specification). Thanks.

Zero-filled results is our current (I think intermediate) approach; But zero-filled (demarcation) isn't blessed by the operator (specification). Thanks.

Yea you need to return a dynamic shape in compute_shape, and then in compute you will need to do a reshape on the outputs arguments to trim off the extra zeros.


[Bugfix] More consistent results from 'ip' on Non-OSX systems

Description
Due to issues matching with some versions of iproute's 'ip' command, I've rewritten and thoroughly commented the non-OSX portion of p9k::parseIp. See https://github.com/Powerlevel9k/powerlevel9k/issues/823
If desired, a lot of this can be rewritten to be shorter (and theoretically a smidge faster to execute); I chose to write the initial code in this manner to make it easier to read what I've done when reviewing the pull request.
Questions
None.
Additional notes against the bulletpoints from your PR guidelines:

This is against the master branch due to it being a bugfix
test/functions/utilities.spec has been run with no errors reported
No manual tests required AFAIK
No user configuration required
I don't believe this needs documentation in the wiki
I hope my commit message suffices

p9k::parseIp used to skip interfaces that aren't UP. Is this still the case with this PR?

I'll rephrase my question.
With the current implementation, if I set POWERLEVEL9K_IP_INTERFACE=foo, ip prompt segment won't be displayed unless network interface foo is UP (as can be seen in the output of ip link show foo).
Is this behavior preserved by the PR?

Yes it is.

Have you tried it? Once you get ip prompt segment working with POWERLEVEL9K_IP_INTERFACE=foo, type sudo ip link set foo down. This should hide ip segment.

Unfortunately, I do not have any systems to test this on (I use WSL on my computer, which it seems cannot toggle interfaces on the Windows host; the other *nix systems are servers and turning off an interface on any one of them would be followed by much yelling), but I see the problem you seem to be hinting at.
The way I've written this, if you manually specify an interface the IP address, if found, will ALWAYS be returned for that interface. The only instances where it will return nothing is if a) no interface is specified and no interface is up with an address b) a non-existent interface is specified.
I'll update this when I can.

The way I've written this, if you manually specify an interface the IP address, if found, will ALWAYS be returned for that interface. The only instances where it will return nothing is if a) no interface is specified and no interface is up with an address b) a non-existent interface is specified.

That's right. The output of ip -o -f inet addr show foo is the same whether foo is UP or DOWN. Since it's the only command that your code calls when POWERLEVEL9K_IP_INTERFACE=foo, it's not possible to differentiate between UP and DOWN links.
Also note that the detection of link state is broken in the current code but in a different direction from your PR. While your PR will sometimes display an IP from an interface that is down, the current code will sometimes fail to display an IP from an interface that is up.
P.S.
It's a good idea to test your code on Linux and FreeBSD in addition to WSL. These systems have different network stacks and tools.

Regarding the issue in the current code, that's exactly what I'm trying (and less successfully than I had hoped) to address. It's failing to show the IP for an interface which is up, as explained in the referenced issue.
I've tested it on several CentOS and Debian systems, I just don't have the ability to flip their interfaces on and off since they're production systems at work.

Regarding the issue in the current code, that's exactly what I'm trying (and less successfully than I had hoped) to address.

Yes, I've read your description of the issue affecting WSL. I'm referring to a different issue that affects Linux. I don't remember the details but the essential part is that the current code is mistakenly looking at the operational link state instead of its administrative state. Operational state is unreliable with many drivers and is best ignored.

I've tested it on several CentOS and Debian systems, I just don't have the ability to flip their interfaces on and off since they're production systems at work.

If you cannot get access to a physical Linux or FreeBSD box, use a VM. WSL is a poor substitute for Linux when it comes to testing your code because it has no Linux kernel. Linux in a VM on Windows will work just like a real Linux in all but the most obscure of corner cases. You could also try WSL2 or Docker, both of which run a real Linux kernel in a VM, but you'll still need access to FreeBSD or some other non-Apple BSD. Either way, it's a good investment of your time to learn how to run an OS in a VM.
P.S.
Please note that I'm neither a developer nor a user of Powerlevel9k. My opinion on what you should do comes with no authority whatsoever.


double_hinge_team compatibility broken

Likely caused by faulty logic in PImpl.complete_by_dijkstra()

This might be related or caused by #32 as preliminary tests show that disabling ERODE, INSERT, and CROSS lead to sensible output in 2H case.

Not likely to be related #32 as that issue is closed yet this problem continus happening.
Opened a branch double-hinge-bug to fix it.


Fix how Warehouse stores metadata (per-file, not per-release)

Describe the bug
Warehouse's API gives the user sometimes inaccurate dependency metadata for a project's release, because:

we only store the dependency information per Release, but it can vary per file.
first file uploaded creates the Release object. which is also problematic -- if the user uploads a source distribution first, no dependency information is encoded for the Release

Expected behavior
As I understand it, we should change how we store and provide dependency information, recording and storing it per file instead of per release. I presume this means that the requires_dist field within the release endpoint would move from the "info" value to the individual "releases" values.
To Reproduce
Sorry, I don't have one to hand.
Additional context
Quoting a conversation in IRC today between @dstufft and @techalchemy (quotes are condensed and edited for grammar):
@dstufft said of the current Warehouse JSON API, "I don't think it's usable in it's current form for resolving dependencies". Regarding the metadata available, which clients would otherwise need to download packages to acquire,
"the data is wrong is the main thing ... for dep info .... because warehouse (and originally PyPI's data model) is wrong. We only store the dependency information per Release, but it can vary per file."
@techalchemy asked: "so which file do you pick for parsing dependencies? the first wheel that gets uploaded? Or the last one?"
@dstufft: "first file uploaded creates the Release object. which is also problematic, if you upload a sdist first no dependency information is encoded.... At one point only twine worked to upload dependency information. If you uploaded with setuptools it didn't get sent no matter what."
Donald also noted, on parseability of that info, "We [Warehouse] do not currently parse anything inside of a wheel, in part because we never did, in part because upload already takes forever and the more stuff we do the longer it takes. I think our timeout on upload is multiple minutes, because that's how long it takes sometimes."  (That's a reason for #7730 but we should not block on that.)
"We might want to tweak the JSON API a bit just to make it suitable for the primary use case I think people want it for, and when I say tweak, I basically mean add a field or two to a dict inside of alist"

@cooperlees is now working on https://github.com/pypa/packaging-problems/issues/367 which is partially blocked by this bug in Warehouse.

I've been thinking about this again, so I looked at exactly what we're storing per Project, Release, and File in terms of metadata.
Currently our metadata looks like:

Project: Name
Release: Version
Release: Author
Release: Author Email
Release: Maintainer
Release: Maintainer Email
Release: Home Page
Release: Download-URL
Release: Project-URL
Release: License
Release: Summary
Release: Description
Release: Keywords
Release: Platform
Release: Requires-Python
Release: Yanked / Yanked Reason
Release: Classifiers
Release: Uploader / Uploaded-Via
Release: Requires / Provides / Obsoletes
Release: Requires-Dist / Provides-Dist / Obsoletes-Dist
Release: Requires-External
File: Python Version
File: Requires-Python (Denormalized from Release via PostgreSQL)
File: Package-Type
File: Comment
File: Filename
File: Signature
File: MD5 / SHA256 / Blake2-256 Digests
File: Upload-Time
File: Uploaded-Via (Duplicated during Upload via Warehouse)

Since all of this metadata comes from uploading a file, technically every single one of these besides Name and Version can vary file to file, but practically speaking much of it is exactly the same for each file within a release.
Additionally, from an implementation point of view, it's a lot easier in the Web UI, and also just general data model and conceptual overhead when most of these values are the same for each release.
Looking though this, the main thing I see that we should change is:

Requires / Provides / Obsoletes should move from Release to File
Requires-Dist / Provides-Dist / Obsoletes-Dist should move from Release to File
Requires-External should move from Release to File
Uploader / Uploaded-Via should exist on both Release and File

You could make an argument that Requires-Python and Yanked / Yanked Reason should move from Release to File.
I think that for Requires-Python, we display that in the Web UI, so it makes sense to want that to be consistent, but more importantly, the intent of that key is that you can make a new release that doesn't support some version(s) of Python without a new release breaking existing users. For that, I think it makes sense to keep it consistent, since every file should be the same version of the code.
For yanking, I think that we've made a conscious choice to implement yanking in terms of a yanking a whole release, not an individual file, which I think is perfectly fine.
So I believe the original issue was roughly accurate, we primarily just need to store dependency information on File, and the rest can pretty much remain on Release. I assumed that would be the case, but I wanted to take a few minutes to dig into it to verify it.

WARNING: I've done a fair amount of thinking on this, and in an effort to get that information out of my head I'm just going to brain dump on this comment.

There are a few inter playing concerns here:

The existing metadata stored in the Warehouse DB does not come from the files that are uploaded to Warehouse, but rather as part of the upload we expect the uploader to POST the data alongside the file, and we store that instead.

This means that an uploader is responsible for providing correct information to Warehouse, with nothing actually checking that, so it's a potential place for incorrect clients to cause different installers to do things differently.
One of the goals for this metadata is to present it to installers, but currently most installers rely on the metadata in the file, if we just suddenly switch to storing the POST metadata per file those installers will switch from relying on the file metadata to the database metadata.

Not all of the artifacts have metadata that is parseable from the file, particularly sdists.

This is true even for new style sdists which have a standard for static metadata, because that standard has an escape hatch that lets a sdist mark a particular bit of metadata as dynamic, even in the static metadata.

Warehouse doesn't want to provide a UI that treats each file as it's own distinct entity, but wants to provide a UI that treats the release as the distinct entity, that holds a number of files.

This doesn't mean that we won't want to move some of the metadata that we treat as release wide, to be file specific in the Warehouse UI.

The primary driving force for this data is to present it to installers, so we need to make sure how we solve this, will work for them.

The actual mechanics of storing metadata per file is straight forward, either add columns to the existing File model, or create a FileMetdata model that has a foreign key to the File.
Most of these problems come down to how do we source this metadata (for existing files, for new files in the interim, and long term), but there's also a question on how we handle sdists which may have dynamic metadata.
Personally, I think the gold standard for what we want to arrive at here is that we have a source of per file metadata, that we guarantee matches the content of the files. If we can't get that information for a file, then we don't attempt to "best guess it", it either comes from the file or we don't provide it. An important aspect here is we'll need to determine the difference between unset and set to nothing.
In the interim to getting to that point, we can have some "best guess" information, if we know that we can later fill it in, but we shouldn't provide "best guess" information, and then delete it completely.
I think the fastest path forward then is we end up with a FileMetadata model (or columns on File), that we only fill in for Wheels currently from the POST, because we know that wheels have static metadata so we can always backfill it. However we don't know that for sdists, so we don't try to guess based on the POST data.
Once we evolve the upload API so that we can introspect artifacts and get metadata from them, then we can switch to using the from-the-artifact data, including in cases where we have that information inside of an sdist.
We can also backfill this "best guess" data at anytime by iterating over the wheels (and actually sdists) that are already uploaded and fill in t hat data with "validated" data. We could do this after we have the upload introspection, or even before if we record that we've done it already.
Then there's the question of handling the metadata that we want to treat as "release" metadata in the Warehouse UI and existing APIs, but which obviously come from one of the files (like summary, long description, URLs, whatever). For this we can do a number of things, either just duplicate the data at the Release level and leave the existing columns there, or have some file end up being promoted as the "metadata source" for that Release (could be done using some logic like first release, or always the sdist, or whatever, or even just an FK and do first uploaded).

So tl;dr I suspect our best path forward here:

Add a FileMetdata or more columns on File, figure out how to mark unset vs nothing, figure out how to mark if it comes from within an artifact or via the POST data.
Start storing that data, only for wheels via the POST data, marked appropriately.
Backfill the above with data from Release only for Wheels.
Optional: Celery task that looks for files that have not been extracted from the artifact, and does that, marking appropriately.

This might want to validate the metadata strictly before doing extraction?

Either keep storing all the various Release columns, or make a FK or something to still let referencing one of the FileMetadata instances.

Then at some point in the future, when we can introspect files on upload, we get validated data on upload.

It's been a while and a few things have changed since https://github.com/pypi/warehouse/issues/8090#issuecomment-1412819768 (namely that we've started extracting metadata from wheels, and have backfilled metadata files for all wheels).
I've updated the first comment (https://github.com/pypi/warehouse/issues/8090#issue-636568899) with a task list that I think accurately describes the work we need to do here.


Enable both ipconfigUSE_IPv6 ipconfigUSE_IPv4 while building

Description
This PR makes it mandatory to enable ipconfigUSE_IPv4 and ipconfigUSE_IPv6 flags to be enabled for build to progress, as separation for both IPv4 and IPv6 is work in progress.
Test Steps
Unit tests  are validated.
Checklist:

[x] I have tested my changes. No regression in existing tests.
[ ] I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue
Issue #771
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/bot run uncrustify


Main command line run have [@coverage off]

let () =
  (* Non terminating expressions currently have to disable coverage, otherwise a
     non visitable coverage point is inserted. This issue has been reported
     upstream.

     {[
       let () = __bisect_post_visit__ 1 (Command_unix.run main)
     ]}
  *)
  (Command_unix.run main [@coverage off])
;;

Fixed by 4cb7927


Minor routes fixes

These are things I ran into when attempting to reproduce the iOS route bug in the skeleton

@tomsmalley Thanks!  I ended up writing the SetRoute instance, too, but the fundep looks like it would be great to add.


Adding Feature to support PR Reviews

What is the context of this PR?
https://trello.com/c/2cE03AG1
How to review
Create own token in GitHub to access new additions to Forth Wall and enter:
file:///Users/"YourName"/projects/fourth-wall/index.html?"YOUR_TOKEN"&team=onsdigital/eq
Who worked on the PR:
Mohammad Samiul Islam
Shahi Noor Ahmed

The .idea directory shouldn't be committed with this PR, if it's useful to have then it should be added as a separate PR

@collisdigital I have just added them to the .gitignore file and am gonna push that.

Please squash then this can merge


What is the actual shortcut to open the window?

I've tried hard to find it but it's nowhere to be found.
Not here:

Not here either:

If there's a magical shortcut that triggers this window, it should be stated somewhere. Best if it's in plugin description.

@Nowaker,
Chrome has a central screen for managing shortcut keys on the extensions page:

... once you click the "keyboard shortcuts" link at the bottom of that screen you should see something like this...

From there you can set the shortcuts, some will work better than others depending on your OS etc so some experimentation might be required.
Thanks for sticking with this =)
Evan

Wow. Thanks. Would never think of looking there. I propose that this be included in README.md. A brief explanation in plugin settings is worth making too. After all, JetBrains IDE users expect this to be available under a shortcut OOTB, otherwise it's not IntelliJ. :rofl:

Well, there's this:

And if you scroll to the bottom, there's this:

But I guess it's still a bit cryptic in that it doesn't state where to find the shortcut that will trigger the popup.

How about adding a direct link to chrome://extensions/?

Chrome ignores links like that, presumably for security reasons, I tried the technique mentioned here ( http://stackoverflow.com/questions/13125616/link-to-chrome-chrome-extensions-from-extension-options-page ) but it's not working...

It doesn't have to be a link. Stating chrome://extensions/ is still good enough. :)

This tip is not too useful:
Important: This shortcut key is now managed by Chrome directly†.
It is better to write something like

go to chrome extension, scroll to the bottom and click shortcut binding to set a shortcut

PS: Forgive me , my system is Chinese, I don''t know the exact words used in Chrome

OK, I found similar tip is write in the bottom.  Why not move to Popup window shortcut??


Consolidate dlpoly readers into single file

For the sake of consistency in the design of file input readers. It makes some sense to confine the readers to a single file. Though this is not exactly a high priority.

I am not sure how much sense that makes. The .dlph and .dlpc trajectory format has much less information in it as the .dlpf topology format. So there isn't much we would gain in terms of reducing code duplication.
But that is a question for @abrukhno.

Is the thumbs down, because I didn't provide an explanation?

Let’s see what @abrukhno thinks, he wrote most of the code!

Hi, sorry for a bit of delay (it's Saturday after all).
I am not sure I follow the idea. In the case of DL_POLY configuration (.dlpc) and trajectory (.dlph) formats are only slightly different (but I think reading either is combine already in one piece of code) whereas topology format is completely different, as it's not about configuration rather molecular structure and force-field. So what is the suggestion?

Well my thoughts were as follows: combining the two readers in same file is more consistent with how the file readers are formatted. From the stand point of maintainability, if all the readers follow the same pattern it is easier to understand what is going on. I think the point @junghans is making is that because the readers are configured so differently it will not result in a reduction in the amount of code (so it's kind of a waste of time).

Hi Joshua, could you please provide more detail as to how you suggest to combine the two readers? -by simply having them as separate routines in the same file, or in the same routine/function? Either way I do not see much of a benefit, only extra work and debugging. Sorry if I misunderstood you.

You are right there is not much benefit. My arguments are mostly trivial, and this is a low priority issue if at all. What I'm trying to illustrate by bringing this up is that the more similar your methods are the easier it is to follow logic of the code between the different methods.
Most of the topology and trajectory readers are in the same file but this one and a few others are not. Which is not a big deal, but if the code base continues to grow small inconsistencies can add up and complicate the code base unnecessarily. For this particular reader, there would not really be much to change.
Most of the readers follow this format in the header file:
    public TrajectoryReader, public TopologyReader
{
    public:
        SomeReader() {}
        ~SomeReader() {}

        /// open a topology file
        bool ReadTopology(string file, Topology &top);

        /// open a trejectory file
        bool Open(const string &file);
        /// read in the first frame
        bool FirstFrame(Topology &top);
        /// read in the next frame
        bool NextFrame(Topology &top);

        void Close();
        // reader specific methods
    private:
        ifstream _fl;
        bool _topology;
        //reader specific variables
};

Where as the dlpoly has two header files
   : public TrajectoryWriter
{
 public:
  // open transformed trajectory file
  void Open(string file, bool bAppend=false);
  // close transformed trajectory file
  void Close();
  // write a frame into transformed trajectory file
  void Write(Topology *conf);

  /// set/get the created configuration or trajectory file name:
  /// <name>.dlpc or <name>.dlph (convention: ".dlpc"="CONFIG_CGV", ".dlph"="HISTORY_CGV")
  void   setFname(string name) { _fname = name; return; }
  string getFname()            { return _fname; }

  /// set/check the flag for the created file as configuration, i.e. not trajectory format
  void setIsConfig(bool isConf) { _isConfig=isConf;  return; }
  bool getIsConfig()            { return _isConfig; }

 private:
  ofstream _fl;
  string _fname;
  bool _isConfig;
};

And
   : public TopologyReader
{
public:
    DLPOLYTopologyReader() {}

    /// read a topology file
    bool ReadTopology(string file, Topology &top);

    /// set the topology file name: <name>.dlpf (convention: ".dlpf"="FIELD")
    void   setFname(string name) { _fname = name; return; }
    /// get the topology file name: <name>.dlpf (convention: ".dlpf"="FIELD")
    string getFname()            { return _fname; }

private:
    string _fname;
    /// function to find and read the next line starting with a keyword/directive (skipping comments starting with "#" or ";")
    string _NextKeyline(ifstream &fs, const char* wsp);
    /// function to read the next line containing only a given keyword and an integer value after it (only skipping comments!)
    string _NextKeyInt(ifstream &fs, const char* wsp, const string &word, int &ival);
    /// function to check if the given (last read) directive line starts with a given keyword and has an integer value at the end
    bool   _isKeyInt(const string &line, const char* wsp, const string &word, int &ival);
};

I do not really care what is decided, I was working on the pdbreader and figured I would offer to do this just for the purpose of having consistency across the readers. After all there is always the risk of introducing bugs when you change code. :)

By the rule of thumb "if it works and no change is necessitated, do not touch it", I would leave it as it is. :)

Ok, well I guess that settles it. :)


Updating daysOfWeekDisabled via options does not work

Updating daysOfWeekDisabled using the options-function does not work. See http://jsfiddle.net/Pyppe/hccLcc5m/1/ illustrating the issue.

the fix will be to make daysOfWeekDisabled accept a bool of false to void the option

Please check the development branch. Pass false to reset


Keyword only containing numbers throws 'Invalid select keyword'

My code looks like this
String httpError(httpError) => Intl.select(
        httpError,
      {
        "400": "Bad Request",
        "401": "Unauthorized",
        "403": "Forbidden",
        "404": "Not Found",
        "405": "Method Not Allowed",
        "406": "Not Acceptable",
        "407": "Proxy Authentication Required",
        "408": "Request Timeout",
        "409": "Conflict",
        "410": "Gone",
        "411": "Length Required",
        "412": "Precondition Failed",
        "413": "Request Entity Too Large",
        "414": "Request-URI Too Long",
        "415": "Unsupported Media Type",
        "416": "Request Range Not Satisfiable",
        "417": "Expectation Failed",
        "422": "Unprocessable Entity",
        "429": "Too Many Requests",
        "500": "Internal Server Error",
        "501": "Not Implemented",
        "502": "Bad Gateway",
        "503": "Service Unavailable",
        "504": "Gateway Timeout",
        "505": "HTTP Version Not Supported",
        "other": "Something went wrong"
      },
      name: "httpError",
      args: [httpError]);

When running extract_to_arb I get the following exception:
Error IntlMessageExtractionException: Invalid select keyword: '400', must match '[a-zA-Z][a-zA-Z0-9_-]*'

Why is it that the first charachter must be a letter? Is there any reason to this?
On the other hand.
The key has to be a String. What I actually would like to see is integers being accepted. Or any other Object, such as the parameter suggests.
For Example:
  String httpError(httpError) => Intl.select(
        httpError,
      <Object, String>{
        400: "Bad Request",
        401: "Unauthorized",
        "other": "Something went wrong"
      },
      name: "httpError",
      args: [httpError]);

I don't remember why that restriction is there in the grammar, but I assume it's coming from somewhere in the format/what translation tools accept. But we can certainly investigate if it can be relaxed.
For the second part, it accepts any Object and will convert it to a string. But the map keys have to be the string form. That's an attempt at accepting enums, which is an obvious use for select. Unfortunately the toString of Dart enums is annoyingly long, so the keys get to be 'MyEnumType.enumValue'.
Accepting any object in general is tricky, because when we read something from the file, it's a string. I think we could make that work, but it's not completely trivial.


Fix get.sh to select between --version and version subcommand

Binary already exists in path :
VERSION=v0.1.15 ./get.sh

To replace an old version of pvsadm, run this script with an environment variable: FORCE=1

pvsadm is already installed!
Version: v0.1.15, GoVersion: go1.21.11
-----------
VERSION=v0.1.18 ./get.sh. <- manually built from source with the version tag set to 1.18

To replace an old version of pvsadm, run this script with an environment variable: FORCE=1

pvsadm is already installed!
Version: 0.18.0 GoVersion: go1.22.4

A binary is required to be installed
VERSION=v0.1.15 ./get.sh

To replace an old version of pvsadm, run this script with an environment variable: FORCE=1

############################################################################################################# 100.0%
Version: v0.1.15, GoVersion: go1.21.11

Additional notes:
0.1.16 does also seem to report of the API key required to be set :  #664.

Additional note: the builds of 0.1.16 are affected too, which may require phasing out the release binary.


Issue with signing package

Hi!
As I need to sign my assembly and none of HockeyApp (HockeySDK.WPF.2.2.2) and HockeyAppPCL (HockeySDK.Core.2.2.2) have a strong name I need to add them a strong name.
For this, I sign your packages with the package StrongNaming https://www.nuget.org/packages/Nivot.StrongNaming/.
The problem after signing with StrongNaming is that I have realised that HockeyApp packages stop working. They throw an exception (which doesn't crash the app) and do nothing.
Can you give me any tip of how can I sign these packages?

We believe that the only solution is to compile our WPF and Core libraries from source and adjust the references between them to work with StrongNaming.

Yep, think so. Thanks ;)


Context propagation in mp-fault-tolerance

Some methods in fault-tolerance are executed on a different thread which breaks context. Namely, methods annotated with @Asynchronous 1 , but also @Timeout 2 (might not apply for all impls 3).

https://github.com/michalszynkiewicz/thorntail-quotes/blob/master/src/main/java/io/thorntail/example/quotes/ads/AdRetriever.java#L39


docs: update tool integration link and multi SDKs description in readme

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

[x] N
[ ] Y

docs: update tool integration link and multi SDKs description in readme

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 71.44%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
52748

Relevant Lines:
73835

💛  - Coveralls


Shifter Game Tools: FBX exporter

[x] old game tools in a tab named "disconnect"
[ ] New main tab FBX export

Root motion options
- [ ] Space recorder options to edit root motion joint
FBX export options:

[x] remove namespaces in FBX (using FBX SDK)
[x] update hierarchy in FBX (using FBX SDK)
[ ] Export animation clips
[x] Selection of up Axis Y or Z
[ ] Configuration script path for more options configuration
[ ] export/import tool options and clips configuration
[x] Skeletal Mesh partition for Modular characters

Feature requests
The ability to set the animation layers we want on export. For example, if I make a run cycle and then make left and right variations on different layers, then export 3 different clips in one click, each one with its own unique animation layers active
Different tabs for different characters’ export settings (or a dropdown, but I personally prefer tabs)  We can achieve tabs by opening different instances and docking it
Quality of life requests
A) quickly check/uncheck all the anim clips to be exported (this is useful for doing things like directional aim poses where we often have to export a lot of assets at once)
B) Set the playback range to the time range that's in the exported clip

the option to also set the export range to the playback range would be welcome\

would it be possible to have an option that sets the export path to the current Maya file, and the name of the FBX as the name of the Maya file?
Yes, Also we can use tokens like {scene_name} or {scene_path}

SkeletalMesh partitions MEMO to research:

[ ] FBX skinning mapping is by index? (check if this is true)
[ ] If it is true, maybe cleaning joint hierarch will break index order?
[ ] deleting not needed joint should be optional?

WIP UI:

Improvements after FBX Exporter review meeting:

[ x ] Top list should keep its size when UI is expanded. Partitions list is the one that should be updated.
[ x ] Allow the selection of multiple partitions.
[ x ] Implement drag&drop partitions functionailty (left click: move partitions ; right click: duplicate partitions).
[ x ] Store UI state when FBX Exporter tool is closed.
[ x ] Load UI state when FBX Exporter tool is closed.
[ x ] Remove full FBX when partitions are used.
[ x ] Remove grab functionality from empty partitions.
[ ]  List of available Unrelal Skeletons should be available within UI.
[ ] Master partition should be renamable and its data should be stored within scene.
[ ] Make sure all export process can be scripted.
[ ] Implement FBX Exporter prestes loading/saving functionality.
[ ] Master partition should contain the full skeleton and if no geometry is available an empty triangle should be created and skinned to the root joint.

Do we want base animation, from Maya animation layer UI

Custom DropDown created, that refreshes on popup.
https://github.com/mgear-dev/mgear4/commit/4a1ff7b9ca4f5d91a05a365cf45562727378c4a1

#315


Detect/handle Accessibility permission not granted

macOS: 13.2.1 (22D68)
Add notification AXFocusedUIElementChanged failed: -25211

checked System Settings -> Privacy & Security -> Accessibility -> WakaTime switch is On

By a few times run / build / install / uninstall, are there some clean job need to be done?

defaults read com.apple.universalaccessAuthWarning | grep waka
get
"xcode-wakatime.WakaTime" = 1;

After trying some attempts, I deleted ~/Library/Application\ Support/com.apple.TCC, which caused all app permissions on the mac to be revoked. Then I restarted wakatime and finally the permissions granted.

sudo tccutil reset Accessibility did the same.


Integrating Overture Map's "Places theme"?

Amazon, Meta, Microsoft, and TomTom got together to share additional data and this group is under the Linux Foundation. I think the location search would be improved if the millions of places in the Overture's dataset could be integrated.

We use pelias for location search. Here's the corresponding issue to add overture to pelias https://github.com/pelias/pelias/issues/954


Add a way to list packages by prefix

https://godoc.org/-/subrepo has a special index to display all the golang.org/x/... subrepos.
It would be nice to have this for any package path prefix. For example, to display all of the google.golang.org/... repos.

That does sound nice. Some queries of that nature may return an exorbitant amount of packages without pagination. Still, it will be less than the page that displays all packages known to godoc.org.
@broady, in addition to google.golang.org/..., would this feature request would also include queries like github.com/username/... and github.com/...?

Exactly. We should paginate. That other page that lists all packages should
be paginated, anyway!
On Apr 19, 2016 8:46 AM, "Dmitri Shuralyov"<EMAIL_ADDRESS>wrote:

That does sound nice. Some queries of that nature may return an exorbitant
amount of packages without pagination. Still, it will be less than the page
that displays all packages known to godoc.org.
@broady https://github.com/broady, in addition to google.golang.org/...,
would this feature request would also include queries like
github.com/username/... and github.com/...?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/golang/gddo/issues/399#issuecomment-211616633