Questions about the dimension of data

Hi, I have some trouble understanding what does sequence-size means in your code. In the 01_kitti_ds_vis.ipynb file, there is an example of getting data from the dataset. The dimension of IMU data is [1, 2, 16, 6]. Referring to the code, "2" stands for the sequence size. Is this actually the length of lidar frames used for training instead of the length of IMU data?
And I used to think a reasonable input of your network would be two frames of lidar images and 10 IMU measurements between them (since in KITTI, imu data is 100Hz and lidar data is 10Hz), then the dimension of IMU data will be batch_size x 10 x 6. Why should we prepare the IMU data in the dimension of [1, 2, 16, 6]? What does 16 mean here?
Hope for your reply!
Best regards,
beniko

@Beniko95J generally you define the sequence-size and the combinations in the config file.
  sequence-size: 2 # must be >= 1
  combinations: [[0, 1], [0, 2], [1, 2]]

In the above example, each sequence is defined to be a pair of images, we say to the system that it should take two sequences, also (2+1) images each time and combine them as in the "combinations"-field.
So each time we call "get_item" we get a seq. of 3 consecutive images at times (t0, t1, t2) and 3x(10x6) IMUs between them.
As you have correctly recognized, between each image pair there are around 10 IMU measurements (100HZ ). So if we combine images [0, 1], we have IMU-Measurements of dimension (10x6), for a combination of images [0, 2], we have around (20x6) IMU-Measurements and so on. Creating combinations out of consecutive measurements is done in "DataCombiner" .  That means after this step out IMU-Measurements array has the shape (1x3x[10 or 20]x6), assuming batch-size=1 and seq-size=2.
But unfortunately, there are some holes in the IMU-Measurements of the KITTI Dataset. That means for some LiDAR frames there are no IMU measurements at that timestamp. For this reason, the dataset-class check if it is the case, if yes it just fills the IMU measurements with zeros of length 8.
I hope it makes more sense for you now!
Best Regards
Arash

@Beniko95J, By the way, I just updated the notebook, to clear the confusion about the dimensions.

Hi, Arash
Thank you for the quick reply!
I would like to use f0, f1, f2 to represent the three consecutive frames in the example.

In the above example, each sequence is defined to be a pair of images, we say to the system that it should take two sequences, also (2+1) images each time and combine them as in the "combinations"-field.

Does the "two sequences" here mean (f0, f1) and (f1, f2)? And I am still confused about the motivation of generating three combinations from three frames because I think use two frames as a training pair is enough. The combination strategy seems to just generate 3 training pairs for me, while adding a dimension to the data. So even in testing instead of training, your network still needs three frames as input?

So if we combine images [0, 1], we have IMU-Measurements of dimension (10x6), for a combination of images [0, 2], we have around (20x6) IMU-Measurements and so on. Creating combinations out of consecutive measurements is done in "DataCombiner". That means after this step out IMU-Measurements array has the shape (1x3x[10 or 20]x6), assuming batch-size=1 and seq-size=2.

Is there a relationship between the number of combinations and seq-size? For combination of [0, 1] and [0, 2], how to concatenate 10x6 and 20x6 IMU measurements together? ((1x3x[10 or 20]x6) seems to be strange for me)

But unfortunately, there are some holes in the IMU-Measurements of the KITTI Dataset. That means for some LiDAR frames there are no IMU measurements at that timestamp. For this reason, the dataset-class check if it is the case, if yes it just fills the IMU measurements with zeros of length 8, e.g. (8x6).

Yes, there are actually some timestamp holes in the KITTI Dataset. I used to check the timestamp holes in the KITTI Odometry Dataset (Seq 00, 01, 02, 04, 05, 06, 07, 08, 09, 10) and the number of frames without timestamps are about 500 which is in fact quite smaller than the total number. (I am glad to share with you the index of invalid frames) I used to just discard the invalid frames and use the left for training. I think the padding of zeros may have some bad influences here since they are actually not the real IMU measurements. May I ask why you choose 8 here instead of 10? For the IMU-measurements without holes, I think 10 is a more suitable selection, and as I have mentioned, they are much more than the IMU-measurements with holes.

The input to the LiDAR-Feature-Nets, e.g. the images has the dim (Bxlen(combinations)xCxHxW) - (1x3x2xHxW). The Input to the IMUFeat-Nets has the dim (B x len(combi) x len(IMU-Seq) x 6)

About the input to the IMUFeat-Nets, in 01_kitti_ds_vis.ipynb file, we have the IMU data of shape [1, 2, 16, 6], while the length of combinations should be 3. Is this a mistake?
Similar to the question above, for the combinations of [0, 1] and [0, 2], we have IMU measurements of different lengths, how to concatenate them together?

Hope for your reply!
Best Regards,
beniko

Does the "two sequences" here mean (f0, f1) and (f1, f2)?
Yes "sequnce-size" of two means we need 3 images. But how they are combined depends on the combination-keyword in the config-file. You could combine as you mentioned ((f0, f1),(f1, f2)) or you could do ((f0, f1),(f0, f2)) or even ((f0, f1), (f0, f2),(f1, f2)).

In the simplest case, you can define the following
  sequence-size: 1 # must be >= 1
  combinations: [[0, 1]]

In fact, at the test time, it's even mandatory to set sequence-size and combination as above. see here.
The motivation behind "sequence-size=2" is the if I combine (f0, f2) the network should learn more global meaning between two frames, that have a larger spatial distance two another.

I am glad to share with you the index of invalid frames.
I understand, unfortunately, it is mentioned nowhere! :(

I used to just discard the invalid frames and use the left for training
Interestingly I did actually the same too, that is why there are valid-keywords in the data. So one can check during the training if the IMU data are really there. But I could not see any real difference. I would be happy if you share your observations.

But anyway, you can change the train-function to check for them, in fact in the earlier version of the training function they were ignored.
        for idx, data in enumerate(self.train_dataloader):
              # skip invalid imu data
              if not data['valid']:
                  continue

May I ask why you choose 8 here instead of 10?
Well, you are 10 might be suitable but since I was ignoring them anyway - at least in the earlier version, I just let it so. But I will the size has really any effect on the loss performance.

Similar to the question above, for the combinations of [0, 1] and [0, 2], we have IMU measurements of different lengths, how to concatenate them together?
That is in fact a really good question. With the current configuration of combinations, we will get IMu-Measurements with different lengths - mostly 8, 10, or 21.  That is why there is an iteration through them in the forward-pass. here and here

By the way, were you able to run the application successfully?
Best Regards
Arash

Hi, Arash
Thank you for the reply!
I have tried to run your project, but it spends too much time reading data from the original oxts files (maybe I need to buy a faster hard drive lol). I am going to try to use your scripts to generate pickle files in advance so that it may load the dataset faster. I will let you know as I manage to run the project tomorrow (It's 2 am here).
Best regards,
beniko

Hi @Beniko95J , ok, sounds great, let me know if there is something not working with the "convert_oxts2bin.py"-script.

Hi, Arash
By the way, I am working on another project which is a self-supervised depth-motion network using RGB images and IMU measurements. My motion network is quite similar to your project with the lidar encoder (lidar feature net) changed to the image encoder:
Image Encoder(Conv)
\
-> Feature Fusion Network ->Pose Regression Network (FC)
/
IMU Encoder(LSTM)
For the feature fusion network, I simply concatenate the encoded features from different sensors just as your fusion layer does when set to 'cat'. My network performs well when the IMU features are disabled, while it gives bad results when the IMU features are enabled. I have considered several possible reasons for this, would you please give me some ideas about this?

In your project, you seem to pre-process the IMU measurements to get them normalized. Does this make a difference to the final performance? In my project, I just encode them from their original values, which I think may cause some problems when fused into the image features since they are not in the same metric.
As this paper has demonstrated, simple concatenation of features from different sensors may make networks fall into the local minimum during training. It introduces two fusion strategy named soft-fusion and hard fusion. Is the soft-fusion in the paper the same to the soft-fusion in your project? I am also trying to implement some other fusion strategies to see whether the performance will be improved.

Best regards,
beniko

@Beniko95J, nice, I would be happy, if you share your project with me :)

Well, in the beginning, I also did not normalize the IMUs, but the performance was really poor. mostly because the values are so differently scaled. But by normalizing them, the results were better.  Another thing is that using RNN results in better odometry inference at least with "hidden-size" set to greater than 64-neurons.

Nice catch, yes I got the idea from that paper, but as you can see in the config file or in the code at the moment only "cat"-fusion is implemented.
Well actually I am running some instances, with fused IMU and Lidar I will upload the result, as soon, as the training is done.

I am also trying to implement some other fusion strategies to see whether the performance will be improved.
Which kind exactly?

Best regards
Arash

@ArashJavan, Thank you very much for the help! :) I will be glad to share my progress with you.

Well, in the beginning, I also did not normalize the IMUs, but the performance was really poor. mostly because the values are so differently scaled. But by normalizing them, the results were better.

This is really helpful. May I confirm that you calculate the mean and standard deviation using the training set or testing set or both?

Another thing is that using RNN results in better odometry inference at least with "hidden-size" set to greater than 64-neurons.

This is very interesting. Since I only use two images (maybe the same to set the seq-size to 1 in your project) as a training pair, I use FC-layers instead of RNN for pose regression. With seq-size set to 1, is it still worth using RNN instead of FC-layers?
And I am interested in why RNN can help improve odometry inference results. I am quite new to RNN and I would like to confirm something with you. During training, RNN is fed with sequence data (with the dimension of seq_length equal to 3 in your project) and it may learn more temporal information hidden in the data, While during testing, the RNN is fed with two frames (with the dimension of seq_length equal to 1), is this true?

Which kind exactly?

I think I will try to implement the soft-fusion in the paper first, then check whether IMU features are appropriately re-weighted by the soft-fusion layer. (Since my networks works well when the IMU is disabled, I am afraid the soft-fusion network may weight IMU features with zero)
Best regards,
beniko

@Beniko95J , with pleasure!
Yes, mean and std are calculated using just training dataset (seq.  00, 01, 02, 04, 05, 06, 07, 08).

I use FC-layers instead of RNN for pose regression.

