v3.2.0-rc.0 compatability

Guys, I'm concerned about breaking backwards compatability in v3.2.0-rc.0 release.
You should avoid doing breaking changes in minor version update (see http://semver.org/).
You could avoid breaking changes in #7488 just having error in the method interface and always returning nil. As you did in 3.0.x BTW :)
And #7305 does not break API at all, but just some logic. So it's safe to keep it in the release as is.
Having "Breaking changes" notice in the release notes is awesome, but let's keep the compatible API? So that users could rely on semver policy and use proper wildcards in their vendoring tools.

It changes the underlying behavior of that API. The logic change can be done without interfering with the API so code still compiles, but the error handling contract will be very different. The choice is either fail it statically at compile time or wait until something depending on the old behavior fails dynamically at runtime.

Nothing will fail in the runtime here, because you still close the keepalive channel in case of the error.

I totally agree that in case of having a failed build you will immediately pay attention to it and read the notice then. But what about the semver? Either you follow it or not...
I understand you feelings here - you want to have the code clean, you want to notify 100% of users with this change and you don't want to increment the major, cause having etcdv3 server and 4.x.x version is clumsy. But I don't think people really catched the bug with KeepAlive like me in #7472. So either they don't care about error handling or they just don't care about this situation :)
It's your choice how to maintain you library, but in my opinion we should respect the semver agreement. Because otherwise it brings pain to users and spoils your Carma :))

OK, I'm kicking this back to 4.0.0 to comply with semver.

Oh... I'm really waiting for fixing this KeepAlive thing, so I was happy you've done it :)
4.0.0 looks like forever :(
Maybe there is any way to keep it in 3.2 with the compatability fixes? Let's ask your teammates' opinion?

The contract has to change for what you're asking. It would be compile compatible, but the /semantics/ are still different. This breaks the spirit of semver. Sorry.

Looking forward for 4.0.0 then :)


⚠ 366.ru has degraded performance

