TypeError When Parsing Argument

Version: 0.5.14
tyro.cli() fails for the following part of the code - Source
  gradient_checkpointing_kwargs: dict = field(
      default=None,
      metadata={
          "help": "Gradient checkpointing key word arguments such as `use_reentrant`. Will be passed to `torch.utils.checkpoint.checkpoint` through `model.gradient_checkpointing_enable`."
      },
  )

Exception traceback:
SOME_PATH/lib/python3.9/site-packages/tyro/_resolver.py:311: UserWarning: <class 'int'> does not match any type in Union: [<class 'float'>, <class 'NoneType'>]
  warnings.warn(
SOME_PATH/lib/python3.9/site-packages/tyro/_resolver.py:311: UserWarning: <class 'dict'> does not match any type in Union: [<class 'str'>, <class 'NoneType'>]
  warnings.warn(
Traceback (most recent call last):
  File "SOME_SCRIPT.py", line 69, in <module>
    script_args = tyro.cli(ScriptArguments)
  File "SOME_PATH/lib/python3.9/site-packages/tyro/_cli.py", line 187, in cli
    output = _cli_impl(
  File "SOME_PATH/lib/python3.9/site-packages/tyro/_cli.py", line 374, in _cli_impl
    parser_spec = _parsers.ParserSpecification.from_callable_or_type(
  File "SOME_PATH/lib/python3.9/site-packages/tyro/_parsers.py", line 106, in from_callable_or_type
    field_out = handle_field(
  File "SOME_PATH/lib/python3.9/site-packages/tyro/_parsers.py", line 320, in handle_field
    return ParserSpecification.from_callable_or_type(
  File "SOME_PATH/lib/python3.9/site-packages/tyro/_parsers.py", line 106, in from_callable_or_type
    field_out = handle_field(
  File "SOME_PATH/lib/python3.9/site-packages/tyro/_parsers.py", line 312, in handle_field
    if _fields.is_nested_type(field.type_or_callable, field.default):
  File "SOME_PATH/lib/python3.9/site-packages/tyro/_unsafe_cache.py", line 33, in wrapped_f
    out = f(*args, **kwargs)
  File "SOME_PATH/lib/python3.9/site-packages/tyro/_fields.py", line 224, in is_nested_type
    _try_field_list_from_callable(typ, default_instance),
  File "SOME_PATH/lib/python3.9/site-packages/tyro/_fields.py", line 348, in _try_field_list_from_callable
    return _field_list_from_dict(f, default_instance)
  File "SOME_PATH/lib/python3.9/site-packages/tyro/_fields.py", line 734, in _field_list_from_dict
    if default_instance in MISSING_SINGLETONS or len(cast(dict, default_instance)) == 0:
TypeError: object of type 'NoneType' has no len()

I suspect that this might be due to the type hint is not Optional but dict. Since the default does set it as None, maybe tyro should handle this case as well?

Thanks for flagging this!
On our end I'm happy to either improve the error message or silently convert the type when the default doesn't match. The latter feels weird, so I'd need to think about it.
But ultimately this looks like an error that should be fixed in the transformers code, right? It seems incorrect to create a field that's annotated as dict but defaults to None.

I agree! The code snippet from transformers was recently implemented.
I think some error message can be helpful to figure out what went wrong without letting the user to dive into the source code too much as sometimes these can get pretty nested.
Regarding converting the type, maybe adding one additional check to determine whether the default is None or not can be helpful? I.e. treat that variable as Optional[TYPE] type if the default is None. Again, this will be your call.

Ok! The newest release should expand the type to Optional[T] after raising a warning.


Cxf 8445

Sonar rule to reduce complexity of a method will entail more unit tests and code refactoring.
This is considered a medium level  if there are unit tests ready for the affected method; however,  if unit tests does not exist for the whole class or the methods inside the class which are affected, this will make the complex level to over medium.
The refactor is focused on method bases and is incremental. This means some classes contains more then one methods to be have reduction in cognitive complexity, one method will be taken and the rest will be accomplished in different pull request.
This pull request will not try to refactor all the complex cognitive methods but rather will do some and once the pull is accepted, it will proceed to next pull and so forth until the core methods has no issue in relation to cognitive complexity
Sonar rule: java:S3776 reduce Cognitive Complexity of a method; see CognitiveComplexity
No more changes will be committed for this PR . Since we want each PR  has very min. changes in this area (CognitiveComplexity)

The check is failed now due to CodeQL  rule which force us to check the directory name not to contain ".."   Any help would be appreciated to relax the codeQL rule.  I are doing refactoring and never touch the business logic.


Make IDENTIFY packet set to DND

Summary
When sending the IDENTIFY packet through the WebSocket, make it set your status to Do Not Disturb.
General Info

[x] If code changes were made then they have been tested.
[ ] This PR fixes an issue (please put issue # in summary).
[ ] This PR adds something new (e.g. new method or parameters).
[ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
[ ] This PR is not a code change (e.g. documentation, README, ...)

AFAIK the status field in Identify doesn't actually do anything.

It does, it changes your status.
You can also change the device to Discord iOS and it will spoof that you're on phone

It changes your status if you're a bot. From my testing, it does nothing for user accounts.

If you're trying to do this in order to prevent a selfbot from changing your status, try the rebase branch. It shouldn't have that problem.

interesting, it changed my status when i tried it
How do I install the rebase branch?

$ git clone --single-branch --branch rebase https://github.com/dolfies/discord.py-self
$ cd discord.py-self
$ pip install -U .[voice,speed]

Thanks

Did it work?

Didnt test lol


Typo in test-URI

PR so it won't get forgotten.
There are still issues with the test-data for alerts and mining, but I'll have a look at that once v0.12.0.x is out.

Hmm... it's not a typo but a real use case test imo
https://github.com/dashpay/dash/blob/v0.12.0.x/src/qt/guiutil.cpp#L186-L198

Good point, missed that call :-/
Will check later why the test fails.
Is there any docu on how to create valid test data?

Ah, it's ok :)
Haven't seen any doc about test data, I guess it's either considered as "trivial" by bitcoin devs or they just don't care :angry:

Found out how to build the test data file for the alerting tests (alertTests.raw).
The good news: it's easy
The bad news: each dataset needs to be signed with the secret key of the person who can send alerts (in Bitcoin's case, Gavin), so I can't do it.
Only @evan82 can do this :-)

Isn't it a bit off topic? ;)
And btw, I guess we can close this PR, right?


Accomodate Guest Orders

I could be totally off-base on this, but I've run into issues with issuing loyalty points to guest orders. From what I could tell, there weren't any other safeguards against this code running on guest orders.
Simple presence check for the base object's user.

Closing as stale and somehow grabbing other commits from people that worked at the company I used to work at.


Ignore column order when reading multiple jsons to a dataframe

I am trying reading multiple jsons to a dataframe, but got an error about mismatched columns. Here is a simple example with two json files:
test/1.json
{"a": 0, "b": 1}
{"b": 0, "a": 0}

And test/2.json
{"b": 0, "a": 0}
{"b": 0, "a": 1}

If I call dd.read_json("test/*.json").compute(), I will get error:
ValueError: The columns in the computed data do not match the columns in the provided metadata
Order of columns does not match

Can we ignore column order when reading multiple jsons (e.g. by sorting columns), since column order does not matter much in json?

@qibin-integral Thanks for reporting! I think this would be a useful feature to support. :)


Change directory structure of the repository to allow simple installation from the zip archive generated by GitHub

The current repository structure on GitHub has an annoying and unnecessary limitation: the download zip is named blender-to-smf-master.zip with no subdirectory blender-to-smf in it. As a consequence, when installing the add-on from that zip file, which should technically work, Blender puts the add-on in a directory blender-to-smf-master while it really should be just blender-to-smf.
This can be solved by putting everything under a blender-to-smf folder. The zip will still have the same name, but the additional directory inside the zip makes it clear to Blender that it should create a subdirectory, with that name.
All other files will of course come with it so ideally users should still use the release zip to do a proper installation of the add-on.
Another advantage of this directory structure would be the option to simply put a directory with example models next to it.

Verified the required directory structure. The zip can have any name as long as it contains a subdirectory with the correct name at the root level.
That directory will be created at %APPDATA%\Blender Foundation\Blender\2.90\scripts\addons with everything under it as well.
This fixes any zip naming issue that might occur.

Directories that are placed next to the blender-to-smf directory are placed in the addons folder as well, but are not properly removed. This is not a very clean way to do it.

Closing this issue since there seems to be no perfect way to do this. People using this add-on should install from a release package or by cloning into the right add-on directory.


Explicitly refresh active text editor from extension api.

There doesn't appear to be any way to explicitly refresh the active text editor. This would be useful for extensions that modify files via external commands and need to show the latest version once said command completes.

@bmingles Would window.showTextDocument help here ?

There is an option for opening editors to forceOpen which will reload the file from disk. Assuming we do not want to make this extension API, an alternative would be to add a command for this.
/cc @jrieken

@bpasero Isn't this a case for file events?

@jrieken yeah though all the bugs I have on file events show me that they do not work in all cases ;-)

Actually in this case what could bite is the fact that I ignore file change events on the currently edited file for a short period because otherwise I would reload the file every time you made a modification.
@bmingles is this a possible explanation that the text content is rapidly changed after the user saved? what is the use case for the extension?

I have an extension that can run arbitrary shell commands whenever a user saves a file (using vscode.workspace.onDidSaveTextDocument). I have some users of the extension that are running commands that modify the source file after save and are asking if it could update the active file after the commands run. The goal would be to explicitly refresh it in the extension after commands run and not based on change detection on the source file.

My current version of VS code is 1.11.1 and got the same issue.
I noticed that the VS code editor do not refresh when an external program update a file (copy, save, etc). If the opened file is currently focused in the editor and change externally, it does not refresh.
The workaround to refresh the opened and focused file in VS code is to select another opened file and get back to the edited/updated opened file.
Steps to reproduce:

Open a file in VS Code.
Open the same file in Notepass++, change it and save it.
Get back to VS Code.

Expected result: The change is visible in VS Code.
I found this while trying to debug a file under the node_module that is copied from another server package during the build process.
Please, give us a solution to automatically refresh opened and focused file in VS Code editor when an external program change it.

@slemireOmni To clarify, it sounds like you are asking for a different feature, one that responds to a file system change or something external to vscode. The feature I am requesting here is for extension developers to be able to explicitly trigger a refresh via a vscode extension through an api of some sort.

@bpasero Has there been anything added to the extension api that would facilitate this,

There is no official API yet (hence this issue is still open).
The only workaround to force refresh the active file from disk is to call our internal command workbench.action.files.revert, e.g. by doing vscode.commands.executeCommand('workbench.action.files.revert').

workbench.action.files.revert should work. It will force the active editor to read the contents from disk again and update the UI. It will not work for dirty files.


Public deployments of demos

Create and announce 'public' deployments of membrane demos, like videoroom demo and rtmp->HLS demo, so that everyone could test them. We need to impose some limits, not to crash servers in case of too big interest.

Regarding the directory structure in membrane_demo, I'd keep it as flat as possible, so that one doesn't have to check the directories to see what demos are available.

I think that using a different domain for demos (like membrane.stream) would only introduce confusion. I'd stick to membraneframework.org unless we decide to switch completely to another one

@bblaszkow06

I mean demo.membraneframework.org with a simple landing page listing all the demos and subdirectories (mapping to the ones in repo) with the actual demos, e.g. demo.membraneframework.org/rtmp-to-hls

This might introduce some problems in the way it is now deployed: depending. of course, on how this single-page app would be constructed. I would say demo.membraneframework.org could list all of the demos and links to demo-videoroom.membraneframework.org


bot still not working

the edit to 261 did not fix the issue

Yea I just tried the fix theres like 3 continue windows I also have an issue with an opponent surrendering

Yea I just tried the fix theres like 3 continue windows I also have an issue with an opponent surrendering

guess now all we can do is wait for OP to return let me know if you find a solution

Hello, you can solve your problem by changing the continue_and_replay function like this :
def continue_and_replay(self):         sleep(4)         continue_btn_pos = (self.window_x + 0.66 * self.window_width, self.window_y + self.window_height * 0.90)         second_continue_btn_pos = (self.window_x + 0.73854 * self.window_width, self.window_y + self.window_height * 0.92222)         self.mouse_handler.click(continue_btn_pos)         sleep(1.5)         self.mouse_handler.click(second_continue_btn_pos)         sleep(1)
The line 261 is used when choosing a deck, it's at the beginning on the game, not at the end

It's not perfect, it's doing the same thing multiple time, i'm trying to change it and I will raise a PR in a few minutes

PR raised :)
https://github.com/MOj0/LoR-Bot/pull/37


ci: switch to go 1.18

Part of #26

@Cian911

I ran the tests via my fork and saw no issues

Looks like there's some issue with the setup-go action for 1.18. Just to be safe for the moment I think we can just upgrade to 1.17


Pytest fixtures are wrongly defined as unused

Describe the bug
Packages that are used just as pytest fixtures are wrongly set as unused.
To Reproduce
Steps to reproduce the behavior:

Install pytest-freezer as an example
Create a test that uses that fixture, e.g.

def test_frozen(freezer):
    freezer.move_to("2021-01-01T00:00:00")

Verify that deptry will flag the package.

Expected behavior
The package should not be flagged.
Additional context
I'm not sure if there's a way to do that, or if it's too much outside of the scope of the package. But I'd say this is probably a big enough use case (supporting pytest) that maybe it should be taken into account.

Development dependencies are not flagged as unused packages, and usually packages that are only meant to be used in dev/tests should be specified in development specific dependencies groups. I don't know about your setup, nor which package manger you use, but if possible, it would be recommended to declare pytest-freezer as a development package in your dependencies.


field varients for relation types shouldn't be shown

In list and matrix view, it would be nice to not see the variants I have and instead see the type of the relationship e.g. Parents.

This could be a setting. I'll add it to the list

Thanks ❤

Should be fixed in the new release 😄 let me know if it works for ya


add time data to returned data

Adds creationTime key to returned data to allow ui to sort applications by creation time.
PR# 150 in brooklyn-ui implements the sorting.

useful.  merging.


Challenge http://www.freecodecamp.com/challenges/waypoint-change-the-color-of-text has an issue

No closing
 element in the More Information section:
Here's how you would set your h2 element's text color to blue:

CatPhotoApp

Hello @JesseNoBata Thanks for filling this issue.
For future reference please wrap code in backticks so that github presents it as text instead of trying to render it as html. I have gone ahead and added them for you. When you get a chance take a look at Mastering Markdown
I have verified the issue and will be filling a fix soon. Thanks again!

@BerkeleyTrue Thanks for the heads up, I was wondering how to show code in the issue box!

No problem. This issue is fixed now. The code should be up in production later today! Thanks again!


Let xhprofRunsFile and xhprofLibFile option be optional

Since xhprof can be installed through composer, the file including
is not a must requirement anymore.

Please send a new pull request against the cleaned up current state of the project. Sorry for the inconvenience.


NIAD-827: add-conditions-for-aws-deployment

Description
Add conditions for AWS deployment for 'main' branch only
Jira Ticket
NIAD-857
Checklist
These are items (excluding GitHub Checks) which should be confirmed before a branch is ready to merge.

[ ] Acceptance Criteria met
[ ] Commit messages are meaningful
[ ] Manually tested
[ ] Self-reviewed your code
[ ] Code reviewed from two other developers
[ ] If your pull request depends on any other, please link them in the description
[ ] main branch is passing/green on CI
[ ] Add/update any relevant documentation

Is there any way we can do as much as possible without actually deploying for PR builds? My hope is to try to mitigate the risk of merging to main only to find we've broken something for the deployment.


Tests for syntax_color_tags

Coverage increased (+0.4%) to 66.102% when pulling 56ca4983bb8812ab7301c5c2d7b13e359a00bd03 on kuter:tests-for-syntax_color_tags into f2e92093890025eb1b8bb3210385f72263062d9b on django-extensions:master.

Coverage increased (+0.4%) to 66.102% when pulling 56ca4983bb8812ab7301c5c2d7b13e359a00bd03 on kuter:tests-for-syntax_color_tags into f2e92093890025eb1b8bb3210385f72263062d9b on django-extensions:master.


Added ROS2StateProbe class

It looks like another .swp file has accidentally been added to the repo.

It looks like a few temporary and miscellaneous files have sneaked into this PR.


Upload hangs

I've been trying to use multer-s3 to create a dropbox like service where users can upload their files and download them later. I've noticed that when uploading files of sizes around 30MB or larger the entire upload (based on the client side progress bar) just hangs and freezes and never makes any more progress. But it works perfectly fine for smaller sized files.
This problem only occurs on my remote production server as well. When on localhost the upload goes smoothly.
My code looks something like this
const upload = multer({
	storage: multerS3({
	    s3: s3,
	    bucket: bucket,
	    acl: 'public-read',
	    contentDisposition: function (request, file, cb) {
	      	cb(null, "filename=" + encodeURIComponent(file.originalname));
	    },
	    key: function (request, file, cb) {
	      	let hash = app.locals.generateHash(16);
	      	cb(null, hash);
	    }
  	}),
  	limits: { fileSize: maxFileSize }
}).array("files", 20);`

app.post('/upload/:sender_id/:receiver_id', function(req, res){
	upload(req, res, function(err){
		res.sendStatus(200);
        }
});

After some further testing and debug messages, I've noticed that this only occurs for large files

This is similar to https://github.com/badunk/multer-s3/issues/69, there is a possible solution to your problem.


WIP Direct Measure eval integration

Rebased onto master
Fixed some dependencies
Work towards fixing tests
Test runs, but fails due to some missing content

Addressed in #701.


[FLINK-2109] [runtime] Fix CancelTaskException handling

Thanks to @StephanEwen for helping out. I'm waiting to hear back from Travis.

Good fix.
+1 to merge very soon!

Merging now.


Login with Facebook Account and Link Facebook Account Returns Error

After trying to log in with a Facebook account or link a Facebook account to the current Warranty Roster account, the app shows a snackbar with the message "Something went wrong. Please try again later."
App log:
launchFacebookLoginManager Callback Exception: User logged in as different Facebook user.

Issue solved and closed.


Add a missing decorator for state().

Without this, is_active() fails since lab.state is a pointer to a method
and not the property itself.

The documentation and also the associated test do not use this as a property but rather as a callable. So, I'm not 100% sure whether I want to change this.
Looking at other methods, the same logic could be applied but isn't (is_active, details, has_converged...)
For me, having this as a callable is probably more consistent... and have the is_active method fixed.

That's fair.  I will point out that node.state is also a property, but changing lab.state now would break the API.  Instead, I fixed lab.is_active().

I'm going to merge this in here. The bundled 2.1 release will have this included as well

this has been addressed in the 2.1.0 code.


make raju data "public"

@alexbaden raju says we can make all the CLARITY brains public, are they?
@kkutten1 can you make a ndviz dataview that has each of the brains and overlaid registrations?

@jovo See links in table here https://github.com/neurodata/internal/blob/master/misc/CLARITY_tokens.md

Note that some CLARITY images are not loading due to ndstore issue https://github.com/neurodata/ndstore/issues/333

that's great!
are they all windowed?
so now, you can make 1 dataview that has a project for each brain, including the overlays that exist for it?

Yup. We set a default window of (0,500) on most of them. The brains are too big for the histogram service to run on dsp. But, we can tweak the window later once we have things cloudified.
I will create the dataview and report back.

Here's the first example: http://viz.neurodata.io/project/Cocaine174
@kkutten1 what is the difference between the "annotation" channel and "labels" channel in the 	Cocaine174ARA token?
@kkutten1 / @jovo what should we do with Cocaine174Coronal? It isn't in the same dataspace, so it won't display with Cocaine174. Two separate vizprojects?

@alexbaden - thanks, something is weird in that link, in particular, there
is an annotation layer in the top left corner of the first image, that does
not seem "correct", not sure whether the data is wrong, or something else?
and yes, i guess 2 separate vizprojects within the same dataview would be
great!
On Mon, Aug 15, 2016 at 8:54 PM, Alex Baden<EMAIL_ADDRESS>wrote:

Here's the first example: http://viz.neurodata.io/project/Cocaine174
@kkutten1 https://github.com/kkutten1 what is the difference between
the "annotation" channel and "labels" channel in the Cocaine174ARA token?
@kkutten1 https://github.com/kkutten1 / @jovo https://github.com/jovo
what should we do with Cocaine174Coronal? It isn't in the same dataspace,
so it won't display with Cocaine174. Two separate vizprojects?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/neurodata/ndstore/issues/325#issuecomment-239973081,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACjcggVmSqI69bJr70CLXZBSmEL1hqSks5qgQpWgaJpZM4JZDNX
.

--
the glass is all full:  half water, half air.
neurodata.io, jovo calendar
https://calendar.google.com/calendar/embed?src=joshuav%40gmail.com&ctz=America/New_York

@alexbaden @jovo:  You should use the "labels" channel which is the newest version. The "annotation" is the old version and was affected by ndio issue #229.  I'll delete the old "annotation" channels.
I haven't uploaded the labels for the "Coronal" datasets since we only do the analysis on the original images.  So you don't have to worry about them (yet).

ok, thanks guys!
@kkutten1 will you make an issue for yourself to upload the coronal views?
we can discuss on monday, i know that allie wants them.
On Tue, Aug 16, 2016 at 2:17 PM, kkutten1<EMAIL_ADDRESS>wrote:

@alexbaden https://github.com/alexbaden @jovo https://github.com/jovo:
You should use the "labels" channel which is the newest version. The
"annotation" is the old version and was affected by ndio issue #229
https://github.com/neurodata/ndio/issues/229. I'll delete the old
"annotation" channels.
I haven't uploaded the labels for the "Coronal" datasets since we only do
the analysis on the original images. So you don't have to worry about them
(yet).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/neurodata/ndstore/issues/325#issuecomment-240190406,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACjcjWRuk8PZTf8_ZJhKorDHNcXPr_9ks5qgf7DgaJpZM4JZDNX
.

--
the glass is all full:  half water, half air.
neurodata.io, jovo calendar
https://calendar.google.com/calendar/embed?src=joshuav%40gmail.com&ctz=America/New_York

If only we had a LIMS system! :-D
Protip: if you put the date in the description field, it helps others track
what channels to use. I do that to keep from getting confused when I
revisit projects 6 months later. If you need help doing that, lemme know!
On Tue, Aug 16, 2016 at 14:36 joshua vogelstein<EMAIL_ADDRESS>wrote:

ok, thanks guys!
@kkutten1 will you make an issue for yourself to upload the coronal views?
we can discuss on monday, i know that allie wants them.
On Tue, Aug 16, 2016 at 2:17 PM, kkutten1<EMAIL_ADDRESS>wrote:

@alexbaden https://github.com/alexbaden @jovo <https://github.com/jovo
:
You should use the "labels" channel which is the newest version. The
"annotation" is the old version and was affected by ndio issue #229
https://github.com/neurodata/ndio/issues/229. I'll delete the old
"annotation" channels.
I haven't uploaded the labels for the "Coronal" datasets since we only do
the analysis on the original images. So you don't have to worry about
them
(yet).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/neurodata/ndstore/issues/325#issuecomment-240190406
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AACjcjWRuk8PZTf8_ZJhKorDHNcXPr_9ks5qgf7DgaJpZM4JZDNX
.

--
the glass is all full: half water, half air.
neurodata.io, jovo calendar
<
https://calendar.google.com/calendar/embed?src=joshuav%40gmail.com&ctz=America/New_York

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/neurodata/ndstore/issues/325#issuecomment-240196199,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFkzUnvzdZJ2tEK13N6X-2dirwE1Az4gks5qggMpgaJpZM4JZDNX
.

See: http://viz.neurodata.io/dataview/tomer15
It needs to be beautified with images and data descriptions for each clarity project. But, all the projects should be encapsulated.
There's an issue with Control239 (#341) but otherwise everything should be visible. The windowing isn't great, but until we either fix the mysql has gone away issue or move to S3 it's the best we can do.

this is great.
some caveats:

fear200: i get to acardona dataset
control258: starts at 0, is all black, the ARA annotation just covers up
the image layer?
control239: can't see image no matter what i do, maybe a windowing issue
control189: starts at 0
control182: starts at 0
cocaine178: can't turn off channels, has that feature been deprecated

maybe others start at zero too.  perhaps that is not a bad decision,
it was not consistent however, so i didn't know what to expect.
On Wed, Aug 17, 2016 at 4:19 PM, Alex Baden<EMAIL_ADDRESS>wrote:

See: http://viz.neurodata.io/dataview/tomer15
It needs to be beautified with images and data descriptions for each
clarity project. But, all the projects should be encapsulated.
There's an issue with Control239 (#341
https://github.com/neurodata/ndstore/issues/341) but otherwise
everything should be visible. The windowing isn't great, but until we
either fix the mysql has gone away issue or move to S3 it's the best we can
do.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/neurodata/ndstore/issues/325#issuecomment-240534565,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACjcmAy_Wk4ZIQS_qEw_b5DxQyTX_M2ks5qg2y4gaJpZM4JZDNX
.

--
the glass is all full:  half water, half air.
neurodata.io, jovo calendar
https://calendar.google.com/calendar/embed?src=joshuav%40gmail.com&ctz=America/New_York

Yeah, those are likely human errors. I'll go through and QC. My attempt was to start at slice 0, res 5, centered (which on most screens is everything). But maybe we should start in the center of the dataset where there's actually a lot of image data? Or maybe @kkutten1 has a better idea?

well, i think the next easiest default is the center of x,y,z.
for certain datasets, that will start us off somewhere black.
another option would be the center of mass as defined by the histograms,
eg, the middle of the "brightest" cube.
but i realize that is more elaborate....
On Fri, Aug 19, 2016 at 6:27 PM, Alex Baden<EMAIL_ADDRESS>wrote:

Yeah, those are likely human errors. I'll go through and QC. My attempt
was to start at slice 0, res 5, centered (which on most screens is
everything). But maybe we should start in the center of the dataset where
there's actually a lot of image data? Or maybe @kkutten1
https://github.com/kkutten1 has a better idea?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/neurodata/ndstore/issues/325#issuecomment-241150923,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACjcrJdOm2vLpCy1Z7WIZtt3dFaBJ1Cks5qhi3ZgaJpZM4JZDNX
.

--
the glass is all full:  half water, half air.
neurodata.io, jovo calendar
https://calendar.google.com/calendar/embed?src=joshuav%40gmail.com&ctz=America/New_York

Maybe we should add a metadata field for "CenterOfData"  point.

For DataViews, we set the default (for now). So, in this case, center x,y,z is pretty reasonable. NDV could calculate that automatically.
For ingested data being displayed on the fly, Randal and I discussed setting up an "anchor" system based on histograms. By looking at the standard deviations and picking the top 5 highest valued standard deviations, we thought we might be able to pick 5 spots where the data was interesting (particularly important for LM datasets like AT, I think). Something to discuss Monday.
The RAMON center on view tool should also help. You could load kasthuri11 with all the annotations and find the annotated slices just by picking a random RAMON object and centering the view.

[x] fear200: i get to acardona dataset
[ ] control258: starts at 0, is all black, the ARA annotation just covers up
the image layer?
[ ] control239: can't see image no matter what i do, maybe a windowing issue
[ ] control189: starts at 0
[ ] control182: starts at 0
[ ] cocaine178: can't turn off channels, has that feature been deprecated

Control239 issue is ongoing ( #341 )
Cocaine178 / turning off channel issue is a ndv bug ( https://github.com/neurodata/ndviz/issues/87 ). You can turn a channel off by setting it's opacity to 0, but the goal is to be able to remove a channel then re-add it layer from the controls toolbox.
I normalized everything to start at 0 except control258, which starts at 6 (the data has offset 6, for whatever reason). Everything started at 0 initially. Once some of the user experience ndviz bugs get fixed I can go back and deal with the creating dataviews page to make it easier to start at the center, etc of the dataset.


Behavior Roles

roles.json will define named roles, which are just collections of behaviors (with parameters).  actors can specify a roles: [x,y...] in actors.json to get all the behaviors of a role.
if an actor specifies a behavior already specified by a role, their specific behavior parameters should override the ones from the role (for any which conflict).

Roles only need to be looked at on initial actorCzar template actor creation -- the roles are created and added to the template actors.  Cloning new actors happens normally without consulting roles.
resources/roles/*.json is read to create the role structures for actorCzar on startup.


Claim redirect_uri on token request

Claim redirect_uri on token request
Add required claim redirect_uri on token request
Review

[X] Ensure your files are written following RST specs (not MD!)
[X] Italian version
[X] English version
[ ] Example files
[X] Ask for review

The update of the token request non normative example is required

Updated examples:
214123149b544c3dcf777bd9ce9a01fa5ac2fe83
4843b93e7da1aefda6221140f8e5f7deac2b60aa

According to https://openid.net/specs/openid-connect-core-1_0.html#TokenRequestValidation
we don't have the requirement of redirect_uri in the token request. I suggest to change this PR by saying that if present, the request_uri must ...


Build failed after package update: Type error: Property 'imageDimensions' does not exist on type 'Node'.

Hi there. It's probably just me but after I updated packages with yarn, I tried deploying it and got this issue below. Do you have any idea how can I solve this issue?
7:35:53 PM: ./components/NextImage.tsx:13:32
7:35:53 PM: Type error: Property 'imageDimensions' does not exist on type 'Node'.
7:35:53 PM:   11 |   const { node } = props
7:35:53 PM:   12 |   if (!node) return null
7:35:53 PM: > 13 |   const imageDimensions = node.imageDimensions as Dimensions
7:35:53 PM:      |                                ^
7:35:53 PM:   14 |   const { src, className: classArray } = node.properties as PropertyProps
7:35:53 PM:   15 |   const className = classArray?.join(' ')
7:35:53 PM:   16 |
https://postimg.cc/gallery/q0Dmyj9

Should be fixed with PR #111.

This was super fast. Thank you very much, love the fix! I can confirm it's working fine now


Add support for client ssl certificates

This adds a --client-cert option as seen in the pip command line so that you can use an alternate index which requires a client certificate for authentication.
I also got rid of two bits of empty line whitespace.

Thanks!

This is now released as part of pip-tools==1.1.6. Thanks for the patch!

Excellent. Thanks for pip-tools, it's been very helpful!


hydro-link navigation does not reset scroll position on new page

When navigating to a new page with hydro-link, the scroll position remains the same as it was on the previous page, requiring the user to scroll back up to the top of the page.
A better UX would be resetting the scroll position to the top of the new page.
Attached video example of issue.
https://github.com/hydrostack/hydro/assets/66449990/a791267e-d919-4bc1-bb37-a5d8bdb2b980

Thanks for the video example! It's now fixed in v0.8.5.


Unable to initialize skeema

I have a MySQL instance running locally with a handful of databases. Here's the configuration I normally connect with:

I'm trying to initialize with skeema, but unfortunately no luck:
$ skeema init -h <IP_ADDRESS> -d mysql
[mysql] 2020/11/09 15:17:10 packets.go:36: unexpected EOF
[mysql] 2020/11/09 15:17:10 connection.go:135: write unix ->/tmp/mysql.sock: write: broken pipe
2020-11-09 15:17:10 [ERROR] Cannot examine schemas on localhost:/tmp/mysql.sock:
                            Error querying information_schema.tables for schema
                            db_test2: invalid connection
[mysql] 2020/11/09 15:17:10 packets.go:122: closing bad idle connection: EOF
[mysql] 2020/11/09 15:17:10 connection.go:135: write unix ->/tmp/mysql.sock: write: broken pipe
[mysql] 2020/11/09 15:17:10 packets.go:122: closing bad idle connection: EOF
[mysql] 2020/11/09 15:17:10 connection.go:135: write unix ->/tmp/mysql.sock: write: broken pipe

I've tried quite a few variations including -o tls=preferred. I also followed this answer to verify that the socket is located in /tmp/mysql.sock.

Update: it turns out db_test2 the table had some problems. I dropped it and now it's working. I'm not sure what the problem with that table was. Feel free to close since I'm not blocked.

Glad you were able to get it working!
FWIW, a problematic table won't affect ability to connect. Most likely the problem was use of localhost, which in MySQL ecosystem tools always means "use a unix domain socket file". If you want a tcp/ip connection you must use <IP_ADDRESS>. More info in Skeema's host option doc, but this is also how the mysql client (and all stock tools including mysqldump etc) work as well.
Also no need to set -o tls=preferred in recent versions of Skeema, as this is enabled by default since v1.4.4.

Sorry, was going by the original issue text, I see you edited re: use of <IP_ADDRESS>. Out of curiosity what did the error output look like with <IP_ADDRESS>? The error text above is currently socket (localhost) specific so that can't be accurate :)

Ah sorry, I edited to match it with the screenshot. I tried both :-)
Unfortunately, I can't reproduce this anymore now that I removed the old tables. I presume it said <IP_ADDRESS>:/tmp/mysql.sock, but I can't be sure.

It must have been a different error entirely if using <IP_ADDRESS>, since in that case you're using TCP/IP, and /tmp/mysql.sock is not involved in any way. No worries though.


Control over logging

We need to have more control over logging:

Control of output IO (file, STDOUT, STDERR, etc..)
Control over format (clear text, Logger, etc..)
Control via levels, warn, error, fatal etc ..

@bararchy yes, Amethyst lacks of logging control. I'm working on it.

Can you use the AddHandler for Logging control in Amethyst ?


palp: fix runtime error introduced by #28029

After #28029 it is necessary to add "strictoverflow" to the disabled
hardening flags. That probably has something to do with the -O3 option
in palps makefile.
This commit also adds a test to check for this regression (as it only
occured at runtime).
Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

Failure on x86_64-darwin (full log)
Attempted: palp
Partial log (click to expand)
configuring
no configure script, doing nothing
building
Building PALP optimized for 6 dimensions
build flags: SHELL=/nix/store/q2wqq1k20v8kc3vckapqf5nws30brnni-bash-4.4-p23/bin/bash
gcc -O3 -g -W -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE   -c -o poly.o poly.c
/nix/store/q2wqq1k20v8kc3vckapqf5nws30brnni-bash-4.4-p23/bin/bash: gcc: command not found
make: *** [<builtin>: poly.o] Error 127
builder for '/nix/store/8ghmsr36s7jvv1smsmhvsrg1bw8cw87g-palp-6d-2.1.drv' failed with exit code 2
error: build of '/nix/store/8ghmsr36s7jvv1smsmhvsrg1bw8cw87g-palp-6d-2.1.drv' failed

Success on aarch64-linux (full log)
Attempted: palp
Partial log (click to expand)
shrinking /nix/store/y4sh34q6qsk8d4yk8h66dsvp6zx02m2g-palp-6d-2.1/bin/mori-6d.x
shrinking /nix/store/y4sh34q6qsk8d4yk8h66dsvp6zx02m2g-palp-6d-2.1/bin/nef-6d.x
shrinking /nix/store/y4sh34q6qsk8d4yk8h66dsvp6zx02m2g-palp-6d-2.1/bin/cws-6d.x
shrinking /nix/store/y4sh34q6qsk8d4yk8h66dsvp6zx02m2g-palp-6d-2.1/bin/class-6d.x
shrinking /nix/store/y4sh34q6qsk8d4yk8h66dsvp6zx02m2g-palp-6d-2.1/bin/poly-6d.x
strip is /nix/store/0pjsgkxz0rp5baycq5sp2s72lrr5q9sg-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/y4sh34q6qsk8d4yk8h66dsvp6zx02m2g-palp-6d-2.1/bin
patching script interpreter paths in /nix/store/y4sh34q6qsk8d4yk8h66dsvp6zx02m2g-palp-6d-2.1
checking for references to /build in /nix/store/y4sh34q6qsk8d4yk8h66dsvp6zx02m2g-palp-6d-2.1...
/nix/store/y4sh34q6qsk8d4yk8h66dsvp6zx02m2g-palp-6d-2.1

Success on x86_64-linux (full log)
Attempted: palp
Partial log (click to expand)
shrinking /nix/store/a5v63bw7wsk6r0db21dn58fc55cq0xa5-palp-6d-2.1/bin/class-6d.x
shrinking /nix/store/a5v63bw7wsk6r0db21dn58fc55cq0xa5-palp-6d-2.1/bin/poly-6d.x
shrinking /nix/store/a5v63bw7wsk6r0db21dn58fc55cq0xa5-palp-6d-2.1/bin/nef-6d.x
shrinking /nix/store/a5v63bw7wsk6r0db21dn58fc55cq0xa5-palp-6d-2.1/bin/mori-6d.x
shrinking /nix/store/a5v63bw7wsk6r0db21dn58fc55cq0xa5-palp-6d-2.1/bin/cws-6d.x
strip is /nix/store/4qvrxzxa535y8304mk195x50b6p9607d-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/a5v63bw7wsk6r0db21dn58fc55cq0xa5-palp-6d-2.1/bin
patching script interpreter paths in /nix/store/a5v63bw7wsk6r0db21dn58fc55cq0xa5-palp-6d-2.1
checking for references to /build in /nix/store/a5v63bw7wsk6r0db21dn58fc55cq0xa5-palp-6d-2.1...
/nix/store/a5v63bw7wsk6r0db21dn58fc55cq0xa5-palp-6d-2.1


Expose flags for max-pods-calculator to use a configurable max pods ceiling

Issue #, if available:
Description of changes:
Provide the ability to pass in the ceiling for max-pods instead of relying on the default values for low/high cpu count.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@overdrive3000 this is a pretty small change, can this be reviewed?

+1 for having a ceiling but also the option to, within the script, to provide an override.

@cartermckinnon would you please provide a reason why this was closed and why it's not a good change?

I'm just going through and closing stale PR's, this one needed a rebase. I'm not really against the change if you're still interested, but there's been no other engagement and I assume you've solved this on your end by now?


Always print invalid configuration data

Description:
There are many issues where the user has problems finding which configuration is causing errors.
Try to improve by always printing invalid configuration data make it easier for the user to track down where the key error is from.
Checklist:

[x] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.

With current state of PR, the additional print looks like this:
(Offending data: OrderedDict([('platform', 'mqtt'), ('name', 'Stair Lights'), ('names', 'adad'), ('state_topic', 'shellies/shellyswitch-9F5ED3/relay/0'), ('command_topic', 'shellies/shellyswitch-9F5ED3/relay/0/command'), ('qos', 2), ('payload_on', 'on'), ('payload_off', 'off'), ('optimistic', False), ('retain', False), ('schema', 'basic')]))
It could also be printed as JSON:
(Offending data: {"platform": "mqtt", "name": "Stair Lights", "names": "adad", "state_topic": "shellies/shellyswitch-9F5ED3/relay/0", "command_topic": "shellies/shellyswitch-9F5ED3/relay/0/command", "qos": 2, "payload_on": "on", "payload_off": "off", "optimistic": false, "retain": false, "schema": "basic"})
Or as yaml:
2019-03-12 17:50:46 WARNING (MainThread) [homeassistant.helpers.config_validation] Your configuration contains extra keys that the platform does not support.
Please remove [names].
Offending data:
platform: mqtt
name: Stair Lights
names: adad
state_topic: shellies/shellyswitch-9F5ED3/relay/0
command_topic: shellies/shellyswitch-9F5ED3/relay/0/command
qos: 2
payload_on: 'on'
payload_off: 'off'
optimistic: false
retain: false
schema: basic

So the downside of this approach is that we can end up printing sensitive data to the logs.

I think we can just prune the configuration dump to just name or in it's absence state_topic.

+1 about secrets issue
As for the output, ordereddict is not very readable, I would suggest using json.dumps

…something something config entries not storing secrets in configuration.yaml…

Is that issue only limited to platform discovery? Especially mqtt platform discovery?
Can we inject some metadata to payload in order to help people better debugging?
Some place before this line
https://github.com/home-assistant/home-assistant/blob/186b48e2eb610a929c2c471c1c289cce0f072cde/homeassistant/components/mqtt/discovery.py#L296-L297
Then print out the metadata latter in the HASchema warning routine, just like we injected __config_file__ and __line__ in yaml util.

Updated to:

Redact configuration data, except for a short whitelist: CONF_NAME, CONF_PLATFORM, .*_topic
Dump as json to improve readability

Can we inject some metadata to payload in order to help people better debugging?

@awarecan Maybe, but how can we be sure the added metadata does not clash with valid configuration variables?


MTV-1477 | Add DataVolume deletion when archiving

Issue:
When running the migration archive we do not delete the DataVolumes.
Fix:
Add deletion of the DataVolumes when running the archive and the VM migration failed.
At some cases the migration in the context is missing the migration ID so we can use the plan instead to find the DataVolume.
Fixes: https://issues.redhat.com/browse/MTV-1477

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.

Project coverage is 16.17%. Comparing base (a9915d8) to head (79a25e9).

Files with missing lines
Patch %
Lines

pkg/controller/plan/migration.go
0.00%
2 Missing :warning:

pkg/controller/plan/kubevirt.go
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1091      +/-   ##
==========================================
- Coverage   16.21%   16.17%   -0.04%
==========================================
  Files         112      112
  Lines       19874    19876       +2
==========================================
- Hits         3222     3215       -7
- Misses      16367    16374       +7
- Partials      285      287       +2

Flag
Coverage Δ

unittests
16.17% <0.00%> (-0.04%)
:arrow_down:

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.


Add support for Atlantic Calypso Connecté (io:AtlanticDomesticHotWaterProductionV2_CETHI_V4_IOComponent)

Hi, thanks for your work !

[x]  I have read the Readme, including the Advanced section regarding debugging.

Device information
"Calypso Connectée" is an Atlantic Water Heater compatible with IO homecontrol.
Full description is here : https://www.atlantic-electrique.fr/chauffe-eau-enr/les-chauffe-eau-thermodynamiques/calypso-connecte
With the cozytouch app we can choose the number of showers , Boost, Eco mode and set it to manual or auto:

Device details
Unsupported TaHoma device detected (io:AtlanticDomesticHotWaterProductionV2_CETHI_V4_IOComponent - WaterHeatingSystem - DomesticHotWaterProduction - io://XXXX-XXXX-XXXX/XXXXXXX#1)
{
	"commands": [{
		"commandName": "delayedStopIdentify",
		"nparams": 1
	}, {
		"commandName": "getName",
		"nparams": 0
	}, {
		"commandName": "identify",
		"nparams": 0
	}, {
		"commandName": "refreshManufacturerName",
		"nparams": 0
	}, {
		"commandName": "refreshTargetTemperature",
		"nparams": 0
	}, {
		"commandName": "refreshWaterConsumption",
		"nparams": 0
	}, {
		"commandName": "setComfortTargetTemperature",
		"nparams": 1
	}, {
		"commandName": "setDateTime",
		"nparams": 1
	}, {
		"commandName": "setEcoTargetTemperature",
		"nparams": 1
	}, {
		"commandName": "setFrostProtectionTargetTemperature",
		"nparams": 1
	}, {
		"commandName": "setName",
		"nparams": 1
	}, {
		"commandName": "setTargetTemperature",
		"nparams": 1
	}, {
		"commandName": "startIdentify",
		"nparams": 0
	}, {
		"commandName": "stopIdentify",
		"nparams": 0
	}, {
		"commandName": "wink",
		"nparams": 1
	}, {
		"commandName": "pairOneWayController",
		"nparams": 2
	}, {
		"commandName": "refreshAntiLegionellosis",
		"nparams": 0
	}, {
		"commandName": "refreshAwayModeDuration",
		"nparams": 0
	}, {
		"commandName": "refreshBoilerInstallationOption",
		"nparams": 0
	}, {
		"commandName": "refreshBoostModeDuration",
		"nparams": 0
	}, {
		"commandName": "refreshCurrentOperatingMode",
		"nparams": 0
	}, {
		"commandName": "refreshDHWCapacity",
		"nparams": 0
	}, {
		"commandName": "refreshDHWError",
		"nparams": 0
	}, {
		"commandName": "refreshDHWMode",
		"nparams": 0
	}, {
		"commandName": "refreshElectricalExtraManagement",
		"nparams": 0
	}, {
		"commandName": "refreshExtractionOption",
		"nparams": 0
	}, {
		"commandName": "refreshInstallation",
		"nparams": 0
	}, {
		"commandName": "refreshMiddleWaterTemperature",
		"nparams": 0
	}, {
		"commandName": "refreshOperatingModeCapabilities",
		"nparams": 0
	}, {
		"commandName": "refreshOperatingRange",
		"nparams": 0
	}, {
		"commandName": "refreshOperatingTime",
		"nparams": 0
	}, {
		"commandName": "refreshProgrammingSlots",
		"nparams": 0
	}, {
		"commandName": "refreshRateManagement",
		"nparams": 0
	}, {
		"commandName": "refreshSmartGridOption",
		"nparams": 0
	}, {
		"commandName": "setAntiLegionellosis",
		"nparams": 1
	}, {
		"commandName": "setAwayModeDuration",
		"nparams": 1
	}, {
		"commandName": "setBoilerInstallationOption",
		"nparams": 1
	}, {
		"commandName": "setBoostModeDuration",
		"nparams": 1
	}, {
		"commandName": "setCurrentOperatingMode",
		"nparams": 1
	}, {
		"commandName": "setDHWMode",
		"nparams": 1
	}, {
		"commandName": "setElectricalExtraManagement",
		"nparams": 1
	}, {
		"commandName": "setExtractionOption",
		"nparams": 1
	}, {
		"commandName": "setHaltedTargetTemperature",
		"nparams": 1
	}, {
		"commandName": "setInstallation",
		"nparams": 1
	}, {
		"commandName": "setOperatingRange",
		"nparams": 1
	}, {
		"commandName": "setProgrammingSlots",
		"nparams": 1
	}, {
		"commandName": "setRateManagement",
		"nparams": 1
	}, {
		"commandName": "setSmartGridOption",
		"nparams": 1
	}, {
		"commandName": "unpairAllOneWayControllers",
		"nparams": 0
	}, {
		"commandName": "unpairOneWayController",
		"nparams": 2
	}],
	"states": [{
		"type": "ContinuousState",
		"qualifiedName": "core:BoostModeDurationState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:ComfortTargetTemperatureState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:DHWPSoftwareVersionState"
	}, {
		"type": "DataState",
		"qualifiedName": "core:DateTimeState"
	}, {
		"values": ["good", "low", "normal", "verylow"],
		"type": "DiscreteState",
		"qualifiedName": "core:DiscreteRSSILevelState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:EcoTargetTemperatureState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:FrostProtectionTargetTemperatureState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:HaltedTargetTemperatureState"
	}, {
		"type": "DataState",
		"qualifiedName": "core:ManufacturerNameState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:MaximalShowerManualModeState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:MaximalTemperatureManualModeState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:MinimalShowerManualModeState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:MinimalTemperatureManualModeState"
	}, {
		"type": "DataState",
		"qualifiedName": "core:NameState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:NumberOfTankState"
	}, {
		"values": ["antifreeze", "auto", "away", "boost", "eco", "frostprotection", "manual", "max", "normal", "off", "on", "prog", "program"],
		"type": "DiscreteState",
		"qualifiedName": "core:OperatingModeState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:PriorityLockTimerState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:RSSILevelState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:SecuredPositionTemperatureState"
	}, {
		"values": ["available", "unavailable"],
		"type": "DiscreteState",
		"qualifiedName": "core:StatusState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:TargetTemperatureState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:TemperatureState"
	}, {
		"type": "DataState",
		"qualifiedName": "core:V40WaterVolumeEstimationState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:VersionState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "core:WaterConsumptionState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:AntiLegionellosisState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:AwayModeDurationState"
	}, {
		"values": ["boilerOptimising", "boilerPriority", "heatPumpOptimising", "heatPumpPriority"],
		"type": "DiscreteState",
		"qualifiedName": "io:BoilerInstallationOptionState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:DHWCapacityState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:DHWErrorState"
	}, {
		"values": ["autoMode", "manualEcoActive", "manualEcoInactive"],
		"type": "DiscreteState",
		"qualifiedName": "io:DHWModeState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:ElectricBoosterOperatingTimeState"
	}, {
		"values": ["auto", "deactive"],
		"type": "DiscreteState",
		"qualifiedName": "io:ElectricalExtraManagementState"
	}, {
		"values": ["fastExtractionSpeed", "lowExtractionSpeed", "noExtraction"],
		"type": "DiscreteState",
		"qualifiedName": "io:ExtractionOptionState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:HeatPumpOperatingTimeState"
	}, {
		"values": ["extraBoiler", "extraSolar", "onlyThermodynamic"],
		"type": "DiscreteState",
		"qualifiedName": "io:InstallationState"
	}, {
		"type": "ContinuousState",
		"qualifiedName": "io:MiddleWaterTemperatureState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:OperatingModeCapabilitiesState"
	}, {
		"values": ["pac24h_elec24h", "pacProg_elecProg"],
		"type": "DiscreteState",
		"qualifiedName": "io:OperatingRangeState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:PowerConsumptionFanState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:PowerHeatElectricalState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:PowerHeatPumpState"
	}, {
		"values": ["comfortLevel1", "comfortLevel2", "comfortLevel3", "comfortLevel4", "environmentProtection", "humanProtection", "userLevel1", "userLevel2"],
		"type": "DiscreteState",
		"qualifiedName": "io:PriorityLockLevelState"
	}, {
		"values": ["LSC", "SAAC", "SFC", "UPS", "externalGateway", "localUser", "myself", "rain", "security", "temperature", "timer", "user", "wind"],
		"type": "DiscreteState",
		"qualifiedName": "io:PriorityLockOriginatorState"
	}, {
		"type": "DataState",
		"qualifiedName": "io:ProgrammingSlotsState"
	}, {
		"values": ["forbidden", "no", "recommended", "unsuitable", "wanted"],
		"type": "DiscreteState",
		"qualifiedName": "io:RateManagementState"
	}, {
		"values": ["active", "deactive"],
		"type": "DiscreteState",
		"qualifiedName": "io:SmartGridOptionState"
	}],
	"dataProperties": [{
		"value": "500",
		"qualifiedName": "core:identifyInterval"
	}],
	"widgetName": "DomesticHotWaterProduction",
	"uiClass": "WaterHeatingSystem",
	"uiClassifiers": ["generator"],
	"qualifiedName": "io:AtlanticDomesticHotWaterProductionV2_CETHI_V4_IOComponent",
	"type": "ACTUATOR"
}

Thanks for reporting @Pol2Tls! What are the possibilities for the 'number of showers' option?
I am thinking about the best way to map this to the Home Assistant platform. @tetienne / @vlebourl any idea's? The only way to map this to climate currently would be to abuse the temperature, set to steps of 1 and limited to the possibilities of this integration. However this won't be nice in the front-end.

Thanks for reporting @Pol2Tls! What are the possibilities for the 'number of showers' option?
I am thinking about the best way to map this to the Home Assistant platform. @tetienne / @vlebourl any idea's? The only way to map this to climate currently would be to abuse the temperature, set to steps of 1 and limited to the possibilities of this integration. However this won't be nice in the front-end.

Thanks for taking the point @iMicknl
I can only choose 5 or 6 showers, but I think it has something to do with the capacity of the water heater as it could be 100, 150, 200 or 250 liters.

Thanks for taking the point @iMicknl
I can only choose 5 or 6 showers, but I think it has something to do with the capacity of the water heater as it could be 100, 150, 200 or 250 liters.

Could you give https://github.com/iMicknl/ha-tahoma/archive/feature/add_water_heater.zip a try? Unzip the package first and place the custom_components/tahoma folder in your custom_components folder.
I am not able to test this myself unfortunately. Please keep debug logging enabled and let me know the results.

Could you give https://github.com/iMicknl/ha-tahoma/archive/feature/add_water_heater.zip a try? Unzip the package first and place the custom_components/tahoma folder in your custom_components folder.
I am not able to test this myself unfortunately. Please keep debug logging enabled and let me know the results.

I tried to replace the whole tahoma but by doing this i'm not able to select the platform Somfy, Rexel or Cozytouch (the dropdown box is not here when you configure the integration) so my credentials are not recognized.
No success with just replacing the files with yours, just after the "official" installation. I still have :
2021-01-14 21:33:34 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected
(io:AtlanticDomesticHotWaterProductionV2_CETHI_V4_IOComponent - WaterHeatingSystem - DomesticHotWaterProduction - io://XXXXXXX#1)

I tried to replace the whole tahoma but by doing this i'm not able to select the platform Somfy, Rexel or Cozytouch (the dropdown box is not here when you configure the integration) so my credentials are not recognized.
No success with just replacing the files with yours, just after the "official" installation. I still have :
2021-01-14 21:33:34 DEBUG (MainThread) [custom_components.tahoma] Unsupported TaHoma device detected
(io:AtlanticDomesticHotWaterProductionV2_CETHI_V4_IOComponent - WaterHeatingSystem - DomesticHotWaterProduction - io://XXXXXXX#1)

@Pol2Tls oops, I forgot to add the latest changes to this version. Could you download the water heater version again? https://github.com/iMicknl/ha-tahoma/archive/feature/add_water_heater.zip

@Pol2Tls oops, I forgot to add the latest changes to this version. Could you download the water heater version again? https://github.com/iMicknl/ha-tahoma/archive/feature/add_water_heater.zip

@iMicknl I think the issue can be closed. I confirm that it's working. For those who wants to change the number of shower, you have to make a script, automation, ... and set the temperature to 50°C for 5 showers or to 53.5°C for 6 showers. Thank you again for your work !

@iMicknl I think the issue can be closed. I confirm that it's working. For those who wants to change the number of shower, you have to make a script, automation, ... and set the temperature to 50°C for 5 showers or to 53.5°C for 6 showers. Thank you again for your work !

@Pol2Tls great to hear! I will close this issue when support for Water Heaters has been merged into this integration.
Are the presets working and is away mode working? Any features you miss in the device implementation?

@Pol2Tls great to hear! I will close this issue when support for Water Heaters has been merged into this integration.
Are the presets working and is away mode working? Any features you miss in the device implementation?

Ok i understand.
Presets and away mode works and no missing functionalities, at least not those present in the cozytouch application !

Ok i understand.
Presets and away mode works and no missing functionalities, at least not those present in the cozytouch application !


'Contact Us' button does not link to the<EMAIL_ADDRESS>email address in Beta or Production www.argosdb.org

@Reeya123 is this included in your page update?

Contact button works now. Closing Issue


Make controllers before_filter free.

This helps in deriving from controllers, and specifying them {refer to exp-multitenant-support branch}, and adding filters the way user wants. At present, there is one before_filter can_administer?, and its too difficult to add any filter before it. One can do skip_before_filter can_administer? and redefine before_filter sequence, but user should be given more control w.r.t controllers.

@aksh93 can you pick this up?

@iffyuva Yeah, let me go through it.


Suggestion: Change or allow optional flag to accept inline comments for imports

An example in a migration source file is as follows (pre-gci run):
import (
	"github.com/golang-migrate/migrate/v4"
	_ "github.com/golang-migrate/migrate/v4/database/postgres" // database migration drivers
	_ "github.com/golang-migrate/migrate/v4/source/file"       // database migration drivers
	_ "github.com/lib/pq"                                      // database drivers
	"github.com/pkg/errors"
)

When _ a import, it requires a comment, for good reason. However, gci dictates that the comments should be above the imports, however that isn't adequate when changed simply to the following:
import (
	"github.com/golang-migrate/migrate/v4"
	// database migration drivers
	_ "github.com/golang-migrate/migrate/v4/database/postgres"
	// database migration drivers
	_ "github.com/golang-migrate/migrate/v4/source/file"
	// database drivers
	_ "github.com/lib/pq"
	"github.com/pkg/errors"
)

This isn't what gci wants either. Fixing it to be gci compliant:
import (
	"github.com/golang-migrate/migrate/v4"

	// database migration drivers
	_ "github.com/golang-migrate/migrate/v4/database/postgres"

	// database migration drivers
	_ "github.com/golang-migrate/migrate/v4/source/file"

	// database drivers
	_ "github.com/lib/pq"
	"github.com/pkg/errors"
)

Perhaps it's just personal opinion, but when there are multiple comments required in the import block, it looks a lot more readable and concise to allow for them to be inline. If a comment requires a new line above them, it indicates to me that the following block of imports all pertain to that comment and not just the one directly below it (e.g. ".../pkg/errors" isn't a database driver).
I would love to hear opinions on this for one way or another.

Now we have new option for it, you can try latest version if you want, thanks.


Service Description - FAQ not up to date: "Is the service code open-source?"

Currently the FAQ states the following
`
Is the service code open-source?
Code used by the service will be released as an open-source sample later 2019. Provisioning uses the PnP Provisioning Engine, which is already open-sourced and available using code or PowerShell.
`
The source code is already available. It would be great to provide a direct link to this repository and the source code.

Thanks for your feedback. Changes have been applied and will go live in the upcoming hours.


Default file name from gen_coords is just called None if -o not given

Describe the bug
If no -o argument is given to gen_coords, the output file is just called None.
Command line arguments
Provide all polyply calls and arguments needed to reproduce the issue:
polyply gen_coords -p topol.top -name name

Expected behavior
There should probably be an output file name of something like coords.gro, rather than just a file called None
Happy to do the PR myself if there's consensus on the default output name!

solved in #312


Decide on a naming convention for ensembles

I have been using names of the form:
NC20C_plans.json
NC20U_plans.json
NC20L_plans.json
The prefixes (e.g., NC20C) seem fine. The plans seems redundant perhaps, in a world in which there's a share point directory (in a repo) that just has ensembles and/or called ensembles.
I'm thinking that maybe we want to add a date and/or time stamp (or a digest of one or something) to the name, so that directory could hold multiple ensembles for a state & plan type combo (e.g., if we fix issues, generate different sizes, etc.).

2024-10-29_NC20C_plans.json
2024-10-29_NC20C_scores.csv

I realized that we left something off that should be added to the metadata and the name: a seed offset.
For repeatability, the starting seed for ReCom is a function of the numbe TO BE CONTINUED
NC20C_2024-10-29_plans.json
NC20C_2024-10-29_log.txt
NC20C_2024-10-29_scores.csv
NC20C_2024-10-29_scores_metadata.json


Update go-iscsi-helper and backupstore in vendor

Also handle sys version conflict and compile error
with snapBlockSize->backupBlockSize in pkg/replica/backup.go
Two commits by @derekbit were cherry-picked over to fix compilation errors as well.
The motivation for this PR is to incorporate the original 'containerd-shim' process namespace fix in go-iscsi-helper into the longhorn-engine 1.5.x build and in the pending 1.5.4 release.  The full discussion for that fix is contained in https://github.com/longhorn/longhorn/issues/5693
Please let me know if I'm following the correct process here, thanks!

@andrewd-zededa Don't we need to introduce this to the master, then backport to 1.5/1.4?

@innobead master and v1.6.0-dev already works in this case and has moved to a different method of looking up the namespace directory where iscsid is searched for (https://github.com/longhorn/longhorn-engine/blob/master/vendor/github.com/longhorn/go-iscsi-helper/util/process.go) instead of docker/containerd/containerd-shim.  I tried backporting that first and if I remember correctly it began to pull in more changes so I switched to this instead which was quicker.  It looks like this original fix was just never fully incorporated into the build.
Would you like me to instead revisit backporting the new iscsid method instead?

Just bumping this to keep it open, I'm working on it now

@andrewd-zededa sorry for the late review. Can you help rebase this PR due to conflicts first? Thanks.

@innobead yes I'll rebase

Hi @andrewd-zededa
Sorry for the late reply, I am here to help you proceed the progress.
So for backporting the update in go-iscsi-helper to upcoming v1.5.4 or v1.5.x
What you have to do is

fork the repo  longhorn/longhorn-engine
check out upstream v1.5.x

this is the head of v1.5.x, we will cut release from this branch every time we are releasing v1.5.x, for example,  upcoming v1.5.4

create your branch from v1.5.x
update the vendor of go-iscsi-helper

go get github.com/longhorn/go-iscsi-helper@${LATEST_COMMIT_OF_MASTER} (go-iscsi-helper is common for all longhorn version)
go mod tidy
go mod vendor

Create a PR to merge your branch to upstream v1.5.x

This the flow of how we update the vendor in previous version for the patch version
That is, in this PR, if you have to fix the conflicts or modify some /pkg/... code, that means something wrong.
Can you help me to close this PR and follow the above steps to recreate the PR again?
Thanks!

Ok, sounds like I need to drop my existing commits and redo, I'll try to get that completed this afternoon

@ChanYiLin I haven't pushed it up yet, but I just created a fresh branch created based off v1.5.x, did a go get of the latest master commit of go-iscsi-helper and it pulls in a number of go.mod updates, in addition to hitting a build issue which I have not yet looked into.  I'll try the slightly older release in my original pr next.
diff --git a/go.mod b/go.mod
index b7299e27..d60674af 100644
--- a/go.mod
+++ b/go.mod
@@ -6,21 +6,21 @@ require (
 	github.com/docker/go-units v0.3.3
 	github.com/gofrs/flock v0.8.1
 	github.com/golang/protobuf v1.5.3
-	github.com/google/uuid v1.3.0
+	github.com/google/uuid v1.3.1
 	github.com/gorilla/handlers v1.5.1
 	github.com/gorilla/mux v1.8.0
 	github.com/longhorn/backupstore v0.0.0-20231025000449-5316e8b5320d
-	github.com/longhorn/go-iscsi-helper v0.0.0-20230802055236-4ec8edae3fad
+	github.com/longhorn/go-iscsi-helper v0.0.0-20240104130856-4bd63e2b676a
 	github.com/longhorn/sparse-tools v0.0.0-20230408015858-c849def39d3c
 	github.com/moby/moby v23.0.2+incompatible
 	github.com/pkg/errors v0.9.1
 	github.com/rancher/go-fibmap v0.0.0-20160418233256-5fc9f8c1ed47
 	github.com/rancher/go-rancher v0.1.1-0.20190307222549-9756097e5e4c
-	github.com/sirupsen/logrus v1.9.0
+	github.com/sirupsen/logrus v1.9.3
 	github.com/urfave/cli v1.22.5
-	golang.org/x/net v0.8.0
-	golang.org/x/sys v0.7.0
-	google.golang.org/grpc v1.53.0
+	golang.org/x/net v0.16.0
+	golang.org/x/sys v0.13.0
+	google.golang.org/grpc v1.60.1
 	gopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c
 	gopkg.in/cheggaaa/pb.v2 v2.0.0-20190301131520-f907f6f5dd81
 )
@@ -31,7 +31,7 @@ require (
 	github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v0.3.0 // indirect
 	github.com/aws/aws-sdk-go v1.34.2 // indirect
 	github.com/beorn7/perks v1.0.1 // indirect
-	github.com/c9s/goprocinfo v0.0.0-20190309065803-0b2ad9ac246b // indirect
+	github.com/c9s/goprocinfo v0.0.0-20210130143923-c95fcf8c64a8 // indirect
 	github.com/cespare/xxhash/v2 v2.2.0 // indirect
 	github.com/cpuguy83/go-md2man/v2 v2.0.0-20190314233015-f79a8a8ca69d // indirect
 	github.com/fatih/color v1.7.0 // indirect
@@ -39,29 +39,34 @@ require (
 	github.com/gammazero/deque v0.2.1 // indirect
 	github.com/gammazero/workerpool v1.1.3 // indirect
 	github.com/go-logr/logr v1.2.4 // indirect
+	github.com/go-ole/go-ole v1.2.6 // indirect
 	github.com/gorilla/context v1.1.1 // indirect
 	github.com/gorilla/websocket v1.4.2 // indirect
 	github.com/jmespath/go-jmespath v0.3.0 // indirect
 	github.com/kr/pretty v0.3.1 // indirect
 	github.com/kr/text v0.2.0 // indirect
-	github.com/longhorn/nsfilelock v0.0.0-20200723175406-fa7c83ad0003 // indirect
+	github.com/longhorn/go-common-libs v0.0.0-20240103081802-3993c5908447 // indirect
 	github.com/mattn/go-colorable v0.1.4 // indirect
 	github.com/mattn/go-runewidth v0.0.5-0.20181218000649-703b5e6b11ae // indirect
 	github.com/matttproud/golang_protobuf_extensions v1.0.4 // indirect
+	github.com/mitchellh/go-ps v1.0.0 // indirect
 	github.com/moby/sys/mountinfo v0.6.2 // indirect
 	github.com/pierrec/lz4/v4 v4.1.17 // indirect
+	github.com/power-devops/perfstat v0.0.0-20210106213030-5aafc221ea8c // indirect
 	github.com/prometheus/client_golang v1.15.0 // indirect
 	github.com/prometheus/client_model v0.3.0 // indirect
 	github.com/prometheus/common v0.42.0 // indirect
 	github.com/prometheus/procfs v0.9.0 // indirect
 	github.com/rogpeppe/go-internal v1.9.0 // indirect
 	github.com/russross/blackfriday/v2 v2.0.1 // indirect
+	github.com/shirou/gopsutil/v3 v3.23.7 // indirect
 	github.com/shurcooL/sanitized_anchor_name v1.0.0 // indirect
 	github.com/slok/goresilience v0.2.0 // indirect
+	github.com/yusufpapurcu/wmi v1.2.3 // indirect
 	go.uber.org/multierr v1.11.0 // indirect
 	golang.org/x/text v0.13.0 // indirect
-	google.golang.org/genproto v0.0.0-20230110181048-76db0878b65f // indirect
-	google.golang.org/protobuf v1.30.0 // indirect
+	google.golang.org/genproto/googleapis/rpc v0.0.0-20231002182017-d307bd883b97 // indirect
+	google.golang.org/protobuf v1.31.0 // indirect
 	gopkg.in/cheggaaa/pb.v1 v1.0.28 // indirect
 	gotest.tools/v3 v3.4.0 // indirect
 	k8s.io/apimachinery v0.27.1 // indirect

.../binarylog/grpc_binarylog_v1/binarylog.pb.go | 4 +- .../grpc/health/grpc_health_v1/health.pb.go | 4 +- .../grpc/health/grpc_health_v1/health_grpc.pb.go | 37 +- .../grpc_reflection_v1alpha/reflection.pb.go | 87 +- .../grpc_reflection_v1alpha/reflection_grpc.pb.go | 10 +- .../protobuf/types/descriptorpb/descriptor.pb.go | 1011 ++++--- .../protobuf/types/known/anypb/any.pb.go | 70 +- .../types/known/timestamppb/timestamp.pb.go | 2 +-
GRPC generated code is not up to date
FATA[0051] exit status 1
make: *** [Makefile:11: ci] Error 1

@andrewd-zededa  I think there are too many changes in go-common-lib/go-iscsi-helper these two packages
And some of the changes we didn't modify longhorn-engine v1.5.x to fit the changes
Might need some time to take a look.
For these kind of common lib, when we did some changes
We might need to backport it in related repos as well, otherwise, when we want to update the library in this older version, we will need to solve many unrelated updates.
cc @innobead @c3y1huang @derekbit

Hi @andrewd-zededa
I will take care of the backport from here, the issue might become too tricky
Here is the context.
longhorn-engine depends on go-iscsi-helper.
We move some go-iscsi-helper functions to go-common-lib later on in v1.6.x, however, we didn't update the changes in longhorn-engine v1.5.x
That is, the go-iscsi-helper is too old in longhorn-engine v1.5.x, and when we update it to the latest version, we have to manually update some code base to meet the changes of  go-iscsi-helper/go-common-lib
cc @longhorn/dev


Velox on GPU on CI

Description
Hello,
Velox is experimenting with accelerating parts of the workload on GPU with Wave [1]. When trying to build it locally, I've run into some compilation issues with the latest CUDA toolchain (12.3.1). The support is still experimental, but I've great interest in this work and would like to support it however I can. I propose to add building and possibly testing on CI to ensure that this doesn't regress in the future.
The building part is fairly easy as it would consist in 1. adding the CUDA toolchain to the CircleCI docker image [2] and 2. add a configuration that compiles with VELOX_ENABLE_GPU=ON [3].
The testing part is possible on CircleCI with their GPU runners [4]. For GitHub Actions, access to GPU is currently on a sign-up basis [5] with a waitlist.
There is also the question of how should contributors build locally when they don't have a GPU available. @assignUser has suggested [6] to add VELOX_BUILD_CUDA_TESTS or VELOX_RUN_CUDA_TESTS cmake variable.
Current contributions:

[x] https://github.com/facebookincubator/velox/pull/8828
[x] https://github.com/facebookincubator/velox/pull/8829

Cc: @assignUser @kgpai @majetideepak @Yuhta @mbasmanova

The testing part is possible on CircleCI with their GPU runners [4]. For GitHub Actions, access to GPU is currently on a sign-up basis [5] with a waitlist.

We are slowly moving away from CircleCI into GitHub Actions, so we will need to check how we could get GPU runners there.

There are ways to add self-hosted cuda capable runners to a repo but those require a bunch of infra work (aws k8s cluster etc.) so not sure if that effort (and cost) is justified for  (correct me if I am wrong) a currently niche, experimental feature.
If there is enough interest to do this a good first step might be to ask the meta OSS team if they have a way to get access to the wait listed runners?

Oh, I did not see @kgpai's comment in the PR, looks like we have something available already!

We have 4-core-ubuntu-gpu-t4 as GPU supported runners in GHA

@luhenry It would be nice to create a README or similar for folks who'd like to get started on Wave.
I also found these resources very helpful:
A short introductory blog post: https://developer.nvidia.com/blog/even-easier-introduction-cuda/
CS344: Intro to Parallel Programming course (well structured, entertaining and easy to follow, my 7 year old daughter particularly enjoyed the story about digging a hole to China): https://developer.nvidia.com/udacity-cs344-intro-parallel-programming

I believe this is resolved now.


Junit Integration

This PR consists of two related changes:

Retrieve Junit test results from LAVA. This requires a new API in the lava-api crate. Parse the test results to check if there were any errors, and produce the correct test status for Gitlab, rather than reporting all runs that complete as successful.
Update to a new Gitlab runner API. This brings with it significant improvements support for Junit integration, such that the pipeline view in gitlab is correctly populated. It also means that users are once again in control of which files are uploaded.

They are together because they fall together under the support for the upload_multiple_artifacts gitlab runner feature tag. That tag requires significant updates to the API, and to the gitlab-runner crate, and the actual point of that feature flag is to provide a much deeper integration for junit test reports than is possible without it.

This PR may break some existing pipelines. The problem is that we always uploaded whatever files we had before, ignoring what the user asked for, and existing pipelines may not ask for the correct artifacts.

I could make this two or three PRs, as needed:

A PR for fixing the exit status
A PR for updating to the new artifact model
And maybe even a PR depending on both previous PRs, to support junit reports.

This PR is draft pending merge of:

[x] gitlab-runner-rs!17
[x] lava-api!24.

bors r+


Integrate serving public key? + Caddy docker example

Thanks for the great work, got it running from Docker with Caddy webserver for SSL termination and serving the public key during setup.
The documentation was a bit difficult to follow, given the integration with Nginx and home assistant. On my setup placed the Tesla HTTP Proxy on a VPS, and HA running on another docker instance on a RPI at home.
Is there any reason the flask server is not directly serving the public key for setup purposes? If the flask server would handle this task, the flow would be easier and less dependent on what software is used as webserver or ssl reverse proxy? The end user doesn't has to bother with the path ".well-known/appspecific/com.tesla.3p.public-key.pem" of that certificate as it is created internally already and can be served directly as well?
Ended up using this Caddy configuration, that allows serving the tasks provided by Flask, as well as the public key, and the Tesla API in one go:
tesla.fqdn.com {
	@teslaapi {
		path /api/*
	}

	@publickey path /.well-known/appspecific/com.tesla.3p.public-key.pem

	@flask {
		 not {
			path /.well-known/appspecific/com.tesla.3p.public-key.pem
                	path /api/*
		}
	}

  	reverse_proxy @teslaapi teslaproxy:443 {
		transport http {
			tls_insecure_skip_verify
		}
	}

	handle @publickey {
		rewrite * com.tesla.3p.public-key.pem
	        root /caddy/teslaproxy
		file_server
	}

	handle @flask {
		reverse_proxy teslaproxy:8099
	}
}

For reference, the docker-compose used, setting the "teslaproxy" hostname used in the Caddy configration, and the shared directory with the certificate.
teslaproxy:
    container_name: teslaproxy
    image: "iainbullock/tesla_http_proxy"
    restart: unless-stopped
    volumes:
      - /media/Docker/teslaproxy:/data:Z
      - /media/Docker/teslaproxy/nginx:/share/nginx:Z
      - /media/Docker/teslaproxy/ha:/share/home-assistant:Z

  caddy:
    image: caddy:latest
    container_name: caddy
    restart: unless-stopped
    ports:
      - 443:443
      - 80:80
    volumes:
      - $PWD/Caddyfile:/etc/caddy/Caddyfile:Z
      - /media/Docker/teslaproxy/nginx:/caddy/teslaproxy:Z

Additionally it would make configuration easier if there is just 1 port to expose, that does both the Flask things for setup, and the Tesla API at /api/* directly I suppose? The above Caddy configuration can handle this, but the documentation of Nginx is using two different configs for setup and exposing the Tesla API?
For others that would use this setup:

Start caddy, ensure to set DOMAIN, CLIENT_ID, CLIENT_SECRET, REGION either in docker environment or in /media/Docker/teslaproxy/config.sh
Follow the five steps as served in the flask application, you can do them all from 1 to 5 without restarting.
Copy the "selfsigned.pem" from "/media/Docker/teslaproxy/ha" to your home assistant config folder.
The necessary information for Tesla custom integration proxy option are printed on the console. Fill in the refresh token, set the url to point to the caddy proxy, and enter the client ID + path to the selfsigned.pem

Thanks for the detailed write up, this is very useful for anyone contemplating a setup simialr to yours.
Regarding the question: 'Is there any reason the flask server is not directly serving the public key for setup purposes'. It's one for the author of the parent project, as my project takes his work and makes it into a docker version, without changing how it works. Maybe he preferred a 'grown up' webserver for the service that is exposed to the internet.
https://github.com/llamafilm/tesla-http-proxy-addon

Ok thanks for the clarifications.
I created a discussion on the source project to handle this. https://github.com/llamafilm/tesla-http-proxy-addon/discussions/150.
Will hereby close this one.


Question regarding open source

Happy to hear the app is open source!
I have a few questions for when the app will be generally available:

Will it be possible to use the app compiled from sources, or does it need some kind of private information entered first (API keys etc.)?
Will the app be available in other app stores, such as F-droid and the Amazon App Store? Not every Belgian uses the Play Store.

The app requires to use the proprietary google API's for covid exposure notification. I guess you will only be able to run it on phones which have the Google services enables (and thus play store).

Hmm, I guess so. Tried to compile it yesterday and was greeted with errors about not having the exposure API. So I guess no.
It's really sad to see such an important app be proprietary and, from a developer perspective, not having the ability to have reproducible builds. This might seem nit-picky, but for me, that's a reason not to fully trust it.

@editicalu The build is reproducible, what @roidelapluie said is that you can't just run it on AOSP Android (<> Google Android). Which errors did you get? Did you install all the required Android SDKs?

I meant: can I compile it, put it on my phone and use it in the production environment as if I downloaded it from the Play Store.
I opened the project in Android Studio, pressed run and that's all I tried so far. Android SDK updated to latest versions.

@editicalu, I just cloned the repo on commit https://github.com/covid-be-app/cwa-app-android/commit/e37a616330fdd5902253dac1c5389732b6ee23f6, compiled with 0 errors. Installed it also on physical device with no issues.
Using Android Studio 4.0.1
Build #AI-193.69<IP_ADDRESS>26763, built on June 25, 2020

@editicalu Nobody can help you if you don't tell us which errors you are getting

@sdebruyn  Installing works, but I get errors when running the app (sometimes when I get to the exposure screen, sometimes only when I activate it). Errors around the Exposure API not being available. Similar issues seem to indicate that it is not possible, because I'm not whitelisted as developer.
I didn't ask for help. My question to the developers is if there was a way to use it from source as is, but the comments on the German app seem to indicate that this is not possible due to Google blocking API access to non-whitelisted apps/signatures/...

So the build is reproducible and this issue is a duplicate of #85?

Well, no, because there's no way to know whether the version in the Play Store is the exact same one that you'd get if you build the app from scratch, because apparently we cannot use the app from scratch in production.
I'd like to compare it to the pacman (package manager) approach, where you could get and use the build instructions (in the form of PKGBUILD files). You'd get the exact same binary as the original packager (or you'd notice).

You do get the same binary. What is the difference?

I think to fully use the app from source, since it requires some touchy functionalities from Google API, you'd need to generate a signed APK, with your own keystore.

Only the apk signed for the play store works with the google exposure api as the keystore certificate has to be whitelisted by google.

@leroynicolasalexi Thank you for your response. That summarizes my questions.
To summarize for anyone reading this in the future:
Due to the Google API rejecting unofficial keystores and their signatures, it will not be possible to compile from source. This makes it unable to be pushed to F-Droid. I do understand the reasons for doing that (namely avoid people abusing the system by e.g. sending out false information), it does make compiling and using the project impossible.
That said, it might work with Micro-G, as said in #85.

Well, it's not impossible, you 'just' need to opt in for a [Google Play signed APK] (https://support.google.com/googleplay/android-developer/answer/7384423?hl=en)


[Feature] End to End Testing

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
Compose several end-to-end test cases to verify the BanyanDB server(Banyand) works fine with SkyWalking ecosystem.

Collect tracing data: demo application + Java agent + OAP + Banyand
Collect logs: filebeat + OAP + Banyand
Collect metrics: oap self observability + OAP + Banyand

The cases should include individual scenarios and a combination of the above.
Use case
No response
Related issues
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

https://blog.csdn.net/oqqford/article/details/125637528?spm=1001.2014.3001.5502
Here's a demo trace capture app I wrote. How can I accomplish this issue? I can do more to help。

@hanahmily What is this issue about? The e2e is already involved in e2e tests in the main repo.
Search banyandb in https://github.com/apache/skywalking/blob/master/.github/workflows/skywalking.yaml.
Could you explain a little more?

I found this issue from [WeOpen Star]

I know that. I mean this is test related issue. I am not sure what is the context of this your sharing

https://blog.csdn.net/oqqford/article/details/125637528?spm=1001.2014.3001.5502
Here's a demo trace capture app I wrote. How can I accomplish this issue? I can do more to help。

"Collect tracing data: demo application + Java agent + OAP + Banyand." So I shared the sample program I wrote

I suppose this goal has already been accomplished in the main repo.

@hanahmily What is this issue about? The e2e is already involved in e2e tests in the main repo. Search banyandb in https://github.com/apache/skywalking/blob/master/.github/workflows/skywalking.yaml.
Could you explain a little more?

The second and the third ones are still missing as I understand

That is SkyWalking project does, not ask you to implement trace.
I think you are better to knowwhat are skywalking and banyandb, also what is end to end testing. Mostly important, how we are using GitHub action and skywalking-infra-e2e today.


Old policy?

Great work! I'm also working on a PPO implementation, but I completely miss where π and π_old come from. Here you store the policy output when actually acting on the environment - if you stored this and retrieved it from the memory, wouldn't it be the same as calculating them again in a batch like you do here?
You then construct a new policy, and calculate the new policy output here. I see that it is different because you load weights that have been updated by other processes, but in a synchronous setting, the weights wouldn't have been updated, and hence the policy outputs wouldn't be any different?

Thanks! Yes, this is why with the synchronous updates, workers have to wait for the update in order to continue the loop of policy updates. . Otherwise your right, the new policy would not be updated. The trick is to find a way to send a message allowing workers to go back working when the update is done.

Sorry, still missing where π and π_old come from for calculating the update.
π0 -> sync workers collect data -> update via A * π1/π0 ? -> send π1 (π2?) to workers, repeat

As for how to stop the workers running until an update is over, you can use locks, as I did for my async code. Create a lock around something that tells you which stage (collecting data/updating) you are at, and don't run the other stage until you (acquire the lock) and find that the previous stage is over.

Main issue I see is that your replay memory contains off-policy data (from 10^6 rollouts ago even though the you only process 10^4 rollouts at a time https://github.com/alexis-jacq/Pytorch-DPPO/blob/master/train.py#L48-L49). You should either change replay memory size to 10^4 or add off-policy correction method such as importance sampling.
Another issue is that each of your (4) train threads performs the size 10^4 batch update asynchronously with respect to each other. This normally is not an issue when each update consists of 1 rollout, but could become a problematic in your implementation in which the updates are larger because they are based on batches of 10^4 rollouts.
My suggestion to remedy second issue would be to use a single Replay Memory that is shared across all train threads, and then perform a single update (maybe on a gpu) (and with all the forward rollouts paused during this update) once that single shared replay memory contains number_of_rollouts=batch_size

@Kaixhin, if I understand correctly the paper, p_old is the policy before the updates and remains unchanged during the updates. And p_new is the policy after all the last updates. So you have something more like:
p_0 -> workers collect data -> set p_old=p_0 -> 1st update with A * p_0/p_old , get p_1 -> 2nd update with A * p_1/p_old , get p_2, repeat

Create a lock around something that tells you which stage (collecting data/updating) you are at, and don't run the other stage until you (acquire the lock) and find that the previous stage is over.
Thanks, that's a good idea, I have seen this clock timer in some other codes, I will try something based on it.

@ethancaballero, the 10^6 is a typo, thanks! You are right, it should be exactly the batchsize, otherwise we loose the advantage of parallelism. The idea of a shared Replayer looks great, but it would be one batch loss computation at the time, while the advantage of parallelism is doing n simultaneous batch loss computations.

I suspected that π_old was simply bootstrapped at the first round of updates, so thanks for confirming! Instead of keeping it fixed, what do you think of the following (which only differs from what you wrote on the 3rd update)?
π_0 -> workers collect data -> set π_old=π_0 ->
1st update with A * π_0/π_old , get π_1 ->
2nd update with A * π_1/π_0 , get π_2, ->
3rd update with A * π_2/π_1 , get π_3, ->
repeat

I'm working on the original/non-distributed version of PPO, or at least the version in OpenAI's blog, and basing it on my A2C code. Still thinking of a way to do some nice batched updates for standard A2C, but once I get that done I'll turn my attention to PPO.


fix fix potential heap-use-after-free issue and cache issue

Proposed changes

When file meta cache is disabled (by setting max_external_file_meta_cache_num=0 in be.conf),
the parquet's meta info is owned by parquet reader and will be released when calling reader->close().
But the underlying file reader of this parquet reader will be released after reader->close(),
this may causing heap-use-after-free bug because some part of meta info may be referenced by file reader.
This PR fix it by making sure that meta info is released after file reader released.

Add modification time for file meta cache in BE, to avoid parquet read error like:
Failed to deserialize parquet page header
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run clickbench

LGTM

LGTM, but what can I do to temporarily solve this problem ：invalid magic number in parquet file


Having issue with extension

Hello,
having this erorr on macOS:
[error] Error: Illegal argument: line must be non-negative
at v (/Applications/Visual Studio

Hi, did you find a solution to this problem? I have an idea of what might cause it but haven't had a chance to reproduce it yet.

I had found that when you open folder where is file it works , but if you open folder , where is folder with the file it cannot work

I am having issues how do I test?

Hey, are you having the same issue? line must be non-negative


Index Pattern Incorrect

Hi guys I have builded this plugin for kibana 5.6 version, but when I'm trying to get it work, I can see that the index patterns are showing as id's and not by their names, and when I'm trying to execute it I'm getting an Elasticsearch error. Also the javascript section is not showing

This was fixed with the updates for 5.6.0


app.js revision

app.js should probably be splitted into multiple files, it grown up too big right now.

Closing due to https://github.com/icmx/xv/commit/fecd1f232f278d9835f186592facda765a6dcb45 and https://github.com/icmx/xv/commit/0cf3470c6b399da7547455ea12010f2425a592b6.


Error traceback

Hello i'm getting this error when i launch the file "runbot" can you help me ?

Use review, not the old version.  https://github.com/SexualRhinoceros/MusicBot/wiki/Installation-guide-for-Windows-7-and-up#2a-download-musicbot


How to provide API token?

Neat project!  This may be obvious or I missed it in the README but how do you provide the chat gpt API token? I don't see an argument or env bar or something similar.

Hey @justinwiley!  It's just the same envvar that the openai library uses: OPENAI_API_KEY (and OPENAI_API_ORG).  I think the library should even give an error saying that it needs to be set if it's missing?  If not then we should add that.


Ability to run JavaScript code to test the response when simple tests are not enough

Forked off from issue #3

Have you considered a mechanism to drop down to javascript asserts/tests when basic ones do not suffice?

For security reasons, the code will have to be run in a sandbox that does not have access to VS Code APIs. We cannot use a simple eval(testCode), which has the potential to inject malicious code into your VS Code and/or the CLI runner. This needs to be thought through and crafted correctly.
In the meantime, the eval approach (with tons of warnings and disclaimers) may be a temporary solution. We can have settings in VS Code that will disable this by default and you will be forced to read the warnings and disclaimers when turning it on.


kubectl exec fails (through ALB)

Rancher Versions:
Server: Rancher v1.3.1
healthcheck: v0.2.0
ipsec: v0.0.2
network-services: v0.0.08
scheduler: v0.3.0
kubernetes:v1.5.1-rancher1-8
Docker Version: 1.12.3
OS and where are the hosts located? (cloud, bare metal, etc): AWS
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB) single node rancher
Environment Type: (Cattle/Kubernetes/Swarm/Mesos) Kubernetes
Steps to Reproduce:

Kubernetes environment
Add AWS hosts in VPC
Create Application Load Balancer for ports 80/443 that terminates SSL and routes to our single Rancher instance on port 8080)
Download kubectl config from https://something.com/env/1a220/kubernetes/kubectl
Run kubectl exec -it container_name bash

Results:
Error from server (BadRequest): Upgrade request required

kubectl logs appears to also not work (may be related?)
(kubectl get, etc. work fine)
Expected:
kubectl exec works
See also:

#7425 (for Rancher HA/traefik)

Here's screenshots of our load balancer config in case that's helpful:

I think we can rule out ALB being the problem. I was able to reproduce it by using curl directly inside of my rancher server:
> ssh rancher.example.com

rancher@ip-10-0-1-31:~$ curl --user 7...:W... 'http://localhost/r/projects/1a220/kubernetes/api/v1/namespaces/exp/pods/echo-text/exec?command=bash&container=echo-text&stderr=true&stdout=true'
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "Upgrade request required",
  "reason": "BadRequest",
  "code": 400
}

Actually, I may have spoken too soon. After reading here, I tried curl -H "Connection: upgrade" -H "Upgrade: SPDY/3.1" and now there's no Upgrade request required error but it just hangs there. What is it supposed to do when you curl it?

@TylerRick This will be fixed shortly (less than a week).  Quite unfortunately ALB does not support SPDY (well, it's deprecated, so really it's unfortunate that k8s uses it).  As such the only option will be to use ELB, which is much more difficult than ALB because it requires setting up proxy protocol.  This is why we dropped ELB support to begin with is that most users struggle to configure proxy protocol properly.  Unfortunately we missed this use case where kubectl exec needs it.  Right now kubectl exec will only work if you are running Rancher single node (non-HA) and you hit port 8080 directly.
We need to reenable our proxy protocol support, so this will be in 1.3.3.

Thanks for the update, @ibuildthecloud! :+1:

Validated the fix on Rancher v1.2.3, and v1.3.3, here are the steps:

Run Rancher HA setup with ELB
The ELB should be configured to use proxy protocol

$ aws elb create-load-balancer-policy --load-balancer-name my-elb --policy-name myorg-ProxyProtocol-policy --policy-type-name ProxyProtocolPolicyType --policy-attributes AttributeName=ProxyProtocol,AttributeValue=true
$ aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-elb --instance-port 81 --policy-names myorg-ProxyProtocol-policy
$ aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-elb --instance-port 444 --policy-names myorg-ProxyProtocol-policy
$ aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-elb --instance-port 8080 --policy-names myorg-ProxyProtocol-policy

Register few agents with Rancher
Install kubernetes stack
Deploy few pods and services
Test kubectl exec and logs from remote kubectl client

Both kubectl exec and logs work from remote client.

Thanks, @galal-hussein. Just to clarify, this issue was for the non-HA setup. (#7425 was the one for HA)
We tried upgrading and setting up ELB as described and it did seem to resolve the "Upgrade request required" error but kubectl exec still doesn't work for us (it just hangs).

I solved the issue, see my article
https://dev.to/aws-builders/kubectl-execport-forward-with-aws-alb-and-nginx-ingress-controller-4fn0