For pose regression, IMHO there is no other choice than just taking linear regression. since the output of RNNs are typically normalized (because of tanh (-1, 1) or sigmoid 0-1). But what i mean was using an RNN-Layer before regression, e.g. the odometry-feature-layer in DeepLIO.
Also I did some tests with larger sequence-sizes
  sequence-size: 5 # must be >= 1   combinations: [[0, 1], [0, 2], [0, 3], [0, 4],[0, 5], [1, 2], [1, 3], [1, 4], [1, 5], [2, 3], [2, 4], [2, 5], [4, 5]]
Which especially results in better estimation of orientation.

RNN is fed with sequen...While during testing, the RNN is fed with two frames

Yes, exactly.

I think I will try to implement the soft-fusion in the paper first
cool, share it, when you are done!

Hi, how are you these days? I tried to run your code but met some issues. The traceback is as follows:
Traceback (most recent call last):
File "deeplio/train.py", line 67, in
trainer.run()
File "/mnt/hdd6TB/zjiang/git/DeepLIO/deeplio/models/trainer.py", line 141, in run
self.train(epoch)
File "/mnt/hdd6TB/zjiang/git/DeepLIO/deeplio/models/trainer.py", line 238, in train
pred_f2g_p, pred_f2g_q = self.se3_to_SE3(pred_f2f_t, pred_f2f_w)
File "/mnt/hdd6TB/zjiang/git/DeepLIO/deeplio/models/trainer.py", line 332, in se3_to_SE3
R_cur = SO3.exp(w_cur).as_matrix() # spatial.quaternion_to_rotation_matrix(q_cur)
File "/home/zjiang/anaconda3/lib/python3.7/site-packages/liegroups/torch/so3.py", line 51, in exp
mat[large_angle_inds])
RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cuda:0 and cpu!
I think the problem is about the liegroups package. I install the package from the github page. Do you have any idea about this?
BTW, my environment is as follows:
Pytorch : 1.6.0
Python: 3.7.3
Cuda: 10.2
OS: Ubuntu 18.04
Thanks!

@Beniko95J , Hi, thanks, hope you are also doing well!
The issue you are facing, as you can see comes from liegroups package. I have already made a PR to the main repo, but until now I didn't get any response :(. Nevertheless, please usemy fork of "liegroups"-package, in this fork the issue is already fixed.
https://github.com/ArashJavan/liegroups
Good luck!
Arash

Thank you for the kind help and now I have started to train the model. I will tell you if I find anything interesting.
Good luck to you too!
Beniko

Sounds good! Cool, thanks for the update!

But what i mean was using an RNN-Layer before regression, e.g. the odometry-feature-layer in DeepLIO.

Sorry I did not find linear layer in forward function

sequence: 1
combination: [ [0,1] ]
Imu Shape: (1,1,15,6)
Batch * combination numbers * ?? * 6
What does 15 mean?

But what i mean was using an RNN-Layer before regression, e.g. the odometry-feature-layer in DeepLIO.

Sorry I did not find linear layer in forward function

Could you plz help answer this question?

@rginjapan IMU and LiDAR are not synchronized, so the number of IMU measurements between two LiDAR frames varies - something between 10 to 13 IMU measurements between two consecutive LiDAR frames. But for RNN we need a fix sequence length. So for this, all IMU measurements between two LiDAR frames are normalized by padding them to 15 measurements and feeling these padding with zero (0) values, which actually means no motion - see [here].(https://github.com/ArashJavan/DeepLIO/blob/master/deeplio/datasets/kitti.py#L218)

@rginjapan linear layers for pose estimation are not part of odom-feature-layer, but are applied after this - see here.

Thank you for your reply, I get it.

@rginjapan, great, you are welcome :)


Frontend: Create user's Profile page

Create Profile page according to Figma design. Do not worry about populating page with data.
https://www.figma.com/file/aCPl5eaWhbmEyVSBNTaNIq/Sprint-3?node-id=313%3A91

I am pretty much done with this issue expect that there are placeholder images for the profile picture and checkmark logo


inline method recursive call cause jadx into infinite loop

When running on Baidu Tieba apk, jadx ran into infinite loop. Eventually it will exhaust memory and show deep nested call on producing code for inline method recursive call.
Root cause:
Insngen.java line 743, need to check if the inline method is invoking recursively.

@newskysecurity
Current version of jadx doesn't contain any known infinite loops.
I also downloaded Baidu Tieba from this link http://c.tieba.baidu.com/c/s/download/pc, and it was decompiled successfully without any endless loops


Gold update

Navigation's gold generator was significantly changed in net212.
Updated test data from a new generator.

@ulex Thank you!


Feature request: MD Pull to Refresh

www.google.com/design/spec/patterns/swipe-to-refresh.html#swipe-to-refresh-swipe-to-refresh

This exists and is called ion-refresher.

Hello! Thank you for opening an issue with us!
As @pwespi points out, this already exists. If you have something else in mind other that what already exists via ion-refresher, please open a new feature request with those differences fully described (even if it is just an enhancement to the existing refresher) and I will make sure it gets moved into the feature requests repo.
Thank you for using Ionic


Add liveness, readiness probe for s3 pod

Add liveness, readiness probe for s3 pod
Signed-off-by: Saravanakumar<EMAIL_ADDRESS>

This change is

LGTM!


Adding field on Schedule Task to differentiate between Permanent Tasks and Temporary Tasks

I came into a problem where i have my System defined tasks , meanwhile in the run time i need to create many tasks which are temporary or single use only .
The problem here is its hard for me to filter the System Tasks and the temporary tasks .
Currently, for my convenience i am denoting Permanent Task and Temporary Task from title placeholder.
But i think , some kind of choice field would be better .
Or even an abstract model which can be helpful in such scenario.
I would be happy to submit a patch, what do you guys think about it ?

I would be happy if this is implemented.
Moreover, the task histories of a scheduled repetitive task could be shown on the scheduled task change form as an action button. This could be helpful to see the run history of the repetitive task. Thanks.

@MahesMnd , i have addressed your concern here at

https://github.com/shrawanx/django-q/commit/33b87d525bb69207bec8299d2d205aae0390bdaa
Is this what you wanted ?

And to address my issue , i have

https://github.com/shrawanx/django-q/commit/99500e8c66f6efc16eea9178d823e67c8f83623e


Unexpected Coverage Result When Testing with Jest

Version
1.0.0-beta.25
Reproduction link
https://github.com/AngusFu/vue-test-utils-jest-example
Steps to reproduce

Clone the link to minimal reproduction

Install dependencies and run npm test to get the coverage result.

Actually, following is what I did with the offical example vue-test-utils-jest-example ——

Clone official repo: https://github.com/vuejs/vue-test-utils-jest-example

Install dependencies

(Optional)  upgrade @vue/test-utils to 1.0.0-beta.25

Append following configurations to .jest in package.json (SEE vue-test-utils.vuejs.org):

"jest": {
   ...

    "collectCoverage": true,
    "collectCoverageFrom": [
      "**/*.{js,vue}",
      "!**/node_modules/**"
    ],
    "coverageReporters": [
      "html",
      "text-summary"
    ]
}

Run npm test

What is expected?
Coverage result just shocked me... How can this happen?
What is actually happening?

I believe<EMAIL_ADDRESS>caused this issue.


Unable to install when using react 18.

I'm not sure if it's compatible but i'm unable to install when using react 18.

Can you leave what the error message is?


added delete to list of methods for which we post json data. it will …

…still add url params to the query which needs to be removed once all API calls are changed to accept json for delete

LGTM


bug(datepicker): min date sticks to current date

Additionally fixed small issue in compare() in datepicker-inner.ts
But not sure if check in daypicker.ts should be removed.

this is great! thanks!


fix:The first theme image is highly out of range

Solve the problem of poor display effect caused by the height of the cover image exceeding the range under the first theme
Before modification

After modification

After the modification, the author information originally caused by the height cannot be displayed normally, and it can be displayed successfully now.

Thank you for contributing


Rename color_enum_t to Color in documentation

We discussed that in slack. And it looks like property color -> Color is much nicer than property color -> color_enum_t. So the consensus was something like: let's make enums equal to object types rather than scalars, as far as I understand. For many scalars types like int64 there is no reason of naming a variable int64.

Let's formalize the thoughts on this in #983

This is now part of https://github.com/edgedb/edgedb/pull/999, closing this one.


Can't read 0 as number

Here:
process.env.FOO = "0"
export const FOO = tsEnv.numberOrThrow("FOO")

Nice find! It must have something to do with the throwing logic, as the simple number() reading function works as intended.
I'll try to look into this later today and release a patch hopefully soon.


Clock: Time ambiguous during switch to/from Daylight Savings Time

Despite my timezone being set to Europe/Vienna, the clock module does not have any output, and the following log message appears during 2023-10-29 00:00 and 2023-10-29 01:00 UTC:
[2023-10-29 02:15:27.000] [error] clock: 2023-10-29 02:15:27 is ambiguous.  It could be
2023-10-29 02:15:27 CEST == 2023-10-29 00:15:27 UTC or
2023-10-29 02:15:27 CET == 2023-10-29 01:15:27 UTC
[2023-10-29 02:15:28.000] [error] clock: 2023-10-29 02:15:28 is ambiguous.  It could be
2023-10-29 02:15:28 CEST == 2023-10-29 00:15:28 UTC or
2023-10-29 02:15:28 CET == 2023-10-29 01:15:28 UTC
[2023-10-29 02:15:29.000] [error] clock: 2023-10-29 02:15:29 is ambiguous.  It could be
2023-10-29 02:15:29 CEST == 2023-10-29 00:15:29 UTC or
2023-10-29 02:15:29 CET == 2023-10-29 01:15:29 UTC