In 7a679f6, 366.ru (https://366.ru) experienced degraded performance:

HTTP code: 200
Response time: 2879 ms

Resolved: 366.ru performance has improved in a254cf9.


Remove Jackson warning when starting the UC server locally

When I start the UC server locally with bin/start-uc-server, I get a Jackson warning, see the following screenshot:

Would be nice if there wasn't any warning.

I think you might've not updated to the latest main? We merged #94 yesterday that should've resolved this.

@vikrantpuppala - I am up to date with the latest main commit and still seeing this.

Are you sure about this? I see another issue, the art in the image above has "vv0.1.0-SNAPSHOT" which was also fixed to "v0.1.0-SNAPSHOT"

I am unable to reproduce the issue, there are no warnings on 6c2a9c3. I did reproduce it on 474d676 before the fix was applied with #94.
Please go to the latest commit and run the following:
$ build/sbt clean
$ bin/start-uc-server

If you ran the server on an older version you might still be using stale jars. bin/start-uc-server uses the existing jars if the project has already been compiled.

Thanks @filipovskid - that worked!


[bug] Import QR opens the camera

Version
Checklist:

[x] I am not using Home Assistant. Or: a developer has told me to come here.
[x] I have checked the troubleshooting section and my problem is not described there.
[x] I have read the changelog and my problem is not mentioned there.

Build/Run method

[ ] Docker
[ ] PKG
[x] Snap package
[ ] Manually built (git clone - yarn install - yarn run build )

zwavejs2mqtt: <IP_ADDRESS>4d303
zwave-js: 8.7.5
Describe the bug
Import QR on a smart phone opens up the camera instead of the file explorer.
To Reproduce
Steps to reproduce the behavior:

Go to Manage nodes
Click on Inclusion
Scroll down to Smart Start and select «Import».
Camera opens and not the file explorer

Expected behavior
Should open the phone (default) file explorer so you can pick from the gallery.

@jmgiaever Are you on an iphone or an android phone? From iphone you should be able to press on bottom left bottom to add it from library

Android 😅

Is the icon you're referring to here? I've tried to click the "drop here" icon, but that's what opening up the camera app.

I am an iPhone user, SCAN doesn't do anything, IMPORT and then click Drop.... Turns camera on and takes a photo (not properly labeled but I like this).
**** HOWEVER! - It fails to recognize/find a QR/DSK code.

Scan should work as you like the import feature. The camera should open. Have you maybe denied access to the camera?
The first time you've visited the scan section it (z2m in your browser) will ask for permission to use your camera. If you deny access it will not load.

Please give a try to https://github.com/zwave-js/zwavejs2mqtt/pull/1956
BTW Are you running it using https?

Me or @doug62 ? I'm running it behind a reverse proxy. Z2m itself is http, but I always request it over the reverse proxy since I've blocked every other ports on this device.

It was for @doug62
BTW the PR attached should fix all the issues expect the **** HOWEVER! - It fails to recognize/find a QR/DSK code. , I have no clue about that as all my qr codes are correctly parsed. I would need the qr code to test

@robertsLando I attached the file to an earlier bug #1958 but attached here as well, I have tried 5 different codes, my phone parses them but zwavejs2mqtt doesn't.  Thanks for your awesome work, I'm hankering to contribute when i get more up to speed w HA

@doug62 In fact I'm able to add it when scanning from camera but not when adding it as an image (weird). Let me investigate

@doug62 I have a feel the problem is that the QR code is too big in the image and the detect fails, just to make a double check could you try to make a new picture of it?

Just tried to use this (simply reduced browser zoom and made a screenshot and it is working:


How to deal with tasks after an unexpected service interruption

I want to know that when the task in the service is still running, the service is interrupted, how to ensure that the task runs until it is completed. How did you do it? Thank you!

Here's a good test:
Here's our helloworld.py greeting service, slightly modified so it takes between 1-2 minutes to complete
from nameko.rpc import rpc
import numpy as np
import time

class GreetingService:
	name = "greeting_service"

	@rpc
	def hello(self):
		start = time.time()
		time.sleep(np.random.randint(60,120))
		duration = time.time() - start
		return duration

We run the service with:
nameko run helloworld

And in a separate shell, lets invoke a call:
from nameko.standalone.rpc import ClusterRpcProxy
import time

config = {
    'AMQP_URI': 'amqp://guest:guest@localhost:5672'  # out of the box Rabbit config. Change as you see fit
}

with ClusterRpcProxy(config) as cluster_rpc:
    print(cluster_rpc.greeting_service.hello())

Once that call is invoked, go to your MQ management console and look at it for a sec. Notice that there's a message that gets placed in the queue, but it will not disappear until your function completes while the service is running. Wait 30s after firing the rpc call above and then shut down your greeting service that was running with Ctrl+Z. You'll notice after leaving your calling application for 5 minutes that there's no response, even though the message should have been picked up and should have been processed. But since the service died, the consumer ack never happened - the task never reported back to MQ that it was complete and thus, it never really did complete from the client's perspective. I'm interested to try this with something more concrete like a file write or a db operation, but I don't have time for that right now. Might also be interesting to try with call_async and see what happens.
 If you gently shut it down, I think the default behavior is to wait for the current active tasks to finish before shutting down, so you'll get a result from the call above, but if your service crashes you should expect the tasks running on it to crash as well

TL;DR - no guarantee that your task will complete if your service crashes. If you gently shut it down, I think the default behavior is to wait for the current active tasks to finish before shutting down, so you'll get a result from the call above, but if your service crashes you should expect the tasks running on it to crash as well

This is correct. If your service crashes, the unack'd request message will be reclaimed by the broker when it detects that the consumer is gone. It's then available to be picked up by another consumer, and the RPC client will happily wait until it receives a response message from somewhere. There are currently no limits to the number of times that a message may be requeued.
The messaging guarantees are "at least once" delivery -- your request message will be processed at least once, maybe more than once. You should aim to make your RPC entrypoints idempotent because of this.
If you gracefully shut down a service, it will wait until it's finished processing all the current workers, and the request messages will be ack'd in that case.
There's no difference in behaviour between sync and async RPC except that the client doesn't wait for the result message.


Font Size is not getting adjusting/changing on orientation change

at runtime on device orientation change font size should be change accordingly

Never mind it works 👌😄


fixed #13

In this pull request I´ve fixed the non-standard-conform data package profile.
fixed #13

Thanks for closing the pull request. Is #13 now resolved or does it continue to be open?


New version: LiErHeXun.Quicker version <IP_ADDRESS>

Created by 🥟 Dumplings in workflow run #6214.

Log
Updated: <IP_ADDRESS> → <IP_ADDRESS>
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request

Microsoft Reviewers: Open in CodeFlow

/azp run


Overlay connected position strategy should have an option to push the contents into the screen.

Bug, feature request, or proposal:
Overlay-connected-position strategy should have an option to push the contents into the screen.
Overlay-connected-position strategy allows setting something like "put the overlay element horizontally centered", so you could have something like this:
 ________________
|                |
|           o    |
|           ^    |
|          ███   |
|________________|

This is nice, but there is one problem, what if the element is in a position where no matter where you put the overlay contents, they will always be rendered off the screen?
 ________________
|                |
|           o    |
|           ^    |
|    ████████████|██
|________________|

What is the expected behavior?
Given an option in the connected-position-strategy, push the element into the screen by the largest amount of pixels that it goes off-screen. For example:

If it goes 20px off screen to the right but there are 50px available to the left before going off screen again, then push it by 20px.
If it goes 10px off screen to the right but there are only 5px available to the left before going off screen again, then push it by 5px.
If it goes 10px off screen to the right but there are is already 20px offscreen to the left, then do nothing.

 ________________
|                |
|           o    |
|           ^    |
| ███████████████|
|________________|

What is the current behavior?
The position strategy gets the amount of pixels that it goes off-screen, and subtracts them from the overlay contents to get the "visible pixels", then multiplies HxW to get the area and selects the position with the largest visible area from the list of fallback positions even if it renders off screen.
What is the use-case or motivation for changing an existing behavior?
Tooltip-like components that render on hover or focus will render after the element. Normally this is not an issue on desktops or tablets because there is a lot of space, but on tiny phones like an iPhone4, this doesn't look good.
Note that we can't use tooltips because we want buttons, links, and other stuff.

I've been working on it.


Updated versioning and updated nav/sidebar changes

Fixes https://github.com/OXRS-IO/OXRS-IO-WEBSITE/pull/53#issuecomment-1173152957 @austinscreations
Should be good for dynamic paths now.
And just makes sure everything is standardized in the sidebar/nav to work correctly with dynamic paths.

can confirm working
@MakerDockio or @sumnerboy12 could consider merging


Error on install

When running on v3.0.0-beta.24  composer require edalzell/anvil
I get the following
In BaseController.php line 11:

  syntax error, unexpected 'Forge' (T_STRING), expecting function (T_FUNCTION
  ) or const (T_CONST)

Script @php artisan package:discover --ansi handling the post-autoload-dump event returned with error code 1

Ah you're on PHP < 7.4 @sotrustmtg ?

I'm only going to support PHP 7.4+ right now.


Support for  element

As Typemill is very good for documentation I miss a way to style keyboard shotcuts like ⌘⇧4 in the text. HTML offers the kbd tag but markdown has no equivalent for that.
As the editor does not allow HTML what about a setting to allow some simple tags? Github does also allow <kbd>.

I will check it for next release

Not on the roadmap right now, but could probably be added with shortcodes.


[Shooting, Multi-agent] Agent moves after/while getting hit by a bullet

The agent's health becomes zero but it still makes the move, please check multi_agent_done_check testcase to see the behavior.

@devrz45 This is known behaviour and it does not affect the game in any way.


Replaced sheadawson/silverstripe-linkable with gorriecoe/silverstripe…

This PR replaces sheadawson/silverstripe-linkable with gorriecoe/silverstripe-linkable.
This because of the fact that sheadawson/silverstripe-linkable is not maintained anymore (and incompatible with SS4.11+).
Should be considered as API change, so I will release this in v2.0.0 release.
Test steps;

[x] Create an grid page
[x] Create an "Map" Grid element
[x] Save it and create an marker (don't care if the Maps API is not working, because we only test the link field in here)
[x] Save the maker and create an link for the marker
[ ] Verify that the link is saved correctly

Right now I've not created an migration script for this change.
If its possible to create an separated migration script for this module with not-that-much effort, I will create a separate PR that can be released as v2.0.1 :smile: .

For the type "url" and "page on this site" and option "open in a new window" it opens it still in the same window

For the type "url" and "page on this site" and option "open in a new window" it opens it still in the same window

Checked out https://github.com/thewebmen/silverstripe-elemental-maps/blob/master/templates/TheWebmen/ElementalMaps/Model/ElementalMaps.ss and found out that the "open in new window" option of Linkable is never implemented.
Created an new issue; https://github.com/thewebmen/silverstripe-elemental-maps/issues/5, can get fixed later in an 2.x release :smile:


LlamaCpp, add n_gqa flag to support Llama2

To load and run llama 2 70b models n_gqa must be set to 8. For other models it can be unset (and defaults to 1). Tested with both llama 2 70b (set) and llama 2 13b (unset) and both work.
Maintainer guess @hwchase17
Fixes https://github.com/langchain-ai/langchain/issues/8486

lookin at llama python bindings, comments suggest this may be a temporary variable?
in general to allow for more flexibility without needing to constantly update parameters, should we introduce a model_kwargs attribute for arbitrary additional params to pass into the client? similar to OpenAI llm https://github.com/langchain-ai/langchain/blob/13ccf202de6678ecd5572027a2182e96da750247/libs/langchain/langchain/llms/openai.py#L164

We could do it that way if you prefer.
I wouldn't be surprised if it ends up being auto-detected by llama.cpp at some point, but for now it's a manual flag.


Add updated font and button size

Related Issue
[Cite any related issue(s) this pull request addresses. If none, simply state “None”]
Fixes:  #(issue no.)
Description
[Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.]

Type of PR

[ ] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
[Attach any relevant screenshots or videos demonstrating the changes. Make sure to attach before & after screenshots in your PR.]
Checklist:

[x] I have made this change from my own.
[ ] I have taken help from some online resources.
[x] My code follows the style guidelines of this project.
[ ] I have performed a self-review of my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[ ] My changes generate no new warnings.
[ ] I have tested the changes thoroughly before submitting this pull request.
[ ] I have provided relevant issue numbers and screenshots after making the changes.

increase the size in light mode too .

increase the size of button in light mode too .

done the changes as you asked


Don't create fileset for IgnoredOutputModules

Fixes #6395
It's needed for the resubmission workflows (rereco recoveries) where we set IgnoredOutputModules in the schema to avoid producing/staging some tiers. Without this patch, JobAccountant fails jobs since the expected outputmodules is != than the one returned in the Report.pkl.
I tested these changes on the agent side and seems to be working ok. I still want to test in a clean environment though

Feel free to merge it as soon as it passes jenkins.


visualize

It's a great job.
I'm curious how to visualize structural maps like Figure 1 in the paper.
Thanks！

It's a great job.
I'm curious how to visualize structural maps like Figure 1 in the paper.
Thanks！

Hello, have you solved this problem?  Can you tell me how you visualized the structure map?  All the best!


[Feature] unify da representations of different datasets

Describe the feature
Unify different dialogue act representation of different datasets to:
(intent, domain, slot, value)
Expected behavior
change dialogue act usage in (multiwoz, camrest) X (nlu, nlg, dst, policy)
Additional context
Add any other context about the feature here.

file to change:

tatk/util

[x] multiwoz/lexicalize.py
[x] multiwoz/state.py
[x] camrest/lexicalize.py
[x] camrest/state.py


Pretrained model without Rendered people

Hello, thank you for sharing this amazing work.
HDNet (trained by 34,000 RenderedPeople images and 100,000 Tiktok images) performance is very impressive compared to previous works :)
After reading the paper, I became curious about the performance of HDNet trained without RenderedPeople and with fewer RenderedPeople
Do you have pre-trained HDNet of those cases? or the results?

Hi. Thanks a lot for your message. This work is trained in a semi-supervised framework therefore having the RenderPeople data is important. We unfortunately don't have the pre-trained model for a smaller amount of RenderPeople.

Thanks!


Update ceton status web page

The 1st part is good, but the second won't always work  If the PCI is the first device and there is only one, it is fine.  Say it is the second device, then the tuner instance is going to be 7, assuming the first device is a six tuner unit.  If we pull in tunerstatus we can check if ceton_pcie and in that case use ['streamurl'] in the call to devinuse

Good point! Glad you're keeping me honest 😜.
OK, I see it getting a bit more funky then. I say that because ...

As we loop through the tuners, need to "break" between devices ... NP, but,
Need to know if each device is internal or external. They may be in either order ... right? I'm assuming you have checked that somewhere? And ... what if there are 2 PCIe cards? I guess we just increment that when switching tuners, and finding the second PCIe?

BTW, it seems what I had stored in stream_info (in Ceton status), you have also added that, e.g. streamurl. Should I remove stream_info?
Thanks!

I got on a roll and just kept adding code, not noticing what you had there in stream_info.  I am not married to streamurl.  I picked the name based on the immediate use case.
I set ceton_pcie to true if it is an internal.  We could make that an int and set it to zero for ethernet and increment a special counter for each HW device found.  Which is on my mental roadmap.  Although I wonder how long I will be the only person with multiple devices actually in use.    The code that tests the ceton_pcie  should not need major changes, if any.
This points one advantage of pre-generating the streamurl.  We do not really have to care about the parent device, we can refer to the keys ceton_pcie, streamurl, seton_tuner in tunerstatus to learn most (all?) we need about the device.  In fact I think I could randomize the instance so that the devices tuners were not grouped together and the code would still function.  It would be pointless to do that, but it means that the tunerstatus dict has most (all?) the critical keys.

I got on a roll and just kept adding code, not noticing what you had there in stream_info. I am not married to streamurl. I picked the name based on the immediate use case.

No worries! I'm fine removing stream_info, just wanted to make sure I wouldn't mess you up.

The code that tests the ceton_pcie should not need major changes, if any.

Agreed!

This points one advantage of pre-generating the streamurl. We do not really have to care about the parent device, we can refer to the keys ceton_pcie, streamurl, seton_tuner in tunerstatus to learn most (all?) we need about the device. In fact I think I could randomize the instance so that the devices tuners were not grouped together and the code would still function. It would be pointless to do that, but it means that the tunerstatus dict has most (all?) the critical keys.

Agreed! Do you want me to update the tuner status table using these? streamurl would work ... for the logic also regarding Direct (want me to make that Hardware?) and RTP. Like you say, if it's handled / sequenced, just use that!

And I missed point 1.  We could add a new device dict that has keys for device type, tuner count, IP etc.  Rough it
tuner = 0
for i in len(device{}):
%code to get env details%
for x in devvice[i][tuner_count]:
tuner += 1
%existing code that displays each tuner%
And to you latest post, if you can use those keys, go for it.  I think they might be enough which is why I had not added the device dict.  If they are not we can use the idea at the start of this post.

WFM! Let's see if I can get the status showing properly based on those ... then that is clean, and behind the scenes we can renumber, etc. => it will just ripple up to the status, hopefully unchanged.

Actually ... 😜. OK to keep stream_info? Because ... fHDHR passes back stream_args (with stream_info) inside it, to,
    def close_stream(self, instance, stream_args):
        closetuner = stream_args["stream_info"]["tuner"]
        self.plugin_utils.logger.noob('Closing Ceton tuner %s (fHDHR tuner %s)' % (closetuner, instance))
        self.startstop_ceton_tuner(closetuner, 0)
        return

Will still use the new vars for the status html, but rather than messing with the information passed back to close_stream. OK?

I rechecked and yes keep it.  It was never a dup.  It serves a function needed by the core, and tunerstatus has way more internal details that the core does not need or even use.  They are complimentary.

Agreed! Think I found an easy change here to get it all working - and even fixes a latent bug that was waiting in the shadows for us ... LOL. Now, if I can get my daughter off the TV, I can check it 😆

BTW, another fix I'll push, if OK with you - this one bit me earlier as well 😄.
In get_ceton_tuner_status, this needs to change slightly,
            if (transport == "STOPPED") and (not hwinuse):
                self.plugin_utils.logger.info('Selected Ceton tuner#: %s' % instance)
                # And, clear tunerstatus (just in case external client stopped using it)
                self.tunerstatus[str(instance)]['status'] =  "Inactive"

changes to,
            if (transport == "STOPPED") and (not hwinuse):
                self.plugin_utils.logger.info('Selected Ceton tuner#: %s' % instance)
                # And, clear tunerstatus (just in case external client stopped using it)
                self.tunerstatus[str(instance)] =  { "status": "Inactive" }

If not, once Inactive, you still see this,
"0": {
"ceton_ip": "<IP_ADDRESS>",
"ceton_pcie": true,
"ceton_tuner": "0",
"port": 8000,
"status": "Inactive",
"stream_args": {
"accessed": "http://<IP_ADDRESS>:5006/api/tuners?method=stream&channel=4c309db8-6bd7-4853-82b1-1730309e4c55&origin=ceton",
"base_url": "http://<IP_ADDRESS>:5006/",
"buffer_size": 3,
"bytes_per_read": 1152000,
"channel": "593",
"channel_callsign": "Golf HD",
"channel_name": "Golf HD",
"client": "<IP_ADDRESS>",
"client_id": "173178a5-6085-4a85-b4c5-725f9a9754b5",
"content_type": "video/mpeg",
"duration": 0,
"method": "ffmpeg",
"origin_name": "ceton",
"origin_quality": null,
"stream_info": {
"headers": null,
"tuner": "0",
"url": "/dev/ceton/ctn91xx_mpeg0_0"
},
"stream_restore_attempts": 3,
"transcode_quality": "working-3.14",
"true_content_type": "video/mpeg",
"tuner_number": null
},
"streamurl": "/dev/ceton/ctn91xx_mpeg0_0"
},

Make sense? And OK with you?

Hmmm ... actually, you have other info stored there now. Perhaps just remove stream_args?

That was a change made on purpose.  It took me 30 minutes to notice the syntax and kept wondering why my dict was empty after init ran.  Setting status to inactive and stream_args to {} would be a happy medium

It took me 30 minutes to notice the syntax and kept wondering why my dict was empty after init ran.

LOL - ya, I can believe that. Sorry!

Setting status to inactive and stream_args to {} would be a happy medium

Agreed! Done 👍

OK, now you threw me a curveball - I guess turnabout is fair play ... LOL.
I was modifying devinuse in __init__.py, and it wasn't working - then I noticed you made a "copy" in ceton_html.py. No wonder my changes didn't work ... LOL. Like above - you married to the one in ceton_html.py? I admit, I'd like to keep it in one place, avoid fixing findings twice.
Thoughts?
Thanks!

Never mind - I may have done that ... LOL. But I may need to find a better way now, to deal with the "shared" state. Give me just a bit digging.

Devices is just a list view of the ceton_ip
Since the config entry tuners is required by the core and cannot be a list I added device_tuners
Example-
[ceton]
ceton_ip = <IP_ADDRESS>,<IP_ADDRESS>  // in priority order
device_tuners = 6,4                                // same order as ceton_ip, device1 has 6 tuners, device2 has 4
tuners = 10                        // Sum of device_tuners

That will work, perfect - thanks!
One more dumb question, but I'm not seeing it 😞. You use tuner_tmp_count, but it seems to me that it's just equal to i, no? Or are you shifting it from device to device? I'm thinking you are, but not seeing it (yet).

tuner_tmp_count represents the total tuners.  At the start of each device i is reset to zero and increments for each device tuner.  tuner_tmp_count also increments for each device tuner but does not get reset, so using the example above:
The last tuner in the 1st device:  tuner_tmp_count = 5, i =5
The first tuner in the 2nd device: tuner_tmp_count = 6, i =0
Hope that makes sense

If you want to see it in action, you can add the same IP multiple times in the ceton_ip list and build a large tunerstatus dict to see the format.  You cannot obviously use the extra tuners.
Which reminds me I should add an error case if the number of devices does not match the number of device_tuners entries

Makes complete sense, thanks! The zip had me a bit confused, got it now. And ... adding about 2 lines, and status can also include the ceton_device, not just tuner ...
"0": {
"ceton_device": "0",
"ceton_ip": "<IP_ADDRESS>",
"ceton_pcie": true,
"ceton_tuner": "0",
"port": 8000,
"status": "Inactive",
"stream_args": {},
"streamurl": "/dev/ceton/ctn91xx_mpeg0_0"
},

Can just pull this, to use in the status table (and other items if needed).

ARRGH! Was pulling my hair out with jinja2. But finally. Thoughts?

Thanks!

The zip was a suggestion from @deathbybandaid.  It worked, so I did not dig further...
I actually was OK with the tuners being lumped together.  What I though folks would want is to see the first six rows for each device (setup/temp/type/etc).

The zip was a suggestion from @deathbybandaid. It worked, so I did not dig further...

And it works great! I just had to figure it out 😆

I actually was OK with the tuners being lumped together. What I though folks would want is to see the first six rows for each device (setup/temp/type/etc).

Sorry, you lost me there. Are you referring to the picture I pasted above? They are lumped by device, tuners within that device. Not what you were thinking?

I do not feel strongly about grouping the tuners, so what you have is useful.
Lets look at the very first row in the table-
Setup  |    Success
That can either be the plugin status, of the 1st device status.  Let's say plugin, no change need.
The second row:
Temperature  |  64.9 C
That is clearly the first device, do we care about the 2nd+  I think so.
So my quandary has been do we have a separate table like it was for each device, or do we try to add dynamically sized columns for the device status rows:
Temperature        |  64.9 C | 80.5C
Hardware Type    |  PCI      | Ethernet
etc...
And keep the tuners in a common section.  A separate table for each device is easier to code, the dynamic columns seems like a PITA, but visually more appealing...

Ahh, gotcha! And never thought of that. What if that top section were also "inside" the Device? That would be pretty easy, just where to loop over.
Thoughts?

Yeah, that is what I describe as the first option, one table per device.  In fact that would be a fine first step even if we eventually want to move to a single table view

Got it - give me just a bit 🤣

Thoughts? I put a blank line between => I could make it 1 table, but kinda liked the separation. Can be removed though. And yes, I have 1 device, so they look similar ... LOL

Like the space and that works perfect.  Commit when you are ready and I will merge

Should be there now (commit updated). Please try it out - of course I can only fake out 2 devices 😆
Thanks!

FYI, also fixed a latent issue I noticed - hard coded /dev path ... using streamurl now!

Thanks! Please let me know how it works for your (real) 2-device setup. Hopefully all smooth 😄

Will be trying on Monday.  Spent time reviewing my array health and it is Ok, but I am out of spares and of course the new ones are coming via the slowest method possible.  I doubt that the plugin was involved, but would rather be running all possible spares before the next attempt...

NP, fully understand! And no panic. Hopefully your array is all happy again soon. If there are (plugin) issues, we'll get them fixed of course.
And, as soon as this got merged - I found one, thanks Mr. Murphy ... LOL. I only found it when I went back to the single device case, the issue line of code is,
            origin_status_dict = {"Devices": len(self.fhdhr.config.dict["ceton"]["device_tuners"])}

len() works fine for > 1 tuners, but with 1 ... self.fhdhr.config.dict["ceton"]["device_tuners"] is an int. Minor, but I just need to fix it. My preferred approach is a list with a length of 1, so consistent then.
Thanks!

OK, one liner fix 🤣
        device_tuners = self.device_tuners
        if not isinstance(device_tuners, list):
            device_tuners = [device_tuners]
            self.config_dict["device_tuners"] = device_tuners

Added the last line. Not sure why to "fix" the list only for the local variable - thoughts? And do the same for devices (store to dict)?
Thanks!

Done! #38


Fix for urllib3 retry parameter method_whitelist rename

For the ullib3 Retry func, the parameter method_whitelist was renamed to allowed_methods.
Fix for #386
Can you take a look at it?
Sorry for any mistake 🙏
Thanks!

I tested your fix in local, it worked 👍

Thanks!

@jamalex Packages installed through pip install notion will still report this error, so it is recommended to update pypi and readme.

It would be nice to set boundary for urllib3 to be >2.0.0 in requirements, cause it will no longer work with older versions


waterfall plot shows wrong text(missing base value sign)

When I use waterfall with huge base value, waterfall plot shows base value instead of f(x) or E[f(x)]
the base value is 287439900 in this case
check out image below

Already fixed, and should be made available in the upcoming release (v0.42.0)


fix: update to eye v5.0.9

fix: update to eye v5.0.9

:tada: This PR is included in version 7.1.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release
v7.1.1

Your semantic-release bot :package::rocket:


Download fails with status 401: refreshToken is required.

Environment

OS: Windows 11
withny-dl version: 1.2.1

Configurations
(Comments do not exist on actual files)
# config.yaml
credentialsFile: 'credential.yaml'

# credential.yaml
token: "someToken"
refreshToken: "someRefreshToken"

Actual output

Output (without timestamp)
$ withny-dl watch -c config.yaml
INF github.com/Darkness4/withny-dl/cmd/watch/watch_command.go:149 > listening listenAddress=:3000
INF github.com/Darkness4/withny-dl/cmd/watch/watch_config.go:73 > initial config detected
INF github.com/Darkness4/withny-dl/cmd/watch/watch_config.go:190 > loaded new config
INF github.com/Darkness4/withny-dl/cmd/watch/watch_command.go:210 > no notifier configured
dummy notify:
title: config reloaded
message:
INF github.com/Darkness4/withny-dl/withny/api/client.go:294 > refreshing token
ERR github.com/Darkness4/withny-dl/withny/api/client.go:331 > unexpected status code error="unexpected status code: 401" method=POST response="{\"message\":\"refreshToken is required.\",\"status\":401}" status=401 url=https://www.withny.fun/api/auth/token
ERR github.com/Darkness4/withny-dl/withny/api/client.go:148 > failed to login error="unexpected status code: 401"
ERR github.com/Darkness4/withny-dl/withny/api/client.go:533 > failed to login to withny error="unexpected status code: 401"
FTL github.com/Darkness4/withny-dl/cmd/watch/watch_command.go:192 > failed to login error="unexpected status code: 401"

Fixed in this commit https://github.com/Darkness4/withny-dl/commit/3ce25f7e078a9b293103a1376a33cf0e936b5269.
I've also added some instructions on the token-based authentication: https://github.com/Darkness4/withny-dl?tab=readme-ov-file#token-based-authentication
TL;DR: Please note that the refresh token can only be used once, and you may need to fetch a new one. But don't worry! Withny-dl will automatically rotate and store the new refresh token in the encrypted file /tmp/withny-dl.json. The only time you'll need to retrieve a new one is when both /tmp/withny-dl.json and credentials.yaml use an invalid refresh token.


We should add another label for organization admin within user list

Basically only in this view (organization > configuration) appears any info about the "owner" of the organization.

What is that cross on the searchbar? 🗡

This is included in #12048.


Generalizing branch and pick to accept nested templates

See issue #96

Codecov Report

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

@@          Coverage Diff          @@
##           master    #97   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           1      1
  Lines         757    762    +5
=====================================
+ Hits          757    762    +5

Impacted Files
Coverage Δ

dist/partial.lenses.cjs.js
100% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


RFC: IndexGet and IndexSet

This RFC adds IndexGet and IndexSet types, which allows for additional options when implementing containers, and changing the behavior of assignments.
Rendered

Additional benefits include more support for DSLs similar to nmigen and its use of Python's index operator to indicate bit slicing. nmigen is based on using Python's operators to construct a description of what the outputted hardware will do rather than executing the operations directly as a normal programming language might.

It's a little sad that "set" as a verb or noun has such different meanings, so your trait IndexSet would collide with this struct IndexSet. Maybe trait IndexAssign is a good alternative here? That would also fit in with ops::AddAssign et al. It wouldn't mirror trait IndexGet as nicely, but maybe something like IndexMove would work there.

I also think that IndexAssign is better than IndexSet, as it matches the other operators with Assign.
As far as IndexGet is concerned -- honestly, this is a bit weird, as it basically is trying to allow indexing to return arbitrary values. I don't really know if that's needed, TBQH.
Hear me out -- bitset and arbitrary bit slicing seems like a good candidate for this, as you can't just reference an arbitrary bit slice.  In most cases, if you were directly copying the data out, this would be mostly optimised away, but otherwise you'd be able to do everything as usual.
If it's copying or cloning data out, it also makes sense to just require a method call or dereference.
If we were moving out, I'd see the need for an explicit trait, but that seems a bit weird and magical IMHO. For example, if map[key] by value were to basically remove an element from the map, I'd say that's super confusing and unexpected.
Basically, IMHO, we should ditch IndexGet.

IndexAssign fits another set of names that was bikeshedded, IndexVal and IndexAssign. I do think IndexGet is pretty fundamental to this proposal though, as not including relegates IndexSet to a very niche use, basically only HashMap situations. In addition, IndexSet would allow the setting of arbitrary values anyways, and IMO it doesn't make sense that you wouldn't have a way to get arbitrary values if you could set them.

I feel like what IndexGet proposes can already be done with ops::Index, though -- the a[b] operator returns <a as Index>:: Output, which you only have to reborrow if Output is not Copy. That BitSet example, at least the immutable part of it, can already be implemented on stable, (and here is where I realize where the distinction between returning a reference borrowed from self with Index vs created with IndexGet, but I already got this far) though somewhat hackily:
fn index(&self, x: u8) -> &bool {
    static TRUE: bool = true;
    static BOOL: bool = false;
    if self.foo(x) { &TRUE } else { &FALSE }
}

(You could probably use const propagation instead of explicit statics, but w/e)
Still, this does seem unnecessary -- I thought the plan for a while has been to add an IndexSet trait that just complements the existing Index/IndexMut? I still fail to see why it's integral to the proposal, Index has always existed to "get arbitrary values if you could set them."

We should definitely explore the custom fat pointer idea before doing this.
In fact, we could implement such fat pointers without necessarily touching rustc by using ATCs that default to references:
pub trait Index<Idx: ?Sized> {
    type Output: ?Sized;
    type Borrowed<'a>: Deref<Output>+DerefMut = &'a Self::Output;
    fn index(&self, index: Idx) -> Borrowed<'_>;
}
pub trait IndexMut<Idx: ?Sized>: Index<Idx> {
    type BorrowedMut<'a>: Deref<Output>+DerefMut = &'a mut Self::Output;
    fn index_mut(&mut self, index: Idx) -> BorrowedMut<'_>;
}

We'd provide the bitvec functionality by returning a guard that tracks an offset, which then work with *Assign ops types too.  We'd extend hashmap by returning some Entry-like guard here, which seemingly provides a far more powerful interface than proposed here.
Aside from likely being suboptimal, I'm afraid this IndexGet/IndexSet solution makes understanding indexing operations quite difficult.  You must internalize these subtle rules and "think like the compiler", which provides one big reason not to do IndexGet/IndexSet regardless.
I think this ATC solution however avoids massive confusion about which traits handle which functionality, which keeps the language simpler and more accessible.  I think even code that needs strange guards like bitvec and hashmap becomes much more comprehensible with the ATC solution.  Any code without strange guards becomes no more complex.
We could explore using similar ATCs to avoid trait proliferation elsewhere too, maybe becoming a common easily understandable design pattern within std.

We've currently no "assignment" trait really.  Would one make sense?
pub trait Assign<T> {
    fn assign(self, t: T);  //  Or &mut self?
}

impl<'a> Assign<V> for BitSetGuard<'a> { .. }

impl<'a, K, V> Assign<V> for ::std::collections::hash_map::Entry<'a, K, V> {
    fn assign(self, t: T) {
        match self {
            Occupied(mut entry) => { entry.insert(value); },
            Vacant(entry) => entry.insert_entry(value),
        }
    }
}

An ATC solution still handles BitSet better than IndexSet even without an assignment trait because BitOrAssign, BitAndAssign, and BitXorAssign are safer and more natural than outright assignment.

I really like the ATC solution, but it breaks backwards compatibility. If your concern is with the teachability of IndexGet, perhaps making it mutually exclusive with Index would alleviate some of the mental burden?

How does the ATC solution break backwards compatibility? AFAICT it's still the same if Borrowed defaults to just &Output, and I don't think there's any place in Rust where you need to exhaustively specify all default and non-default associative types (?)

In the end, index notation for bitsets and hashmap sounds nice, but should not be considered too important really, certainly not important enough to make reading code harder.
An unambiguous notation like foo[[bar]] for IndexGet/IndexAssign would resolves any confusion obviously.  You cannot make traits mutually exclusive normally, but yeah anything this magic sure okay, but doing that still makes identifying the impl tricky.  Would HashMap get one for Copy types and one drop types?  At first blush this sounds messy..
Yes, I noticed the ATC solution would "break" generic types that delegate Index/IndexMut, but that's the only situation, right?  Do any generic types that delegate Index/IndexMut exist now?  I'd think otherwise the defaults for those types prevent breakage.
Also, any generic types that delegate Index/IndexMut should still work with all current types that impl Index/IndexMut, just not with new impls using guards, like bitset and hashmaps.  It should therefore not break any binary builds, maybe acceptable.
Am I missing another breakage?

One use case I've wanted, which might be similar to bit sets, is a way to "index" into a 2d slice (eg: image data) and get a 2d sub-slice.
I'm not sure if this would need to change design to support that, but I've also been told that we'd probably need some custom DST stuff in the language as well to make anything like that be practical.

Well, code like this would require authors to specify another type bound, playground.
I'd assume making the traits exclusive (if we were to go down that path) would be compiler magic, but I'm not sure what you mean by HashMap and Copy and drop types?

Interesting, the ATC trick breaks any code that uses explicit Index* bounds, so the ATC solution separate traits IndexDeref* ro IndexGuard* too, either exclusive vs Index* or else invoked by foo[[index]].  It's plausible some compiler magic fat pointer might work here, but it does not cover the other use cases.
I'd suspect any solution involving exclusive traits would be rejected just because rust worked so hard to avoid those in the past, so maybe we should be discussing the foo[[index]] notation more seriously?
I actually think two dimensional indexing sounds more valuable than indexing for bitsets or hashmap.  If we'd some foo[[index]] notation that invoked some IndexGuard trait then you could have
pub struct Matrix<..> { .. }

/// Index into elements with self[row,col]
impl<..> Index<(usize,usize)> for Matrix<..> { .. }

/// Index into rows with self[row]
impl<..> Index<usize> for Matrix<..> { .. }

pub struct MatrixColumnGuard<'a,..> { .. }

/// Index into columns with self[[col]]
impl<..> IndexGuard<usize> for Matrix<..> { .. }

Amusingly, one could already make bitset work using existing dyn Trait fat pointers, although obviously doing that sucks:
pub trait BitGuard {
    fn get(&self) -> bool;
    fn set(&mut self, b: bool);
}
pub struct BitOffsetGuard<const OFFSET: usize>(usize)

impl<const OFFSET: usize> BitGuard for BitOffsetGuard<OFFSET> { .. }

impl Index<Idx> for BitSet {
    type Output: dyn BitGuard;
    fn index(&self, index: Idx) -> &'a Self::Output { .. }
}
pub trait IndexMut<Idx> for BitSet {
    fn index_mut(&mut self, index: Idx) -> &'a mut Self::Output { .. }
}

What would your IndexGuard trait look like? I'm also uncertain of how your CrazyEntry would let map[key] = value work, which is one of the main points of this proposal. Could you provide a playground link of what you mean?
The main issue is that none of the existing Index traits use GATs, which kind of preclude 2d subslicing. I think if we had a design with GATs (this was hastily sketched up) we could support it, but that would basically be a complete overhaul of how indexing works right now.
The main reason I don't want to just add <'a> to 'IndexGetwithout changing the others is because there's no reason the normal Index traits shouldn't get it too, or else we'll just see a proliferation of returning structs that implementDerefandDerefMut`.
The more I think about it though, IndexGet really is just IndexGuard by a different name. I'm unsure of what the purpose of the '[[]]` is, just a more explicit way of knowing whether you're taking by value or by reference?

I think today, foo[[index]] would try to use impl Index<[T; 1]> for Foo, which could plausibly exist.

Yes, I only proposed foo[[index]] so that traits could avoid the confusion caused by overlap rules, but yeah impl Index<[T; 1]> for Foo breaks this.  :(
I no longer think CrazyEntry works, which sounds unsurprising, so dyn Bool looks unique.

If Rust had associated types with generic lifetime parameters, the Index and IndexGet problem could be trivially solved with a blanket impl:
impl<T: Index<Idx>, Idx> IndexGet<Idx> for T {
    type Output<'a> = &'a <T as Index<Idx>>::Output;
    fn index_get(&'a self, idx: Idx) -> Self::Output<'a> {
        self.index(idx)
    }
}

You can do the same for IndexSet as well. That way, the compiler can switch to only use index_get and index_set exclusively. It also avoids any issues with new syntax.
Feel free to point out all the problems with this approach. I will admit I didn't read all of the proposal before commenting this, but I didn't see any mention during a skim.

We dropped another question up thread:  Is doing an assignment with hm[key] = value; ever wise for hashmaps?
It appears no because it does not propagate errors correctly.  hm.insert(key,value); ignores the returned option, which rust permit by Option not being #[must_use], but code should normally be assert!( hm.insert(key,value).is_noce() ); or hm.insert(key,value).ok_or(SomeError) ?; or hm.entry(key)...
It's maybe best not to give users a "more ergonomic" option that discourages error handling.  I felt hm[key] should return roughly an Entry for exactly this reason.

I mean vec[index] = val already panics if index is invalid, and so does &map[key]. The pattern if Index* panicking is already baked into the standard library. It feels like a holdover from C++, but I think it's too late to change that.
I've backtracked on my claim that we would need to GAT the rest of the traits, a simple GAT in the associated type of IndexGet would be good enough. I tried doing what @yellowsquid was saying, but I ran into obtuse lifetime errors. There's no reason this shouldn't work, but I don't know if I need HRTBs or if the current GAT impl just doesn't support this.

hm[k] = v; should absolutely allow assignment. Both as a way to assign a new key with a value or as a way to replace an old value at that key.
 If you need something more complicated, like checking that you never overwrite a key, then you can call the other methods.

IndexSet for Vec could allow inserting at Vec::len as an insertion.
I dunno, I think that assigning index is pretty idiomatic in a lot of cases. If you want to cover all cases, something like Entry is better, but it seems natural especially for prototyping.

So after looking at #159's Alternatives block, I came up with this design that should solve most of @burdges concerns regarding mutually exclusive traits as well as compelx reasoning. It's use of a GAT also makes 2d subslicing possible, but it comes with a plethora of Sized and lifetime issues.

pub trait IndexMut<Idx: ?Sized>: Index<Idx> {
    fn index_mut(&mut self, index: Idx) -> &mut Self::Output;

    fn index_set(&mut self, index: Idx, value: Self::Output)
    where
        <Self as Index<Idx>>::Output: Sized,
    {
        *self.index_mut(index) = value;
    }
}

pub trait IndexGet<Idx: ?Sized> {
    type Output<'a>: ?Sized;
    fn index_get(&'a self, index: Idx) -> Self::Output;
}

pub  trait IndexSet<Idx: ?Sized> {
    type Input: ?Sized;
    fn index_set(&mut self, index: Idx, value: Self::Input);
}

We get around complex reasoning by making the desugaring obvious. We can get around mutually exclusive traits by simply relying on coherence and blanket impls. This design allows for 2d subslicing and other use cases, in addition to the simple ones.
I think we could even propose the IndexMut change first and follow up with the the others once GATs are more stable.

How does the compiler decide between the methods in IndexMut?

&mut container[key] desugars to index_mut, container[key] = valuedesugars to theindex_set`.

Is *container[key] still valid syntax?

No? Well, if Self::Output is Deref I guess.

Wait, but something like vec[idx] = foo works now; would that be changed to still use IndexSet? Wouldn't that break backwards compatibility?

There would be an blanket forwarding impl for IndexSet. I took a stab at IndexGet and imo it's not possible to implement it without exclusive traits or the overload mechanism in this RFC.

I still don't quite understand the motivation on why Index and IndexMut is not necessary. Can there an example to show case why it is not enough and how IndexGet and IndexSet can solve this?

@pickfire Some examples are in the RFC, but it's for cases where returning a reference is impossible.

At this point your rules ensure that any existing code still compiles with the existing reference methods, right?  If not, then we should watch for performance regressions due to using moves over copies?  At the extreme one might consider Copy bounds for some new methods, which breaks doing this for hashmap I guess.

Yup, without any user-side changes everything will desguar identically.

So IndexGet and IndexSet can have impl IndexGet<u8> for T and impl IndexSet<usize> for T at the same time?

Yes.  In principle, we might exploit that either to avoid the if-else trait matching logic, and/or for fancier interfaces, ala
impl<..> Index<(usize,usize)> for Matrix<..> {
    type Output = ..;
}
impl<..> Index<Row<usize>> for Matrix<..> {
    type Output = [..];
}
impl<..> Index??<Column<usize>> for Matrix<..> {
    type Output<'a> = MatrixColumn<'a,..>;  // Some ATC guard type for accessing the column
}

We've discussed such options relatively well here so far, although a bit more exploration maybe warranted.
All these ideas incur some soundness risks too because they interact with unsafe code everywhere.  At first blush, I'd think the if-else trait matching logic incurs less soundness risks than using ATCs, which probably still invoke some even more flexible form of that logic on the ATC itself, but unclear.

We could explore the custom fat pointer suggestion by @clarfon slightly more..
I showed up thread in https://github.com/rust-lang/rfcs/pull/2953#issuecomment-657030675 that bitsets could work without IndexGet etc. by encoding offsets into the trait objects &dyn Bool defined by some type:
pub struct BoolOffset<T,const OFFSET: usize>(MutMaybe<T>);
impl<T,const OFFSET: usize> Bool for BoolOffset<T,OFFSET> { .. }

I think const generics can encode any index at the type level so long as it is foreseeable at compile time, but that last restriction prevents doing this trick for hashmap.
At the same time, we do risk a massive code size explosion from const generics being used with trait objects, which might require expanding our fat pointer repertoire eventually.  In other words, should/does rust reject making a trait object from &BoolOffset?  If yes, should rust provide some mechanism for passing along those type parameters as values at runtime?  Some 24byte &dyn<usize> Bool trait obejct?  If yes, then this might provide our cleanest solution because you could push the borrowed vs moved key question outwards.  Anything like this sounds very far away obviously.
Impl<'a,K,V,R> Index<&'a K> for HashMap<K,V,R> {
    type Output = dyn<&'a K> RefEntry<K,V>;  // Includes only a reference to the index
    fn index(&self, index: &'a K) -> &Self::Output;
}
Impl<'a,K,V,R> Index<&'a K> for HashMap<K,V,R> {
    fn index_mut(&mut self, index: &'a K) -> &Self::Output;
}
Impl<K,V,R> Index<K> for HashMap<K,V,R> {
    type Output = dyn<K> MoveEntry<K,V>;  // Includes the moved index
    fn index(&self, index: K) -> &Self::Output;
}
Impl<K,V,R> Index<K> for HashMap<K,V,R> {
    fn index_mut(&mut self, index: K) -> &Self::Output;
}

I'd some thoughts about Index: Copy too, but never made sense of them..
cc https://github.com/rust-lang/rfcs/issues/1403

One problem with this proposal is this bakes into IndexSet that Rust does not allow assignments to ?Unsized, and eddyb mentioned to me on Zulip that it would be impossible because you don't know you the concrete type for a trait object.
I suspect you've read #2594 and all of it's precursors, some of which sound a lot like what you're trying to do.

FWIW I'm in favour of having assignment be a method on IndexMut if it can be done right. It conveys the fact that IndexMut in a sense implies that you can set values whether you override it or not, whereas something like AddAssign would prevent you from using the operator if it doesn't exist.

One thing I've still been debating is the GAT on IndexGet. Is there a purpose for the GAT that would not be better served by #2594? @burdges looking for your thoughts on this.  The main thjng it would allow you to do is return a reference to &self, but the lack of proper mut support do hamper it, GATs are still a ways away, and custom DSTs are arguably the better move.
I guess the main question is does a GAT here open up anything custok DSTs won't?


Rename Is{}Exist -> {}Exist, and fix lint issues

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- yos/compare.go  1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- yos/compare.go  1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- yos/compare.go  1

See the complete overview on Codacy


Handle Meta

Issues a warning when a meta section is encountered in a WDL document.
Added new test case

wdl2cwl/tests/test_cwl.py: note: In function "test_meta":
  wdl2cwl/tests/test_cwl.py:13: error: Missing type parameters for generic type
  "CaptureFixture"  [type-arg]
      def test_meta(capsys: pytest.CaptureFixture) -> None:
      ^
  Found 1 error in 1 file (checked 4 source files)

Is the type incorrect?

wdl2cwl/tests/test_cwl.py: note: In function "test_meta":
  wdl2cwl/tests/test_cwl.py:13: error: Missing type parameters for generic type
  "CaptureFixture"  [type-arg]
      def test_meta(capsys: pytest.CaptureFixture) -> None:
      ^
  Found 1 error in 1 file (checked 4 source files)

Is the type incorrect?

Try def test_meta(capsys: pytest.CaptureFixture[str]) -> None:


Configuration options in Settings

path to rad binary
No need to have a default option (on all platforms). Match default with radicle installation guide. Attempt to run which rad and if found set output as the value of the field. If path hasn't been set we have to tell the user. (Dismiss / Resolve -> takes you takes you to settings OR (better?) asks for input in the command palette (?) )
Once a path has been defined, it would be great if we had a Test button that ensures rad --version can be invoked (so that we have the minimum CLI version installed and path / file exist and are executable, etc. ).

In practice, this ticket turned out to be the equivalent work of multiple tickets (as usually specced) in one, due to the branching factor and the numerous VS Code APIs needed to be used for the first time.
This is a rough sketch outlining the missing rad CLI handler's logic:

Notable features of the solution are:

pathToBinary config is placed under the "Advanced" settings subcategory
pathToBinary config by default isn't synced along with the user's VS Code config across computers and is visually marked as such. However, it can still be synced if the user chooses and is additionally overridable by workspace config if necessary.
pathToBinary config's string input is trimmed
edits to pathToBinary config take effect immediately as the user types (denounced event handler), without requiring IDE restart
When the extension cannot resolve rad the user is notified with a warning explaining the cause of the issue setting UX expectations and offering guided resolution with a multi-branch and multi-step troubleshooter
The troubleshooter follows all UX best practices defined in the VS Code extension authoring docs.
The troubleshooter results in either

open the browser to https://radicle.xyz/get-started.html
browse the filesystem using the native file picker
type the path into an InputBox with on-the-fly path validation

The resolved rad version and path are logged upon the extension's activation
Upon the extension's activation, or upon edits to pathToBinary config (via any current or future method), a hook will validate that the rad CLI resolves and if not, will notify the user and offer the option to troubleshoot as previously described, always providing timely feedback to the user.
No rad CLI installation validation (and thus notifications) take place, unless the extension is somehow activated (e.g. command is run from Command Pallete, Radicle View Container is shown in the Activity Bar, etc).

A demo showcasing some of the above features:
https://user-images.githubusercontent.com/7542054/227825688-83f1b8de-ffb1-4add-bbb5-40f3a0c38d5e.mp4

Nice work @maninak - and 👏 on its documentation!
If I understand correctly, if the path in the settings is empty, VS code can still use rad from e.g. $PATH ?
If so, I'm wondering if we should call that setting path override or something to indicate what the value there is meant for.
Or maybe we auto-detect rad and we pre-fill that field with the value from $PATH ?

If I understand correctly, if the path in the settings is empty, VS code can still use rad from e.g. $PATH ?

Yes. Following the Getting Started guide, rad should be globally accessible in the shell, at least on Linux which I've tested (effectively it's appended in $PATH). So, by default, the extension will just run rad push, or rad pull.
If the user sets pathToBinary: '/usr/bin/rad then the commands shown above will be run in the shell as /usr/bin/rad push and /usr/bin/rad pull.
The above can be seen in the source code here https://github.com/cytechmobile/radicle-vscode-extension/blob/73a05d985710f0c45ce445a7c900b31c9b245dba/src/utils/radCli.ts#L12

Or maybe we auto-detect rad and we pre-fill that field with the value from $PATH?

Nop, we don't pre-fill/set the config pathToBinary, because that would mean that we're setting a user config without explicit user action, which as it turns out is bad practice.
If we pre-filled the config after reading its path with something like which rad (which sources the response from $PATH) and then the user changed the location of the binary and the related definition in $PATH, our extension will fall out of sync and error out, even though the user has done everything right and running rad --version in the terminal would still work.
FYI every config that is set adds a new entry in the settings.json, which some people maintain directly instead of using the settings UI (has rich autocompletion and JSDoc-powered tooltip docs). Furthermore, uninstalling an extension doesn't remove its configs set in settings.json (in case the extension is later re-installed). For those two reasons, we must avoid unnecessarily and unilaterally "littering" the file with configs. And that's why if the setting is "undefined" we default calling the CLI just rad which is a sane default per the Getting Started guide (and if that fails, our new user notification and troubleshooting process is available to take up the slack).

Thanks for the additional context.

Following the Getting Started guide, rad should be globally accessible in the shell, at least on Linux which I've tested (effectively it's appended in $PATH). So, by default, the extension will just run rad push, or rad pull.

I see 2 different processes being referenced here:

a process spawned in a shell, where $PATH can be read / modified a bunch of different ways - e.g. .bashrc , .bash_profile (and other terminal variations), etc. : let's say this process is rad --version
a process that is spawned inside VS Code somehow, by our extension, which also eventually invokes rad --version

How can we be sure that these 2 processes read the same $PATH? 🤔
If our recommendation is "leave the setting empty and set your $PATH correctly", I think it's important to clarify what the valid ways to set the $PATH are.
( e.g. from a quick search, I see it has been an issue - but there are some newer developments that mean maybe this isn't (?) so much of a concern any more
With that in mind, perhaps it would make sense to add a simple "learn more about how to correctly set $PATH on your platform" in the settings screen ? I am not 100% sure that the link above is the best page to link to though...
what do you think?

Hey, thanks for describing your thoughts in detail and for providing the references.
Personally, I've never experienced any $PATH- or shell-related issues with either VS Code or Linux and I've been using both explicitly since 2016 and 2009 respectively.
IMO I think this whole topic rad CLI resolution topic is pretty simple:

for most people, in most cases everything will "just work"™
if not, for whatever reason, all the user has to do is download the rad binary and save it anywhere on their machine, and via any of the 3 available methods we offer, set the pathToBinary config in the settings.

There's no need for them to fiddle with advanced $PATH stuff or shell config like .bashrc (although if they do that, our extension will again work 🙂).

So, to recap, as we have things now, everything will either just work, or at worst the user will download a file and tell the extension where it is.
That's pretty good UX, IMO, and could only get better if we bundled rad into the extension itself (which requires plenty of CI and build-tooling work but is indeed doable).

ok, I think you're right and that makes sense.
Adding $PATH into the equation probably confuses things more rather than asking them to point to the binary, with the guide you've already created here.
All good - thanks for the input!

Adding $PATH into the equation probably confuses things more rather than asking them to point to the binary, with the guide you've already created here.

Yup, that's why I only use this more advanced terminology under the "Advanced" config's description in the settings and nowhere else; neither in the notification nor in any copy throughout the troubleshooting flow. That's on purpose, not by accident. I spend a lot of time crafting those copies (not implying they are perfect and shouldn't be changed, though).

All good - thanks for the input!

Sure thing! :beers:


Smart Charging enhancements

- [ ]  Show the current Charging Plan List/Chart component with switch button (chart is displayed by default)
- [ ]  Hide input fields: Temporary plan, Start date, Apply and Delete buttons
- [ ]  Auto-refresh on list

Created separate issues


address issue #248

This PR changes the behavior of cftime.datetime initialization.  Previously, specifying year=0 without the has_year_zero kwarg will raise an exception if the default  for that calendar is has_year_zero=False.  With this change specifying year=0 without a has_year_zero kwarg will cause has_year_zero to be set to True.
The assumption here is that if the user is asking for an instance for year=0, they implicitly want the version of the calendar that includes year zero.
@spencerkclark would appreciate it if you would take a look at this and make sure it doesn't break xarray

@bjlittle and @spencerkclark - if you have a chance your feedback would be welcome.  I plan to merge later next week.

Thanks for the ping @jswhit.  I believe everything in xarray would still work with this change.  That said, from a user experience perspective, if this change is adopted we might move toward explicitly specifying our year-zero conventions anywhere where we construct dates manually in the code.  I prefer that the error message continues to come immediately from specifying a date with an inconsistent convention rather than something downstream, since in xarray we assume the CF conventions are followed.
I see @bjlittle's point regarding if a user specifies year zero then they would likely want year zero, but at the same time I do find it a little awkward that one can effectively create two different date types with the same constructor:
>>> import cftime
>>> a = cftime.DatetimeGregorian(0, 1, 1)
>>> b = cftime.DatetimeGregorian(1, 1, 1)
>>> b - a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "src/cftime/_cftime.pyx", line 1398, in cftime._cftime.datetime.__sub__
TypeError: cannot compute the time difference between dates with year zero conventions

Perhaps a warning should be raised when year zero is requested and the default has_year_zero kwarg would otherwise be False, so that the user is aware they are creating an instance that doesn't conform to CF standards/

I like the idea of including a warning.  That would be a good compromise.

@bjlittle I'd still like to have you look this over to make sure it addresses your original issue.  I'll go ahead and merge if I don't hear from you by this Friday (Aug 13).


ESP8266 build.opt missing fix

resolves #13

I would have preferred to add a conditional
if ("${ARDUINO_BOARD" MATCHES "ESP8266")

However on the first run, when BoardOptions.cmake does not exist, the variable was empty and thereafter the CMakeCache.txt had
//Arduino board for which the project is build for
ARDUINO_BOARD:STRING=

So the variable was blank.  Not sure what I am doing wrong here.

I hit this issue today. What's blocking this from a merge?

Might  be worth raising an issue on the parent repo, and reference this merge request.


Error (babel) on npm run serve

Hello ! I've been trying to create a vue sfc using vue-sfc-rollup, however npm run serve doesn't seem to work (I haven't done any modification to the default files).
What I did:

npm install -g vue-sfc-rollup
sfc-init (vue2, single-component, javascript)
cd my-project
npm install
npm run serve

And I got the following error message:

I'm using node v14.16.0 (installed with nvm) on a MacBook Pro (intel).

Running the same command, I don't have the same issue. Even ran npm install --cache /tmp/empty-folder to ensure I wasn't getting cached npm modules.
If you try again, perhaps with the same cache technique I mentioend, does it still happen? If so, a sample repo that includes the generated package-lock.json might be helpful.
In all honesty, though, the error is not with the scaffolded code, it's an upstream error. So it's not something that can/needs to be fixed here.

Hello, I had the same error and 3 vulnerabilities. After fixing these by running "npm audit fix --force" everything worked fine.

Closing, as this is an upstream problem.

I appreciate this is maybe an upstream error but I find it odd using provided versions it is happening. I have the same error using scaffolded code, but forcing a dependency update makes a new error.
 ERROR  Failed to compile with 1 error                                                                                11:30:54 pm
 error  in ./dev/serve.ts

Syntax Error: Error: [BABEL] D:\Projects\test\dev\serve.ts: Cannot find module 'core-js/package.json'
Require stack:
-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>(While processing<EMAIL_ADDRESS>    at Generator.next (<anonymous>)
    at Generator.next (<anonymous>)
    at Generator.next (<anonymous>)

 @ multi (webpack)-dev-server/client?http://<IP_ADDRESS>:8080&sockPath=/sockjs-node (webpack)/hot/dev-server.js ./dev/serve.ts

After strictly declaring which core npm package to include in my package.json my errors went away. Something was causing a weird collision.
Try installing vue cli tools globally, vue upgrade, then if that still doesn't jive, add core-js and core-js-compat as dev dependencies.
https://cli.vuejs.org/guide/installation.html
https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/babel-preset-app/package.json#L38-L39
Hope that helps!


hubble: move hubble-serve out of daemon, re-organize packages

This commit moves package hubble-serve out of daemon/ and into
pkg/hubble/server. The package previous pkg/hubble/server is renamed to
pkg/hubble/observer to avoid possible confusion with hubble's gRPC
server. The observer package is indeed an implementation of the observer
server gRPC service. In order to avoid confusion of the observer
implementation and its protobuf definition, modules that imported the
protobuf definition have been import-renamed to observerpb.
This commit is in preparation of the addition of the peer service
implementation and brings no functional changes.

Coverage decreased (-0.03%) to 46.946% when pulling 91fc8696dbcd548f2cebb07454a718c68b230652 on pr/rolinh/hubble-move into 418500bad872814fd9582ba6eb30b9819e4ee3b6 on master.

test-me-please

test-with-kernel

test-with-kernel

test-with-kernel


Trojan detected from windows security

Hi, I want to ask anyone that has a lot of experience with this program does it have viruses or ?
Also, anyone that is using it for a long time, is it bannable on your league of legends account?
Thanks!

false

false what bro i dont understand

be careful...
https://www.virustotal.com/gui/file/c6c5052f927c8928fa3d1d477aa10b0475464757e55050ab8e4efe65904331c5/detection

That is a false positive. The skin changer as well as the injector uses some Win32 API's that aren't commonly used in normal programs. The project is open-source, so you are welcome to compile the skin changer on your own, otherwise disable your antivirus and add the folder with the binaries to the exclusion list.
I'm tired of closing issues like this one is like a 10 issue relating to this issue this week. Please check closed issues before posting an another one.


Add Bech32 address format package.

This PR implements the Bech32 address format as specified in BIP 173: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
Test are modeled after the Python reference implementation (https://github.com/sipa/bech32/blob/master/ref/python/tests.py) to ensure compatibility.

Will need https://github.com/btcsuite/btcd/pull/959 to build.

Done 👍

Thanks for the update.  This looks good now.  Please go ahead and squash it, then I'll approve and merge it.

Thanks! Done :)


Css format fix

Removes embedded style rules from HTML code

Looks like jasper's got this review and has already approved :) no need to get my approval.


500 error on upgrade from 5.somthing to 6.3

Hi,
I've been trying to upgrade from 5 to 6.3.
I keep getting the error shown below and at this point the app_data\ADBackend folder is almost wiped out.
I've checked the permissions, I've installed .Net 4.6.2, I'm at a loss as to how to continue to fix this.
Error shown on screen:
Server Error in '/Bonobo.Git.Server' Application.
--------------------------------------------------------------------------------

Runtime Error
Description: An exception occurred while processing your request. Additionally, another exception occurred while executing the custom error page for the first exception. The request has been terminated.

Here is the error from the log:
2017-11-06 18:12:56.998 +00:00 [Information] Searching for group "Redacted_group" in domain "redacted.domain.com"
2017-11-06 18:12:57.011 +00:00 [Error] Startup exception
System.ArgumentNullException: Value cannot be null.
Parameter name: key
   at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at Bonobo.Git.Server.Data.Update.ADBackendUpdate.Pre600UpdateTo600.UpdateTeams(String dir, Dictionary`2 users)
   at Bonobo.Git.Server.Data.Update.ADBackendUpdate.Pre600UpdateTo600.UpdateADBackend()
   at Bonobo.Git.Server.MvcApplication.Application_Start()

It seems it fail updating the teams directly from your version to the newest.
I can't remember if you need to update one version to the next.
If you want a new 6.something I would go for 6.2.1 because there are something not working with 6.3 with AD. See #755.
The only way is probably to set up a empty new instance of bonobo and the copy only the repositories which would end up as 'found in filesystem' but nothing else of information, team and personal assignment etc.

@larshg Thanks for the quick response.
I managed to get a bit further by myself.
I found a couple of issues that stopped the upgrade.
Firstly, in the team members list we had a user ```null````.
Secondly, at one time we had a sync issue and had two users with the same username in AD.
This hadn't been an issue until the upgrade tried to map the two users to the same UID.
After all that I couldn't log in, but downgrading to 6.2.1 sorted the AD login.
Thanks for your help.

Ahh. Great. So you are up and running with 6.2.1?

Yes, thank you.


Rebuild to try to understand 'Illegal instructions' error

Checklist

[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender


Add ROS design

Adds ros design. Still have some things to hammer out before finalising this.

TODO next is to make mermaid diagrams of the three packages, then figure out how the file structure of the training data will look like

Just need to define the data format, then this is done

Should be pretty much set, last things that are TODO are just algorithmic things we need to develup. Going to wait a bit for the dust to settle on this before merging.


Enable pure IPv6 Director/UAA/Credhub integration without use of DNS

Previous iteration: https://github.com/cloudfoundry/bosh/pull/1948
Rebased onto master on Jun 4.
Building: https://main.bosh-ci.cf-app.com/teams/main/pipelines/ipv6

@cppforlife If this is the now-canonical implementation of this behavior, would you mind closing the previous PR?

Closed the last PR. In the future, please keep pull requests open and push your changes to the existing branch rather than creating duplicate PRs in order to ease discussion and tracking. If you want to retain history prior to rebases, feel free to keep local branches or branches in your fork to avoid cluttering branch lists.

Closing and reopening to generate a tracker story.

We've manually merged the PR. We found that with newer versions some of the changes in here were no longer necessary, so we omitted a few of the commits in this PR. Thanks.


B726

Some fine tuning in spreg/tests that will have to go back upstream to spreg, but travis passes now with unpinned scipy and numpy to development can move forward.

:tada: :balloon: :tada: will merge when passing.
We should still look into using CircleCI for the private repositories. I can get circleCI running on my private spreg fork, but cannot test out how to set it up for pysal/spreg, since I'm not an admin.

Brilliant!

For future reference, when we are testing allclose and one of the parameters in the array is close to (or equal to) 0, just using rtol will lead to problems, since rtol*v will be 0. In that case using atol will be the way to go.

:+1:


[Snyk] Security upgrade express-session from 1.17.3 to 1.18.1

Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

package.json
package-lock.json

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

44/1000  Why? Confidentiality impact: None, Integrity impact: Low, Availability impact: None, Scope: Unchanged, Exploit Maturity: No data, User Interaction (UI): None, Privileges Required (PR): None, Attack Complexity: High, Attack Vector: Network, EPSS: 0.01055, Social Trends: No, Days since published: 3, Reachable: No, Transitive dependency: Yes, Is Malicious: No, Business Criticality: High, Provider Urgency: Medium, Package Popularity Score: 99, Impact: 2.35, Likelihood: 1.86, Score Version: V5
Cross-site Scripting (XSS) SNYK-JS-COOKIE-8163060
No
No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Commit messages

Package name: express-session
    The new version differs by 47 commits.

bbeca94 1.18.1
341b179 dep<EMAIL_ADDRESS>(#997)
8f0a1c4 ci: add support for OSSF scorecard reporting (#984)
24d4972 1.18.0
855f21a docs: add connect-ottoman to the list of session stores
991b7ee Add debug log for pathname mismatch
408229e Add "partitioned" to cookie options
50e1429 build<EMAIL_ADDRESS>6153b3f build<EMAIL_ADDRESS>88e0f2e build: actions/checkout@v4
d9354ef Fix handling errors from setting cookie
f9f2318 docs: remove session-rethinkdb to the list of session stores
3ee08c4 Add "priority" to cookie options
71c3f74 docs: add connect-cosmosdb to the list of session stores
9d377c5 docs: add dynamodb-store-v3 to the list of session stores
a1f884f docs: add @ cyclic.sh/session-store to the list of session stores
e5f19ce docs: add note on length of secret
2a7a50b<EMAIL_ADDRESS>a46e857<EMAIL_ADDRESS>7dec651 build<EMAIL_ADDRESS>8e9f7a4 build<EMAIL_ADDRESS>6b7c9a0 build<EMAIL_ADDRESS>825e6c0 build: fix code coverage aggregate upload
c1611ad build: actions/checkout@v3

See the full diff

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Cross-site Scripting (XSS)

🎉 Snyk hasn't found any issues so far.
✅ security/snyk check is completed. No issues were found. (View Details)
✅ license/snyk check is completed. No issues were found. (View Details)


Feature/cmjd 70 room schedule (more like "calendar refinement")

This branch adds all the features that the #126 branch was missing like:

Searchable Events
A calendar that displays all of the events
CSS for calendar events

There are also a few refinements like:

fixing the hack of including the slightly modified template files from the simple calendar gem into our project, with a very hacky  line in app/views/rooms/calendar.html.erb
fixing the tests as there are multiple incomparable time classes in rails and the devices randomly decide with which to parse a string... (in short, they didn't work on my machine)

Does anyone have an idea what to do about the too many lines problem from CodeFactor?
Is there a possible refactor that would reduce this line-count?
If so, please suggest a solution or simply push to this PR 😀


Allow a given bundle-size configuration/path/glob to aggregate the file sizes into one summation number

With this configuration,
{
  "path": "./dist/*.js",
  "maxSize": "3 kB"
}

instead of this
─ ./dist/*.js
  √ ./dist/index.js    91B < 3 kB gzip
  √ ./dist/types.js    65B < 3 kB gzip
  √ ./dist/utils.js    293B < 3 kB gzip

add a flag that outputs one path/glob summation for file size
─ ./dist/*.js
  √ ./dist/*.js   449B < 3 kB gzip

Here's a suggestion for that flag/interface for this option:
{
  "path": "./dist/*.js",
  "maxSize": "3 kB",
  "sum": true
}

Thanks for taking the time!
Can you explain the motivation behind this feature? Where would you like to measure this and what would you do with the metric?
Context: In the past I have tried to shy away from summing up multiple files because the performance of a page depends a lot on the way the individual chunks are loaded on the page (split across pages, lazy loaded, etc.). In my opinion, total size of dist/*.js or chunks/*.js isn't a good metric to measure/optimise. (previous discussion: https://github.com/siddharthkp/bundlesize/issues/20)

Honestly, my thought was to just use this tool as a cross-platform tool for checking all file sizes via CLI, and the use case that comes to mind is file size checking for libraries/modules (what bundlephobia does but CLI, maybe something already exists but I'm already use this tool and love it so far), using this to compare file sizes via different projects or different versions of the same project (my enterprise client is converting Angular.js to React site and I'm curious to show them how much less file size there is in general, and having a max total size in certain parts of the project may be helpful so we don't fall into the same bad patterns again), and then just generally set file-size restrictions on a group of source code that matches a pattern (such as restricting the size of the contents in a folder, like a feature folder, or just restricting a folder from a certain upper limit size an encouraging subfolders to be created when that size is reached).
I think now after thinking about it, it's pretty clear that this is beyond the scope of calculating bundlesize. I think individual file/chunk sizes is definitely what you should optimize for, not an aggregate sum that doesn't mean anything. I just thought as an optional parameter, it wouldn't be that big of a deal and consumers of this library maybe find good use cases of wanting to put an upper limit on a group of files in their projects.
All these use cases were much more practical extensions of what this tool already does, and these use cases don't really relate to "bundlesize optimization" as much as they relate to other file size restriction activities, separate from the bundle. Clearly the name of the library denotes it's intention around bundle size, so maybe this functionality should live in another tool, but I thought it couldn't hurt because the library does a bulk of the work to enable this feature anyways.

Thanks for your well thought out reply, I appreciate it 👍
Yep, I'd like to keep bundlesize do just 1 thing, but please feel free to fork/clone and take the relevant bits to build the idea you're thinking of. Another related project that might be helpful to take from: https://github.com/siddharthkp/cost-of-modules


Create a Security Policy

Closes #34
I've created the SECURITY.md file considering the report vulnerability through security advisory, which is a new github feature still in beta and that has to be enabled.
If you're interested in GitHub's feature, it must be activated for the repository:

Open the repo's settings
Click on Code security & analysis
Click "Enable" for "Private vulnerability reporting (Beta)"

If you rather not enable it there is also the possibility to receive the vulnerability report through an email, in this case just let me know which email it would be and I'll submit the change.
Besides that, feel free to edit or suggest any changes to this document, it is supposed to reflect the amount of effort the team can offer to handle vulnerabilities.

Looks good, thanks for submitting this! I enabled the the feature in the repo settings.


changes nav display according to auth status

👷 Deploy Preview for cg-eleventy-blog processing.

Name
Link

🔨 Latest commit
ec8a6b4bd9298fbb797db64a46ffa51efa3b8248

🔍 Latest deploy log
https://app.netlify.com/sites/cg-eleventy-blog/deploys/65c8498bb2d9a10008d94f9a


Merge master internal 22020923

Merge master internal 22020923

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: wenmengzhou:white_check_mark: Cathy0908:x: shouzhou.bxshouzhou.bx seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Question about ssd operator implementation?

def Execute(self, request, context):
    logging.info("execute")
    grpc_metas = []
    result_images = run(self.detector, request.datas, request.urls)
    # just for test, need adjust proto
    logging.info('len of result images： %d', len(result_images))
    result_images = result_images[0]

    for result_image in result_images:
        data = rpc.rpc_pb2.MetaData(data=bytes(result_image, encoding='utf-8'))
        grpc_metas.append(data)
    return rpc.rpc_pb2.ExecuteReply(nums=len(grpc_metas),
                                    vectors=[],
                                    `metadata=grpc_metas)`

What do you mean by “just for test”？
result_images = result_images[0] , Does that mean the operator will only process one image at a time ?

Yes, you're right.
This is just a solution in current version because of the design of rpc proto.


"cudart64_101.dll not found" but the nvidia GPU computing toolkit has the file cudart64_102.dll file under the bin folder?

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Windows 10 Pro
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary): using pip after creating environment from within the scripts folder of the environment after using "activate", so in short using binary
TensorFlow version: tensorflow gpu 2.3.0
Python version: 3.6
Installed using virtualenv? pip? conda?: pip after creating an environment
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version: 10.2
GPU model and memory: Nvidia GeForce 940MX

I tried to install tensorflow gpu to get started with using CUDA with it. But after installing it in the created environment, when I open the python interactive mode and try to import tensorflow it throws a error/warning that cudart64_101.dll not found. But installed cuda 10.2 and then it's patch listed on the nvidia cuda website and also cudnn. I even included everything in the PATH. But why is my installation looking for cudart64_101.dll when I have an updated file named cudart64_102.dll in my nvidia gpu toolkit's binary folder. How can I fix this? I am trying this to learn about cuda and how to use them with tensorflow and pytorch both.
You should consider upgrading via the 'python -m pip install --upgrade pip' command.
(gputest) C:\gputest\Scripts>python -m pip install --upgrade pip
Cache entry deserialization failed, entry ignored
Collecting pip
Cache entry deserialization failed, entry ignored
Downloading https://files.pythonhosted.org/packages/5a/4a/39400ff9b36e719bdf8f31c99fe1fa7842a42fa77432e584f707a5080063/pip-20.2.2-py2.py3-none-any.whl (1.5MB)
100% |████████████████████████████████| 1.5MB 230kB/s
Installing collected packages: pip
Found existing installation: pip 9.0.1
Uninstalling pip-9.0.1:
Successfully uninstalled pip-9.0.1
Successfully installed pip-20.2.2
(gputest) C:\gputest\Scripts>python
Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

import tensorflow
2020-08-30 21:51:17.099536: W tensorflow/stream_executor/platform/default/dso_loader.cc:59] Could not load dynamic library 'cudart64_101.dll'; dlerror: cudart64_101.dll not found
2020-08-30 21:51:17.100010: I tensorflow/stream_executor/cuda/cudart_stub.cc:29] Ignore above cudart dlerror if you do not have a GPU set up on your machine.

@NahianAlindo
You may need to find which directory these dlls are in, and then update your PATH to include that directory.
Can you refer to this issue [#36111] with same error and let us know if it helps.

@NahianAlindo
You may need to find which directory these dlls are in, and then update your PATH to include that directory.
Can you refer to this issue [#36111] with same error and let us know if it helps.

I think I got where the issue was reading the tensorflow website. Apparently, tensorflow 2.3.0 which is the latest version of tensorflow requires cuda 10.1 but I  have installed cuda 10.2. I will try uninstalling and reinstalling. Maybe that will fix things up.

on my Windows, I just do symbolic link and the tensorflow just runs fine on me 😉

@NahianAlindo
Can you please update.

@NahianAlindo
Can you please update.

Yes, I have fixed it just now. It seems that the TensorFlow 2.3.0 requires CUDA 10.1 after all. That's why it was searching for cudart64_101.dll instead of what I had which was cudart64_102.dll. So, I uninstalled the CUDA toolkit 10.2 and installed the CUDA toolkit 10.1 and the latest CUDNN for the CUDA toolkit 10.1. Thus, I managed to make GPU available for both TensorFlow and PyTorch.

@NahianAlindo
Thanks for your update, glad to hear the issue is resolved.