timedatectl has a very clear opinion on this:
kescher@laptop2 ~ $ timedatectl
               Local time: So 2023-10-29 02:18:24 CEST
           Universal time: So 2023-10-29 00:18:24 UTC
                 RTC time: So 2023-10-29 00:18:24
                Time zone: Europe/Vienna (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Closing, duplicate of #2615


feat: chain modal v2

Changes

Now you can choose any chains even if your wallet is not connected.
Works with siwe.
During connection process, it automatically selects the chain you picked earlier. Or the one you set as your default initialChain instead.
If you've set initialChain, the option to change networks will be hidden to prevent accidental switches.
The current chain will show up only even if you have one chain unless you set chainStatus to none

Screen recordings / screenshots
https://github.com/rainbow-me/rainbowkit/assets/53529533/fab003eb-5526-45ca-976d-f8a8afc2e702
What to test

Checkbox the chainModalOnConnect in the example app
Try opening the chain modal and switch through your desired chain
While connecting your wallet, confirm it connects to the chain you chose.
Set initialChain and check if the chain button is no longer visible.
Make sure everything works well with siwe. Test this connecting to your wallet first and then you should see chain button dissapear. This prevents users from switching chains with their connected wallet when they are not signed in yet.

Hi, can we expect this feature soon? Been waiting for this a while.

@0xartcro Apologies for this taking a while, we'll try to aim launching this as soon as possible. Please bear with us 🙏

Hey guys! Do you have any progress on this?

Hello! That would be super useful to have :)

@rakpawel Apologies for taking a bit long on this. We're deprioritizing this at the moment, but i'll let you guys know when it's merged 👍

@rakpawel @t0rbik Apologies for taking a bit long on this. We're deprioritizing this at the moment, but i'll let you guys know when it's merged 👍

+1 to getting this in

@Alexangelj We're aiming to get this in very soon.

@Alexangelj We're aiming to get this in very soon.

awesome, waiting with update to get it in :)

@rakpawel We'll have this PR on hold for now, since there might be some new EIP's introduced.

Any update on this? Our app would greatly benefit from that functionality.

Hey @DanielSinclair, why was this closed? Have been looking forward to this one for a while.

@rakpawel We'll have this PR on hold for now, since there might be some new EIP's introduced.

Where can we track this new EIP?


Out of the box Rancher has 2x Catalogues broken.

Rancher Server Setup

Rancher version: 2.5.9
Installation option (Docker install/Helm Chart): Docker (method on main website page)
Proxy/Cert Details: self-signed, testing

So I'm teh newb to Rancher and k8s still. I understand a lot of it conceptually, but I've spun up Rancher in a testing space for me to test it, break it, stuff like that.
Out of the box 4x of the included default Catalogues work, but 2x throw 403 errors. I suspect this is just incorrect URLs used, but i'm not sure, and this probably should get updated somewhere. Anyways, this is what I see on the catalogue page when each of the 2x baddy repos are refreshed:
Global	helm	https://kubernetes-charts.storage.googleapis.com/	master
Unexpected HTTP status code 403 from [https://kubernetes-charts.storage.googleapis.com/index.yaml], expected 200
Global	helm-incubator	https://kubernetes-charts-incubator.storage.googleapis.com/	master
Unexpected HTTP status code 404 from [https://kubernetes-charts-incubator.storage.googleapis.com/index.yaml], expected 200
My google-fu didn't really turn up solutions, so unsure how to proceed. Plus IMO this shouldn't be broken out of the box ;P

I think rancher guys disabled these but here is an article for you to reference https://helm.sh/blog/new-location-stable-incubator-charts/. Maybe rancher will update the links in the future

You're missing the point. If they're no longer accurate, used, or whatnot, then they either should be updated in the release version with the correct info or removed. But I'll check that out as an interim option, thanks.

As we move away from cluster manager to the cluster explorer, we are not including these catalogs as default options to enable, and they are already disabled in cluster manager which will eventually go away. Since this isn't a blocking problem I am going to close issue.

Ahh okay, didn't know if they were going to be relevant at all for future direction. Considering moving away from Cluster Manager I can see why the effort to address this really isn't worth it. No worries! Thanks for the insight :)


Issue with Flashlight loop, Seems to be running at all times even whilst weapon is put away

This is causing the Click noise to be heard at all and any times whilst pressing E I found this issue whilst developing another script in C# And Putting them both together hope my input helps, Here is an example video
https://www.mediafire.com/file/75krj5b6sgjbh6d/2022-02-11_21-23-38.mkv/file

8899e2e6bd52439d8e6fc33abd4aa4e998c39075 -  Fixed click sound being played while not holding any weapons and pressing E


1695 report tab

Coverage remained the same at 74.197% when pulling 89fe904c1e0a5159f59e6828310743d9985ec447 on 1695-report-tab into 0d49bd8304a7743bc12e99af19cb1a73b69da747 on master.


Flag for strict default function this types for call-site and assignability checking (--strictThis)

#6018 was originally going to add a --strictThis flag that made function this types default to void or the enclosing class (instead of any) for purposes of call-site and assignability checking, but that functionality was dropped (details).  This is a follow-up suggestion for the dropped functionality, whatever the flag ends up being named.

Please see https://github.com/Microsoft/TypeScript/issues/7689 for the relevant desing discussion

I just ran into a problem where the obvious solution would be that methods should default the this parameter to the this type.  Searching brought me here.  So the main problem is... performance?  In any case, I hope a --strictThis option makes it into TS sometime (adding my 👍 ).

Maybe we can revive this thing as I believe it would bring a lot of benefit.
Regarding the "backwards compatibility" problem - is this due to class-this context for methods which in reality should stay any because they are allowed to be called from different contexts? If yes, --strictThis could only implicitly set the context to class-this for methods which have a typescript implementation and actually use this in the method body. DefinitelyTyped could adapt step by step and  pure typescript code bases could use the improved type check right away.

I also hope this is added back. I just started using Typescript last week, and this is basically the only "type error" I run into in my all Typescript codebase. I hit it frequently when I am using an ES6 classes as a router/controller in my Express app, e.g. app.use(this.someClassFunction). In response to failing tests with an error like cannot access property someClassFunction of undefined, I just change the declaration syntax to ES7 function bind syntax class X { constructor() {} x: (req, res) => {} } but it would be nice to know about that at compile time instead of at runtime.
I've been impressed with Typescript in general but was very surprised to hear that it's not checked at compile time since I can't think of another typed language, where such an error is possible.

Hi, I was surprised that strict type checking for the this parameter is currently that limited and would like to see enhancements in future versions. Since the problem caused by the absence of type checking made it into the FAQ, it seems to be supising for many users.
As already mentioned in previous comments, the issues #3694 and #6018 have already proposed some changes and some of them were already implemented in the pull requests #4910 and #6739. Since there is a long history, I found it difficult to get an overview about the situation. I therefore tried to summarize it below. I hope that I did not mix up anything. At the bottom, I bring up my own thoughts about the current situation.
Implemented

:heavy_check_mark: Polymorphic this type
Proposed by #3694 and implemented by #4910. It has added a special type which represents the actual type of this which might be a subclass.
class C {
  newInstance(): this {
    // Error because 'this' my be a subclass.
    return new C();
  }
}

class D extends C {
  run() {
    // Works
    let x: D = this.newInstance();
  }
}

Within method bodies, this now has type this (as default).
class C {
  f() {
    // `this` and therefore `x` have type `this`. In previous versions, they
    // would have type `C`.
    let x = this;
  }
}

// However, for the users of the method, `this` is still considered to has
// type `any`. Even so it might cause a runtime error, the following compiles
// because `null` is assignable to `any`.
const c = new C();
c.f.call(null);

Note that TypeScript looses the “it might be a subtype” semantic when you are outside of the class.
class C {
  f(arg: this) {
    // Error because the method might require a subtype of C.
    this.f(new C()); // <-- Error
  }
}

declare let c: C;
// The method might still require a subtype of C but TypeScript does not
// have this kind of semantic outside of the class.
c.f(new C()); // <-- Compiles

:heavy_check_mark: Type specifications for this parameter
Proposed by #3694, refined by #6018, and implemented by #6739. There were proposals for different syntaxes but I only show the implemented one.
function f(this: string) {
  // A function that expects a string for the `this` parameter.
}

Note that this also works when a function is called as constructor. It then also specifies the type of the created object.
interface F {}
function F(this: F) {}
let f = new F(); // `f` has type `F`

:heavy_check_mark: Type checking for this parameter on call sites
Proposed by #3694, resumed by #6018, and implemented by #6739. It's about actually checking the argument for the this parameter.
declare function f(this: string): any;
const obj = {f};
obj.f(); // <-- Error, `obj` is not a `string`

Note that #3694 alternatively suggested that we could already fail when a function is assigned to an object that does not satisfy the this parameter. Then, the second line of the code snipped would already fail. However, it was never mentioned again (and I think it would be strange).

:heavy_check_mark: --noImplicitThis
Implemented in #6739 as replacement for --strictThis which will be described later. The --noImplicitThis causes a compilation error when you access this but the type of this is implicitly set to any. This can happen when you access this in the function body or when you use new.
function f() {
  this.x; // <-- Error because type of this is unspecified.
}

function C() {}
const c = new C(); // Error because type for `this` in `C` unspecified.

However, note that it does not check call sites of such methods. Since the default type for this is inconsistent inside and outside of the method body, the following still compiles without errors.
class C {
  f() {
    // Fine because `this` has type `this`.
    this.f();
  }
  g() {}
}

const c = new C();
// Fine because `C.f` has type `(this: any) => void`.
c.f.call(null);

:heavy_check_mark: Modified assignability checks
Proposed by #6018 and implemented by #6739. It allows assigning anything to the this parameter if the this parameter is void. Usually, only undefined (or null) can be assigned to void.
function f(this: void): void {}
const obj = {f};

// Passes `obj` to `void` but still compiles.
obj.f();
// Assigns `string` to `void` but still compiles.
const g: (this: string) => void = f;

:heavy_check_mark: Contextually typed this
Proposed by #6018 and implemented by #6739. In some cases, TypeScript will infer the type for this from the context. For example, when you directly assign a new function to a variable that has a declared type. The inferred type will only be used in the method body but not on call sites.
declare let x: (this: string) => void;
x = function () {
  // `this` has type `string`.
};

If the type for this is not specified by the target, this is contextually typed to the object where it is assigned to.
const obj = {
  x: 0,
  f: function () {
    // Ok, `this` is contextually typed as `typeof obj`.
    this.x;
  },
}

Proposed

:blue_book: New implicit type for this parameter (--strictThis)
Proposed by a comment in #3694 and further specified by #6018 but not yet implemented. The proposal is about adding a new compiler option like --strictThis which changes the default type for this from any to either this or void.
class C {
  f() {
    // Works since `this` is of type `this`, just as in current versions.
    this.g();
  }
  g() {}
}

const c = new C();
// Fails because `C.f` is of type `(this: C) => void`.
// Currently, TypeScript considers the type to be `(this: any) => void`.
c.f.call(null);

The type shall be this for method-style declarations and void for function-style declarations. Currently, it is always this in the method body, and any outside of the method body.
// type: (this: void) => void
function f() {}

interface I {
  // type: (this: void) => any
  g: () => any;
  // type: (this: this) => void
  h();
}

const obj = {
  // type: (this: typeof obj) => void
  // (However, I think it should be `(this: void) => void` as I describe later)
  g: function() {},
  // type: (this: typeof obj) => void
  h(): void {},
}

According to #7689, it has not been implemented because

it decreases performance by 5% to 10%, and
the difference for method-style declarations and function-style declarations might not be obvious for some users. (As a user that does not have that much experience with TypeScript, I want to mention that I kind of expected this difference until I found out that it does not exist.)

My thoughts

:large_blue_diamond: Safe method invocation still missing
A lot of stuff have already been implemented, but we are still kind of missing safe method invocations. For me, safe method invocations actually look like one of the most important motivations behind the topic. As of today, we only get safe method invocations if we always explicitly specify the type of this.
function schedule(callback: (this: void) => void) {}
class C {
  data = 10;
  f(this: C) {}
}
const c = new C();
schedule(c.f); // Error

The problem: If we miss the type specification for either schedule or f, everything compiles without errors. Additionally, one of both places might not be in our control. For example, setTimeout does not specify the type of this for the callback. Therefore, in many situations, users are not able to get safe method invocations even if they explicitly specify the type of this for all their functions and methods.

:large_blue_diamond: Use unknown instead of void
A few weeks ago, I started a project with TypeScript. At one point, I was quite confused that the following assignment works even so, it contradicts the description of void.
declare let x: (this: string) => any;
declare let y: (this: void) => any;
x = y;

The snipped compiles due to the modified assignability checks mentioned above. If we would use this: unknown instead of this: void, the special handling in the assignability checks would not be necessary, and it would not confuse new users like me. However, we can probably not revert the special handling since it would break a lot of existing code. However, if we want to change this in the long term, TypeScript could generate a warning whenever this is specified as void and recommend using unknown instead.

:large_blue_diamond: Revert part of Contextually typed this
I think an important objective is that the type for this is mostly consistent between the call-site and the method body. Whenever it becomes inconsistent, it enables incorrect usage. With this objective in mind, we should revert the contextual typing when the type is not specified.
const obj = {
  x: 0,
  f: function () {
    // Currently: Ok, `this` is contextually typed as `typeof obj`
    // Proposed: Error, because `this` is `void` (or `unknown`)
    this.x;
  },
  g() {
    // Continues to work sine it uses a method-style declaration
    this.x;
  }
};
// Currently: Ok, `obj.f` is typed as `(this: any) => void`
// Proposed (1): Ok, `obj.f` is typed as `(this: unknown) => void`
// Proposed (2): Error, `obj.f` is typed as `(this: void) => void`
obj.f.call(null);
// Currently: Ok, `obj.g` is typed as `(this: any) => void`
// Proposed: Error, `obj.g` is typed as `(this: typeof obj) => void`
obj.g.call(null);

interface I {
  x: number;
  f: (this: this) => void;
}
const obj2: I = {
  x: 0,
  f: function () {
    // Ok, `this` is contextually typed as `ThisType<I['f']>`
    // So, it does not change to the current behavior.
    this.x;
  },
};

I think the proposal in #6018 was kind of inconsistent in this regard.
// Copy from the proposal
interface I {
  f: (n: number) => string; // this: void
  g(n: number): string; // this: this
}
// Also from the proposal (but I removed a member)
let o = {
  data: 12,
  g: function() {   // this is inferred from the contextual type
    console.log(this.data);
  }
}
// However, I think we should use the same rules as for interfaces and
// look at the style of the declaration.
let p = {
  data: 12,
  g() {   // `this` has type of `p`
    console.log(this.data);
  },
  h: function() {   // `this` has type `void` (or `unknown`)
    console.log(this.data); // Error
  },
}

:large_blue_diamond: Avoiding performance hit
If I understood the conversations correctly, whenever we use this in the facade of a type, the type becomes generic, which then causes a loss in performance. As an approximation, we could avoid the usage of this in the facade but use the most specific concrete type we know.
class B {
  private x = 0;
  f() { // Has type `(this: B) => void` instead of `(this: this) => void`
    // Within the method body, we still consider `this` to have type `this`
  }
}
class C extends B {
  private y = 0;
  g() {} // Has type `(this: C) => void` instead of `(this: this) => void`
}
const c = new C();
// Compiles since due to the approximation, `this` has type `B` instead of `C`
c.f.call(new B());
// However, most cases like the following two are detected.
c.f.call(null); // Error
setTimeout(c.f, 0); // Error

Even if the correct deduction of the this type is not viable, at least "strict" should imply that the implicit coercion of this types is disallowed. The fact that
class Foo {
    _a = 5;
    f() { console.log(this._a); }
}
let foo = new Foo();
let cb: () => void = foo.f;
cb(); // oops

compiles under strict[^1] is just very unfortunate and leads to a lot of subtle errors that could be easily avoided even without a perfect deduction of the this type.
[^1]: Even changing f to mention an explict this type, as f(this: Foo) allows the assignment of foo.f to cb: (this: any) => void

I think I ran into this as well - https://www.typescriptlang.org/play?#code/MYGwhgzhAEAKCmAnCB7AdtA3gKGtNYAtvAFzQQAuiAlmgOYDcu0w6liArsBSogBQFiZdrToBKLMzwUAFtQgA6QfGgBefEXhM8AX2YQwATwBymvhJx48rNKhDwFIFHT6z5SzWO3Q9e+xWgAIxRAtXx4AHc4JFQ0PgByACEQ+K9sf2gONGCsgBMw4MCFAxNNJiyctFzzJiA - if you hover over the sayName on the second to last line, it says "Person.sayName()", which is wrong, because it implies it's a static method when it's actually an instance method.

which is wrong, because it implies it's a static method when it's actually an instance method.

Currently TS shows tooltip of instance properties/methods vs static properties/methods exactly the same.
Which could be optimized, but is unrelated to this item.

I hope that this feature will someday be included into the release :)

I ran into an issue that I'd love to avoid in the future via a flag like this:
class Foo {
	fighters = []

	popFighter() {
		return this.fighters.pop()
	}
}

class Bar {
	foo = new Foo()

	get popFighter() {
		// this ends up being the Bar instance here when called in JS
		// if the user doesn't know it needs to be bound here (like I didn't)
		return this.foo.popFighter
	}
}

const bar = new Bar()
// runtime error: cannot read properties of undefined (reading 'pop')
bar.popFighter() //?

class FooWithThis {
	fighters = []

        // can also use `this: this`
	popFighter(this: FooWithThis) {
		return this.fighters.pop()
	}
}

class Bar2 {
	foo = new FooWithThis()

	get popFighter() {
		// this ends up being the Bar instance here when called in JS
		// if the user doesn't know it needs to be bound here (like I didn't)
		return this.foo.popFighter
	}
}

const bar2 = new Bar2()
// TS will actually warn us here that the `this` context is wrong as long as it was explicitly typed 😍
bar2.popFighter()

// The problem is it's hard to know how a method on a class might be referenced like this when the
// class is being written.

TS Playground
I assume the actual implementation work involved must be relatively limited since TS can already identify this problem if the type is manually specified (which I was very impressed with!)? Could probably help catch quite a few of JS's notorious this-related gotchas.

Why would you use a getter there instead of popFighter() { return this.foo.popFighter(); } tho?

@ljharb This is a repro meant to be minimal not realistic.

Maybe it helps if I put everything I learned earlier in the form of a proposal. Note that I am not really an active TypeScript user at the moment, but I still think this is an important issue and I would like to see it fixed when I return to TypeScript eventually. It would be interesting to know if this proposal would have a chance of being accepted if someone created a Pull Request.
Problem Statement (Motivation)
The type of this is practically unchecked in many scenarios. This causes runtime errors which could otherwise be detected by TypeScript. These types of runtime errors often happen in combination with callbacks. They are common enough that they have their own entry in the FAQ of TypeScript.
Back when class components were still a thing in React, the official React documentation also spent a large portion of Handling Events discussing this problem as part of their introduction.
The option --noImplicitThis already tries to mitigate this issue, but --noImplicitThis doesn't work for method-style function declarations. Unfortunately, method-style declarations are often the more natural syntax for functions that are using the this parameter. Besides, many function types used for callbacks do not declare the type of this (e.g. setTimeout). This often makes declaring the type of this in function definitions ineffective, which makes --noImplicitThis ineffective as well.
This proposal introduces a compiler flag that allows the compiler to detect these types of errors at compile time. While the runtime error was an aftereffect (which was often delayed), with this proposal the compiler can pinpoint the problematic location in the source code at compile time.

Example Code with setTimeout
The following code runs into TypeError: this is undefined at the end of the second update. The first update runs through without issues. This proposal introduces the option --strictThis which causes a compile error at the first argument of setTimeout.
class LiveData {

  constructor() {
    this.update();
  }

  update() {
    // updae data ...
    setTimeout(this.update, 1000);
  }
}

Example Code with React (old style class component)
The following code runs into TypeError: this is undefined within handleClick when a user clicks on the toggle button. This proposal introduces the option --strictThis which causes a compile error in the render function.
class Toggle extends React.Component {
  constructor(props) {
    super(props);
    this.state = {isToggleOn: true};
  }

  handleClick() {
    this.setState(prevState => ({
      isToggleOn: !prevState.isToggleOn
    }));
  }

  render() {
    return (
      <button onClick={this.handleClick}>
        {this.state.isToggleOn ? 'ON' : 'OFF'}
      </button>
    );
  }
}

Example Code with Explicit Type Specification
Even when specifying the type of this explicitly, TypeScript may not detect the error. The following example compiles without error even with strict type checking enabled. The code fails to print Hello World! and prints undefined instead.
class MyClass {
  private text = "Hello World!";

  logText(this: MyClass) {
    console.log(this.text);
  }
}

const instance = new MyClass();
setTimeout(instance.logText, 1);

Open in Playground
As long as either logText or setTimeout does not specify the type explicitly, the current TypeScript compiler does not detect the error. As of today, functions like setTimeout do usually not specify the type of this in their declarations. Even if you try the specify the type everywhere, this is also something which can easily be forgotten.

History
The type of this has been the topic of many issues over the years. The first issue I am aware of is #229. Later, proposal #3694 explicitly declared “Safe method invocations” as part of the motivation. Its implementation in #4910 was eventually narrowed down. The topic was picked up again by #6018, but its implementation in #6739 was also narrowed down eventually.
While #4910 and #6739 introduced many of the necessary fundamentals, the goal of “Safe method invocations” is still not achieved in practice today. Two issues make type-checking of this ineffective:

Implicit use of this: any in function type-declarations.
(These function-type declarations are often defined by libraries and used for callbacks.)
The implicit type of this is inconsistent inside and outside of functions.
(Inside method-style functions, TypeScipt implicitly declares this as having the polymorphic this type. Outside the function, the type is declared as this: any.)

Concerns that led to narrowing down the proposals included some resistance to introducing new compiler flags which might not work well with existing declarations in libraries (including DefinitelyTyped). Another concern was the impact on the compiler performance, but it might have been specific to the previous solution. Some resistance to introducing too many changes at once might also have played a role.
Goals

Make strict type checking of this effective on call-sites.

Provide a (mostly) consistent type for the this parameter inside and outside of functions.
Make void the default type of this in function types.

Changes
New compiler option --strictThis
The proposal adds --strictThis as a new compiler option. You may use it by specifying --strictThis as a command line argument or by adding "strictThis": true below "compilerOptions" in the tsconfig.json.
The new option changes the implicit default from this: any to this: void in function-style declarations and function types. In method-style declarations, the default changes from this: any to the type of the surrounding structure. Consider the following code in TypeScript.
type Callback = () => void;
const obj = {
  func: function () {},
  method() {}
};

Without --strictThis and in previous versions of TypeScript, the effective types match the following declarations:
type Callback = (this: any) => void;
declare const obj: {
    func: (this: any) => void;
    method: (this: any) => void;
};

When --strictThis is enabled, the effective types instead match the following declarations:
type Callback = (this: void) => void;   // this: any -> this: void
declare const obj: {
    func: (this: void) => void;         // this: any -> this: void
    method: (this: typeof obj) => void; // this: any -> this: typeof obj
};

If the new option is enabled, --noImplicitThis becomes obsolete. If both options are enabled, --noImplicitThis shall be ignored. In all scenarios where --noImplicitThis would prevent the usage of this, --strictThis will implicitly declare this: void and therefore also effectively prevent its usage. There shall be no error if both options are enabled to allow the combination --strict, which implies --noImplicitThis.
Type of this in function types (--strictThis only)
If --strictThis is enabled, the default type of this in function types becomes void. Otherwise, TypeScript continues to use any as the default type.
type Callback = () => void;
//   ^ --strictThis disabled: (this: any) => void
//     --strictThis enabled:  (this: void) => void

Type of this in method-style declarations (--strictThis only)
The default type of this is not changed within the body of method-style declarations.
class Class {
  method() {
    type self = typeof this;
    //   ^? type self = this
    // (Just as in previous versions, independent from --strictThis)
  }
}

However, the type of the resulting function changes if --strictThis is enabled. Consider the following code.
class Class {
  method() {}
}

In previous versions of TypeScript or when --strictThis is disabled, the effective types match the following declaration:
declare class Class {
    method: (this: any) => void;
}

When --strictThis gets enabled, the effective type changes. Method style declarations will use the type of the surrounding structure as the type for this. The effective types therefore match the following declarations:
declare class Class {
    method: (this: Class) => void; // this: any -> this: Class
}

Method-style declarations in interfaces (and object literals) are equally affected by --strictThis.
interface Interface {
  // --strictThis disabled: method: (this: any) => void
  // --strictThis enabled:  method: (this: Interface) => void
  method(): void;
}

Note that the usage of the surrounding structure as the type is an approximation. Using the polymorphic this type would be more correct, but a previous implementation ran into a performance degradation (#7689). The polymorphic this type might have caused the performance degradation as it made all methods generic.

Type of this in function-style declarations
The default type of this changes to any within the body of function-style declarations when --strictThis is disabled. (It looks like this is already the case in current versions of TypeScript according to my tests on the Playground. I just list it as a change because I thought it was different in some previous version and I am not sure if I missed something.)
class Class {
  func = function() {
    type self = typeof this;
    //   ^? type self = any
    // (Wasn't it "self: this" in some previous versions?)
  }
}

When --strictThis is enabled, the default type of this changes to void.
class Class {
  func = function() {
    type self = typeof this;
    //   ^? type self = void
  }
}

This change also affects the type of the resulting function. This means the effective type of Class["func"] is (this: void) => void when --strictThis is enabled.
Future Work

--strictThis can be made a part of --strict, assuming the community has generally accepted this option and libraries had some time to adjust their type declarations.
--noImplicitThis might be deprecated in favor of --strictThis.

Note: Void vs Unknown
In the current version of TypeScript, this: void behaves mostly like this: unknown. The usages of void in this proposal could technically be replaced by unknown without changing any of the arguments. I am using this: void for consistency with previous implementations. Note that the documentation of void currently only describes its meaning when used as the return type. Also note that ThisParameterType<() => void> currently results in unknown, which is inconsistent with this proposal. It might make sense to also change the behavior of ThisParameterType when --strictThis is enabled, or alternatively change the proposal to use this: unknown as the default.


Data types selection limited to (cid, oid, tid, varchar, xid) for column definition - Version <IP_ADDRESS>910061950 - ops Debian 10 - Postgresql version 11 -  This issue occurs sporadically, it happened in a previous version

System information:

Operating system (distribution) and version
DBeaver version
Additional extensions

Connection specification:

Database name and version
Driver name
Do you use tunnels or proxies (SSH, SOCKS, etc)?

Describe the problem you're observing:
Steps to reproduce, if exist:
Include any warning/errors/backtraces from the logs

there is no update for the ticket more than a month. ticket closed


Exclude overlapping bases not necessarry to be in "GHIF WGS QC all the Metric definitions" googledoc

https://github.com/c-BIG/NPM-sample-qc/blob/aa21ba718d0612426246bf14edd3c59385c3441a/bin/metrics/metrics.py#L18
can be removed from the list of the metrics definition where it's not relevant?

See in the latest metrics_definitions.md https://github.com/ga4gh/quality-control-wgs/pull/7
https://github.com/ga4gh/quality-control-wgs/blob/main/metrics_definitions/metrics_definitions.md


[BUG] Permission Denied when Yarn start or Yarn dev

Describe the bug
Permission is denied when running Yarn start or Yarn dev on Linux based machine.
To Reproduce
Steps to reproduce the behavior:

Clone and bootstrap the repo
Yarn build
Yarn start or Yarn dev

Expected behavior
App should start up fine, shouldnt need permission to do so.
Screenshots

Setup

OS: Linux based machine
Browser: All

Additional context
All helper icons can be changed to show only plain text rather than HTML code.

PR #96 merged.


[Improvement] Refactor CI

Purpose
Refactor CI

Split release and regular push,pull request
Create front-end check CI
Split front-end check CI and back-end check CI

Tests

API and Format

Documentation

#456


DEV backend pointing to PROD Forest Client

Backend is configured to point to the Forest Client API in PROD.  This is obscenely bad for development, since changes need to go all the way to production before they can be properly tested.
Worse still, this appears to have been configured MANUALLY so the problem could not be uncovered with a search.
https://console.apps.silver.devops.gov.bc.ca/k8s/ns/b9d53b-dev/secrets/nr-spar-backend
data:
  allowed_origins: http://localhost:300*,https://*.apps.silver.devops.gov.bc.ca
  forest-client-api.address: https://nr-forest-client-api-prod.api.gov.bc.ca/api
  forest-client-api.key: <REDACTED>
  keycloak-realm-url: https://test.loginproxy.gov.bc.ca/auth/realms/standard

Apparently this data is in consideration for public publishing, so I'd like to walk back the severity of the above comments.
Handling of this config has been completed, with TEST API configured and available, but not default in the corrent workflows.


stub

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Other information

Codecov Report
Base: 60.51% // Head: 47.48% // Decreases project coverage by -13.02% :warning:

Coverage data is based on head (2010486) compared to base (d9f7ffb).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff             @@
##           master     #412       +/-   ##
===========================================
- Coverage   60.51%   47.48%   -13.03%
===========================================
  Files         234      233        -1
  Lines       25313    25299       -14
===========================================
- Hits        15317    12014     -3303
- Misses       9034    12577     +3543
+ Partials      962      708      -254

Flag
Coverage Δ

1.16.x
46.95% <ø> (-13.22%)
:arrow_down:

1.18.x
38.32% <ø> (-22.07%)
:arrow_down:

1.19.x
47.48% <ø> (-12.75%)
:arrow_down:

connection
?

database_sql
?

discovery
?

e2e
27.90% <ø> (-21.15%)
:arrow_down:

integration
?

macOS-latest
38.32% <ø> (+0.03%)
:arrow_up:

ratelimiter
?

scripting
?

table
27.90% <ø> (-0.11%)
:arrow_down:

topic
?

ubuntu-latest
47.46% <ø> (-13.04%)
:arrow_down:

unit
38.30% <ø> (+0.01%)
:arrow_up:

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

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


EmptyStream isn't used

Hi there, thanks for putting this library together! I noticed that you've defined EmptyStream and even handle it in ActivationBuffer.__next__, but it's never thrown. As an experiment I changed my dataset to have only a single point and this triggered an exception (which from my reading of the code it shouldn't have).
Traceback (most recent call last):
  File "/home/joel/code/mamba-train/analyze_sae.py", line 180, in <module>
    run(args)
  File "/home/joel/code/mamba-train/analyze_sae.py", line 154, in run
    result = evaluate(model, submodule, ae, buffer)
  File "/home/joel/code/mamba-train/dictionary_learning/evaluation.py", line 82, in evaluate
    acts = next(activations).to(device)
  File "/home/joel/code/mamba-train/dictionary_learning/buffer.py", line 103, in __next__
    self.refresh()
  File "/home/joel/code/mamba-train/dictionary_learning/buffer.py", line 223, in refresh
    self._refresh_std()
  File "/home/joel/code/mamba-train/dictionary_learning/buffer.py", line 156, in _refresh_std
    tokens = self.tokenized_batch()["input_ids"]
  File "/home/joel/code/mamba-train/dictionary_learning/buffer.py", line 129, in tokenized_batch
    texts = self.text_batch(batch_size=batch_size)
  File "/home/joel/code/mamba-train/dictionary_learning/buffer.py", line 123, in text_batch
    return [next(self.data) for _ in range(batch_size)]
  File "/home/joel/code/mamba-train/dictionary_learning/buffer.py", line 123, in <listcomp>
    return [next(self.data) for _ in range(batch_size)]
StopIteration

Thanks for pointing this out, and sorry it took so long to resolve. As of the last update, I think this should be fixed.


Allow tests to run without numba

Refactored tests for "pytest-style"
Conditionally run tests requiring numba
Note that one can run pytest with the "-rs" flag to report
on the reason for some tests being skipped.

Note that I haven't actually run these tests since I don't have Julia on this particular computer. Feel free to push into this branch if I messed up.

Seeing if the CI failures were a fluke.

Looks like CI is failing @tkf can you incorporate this into yours? Maybe this just needs a rebase.

Handled via https://github.com/JuliaDiffEq/diffeqpy/pull/14


Auto open ipynb file in jupyter does not work after update vscode

Environment data
version: 1.54.1 (user setup)
commit: f30a9b73e8ffc278e71575118b6bf568f04587c8
date: 2021-03-04T22:38:31.419Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.18363
Expected behaviour
Auto open ipynb file in jupyter
Actual behaviour

Auto open ipynb file does not work .

@CatNofishing if you right click on the file in the side panel do you still see the option to open with the preview notebook editor?

Could you also please provide logs from the Jupyter output panel?

Thanks for your help 😊


Request: add validsense.com to the filter

Evidence: https://validsense.com/1642028/what-is-the-operator-in-c-c/
Original: https://stackoverflow.com/questions/1642028/what-is-the-operator-in-c-c

Thanks a lot!


WIP: refactor to separate server and hocuspocus

The following PR has breaking changes and is thus intended for a major release. Feedback is highly appreciated.
With this PR we moved the server logic into it's own server class (Server.ts). The server class then will use hocuspocus like you would mostly also use it as a library in other frameworks. This changes the way how you use hocuspocus though.
The goal is to make hocuspocus more flexible for further development. Without any server logic, hocuspocus could potentially run on edge services like cloudflare workers in the future. Also it is easier to extend the server with new functionalities such as additional APIs.
New usages
There are two ways on how you can use hocuspocus.

Usage within other frameworks like express (omitting most of express related stuff for better readability):

import { Logger } from '@hocuspocus/extension-logger'
import { Hocuspocus } from '@hocuspocus/server'

# ... other express stuff.
const { app } = expressWebsockets(express())

const hocuspocus = new Hocuspocus({
  extensions: [
    new Logger(),
  ],
})

app.ws('/:documentName', (websocket, request: any) => {
  const context = { user_id: 1234 }
  hocuspocus.handleConnection(websocket, request, context)
})

app.listen(1234, () => console.log('Listening on http://<IP_ADDRESS>:1234…'))

Usage with it's standalone server:

# Notice that you now import the Server and not Hocuspocus anymore.
import { Server } from '@hocuspocus/server'
import { Logger } from '@hocuspocus/extension-logger'

const server = new Server({
  port: 1234,
  extensions: [
    new Logger(),
  ],
})

server.listen()

We also changed the parameters of the .listen() method:
# Old:
async listen(
  portOrCallback: number | ((data: onListenPayload) => Promise<any>) | null = null,
  callback: any = null,
): Promise<Hocuspocus> { ... }

# New:
async listen(port?: number, callback: any = null): Promise<Hocuspocus> { ... }

This simplifies the usage of hocuspocus while you can still reach the same behavior as before. You are also still able to configure port and callbacks within the constructor of the Server.
Breaking
.configure() still exists on hocuspocus but not on the server. We also do not export instances anymore but only the classes. Thus, it is no longer possible to use hocuspocus like:
import { Server } from '@hocuspocus/server'

const server = Server.configure({...})

server.listen()

Because the .listen() method was removed from hocuspocus and moved to the server, you can no longer use it like:
import { Hocuspocus } from '@hocuspocus/server'

const server = new Hocuspocus({...})

server.listen()

TODO:

[X] Tests have to be updated for new usage.
[X] The configuration flow in the server is not optimal yet and should be improved.
[X] Perhaps server-specific configurations, such as port and address, can be removed from Hocuspocus configuration altogether and only kept in the server.
[x] Update documentation
[x] Write migration guide

Hey there, any news on this? Would love to deploy Hocuspocus on cloudflare :)


dns-sd name conflict resolution leads to space in name, causing malformed host header and failure to pair

First off: love this package! Recently I tried to re-pair an accessory. Pairing with the Home app times out. With the hkontroller example app it pairs successfully. I made a packet dump, and I found the following difference.
hkontroller sets an empty host header, whereas the Home app send Host: Incomfort_Gateway\0322._hap._tcp.local. Go's http server doesn't like that, responding with a 400 Bad Request: malformed Host header.
Now, I'm not sure who's at fault here. Btw, dns-sd -Z _hap._tcp local. returns
_hap._tcp                                       PTR     Incomfort_Gateway\0322._hap._tcp
Incomfort_Gateway\0322._hap._tcp                SRV     0 0 33133 BB804B1E71D9\0322.local. ; Replace with unicast FQDN of target host
Incomfort_Gateway\0322._hap._tcp                TXT     "c#=2" "ci=9" "ff=0" "id=BB:80:4B:1E:71:D9" "md=Incomfort Gateway" "pv=1.0" "s#=1" "sf=0" "sh=5oin+Q=="

This was on Linux. When tetsting on Mac, the advertisement is Incomfort_Gateway._hap._tcp and that does work.

Related iOS misbehaviour radar: http://openradar.appspot.com/radar?id=4931940373233664

Mac vs Linux was a red herring. The crucial difference was that the Linux machine had two interfaces. For some reason this caused dnssd to retry and land on the name Incomfort_Gateway 2. This in turn hit the earlier mentioned iOS bug. Restricting to a single interfaces by setting Server.Ifaces fixes it. Surprisingly changing dnssd to use _2 (etc) instead of  2 doesn't work.

Surprisingly changing dnssd to use _2 (etc) instead of  2 doesn't work.

Are you sure about that? When you make that change, does the Home app send a different Host header – I expect it to be _2.

I didn't get to that point yet: dnssd would keep incrementing the counter and not land on a name it thinks is free.

Ok, so I've made two changes to dnssd, which should fix your issue.

brutella/dnssd@64826ad5bebdb368802a976ced703497bc7457c6 Suffixes for hostname conflict resolution doesn't contain spaces anymore; instead of name 2 it will be name_2.
This should prevent the issue that iOS sends a wrong http host header field as described in http://openradar.appspot.com/radar?id=4931940373233664
brutella/dnssd@6f66c93b969dcf4bbaaa2bbeb5b829191cd0e5cf Hostname conflicts, because of multiple network interfaces, are now fixed.

Those changes are now in v0.0.34.

That fixed it. Thanks.


Surface Tube Placement Warning

When placing surface tubes, attempting to place on non-dozed terrain will silently fail. Buildings will give a helpful error in the same circumstances, tubes should too.
I don't mind working on this, feel free to assign to me

Alright, this is a pretty straight forward task, give it a go! :D

Will do!


How to update join table in habtm association when creating new item

Hello,
I have 2 models Item and Provider linked with habtm association via a items_providers join table. When creating the Items i use the f.association helper to select existing providers. The issue is when i create the item the join table is not update. Please help me figure out how properly implement this. Thanks in advance.

Please use StackOverflow for questions/help, where a wider community will be able to help you. We reserve the issues tracker for issues only.


Consider how to document available gates

Could we generate from circuit.py? Should we give example unitaries? Should we point at the ISA paper?
We need to think through what the best approach is to this.

Gates (and all bosonic-qiskit classes) are documented at https://c2qa.github.io/bosonic-qiskit/c2qa.circuit.CVCircuit.html


Overlay not working

Hi , Thanks for your amazing library.
I am having issues working with PConfirmPopup and other overlay controls.
It seems like the confirmationService or overlay service is injecting the control to main document (which does not contain any stylesheet) which is why the overlay does not have any styles. I have tried using the directive you provided in the library but it won't work. In your demo app, you are linking the style.css to the index.html which is why the overlay is working .
I need to encapsulate the entire CSS of my web component so linking is not a solution for me.
Please help!

Here the div container for overlay or popConfirm is appended to the main body instead of shadowRoot.

I am just sending a click event to this function and rendering the pop confirm:
   confirmDelete(event: Event,node) {
      event.preventDefault()
      event.stopPropagation()
      this.confirmationService.confirm({
          target: event.target as EventTarget,
          message: 'Are you sure that you want to delete this page?',
          icon: 'pi pi-exclamation-triangle',
          accept: () => {

          }
    });

Also, I am using following versions in my app.
 json  "@angular/animations": "^16.2.0",     "@angular/common": "^16.2.0",     "@angular/compiler": "^16.2.0",     "@angular/core": "^16.2.0",     "@angular/elements": "^16.2.5",     "@angular/forms": "^16.2.0",     "@angular/platform-browser": "^16.2.0",     "@angular/platform-browser-dynamic": "^16.2.0",     "@angular/router": "^16.2.0",     "primeicons": "^6.0.1",     "primeng": "^16.3.1",     "primeng-shadowdom-directives": "^0.2.2",     "rxjs": "~7.8.0",     "tslib": "^2.3.0",     "zone.js": "~0.13.0"

This is issue not related to the problem my lib sovles.
Your issue is because you're trying to append the overlay component to body. Meanwhile PrimeCSS is not available at document root context.
Thats why in my demo you see I need to have PrimeCss in styles.scss to make sure PrimeNG style is global for this case.
There's no choice :)

Is there any way to resolve this?
Any place that you can point me at to fix this?
Any help is appreciated.

You have to choice of not "appendTo=body" then it'll be rendered inside shadowDom. In that case you can do import style directly from your component file with "styleUrls"

How do I append it to shadow DOM?  The confirmation service is always adding it to the main body

Yes, all overlay components have "appendTo" pls check PrimeNG docs
https://primeng.org/dropdown#api.dropdown.props.appendTo

From why I know, default it should be render inside shadowDOM
You can run example project in repo and check

It seems like they don't have the appendTo for pConfirmDialog..I'm not sure if there's any fix for this

Confirm dialog does have bro
https://primeng.org/confirmdialog#api.confirmdialog.props.appendTo

I am using confirmPopup. Sorry for the confusion.
https://primeng.org/confirmpopup
I can't find its appendTo

I tried rewriting its implementation but tough luck..I can see the control puts it to the document body in confirmPopup.ts file.
`js
onAnimationStart(event: AnimationEvent) {
if (event.toState === 'open') {
this.container = event.element;
this.renderer.appendChild(this.document.body, this.container);
this.align();
this.bindListeners();
        const element = this.getElementToFocus();
        if (element) {
            element.focus();
        }
    }
}

`

Hi @Sabin-Adhikari you better raise a PR in PrimeNG and ask for this. Or implement your own, but not recommended.

Thanks a lot man! I got it working finally after using appendTo and custom directives .

Resolved!

Great to hear that.
You may want to make sure data binding is reflected correctly in the UI when using your custom directive.


Note the dependency on javascript-lint.js

Similar to css-lint.js & json-lint.js etc, it would be useful to mention the javascript-lint.js dependency.
e.g.
// Depends on jshint.js https://github.com/jshint/jshint

Makes sense. Want to submit a pull request?

Want to submit a pull request?

Which branch to? master?

Yes

done

Thanks!


Serial number under diagnostic in HA?

Describe the solution you'd like
Have several traps here on the table and it would be nice to have the serial number/id in the diagnostic overview, it's lister under battery and  other entities but you have to find it, not intuitive or quick and easy.

Forgot to mention that the ID is the name of the trap until you rename it, then the ID is not displayed anymore.


What are examples for initialQuery?

For example, can I pass coordinates or is this intended more for human readable addresses?
If yes to lat/long, how should they be formatted?
The docs here, just say that it's an "initial query", but don't really indicate a meaning:
https://developers.google.com/places/android-sdk/reference/com/google/android/libraries/places/widget/Autocomplete.IntentBuilder.html#setInitialQuery(java.lang.String)

This is intended to be a human readable query string


DO NOT MERGE: TESTING NEW F29 RUNC

This is temporary, just to give karma to https://bodhi.fedoraproject.org/updates/FEDORA-2019-6174b47003

Passed.  Added Karma.


Tables: rendering to PDF, Word

I added some comments to the MD demo file on approaches to reliably rendering tables in PDF and Word (related to Issue #2).  Also updated header.tex file to include multirow.
Currently, the comments suggest to manually format tables in a table generator then render in LaTeX. Based on links you had shared previously, there are ways to program tables in Pandas and render to LaTeX, with (fancy) formatting. I'm not sure what is the most general/user-friendly way to include this approach in the demo files. It might mean including a Python file. Or place some template code in the demo MD file. Any thoughts?
Cheers

PS. From further mucking around with the Pandas to_latex() function (since I'm on a roll!) it seems quite difficult to exactly custom-format tables programatically, simple or multi-index ones. The Youtube videos show wonderful render of Pandas tables to LaTeX. But I can't seem to get Pandoc to render to Word, not just PDF, in the identical format (at least at this point). It's little things like a shared 'superheader', adding horizontal lines where a user might want them, and custom-formating column names in math format. I could still add some code that does work though.
Could be worth playing around further when have energy. But given that tables are variable between users and datasets, it seems more bomb proof to programatically obtain a spreadsheet of table data, then manually format in a LaTeX table generator before passing to papermate/pandoc. Just a thought; open to discussion.
A future next step might be to build in the line pandoc tables.tex -f latex -t docx -o tables.docx into papermate to separately render tables in Word


Is it a good idea to split the lowlevel and highlevel as separate crate?

It seems that the API of lowlevel and highlevel aren't that tightly coupled.
Changes to the lowlevel can often be wrapped up by the highlevel, thus not posing a breaking change in the highlevel API, yet with the current model, users of the highlevel API are also forced to bump their major version number.
Splitting them into two different crates would make it possible to release these crates separately at different pace, though it would make the maintenance of it a bit harder.
If we are going with this new release model, shall we use the workspace features so that all scripts and ci setups can be shared between them, or shall we create a separate repository for the lowlevel part?

I think splitting into two crates makes a lot of sense, and if you do I'd certainly recommend doing so through a workspace.

I actually ended up creating 3 workspaces:

openssh-sftp-client-lowlevel for the lowlevel interface
openssh-sftp-error for the error type shared by lowlevel and highlevel interface. Checkout #13 for the rationale.
sftp-test-common for building the sftp-portable and all the functions shared by integration tests.


Return missing on implicit class return value

swc_bundler specific used in Deno.
Describe the bug
implicit return is transformed into explicit return without return keyword if return value is a class.
Input code
Input:
const fn = () => class Bug {}
console.log(fn())

Output:
const fn = ()=>{
    /* missing return */ class Bug {
    }
};
console.log(fn());

Expected behavior
No transformation to explicit return OR with transformation to explicit return with return keyword.
Either
const fn = () => class Bug {}
console.log(fn())

or
const fn = ()=>{
    return class Bug {
    }
};
console.log(fn());

Version
swc_bundler = "0.34.0"
Additional context
Appeared when using Deno.emit.
https://github.com/denoland/deno/blob/6044b037fb3efd638e599f39da2b28f53c915319/cli/ast.rs#L146-L183

I think it's already fixed with recent version of swc_ecma_transform_typescript.
Maybe I forgot releasing it, but it's fixed on master.


How to center a node on from external event

Hi, Really sorry if I wasn't suppose to ask this question. But I really tried everything I could to center a node on render. But couldn't.
I saw the example on code sandbox. It is setting the dimention of tree container. I have also set dimention like that.
    <div
      id="treeWrapper"
      ref={containerRef}
      style={{ width: "100%", height: "100%" }}
      className="fixed"
    >
      <button onClick={handleCenterUser} className="absolute top-4 right-28">
        Center Me
      </button>

      {data ? (
        <Tree
          dimensions={dimentions}
          data={data}
          scaleExtent={{ max: 10, min: 0.3 }}
          pathFunc={stepPathFunc}
          pathClassFunc={customPathClass}
          nodeSize={nodeSize}
          translate={translate}
          orientation="vertical"
          enableLegacyTransitions
          renderCustomNodeElement={(rd3tProps: any) =>
            renderForeignObjectNode({ ...rd3tProps, foreignObjectProps })
          }
        />
</div>

  const handleCenterUser = () => {
    const user = document.getElementById("isuser");
    if (user && containerRef.current) {
      const { x, y } = user.getBoundingClientRect();
      const { height, width } = containerRef.current.getBoundingClientRect();
    }
  };

I am able to get height and width of the container and the x & y cordinates of the node that I want to center. But I am unable to center the node using translate. When I translate using those cordinates I can't move the tree freely.

Just weighing in to say, that I also want to be able to trigger centering/focus on a node externally. User clicks a "show me" button, and the tree centers on their node.

Any update on this? Implementing a "search" functionality and would need to A) open the search result node if it is closed, and B) need to center to it

The way I wound up doing it is making a list of all the nodes with a queryselector. Each node has a "transform" attribute that has the values you must subtract from the container values like so (and then pass in translate as the translate prop on the Tree)
onGoToItem(item)
const x = item.attributes.transform.value.split(",")[0].split("(")[1];
const y = item.attributes.transform.value.split(",")[1].split(")")[0];
const width = containerRef.current.getBoundingClientRect().width;
const height = containerRef.current.getBoundingClientRect().height;
const xTranslate = width / 2 - parseFloat(x);
const yTranslate = height / 2 - parseFloat(y);
return setTranslate({ x: xTranslate, y: yTranslate });


Automatic typename handling

Newtonsoft has a concept of TypeNameHandling which gives the possibility to include type information when serializing JSON so that de-serialization can be successfully completed without any major hassles even in those situations where exact type of incoming message is not known to the receiving application before inspecting that message itself.
Looked around in Options class but couldn't find anything resembling that in Jil.
Could this feature be added? @kevin-montrose

You should be extremly careful with TypeNameHandling. It is widely considered a possible security problem. See https://stackoverflow.com/questions/48159442/is-it-possible-to-set-json-net-to-ignore-type and watch the linked video there.

Interesting. But what can you do when you have literally thousands of different object types coming from an enterprise service bus towards hundreds of different services.
The way we handle that situation is by providing a central client library which does the heavy lifting, along with the help of automatic type name handling.
I'm sure there might be other good (architectural) alternatives to this which give the benefits of a single client library for hundreds of different services and at the same time address security along with relatively painless mapping of thousands of different object types but unfortunately a rather significant investment has already been made, so we won't be re-architecting anything soon.
The reason I posted this questions is because Jil is much much more performant compared to Newtonsoft. If it had automatic type name handling, it would be a no-brainer.

Jil will not be adding this feature.  Generally, I try to keep it as close to "proper" JSON as I can: no comments, no $type, etc.
If you need more customization, at least as things are today, I think Newtonsoft is a fine option.


[#211]phone number to allow space and plus

fixes #211

Codecov Report

Merging #248 (569c687) into master (aa88a3b) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #248   +/-   ##
=========================================
  Coverage     70.71%   70.71%
  Complexity      629      629
=========================================
  Files            96       96
  Lines          2049     2049
  Branches        227      227
=========================================
  Hits           1449     1449
  Misses          522      522
  Partials         78       78

Impacted Files
Coverage Δ

...rc/main/java/seedu/address/model/person/Phone.java
90.00% <ø> (ø)

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 aa88a3b...569c687. Read the comment docs.


Cannot resolve caller AUTOGEN

I'm getting the following error when trying to use Bailador:
Cannot resolve caller AUTOGEN(Bailador::App: Int); none of these signatures match:
    (Bailador::App $: *%_)
    (Bailador::App $: Str $command, *@args, *%_)
  in sub baile at /home/tyil/rakudobrew/moar-nom/install/share/perl6/site/sources/6F33C03589936F3E254B5C14BC95945C77196A75 (Bailador) line 157
  in block <unit> at t.pl6 line 9

The script I'm running is
#! /usr/bin/env perl6

use Bailador;

get "/" => sub {
	say "hi";
}

baile(8000);

perl6 --version: This is Rakudo version 2017.08-108-g760530a built on MoarVM version 2017.08.1-150-g0b81969. This perl6 was compiled with rakudobrew build moar. I've also tried a MoarVM configured with --has-libffi. The result is the same.
OS is Ubuntu 16.04.3, running as a VM with vm-bhyve on FreeBSD 11.

the call to baile(8000); is wrong
try this:
#! /usr/bin/env perl6

use Bailador;
config.port = 8000;
get "/" => sub {
	say "hi";
}

baile();

That was an easy fix. I seem to have copied code from an old source. Thanks for the help!


Add Alliance quest ID for "A Time to Reflect"

Chore tracker is only checking the Horde version (43461) https://www.wowhead.com/quest=43461/a-time-to-reflect
Equivalent Alliance quest has a different ID (43323) https://www.wowhead.com/quest=43323/a-time-to-reflect and does not mark the Horde version as complete once done.

Oops, thanks


[feature request] Migrate to Closure compiler

Closure compiler seems objectively better: https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016#raw-data
https://github.com/cramforce/splittable

It seems splittable doesn't support some feature we need (HMR, multiple layers of bundle).
I think ClosureComiler (JS version) can be a good replacement of UglifyJS.

Good points. I think that's a good idea.

I think it's uglify does a good job in general. (Both the size and execution)
Since we are using babel, https://github.com/babel/babili is also another option.
I think current setup is reasonable.

reasonable !== best


Runtime error

Hi I am getting the following runtime error:
(textfusenet) mickey@MICKEY-2080TI:/mnt/d/download/GitHub/Examples/2020-09-28 TextFuseNet/TextFuseNet-master$ python demo/icdar2015_detection.py --input one-frame.jpg
Config './configs/ocr/icdar2015_101_FPN.yaml' has no VERSION. Assuming it to be compatible with latest v2.
Traceback (most recent call last):
  File "demo/icdar2015_detection.py", line 128, in <module>
    for i in glob.glob(test_images_path):
  File "/home/mickey/miniconda3/envs/textfusenet/lib/python3.7/glob.py", line 20, in glob
    return list(iglob(pathname, recursive=recursive))
  File "/home/mickey/miniconda3/envs/textfusenet/lib/python3.7/glob.py", line 40, in _iglob
    dirname, basename = os.path.split(pathname)
  File "/home/mickey/miniconda3/envs/textfusenet/lib/python3.7/posixpath.py", line 107, in split
    p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not list

Best,
Mickey

@tadam98  path error

The problem is in the code. the --input  processed in row 112 of icdar2015_detection.py (and the others)
test_images_path = args.input
sets test_images_path to a list. not a string. while glob.glob requires a string. and this is the reported error.
for i in glob.glob(test_images_path):
Changed so that i runs on test_images_path and then another for on the glob.glob of i.
Can you send me a sample command line that would take an image called 1.jpg from a ./images folder?

The problem is in the code. the --input processed in row 112 of icdar2015_detection.py (and the others)
test_images_path = args.input
sets test_images_path to a list. not a string. while glob.glob requires a string. and this is the reported error.
for i in glob.glob(test_images_path):
Changed so that i runs on test_images_path and then another for on the glob.glob of i.
Can you send me a sample command line that would take an image called 1.jpg from a ./images folder?

@tadam98 Hi,  the argument of '--input' is the folder of test images. We have modified the default and help of '--input'.

It does not solve the error because test_images_path is of type list and glob.glob does not support it. (regardless of whatever one places after the --input parameter)
TypeError: expected str, bytes or os.PathLike object, not list

It does not solve the error because test_images_path is of type list and glob.glob does not support it. (regardless of whatever one places after the --input parameter)
TypeError: expected str, bytes or os.PathLike object, not list

Yeah, I encountered this problem too. I simply put test_images_path = args.input[0], then the problem was solved

that works too. I made another fix. All I was trying to say is that the code as it is does not work.

Hi all. The argument of '--input' should be set to "./input_images/*.jpg". We have modified the default of '--input'.


Update meta module info in package.json

@donnieberg @johnotander
If this looks good feel free to merge.

👍  Looks good to me, with or without the minor nitpick change.

Oh good to know. I will make that change.

Looks good to me too! Thanks Adam :)

@mrmrs if you have time to update the string "true" to a bool, I'll go ahead and merge that in :)

Updated :)


npm run dev has to be restarted after Prisma change.

Have you experienced this bug with the latest version of the template?
Yes
Steps to Reproduce

Init Blues template
Add author String to schema.prisma
Update note.server.ts with author key.
Add
{data.note.author}
 to $noteId.tsx
In new.tsx copy functionality from title and name it author.
Run migration npx prisma migrate dev --name adding-author
Navigate to http://localhost:3000/notes/new and try to create a new note

Expected Behavior
New note will be displayed after submit.
Actual Behavior
Error is shown. You have to rerun npm run dev to get it working again.

this is due to prisma generate making changes to node_modules, you could add a check for node_modules/@prisma/client to the purgeRequireCache function


Board Review: Azure KeyVault Certificates SDK (all languages)

Preferred Time: 3rd Oct 2 -4
The Basics

Service team responsible for the client library:  DevDiv - Azure KV Team(Scott Schaab, Jonathan Turner, Charles Lowell, Vinay Gera, Isabella Cai, Daniel Rodriguez)
Link to documentation describing the service: https://docs.microsoft.com/en-us/azure/key-vault/

About this client library

Name of the client library: Azure KeyVault Certificates SDK (MVP)
Languages for this review: Java, .NET, Python, JS/TS
Link to the service REST APIs: https://docs.microsoft.com/en-us/rest/api/keyvault/
Link to the reference documentation: WIP https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/keyvault/Azure.Security.KeyVault.Certificates/README.md
Link to several samples: WIP https://github.com/Azure/azure-sdk-for-net/tree/master/sdk/keyvault/Azure.Security.KeyVault.Certificates/samples

Champion Scenarios
Under development
Agenda for the review
The following agenda will normally be followed:

Introduction to the Azure KV Certificates service (5 - 10 minutes)
Class Hierarchy (general) and public API surface

To ensure consistency, discuss any language then indicate/look at the API surface of other languages.

Per-language exceptions and examples
Implementation of champion scenarios (top 3-4 only) with code in preferred language

Include samples as attachments for other languages - all languages under consideration must be provided

Thank you for your submission

In .NET:

Combine Certificate and Certificate Policy

In Python

Johan thinks the poller needs a .result() - to be reviewed (in Azure.Core)
Tags and Enabled in create_certificate should be **kwargs
Splat out the args in update_certificate_policy
Rename name to certificateName in update_certificate_policy

In Java

The sync version of createCertificate should return a poller
Method name should be beginCreateCertificate

In JavaScript

Need to provide example with the poller
createCertificate should be beginCreateCertificate and return a poller
Enabled and tags should go in an options bag
Rename name to certificateName in updateCertificatePolicy

Generally

Maybe place the deleted certificates in a sub-space of the clinet.
Give more thought to naming of certificate / certificate-with-policy (perhaps getCertificate and getCertificateVersion)
Convert delete_certificate to a poller (may have issues - check design with architects)


C:\Users\Abdo sa3ed>flutter doctor --android-licenses Error: Could not find or load main class sa3ed\AppData\Local\Android\Sdk\cmdline-tools\latest\bin\.. Caused by: java.lang.ClassNotFoundException: sa3ed\AppData\Local\Android\Sdk\cmdline-tools\latest\bin\//

Steps to Reproduce

...
...
...

Logs

Logs

    • Flutter version 2.2.3 at C:\flutter
    • Framework revision f4abaa0735 (2 weeks ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

[!] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at C:\Users\Abdo sa3ed\AppData\Local\Android\sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)
    X Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/windows#android-setup for more details.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[√] Android Studio (version 3.3)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)

[√] Connected device (2 available)
    • Chrome (web) • chrome • web-javascript • Google Chrome 91.0.4472.124
    • Edge (web)   • edge   • web-javascript • Microsoft Edge 91.0.864.67

! Doctor found issues in 1 category.```

</details>

HI @AbdoSaid2024
Please delete existing cmd tools from your SDK folder and download it again from SDK manager or try download zip
Then execute flutter doctor --android-licenses

No problems sur it has been solved
On Mon, 19 Jul 2021, 2:09 pm Taha Tesser, @.***> wrote:

HI @AbdoSaid2024 https://github.com/AbdoSaid2024
Please delete existing cmd tools from your SDK folder and download it
again from SDK manager or try download zip
https://dl.google.com/android/repository/commandlinetools-win-7302050_latest.zip
Then execute flutter doctor --android-licenses
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/86594#issuecomment-882496203,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AU37LFSRM4QX226B3YEO3NDTYQIZDANCNFSM5AQRDREQ
.