os.walk error

(Python2.7) root@LT2226:/mnt/c/python# python import-mailbox-to-gmail.py --json /MBOX/Credentials.json --dir /MBOX --logging_level INFO
15:31:08 INFO<EMAIL_ADDRESS>*** Starting import-mailbox-to-gmail 1.5 on Python 2.7.12 (default, Dec  4 2017, 14:50:18)
[GCC 5.4.0 20160609] ***
15:31:08 INFO<EMAIL_ADDRESS>Arguments:
15:31:08 INFO<EMAIL_ADDRESS> auth_host_name: 'localhost'
15:31:08 INFO<EMAIL_ADDRESS> auth_host_port: [8080, 8090]
15:31:08 INFO<EMAIL_ADDRESS> dir: '/MBOX'
15:31:08 INFO<EMAIL_ADDRESS> fix_msgid: True
15:31:08 INFO<EMAIL_ADDRESS> from_message: 0
15:31:08 INFO<EMAIL_ADDRESS> httplib2debuglevel: 0
15:31:08 INFO<EMAIL_ADDRESS> json: '/MBOX/Credentials.json'
15:31:08 INFO<EMAIL_ADDRESS> log: 'import-mailbox-to-gmail-535.log'
15:31:08 INFO<EMAIL_ADDRESS> logging_level: 'INFO'
15:31:08 INFO<EMAIL_ADDRESS> noauth_local_webserver: False
15:31:08 INFO<EMAIL_ADDRESS> num_retries: 10
15:31:08 INFO<EMAIL_ADDRESS> replace_quoted_printable: True
Traceback (most recent call last):
File "import-mailbox-to-gmail.py", line 415, in
main()
File "import-mailbox-to-gmail.py", line 341, in main
for username in next(os.walk(args.dir))[1]:
StopIteration
any ideas?

Based on https://stackoverflow.com/a/37289741/3275273, it looks like the directory you specified (/MBOX) doesn't exist. Please let me know if this is the case.
I'll leave this open anyway because it needs a better error message.
Thanks for reporting!

It does exist.
I'm running my script from c:/python and the full path for mbox is
c:/python/mbox
I've tried putting the full path as well with the same results.
Those are the only errors I've gotten and mimics exactly what's in the log
file
On Fri, Sep 21, 2018, 1:27 AM Liron Newman<EMAIL_ADDRESS>wrote:

Based on https://stackoverflow.com/a/37289741/3275273, it looks like the
directory you specified (/MBOX) doesn't exist. Please let me know if this
is the case.
I'll leave this open anyway because it needs a better error message.
Thanks for reporting!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/import-mailbox-to-gmail/issues/42#issuecomment-423417397,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ambw7I7-dyheHmgZ_Z5Ma-cb3WZPHPGIks5udHi6gaJpZM4Wyy8d
.

In that case, you should probably use -dir mbox, without the slash. The slash means it will search for c:\mbox.
Also, in Windows it's generally better to use backslashes for paths, as not everything works well with forward slashes.
Please let me know if it works.
Thanks!

That resolved my os.walk error.. but not it's telling me it can't find my Credentials.json file....
0:53:26 INFO<EMAIL_ADDRESS> httplib2debuglevel: 0
10:53:26 INFO<EMAIL_ADDRESS> json: 'C:/Credentials.json'
10:53:26 INFO<EMAIL_ADDRESS> log: 'import-mailbox-to-gmail-658.log'
10:53:26 INFO<EMAIL_ADDRESS> logging_level: 'INFO'
10:53:26 INFO<EMAIL_ADDRESS> noauth_local_webserver: False
10:53:26 INFO<EMAIL_ADDRESS> num_retries: 10
10:53:26 INFO<EMAIL_ADDRESS> replace_quoted_printable: True
10:53:26 INFO<EMAIL_ADDRESS>Processing user<EMAIL_ADDRESS>10:53:26 ERROR<EMAIL_ADDRESS>Can't get access token for user<EMAIL_ADDRESS>10:53:26 ERROR<EMAIL_ADDRESS>Can't process user<EMAIL_ADDRESS>Traceback (most recent call last):
File "import-mailbox-to-gmail.py", line 345, in main
credentials = get_credentials(username)
File "import-mailbox-to-gmail.py", line 130, in get_credentials
scopes=SCOPES).create_delegated(username)
File "/usr/local/lib/python3.5/dist-packages/oauth2client/service_account.py", line 219, in from_json_keyfile_name
with open(filename, 'r') as file_obj:
FileNotFoundError: [Errno 2] No such file or directory: 'C:/Credentials.json'


Refactor: Improve seeders

Changes

Fix: Typo in install script
Refactor: I have removed a ton of commented and empty seeders as these are not needed now (and most likely never will be need) and just make it more complex to manage seeders, now it will be easier and more straight forward (if this is not welcome tell me and I will undo the commits for these changes). I will have to create some more seeders for my big permission PR, so this is a step in the right direction. If we need the seeders in the future, we can just create fresh ones.

-> I also have some more ideas and plans to improve the seeders in the future, but these would include bigger modification and also new features and possibly could introduce new bugs, so I will hold on to those for the next time when I have a more detailed plan (because we are currently in a feature freeze.).

Thank you for the PR! Removing unnecessary things are always welcomed.


An empty Traceparent spanId should be allowed

see: https://github.com/microsoft/ApplicationInsights-node.js/blob/38f684019f4a577477f48ab3052d190bf593fe30/Library/Traceparent.ts#L105
Accordingly (https://docs.microsoft.com/en-us/azure/azure-monitor/app/correlation#correlation-headers-using-w3c-tracecontext) an initial request should have an empty parent-id.
If a request includes traceparent header with an empty parent-id (eg: 00-d6ec8fc03a14464fb38104562a4b7ff4--01) then the entire traceparent will be replaced with a randomly generated value.

I now believe that I had mis-understood the context for the assertion that a parent-id could be empty.


Error occured during training BasicVSR

During training, error as follows occured. I run it with official config in "configs/restorers/basicvsr/basicvsr_reds4.py".
RuntimeError: Expected to have finished reduction in the prior iteration before starting a new one. This error indicates that your module has parameters that were not used in producing loss. You can enable unused parameter detection by (1) passing the keyword argument "find_unused_parameters=True" to "torch.nn.parallel.DistributedDataParallel"; (2) making sure all "forward" function outputs participate in calculating loss. If you already have done the above two steps, then the distributed data parallel module wasn't able to locate the output tensors in the return value of your module's "forward" function. Please include the loss function and the structure of the return value of "forward" of your module when reporting this issue (e.g. list, dict, iterable).
Though I solved it by adding find_unused_parameters=True in line 128, "apis/train.py" and removing self.generator.find_unused_parameters = False in line 84, "models/restorers/basicvsr.py", I still don't know why that error happened.
In "models/restorers/basicvsr.py", author declares a variable "self.generator.find_unused_parameters = False", which seems that shouldn't have influence on program, for it's never used as a parameter in program. However, it indeed causes the error mentioned above.

Did you use the provided configuration? This error occur because some trainable parameters do not receive gradient.

Did you use the provided configuration? This error occur because some trainable parameters do not receive gradient.
Yes, I use configuration in "configs/restorers/basicvsr/basicvsr_reds4.py". if I don't add find_unused_parameters=True, program crashes after the first iteration and if I don't remove self.generator.find_unused_parameters = False, program crashes while self.step_counter == self.fix_iter.

I just tried and did not encounter the error. Could you provide me with more details? What command do you use for training? And did you modify any codes in the model or architecture?

Environment：
python==3.7.10
pytorch==1.8.1
torchvision==0.9.1
20210423_214330.log
openCV==4.5.1
mmcv==1.3.1
mmediting==0.6.0+b6a516c
command for training: ./tools/dist_train.sh ./configs/restorers/basicvsr/basicvsr_reds4.py 2
I double check configuation file and make sure that I use official configuation. And here is my training log.
20210423_214330.log

Could you revert to the original code (don't add or remove self.generator.find_unused_parameters) and try fix_iter==-1,  and let me know what happened?

I tried original code with fix_iter==-1 and it works well. However, if I change  fix_iter to a positive number, the same error occurs again.

I just tried to run ./tools/dist_train.sh ./configs/restorers/basicvsr/basicvsr_reds4.py 2 and did not encounter any error. I am using PyTorch 1.6, and that may be the reason.
Can you please try to print out the value of self.generator.find_unused_parameters before line 91 (i.e. optimizer['generator'].zero_grad())?

It is True .

It is True but you still encounter the error after the first iteration, even when fix_iter==5000?

Yes...I'm also very confused about that.

It seems that in the repository "MMDetection", someone encountered similiar issue

That's strange, I will look into that.

Thanks for your your detailed reply.

@NK-CS-ZZL Hi, would you be able to test whether the code in PyTorch 1.6.0? I want to see whether it is the problem of PyTorch version, but my CUDA driver is too old to install PyTorch 1.8.1. It may take some time to reconfigure the server.

@NK-CS-ZZL Hi, would you be able to test whether the problem exists in PyTorch 1.6.0? I want to see whether it is the problem of PyTorch version, but my CUDA driver is too old to install PyTorch 1.8.1. It may take some time to reconfigure the server.

I tried it and code works well. After 5000 iterations, Spynet updates as expected.
My current environment:
PyTorch: 1.6.0
TorchVision: 0.7.0
OpenCV: 4.5.1
MMCV: 1.3.2
MMCV Compiler: GCC 7.5
MMCV CUDA Compiler: 11.1
CUDA Runtime 10.1
CuDNN 7.6.3
MMEditing: 0.6.0+67ac739
20210430_120021.log

Then it's probably because of the difference in the PyTorch version. I will further look into the problem. Thanks for your report.

Fixed in #290. Thank you for your report. Please reopen there are still any issues.


Accessing the Model Equation

Hi!
Is there anyway to print out the model equation after building the model? Trying to conduct a sensitivity analysis on the model and need to access the formal equation.
Cheers!

Hi @tim-mcwilliams! When you say the model equation, I assume you mean y(t) = Z(t)*a(t), where Z(t) is the observation matrix and a(t) is the state vector. For example, if you only specified a stochastic level component, Z(t) = [1] and a(t) = level(t-1) + level_error(t). Is this what you're after?

Hmm, I'm pretty sure that would work.
Some context as to why I'm asking. Wanting to use this package (sensitivity) to conduct sensitivity analyses to assess the robustness of the UC model.
Have you tried anything like that before with this package??

I've not used this before, but it looks like it creates pairwise permutations of the data to assess robustness of the model to different inputs. What inputs are you trying to vary? Regression variables? Priors? Components?

yea exactly, it basically assess how stable the model is if inputs were to change to some degree. For this use case I would be looking to vary the Regression variables.

Maybe I'm overthinking this, but there are two ways to assess sensitivity with respect to regression variables. One way is to estimate a new set of parameters, treating the different variable permutations as distinct model instantiations. The other way is to estimate your model with the original data, and then plug in your permuted variables for different in-sample and forecasted predictions. Both methods assume the model specification stays the same, i.e., the component specification is the same.
The first approach will give you different posteriors for the parameters. The second approach will keep the posterior parameter values the same.
Which of the above are you trying to achieve? If it's the second approach, then I will need to add code to accommodate that.

Sorry for the delayed response here!
I would say the second approach is what I would be looking for. That way we will be able to test different in-sample and forecasted predictions to see how variable the model is when handling different swings in the IV vars.

Hi @tim-mcwilliams! I will start working on this this week. Most likely it will be an augmentation of the posterior_predictive_distribution() method to allow for different values of the predictors. The forecast() method can already accept whatever values you want/have for the predictors.

Awesome, looking forward to the new feature!

Hey @tim-mcwilliams. A new version, 0.18.2, has been released to reflect this new feature. Note that I changed the name of the method posterior_predictive_distribution() to post_pred_dist() for brevity. Example fake code:
from pybuc.buc import BayesianUnobservedComponents as BUC
burn = 100
mod = BUC(response=y, predictors=x_orig, level=True, seed=123)
mod.sample(1000)
ppd_orig = mod.post_pred_dist(burn=burn)
ppd_new = mod.post_pred_dist(predictors=x_new, burn=burn)
yhat_orig_mean = np.mean(ppd_orig, axis=0)
yhat_new_mean = np.mean(ppd_new, axis=0)

The post_pred_dist() method returns an array of dimension (s, n - num_first_obs_ignore), where s is the number of non-burned posterior samples and n is the number of observations for the response. By default, num_first_obs_ignore=None, in which case the first few observations will be ignored for computing the posterior predictive distribution. You can read more about this argument and what it means in the documentation. Briefly, though, some of the first observations are ignored by default because the Kalman filter requires initialization, which in turn means the first few predictions from the Kalman filter may be unreliable. If you want to keep all observations, you can pass num_first_obs_ignore=0.

Awesome, looking forward to the new feature!

Hey @tim-mcwilliams, did the above resolve your issue?

@devindg, Had to take a break on this research project but will be picking it back up later this week. Will try your solution then and let you know how it went.

@devindg , this is exactly what I was looking for from this issue.  Nice and easy to use too! Thanks so much 👍🏼

Closing!


Update content.md

Trello card
https://trello.com/c/lbJvbJGS/5301-update-github-guidance
Context
Add more info on how to complete actions in github to the existing content guidance page.
Changes proposed in this pull request

add how to make a new page
how to set up github

Guidance to review

Have added more content around getting into Visual Code studio and tips for using the site.
Also added how to change the branch location.
Havent added component info as i haven't done that before so wouldn't know what to do.


TICKF calculatePoolDistr

[ ] Get approval about exhaustiveness of changes required
[ ] Update changelog
[ ] Squash all history and write an elaborate commit message with links to issues

References

https://github.com/input-output-hk/cardano-node/issues/4421
#3034
#3132

Closes #3132

@nfrisby I have just merged your latest changes on to this one, which remains rebased on top of master. Would really like to have your eyes go over this.

replaced by #3209


Stellar | Adding Stellar into impact-graph (main DB)

Explorer: https://stellar.expert/explorer/public
Token List:

Symbol, Name, address, coingeckoID, nonEVM
XLM, Stellar Lumens, CAS3J7GYLGXMF6TDJBBYYSE3HQ6BBSMLNUQ34T6TZMYMW2EVH34XOWMA, stellar, isEVM=false

Notes:

[ ] Stellar tokens are different from 0x addresses, we currently have non-evm fields, Im suggesting adding another as isQR   for those tokens that we handle with QR without the need of connecting to the DApp.
[ ] For more details on changes please read #1690 (backend) and https://github.com/Giveth/giveth-dapps-v2/issues/4422 (Frontend)

This token is added in admin @MoeNick
https://impact-graph.serve.giveth.io/admin/resources/Token/records/306/show


Adds Laravel 7 support

Laravel 7 in composer.json
Solves : #404

Can you install this package on Laravel 7? I get the following error on a fresh Laravel 7 install:
Your requirements could not be resolved to an installable set of packages.

Problem 1
- Conclusion: remove laravel/framework v7.0.8
- Conclusion: don't install laravel/framework v7.0.8
- osiset/laravel-shopify v10.3.0 requires laravel/framework ~5.6 | ^6.0 -> satisfiable by laravel/framework[5.6.x-dev, 5.7.x-dev, 5.8.x-dev, 6.x-dev].
- osiset/laravel-shopify v10.3.1 requires laravel/framework ~5.6 | ^6.0 -> satisfiable by laravel/framework[5.6.x-dev, 5.7.x-dev, 5.8.x-dev, 6.x-dev].
- Can only install one of: laravel/framework[6.x-dev, v7.0.8].
- Can only install one of: laravel/framework[5.6.x-dev, v7.0.8].
- Can only install one of: laravel/framework[5.7.x-dev, v7.0.8].
- Can only install one of: laravel/framework[5.8.x-dev, v7.0.8].
- Installation request for laravel/framework (locked at v7.0.8, required as ^7.0) -> satisfiable by laravel/framework[v7.0.8].
- Installation request for osiset/laravel-shopify ^10.3 -> satisfiable by osiset/laravel-shopify[v10.3.0, v10.3.1].


Add button to generate a range of addresses

https://github.com/Thoralf-M/iota-ed25519-address-wasm/commit/5dde79826a2d48c7fefa843a4a55d67ad1f0c6ac


Refactoring of script alias handling and code generation.

Refactoring of how we process scripts to make it easier to perform script code transformation which we'll need to get Mono.CSharp running.
Do not merge this since it's a work in progress.

Merge conflict resolved and merged.


Add plugins system

This adds support for functional and control plugins, albeit with a limited number of actions right now. This doesn't yet include support for CLI instructions, that will come in future (but very likely before v0.3.0). This is missing support for extending Actix Web server configuration due to certain typing/compilation issues with that library, though there's a workaround of a simple replacement character at present, which could be set by functional or control plugins, which is all documented (or rather will be).
As a side note, this does not add support for custom engines (formerly known as type 3 plugins).

I'll add the new testing workflow for the plugins example after this is merged.


[WIP] Add tile statistics to mbtiles

Try to fix #964

[x] Add tile statistics to mbtiles tools
[x] Add test
[ ] Add document
[ ] Cleanup and reformat

After rebasing on maplibre/martin, I can't push to my branch. I need to fix this first 😂
@sharkAndshark ➜ /workspaces/martin (mbstats) $ git push --no-verify -f
...
remote: Resolving deltas: 100% (45/45), completed with 20 local objects.
To https://github.com/sharkAndshark/martin.git
 ! [remote rejected] mbstats -> mbstats (refusing to allow a GitHub App to create or update workflow `.github/workflows/grcov.yml` without `workflows` permission)
error: failed to push some refs to 'https://github.com/sharkAndshark/martin.git'

P.S. It is usually better to use git merge main, rather than using rebase.  Rebase tends to loose tracking of the review comments.

P.S. It is usually better to use git merge main, rather than using rebase. Rebase tends to loose tracking of the review comments.

Thx! Didn't know that before : )

its getting almost there, really like it!
I wonder how we can optimize the bounding box printing. I don't like that it prints all those unneeded digits. Instead, we should have some formula to compute how many digits are significant for each zoom level.  For example, you can convert a single tile near the equator, see how big it is in terms of digits, and use that many digits?  Something like this
let tile_size = 40075016.7 / (2_u32.pow(zoom as u32)) as f64;
let lng_delta = (tile_size / 6378137.0).to_degrees();
let log = log10(lng_delta)
let precision = if log < 0 { 0 } else { ceil(-log) };
let bbox = format!("{box:.precision$}")

Forgot to mention - I am not certain if you are affected by this, but mbtiles invert the Y value (tile_row) -- the Y coordinate of a tile corresponds to 2^zoom - 1 - tile_row in mbtiles.

Thx for the mention. I did some research and I hope it's right.
MBTiles spec says it follow TMS, so the the Y of tile index increase from down to top.

Schema
Y

XYZ
From top to down

TMS
From down to top

Tile Origin and Bbox of 3857

Origin
Bbox

(-20037508.34, -20037508.34)
[-20037508.34, -20037508.34, 20037508.34, 20037508.34]

Length of one single tile
(20037508.34 * 2) /  (2^zoom_level)
MinX,MaxX
MinX =   OriginX + X * TileLength
MaxX = MinX + TileLength
MinY,MaxY
MinY =  OriginY + Y * TileLength
MaxY = MinY + TileLength

@bdon you did something similar for pmtiles, right?

Awesome job, well done, thank you!!!

Thx all your guidance ！Hope I can do better in next : )


feat: add GroupAccessToken

Description of your changes
This PR adds GroupAccessTokens
I have:

[x] Read and followed Crossplane's contribution process.
[ ] Run make reviewable test to ensure this PR is ready for review.

=> fails - even on master
How has this code been tested
running in our cluster, created some unit tests

Thanks for the PR @markussiebert. Could you squash your changes into a single commit?

Thanks for the PR @markussiebert. Could you squash your changes into a single commit?

done!


[packages/core] delete the current jsx mail core and restart it from scratch

Is your feature request related to a problem? Please describe.
With the decision to have our own js runtime some things had to be changed brutally, and one of them is the core that will be completely rebuilt
Describe the solution you'd like
The focus for this issue is quite simple: delete the packages/core project and start it again, with absolutely everything new. we will need to configure the following things:

configure .gitignore
configure the same CHANGELOG.md
Add a file README.md (it's not required add documentation that right now)
And configure a new tsconfig.json

On the v2.x/runtime branch I already started the process, but so far I just deleted the old core and initialized a new one, I just configured ts

the .gitignore is not required because the workspace already has it

made in branch v2.x/runtime


Indent highlight doesn't work

Problem
After upgrade to v3, I can't change indent line color.
If I set default highlight, it is ignored. If I set a custom highlight, plugin errors out that the provided highlight doesn't exist, although I set it in my local theme. I tried to use hooks, but it has no effect. It seems like it's the loading order issue, but I can't load theme before the plugins, since I build theme with lush. I tried to load ibl on VeryLazy event, but it didn't work either.
Commit with update: https://github.com/alex35mil/dotfiles/commit/2a940d4537dae7370b403091e0336b7c3dcf6355
Plugin config
Theme with highlight
Screenshots:

Steps to reproduce
My config: https://github.com/alex35mil/dotfiles/tree/2a940d4537dae7370b403091e0336b7c3dcf6355/home/.config/nvim
Expected behavior
Indent highlight works.
Neovim version (nvim -v)
v0.9.2

Yeah, if I start nvim with plugin disabled, and then IBLEnable, it picks up the highlight.

If you want to use highlight groups from your color scheme, you need to load the color scheme first.

Workaround

Also seeing this issue. If it's really impossible to fix, it could use a note in the docs.


Telegram bot won't connect on fresh install

On a completely fresh install the mpact_telegram_bot_1 docker has 5 failed connections and quits. The only way I could get it to connect was to connect manually from the command line first, then run it in docker. I suspect it is a permissions issue with creating the bot.session file.
(Keeping in the same issue because it feels related)
When I run it in docker after the manual run it will connect but then gives an endless stream of:
2021-05-04 18:39:37,500 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/mtprotosender.py:447} - DEBUG - Encrypting 101 message(s) in 3256 bytes for sending
2021-05-04 18:39:37,500 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/connection/connection.py:173} - INFO - The server closed the connection while sending
2021-05-04 18:39:37,501 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/connection/connection.py:191} - INFO - The server closed the connection
2021-05-04 18:39:37,501 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/connection/connection.py:135} - INFO - <class 'ConnectionResetError'> during disconnect: [Errno 104] Connection reset by peer
2021-05-04 18:39:37,501 - p1 {/usr
/local/lib/python3.8/site-packages/telethon/network/connection/connection.py:135} - INFO - <class 'ConnectionResetError'> during disconnect: [Errno 104] Connection reset by peer
2021-05-04 18:39:37,501 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/mtprotosender.py:487} - INFO - Connection closed while receiving data
2021-05-04 18:39:37,501 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/mtprotosender.py:341} - INFO - Closing current connection to begin reconnect...
2021-05-04 18:39:37,501 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/connection/connection.py:135} - INFO - <class 'ConnectionResetError'> during disconnect: [Errno 104] Connection reset by peer
2021-05-04 18:39:37,501 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/mtprotosender.py:217} - INFO - Connecting to <IP_ADDRESS>:443/TcpFull...
2021-05-04 18:39:37,501 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/mtprotosender.py:272} - DEBUG - Connection attempt 1...
2021-05-04 18:39:37,509 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/mtprotosender.py:274} - DEBUG - Connection success!
2021-05-04 18:39:37,510 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/mtprotosender.py:256} - DEBUG - Starting send loop
2021-05-04 18:39:37,510 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/mtprotosender.py:259} - DEBUG - Starting receive loop
2021-05-04 18:39:37,510 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/mtprotosender.py:268} - INFO - Connection to <IP_ADDRESS>:443/TcpFull complete!
2021-05-04 18:39:37,511 - p1 {/usr/local/lib/python3.8/site-packages/telethon/network/mtprotosender.py:438} - DEBUG - Waiting for messages to send...
2021-05-04 18:39:37,512 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>763261028 to GetUsersRequest (7f0f42343520)
2021-05-04 18:39:37,513 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>764668652 to GetUsersRequest (7f0f423437f0)
2021-05-04 18:39:37,513 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>767227360 to GetUsersRequest (7f0f421ae520)
2021-05-04 18:39:37,513 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>767911144 to GetUsersRequest (7f0f42343ac0)
2021-05-04 18:39:37,514 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>768595884 to GetUsersRequest (7f0f4239fca0)
2021-05-04 18:39:37,514 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>769031712 to GetUsersRequest (7f0f42109cd0)
2021-05-04 18:39:37,514 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>769354056 to GetUsersRequest (7f0f41d2eb80)
2021-05-04 18:39:37,514 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>769920536 to GetUsersRequest (7f0f420e98b0)
2021-05-04 18:39:37,514 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>771195600 to GetUsersRequest (7f0f4202fd00)
2021-05-04 18:39:37,514 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>771939464 to GetUsersRequest (7f0f42003a30)
2021-05-04 18:39:37,515 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>775766560 to GetUsersRequest (7f0f42264760)
2021-05-04 18:39:37,516 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>776530452 to GetUsersRequest (7f0f42109a00)
2021-05-04 18:39:37,516 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>777115056 to GetUsersRequest (7f0f41e56bb0)
2021-05-04 18:39:37,516 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>777693936 to GetUsersRequest (7f0f42011250)
2021-05-04 18:39:37,516 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>778276632 to GetUsersRequest (7f0f41f26550)
2021-05-04 18:39:37,516 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>779917904 to GetUsersRequest (7f0f4213bc10)
2021-05-04 18:39:37,517 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>781242560 to GetUsersRequest (7f0f42343d60)
2021-05-04 18:39:37,518 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>784895132 to GetUsersRequest (7f0f42343b80)
2021-05-04 18:39:37,518 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>785472104 to GetUsersRequest (7f0f4220f850)
2021-05-04 18:39:37,518 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>786080548 to GetUsersRequest (7f0f42173be0)
2021-05-04 18:39:37,518 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>786739536 to GetUsersRequest (7f0f420c5b80)
2021-05-04 18:39:37,518 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>787762828 to GetUsersRequest (7f0f4213b670)
2021-05-04 18:39:37,518 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>787978360 to GetUsersRequest (7f0f41d66160)
2021-05-04 18:39:37,519 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>788564868 to GetUsersRequest (7f0f41d40910)
2021-05-04 18:39:37,519 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>789220044 to GetUsersRequest (7f0f41def4c0)
2021-05-04 18:39:37,519 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>789828488 to GetUsersRequest (7f0f4234b9a0)
2021-05-04 18:39:37,519 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>790462680 to GetUsersRequest (7f0f41e904c0)
2021-05-04 18:39:37,519 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>791078756 to GetUsersRequest (7f0f41fe9e80)
2021-05-04 18:39:37,520 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>792783924 to GetUsersRequest (7f0f42222a30)
2021-05-04 18:39:37,520 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>793843456 to GetUsersRequest (7f0f41e021c0)
2021-05-04 18:39:37,520 - p1 {/usr/local/lib/python3.8/site-packages/telethon/extensions/messagepacker.py:66} - DEBUG - Assigned msg_id =<PHONE_NUMBER>794624516 to GetUsersRequest (7f0f4202f670)

This appeared to resolve after updating Docker. My best guess is that it was a permissions issue with internal docker / macOS things. Some combination of rebooting my machine since last night + updating docker seems to have resolved it.


rtd not working

Not building the package e.g. https://readthedocs.org/projects/xskillscore/builds/11691073/
ModuleNotFoundError: No module named 'xskillscore'
I imagine the solutions lies somewhere between
https://github.com/raybellwaves/xskillscore/blob/master/ci/doc.yml
https://github.com/raybellwaves/xskillscore/blob/master/docs/source/conf.py
https://github.com/raybellwaves/xskillscore/blob/master/readthedocs.yml
as well as the settings on rtd

Making progress with https://github.com/raybellwaves/xskillscore/pull/145
and also learned about https://github.com/pydata/xarray/pull/4350

Believe it's working. Just quite a few warnings to fix

Tempted to change https://github.com/raybellwaves/xskillscore/blob/master/readthedocs.yml#L10 to fail_on_warning: false and fix these in another PR.

Closed via #145


integrations: Prevent duplicate submitted pr review messages.

After opening a pr review, user will see exactly one message instead of two.
Fixes #26145

Screenshots and screen captures:

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Closing as this seems to not be a correct fix for https://github.com/zulip/zulip/issues/26145 and hasn't been updated in some time.


Better Docstrings/Comments on Contract Code

As this code is likely to be audited by others more closely, I think it would be great to start building clear comments and docstrings. I really like the format here: https://github.com/ConsenSys/PLCRVoting/blob/master/contracts/PLCRVoting.sol#L78
I like how it's clearly split into its helpers, etc.. In this case, it could be split into bounty interfaces, fulfillment interfaces, and helpers/internal. It is very clean, makes for more readable content, and gives more trust to the standard.

Also - something like this should have a line explaining it is a duplication check - https://github.com/Bounties-Network/StandardBounties/blob/develop/contracts/StandardBounty.sol#L148 or https://github.com/Bounties-Network/StandardBounties/blob/develop/contracts/StandardBounty.sol#L194 explaining it is verifying no overflow - or https://github.com/Bounties-Network/StandardBounties/blob/develop/contracts/StandardBounty.sol#L68 explaining it is verifying we don't go over array max size.


Disable periodic jobs for all versions except "latest' and "latest - 1"

Currently, odo periodic jobs are running for the OCP versions 4.2 through 4.7. However, only the latest (4.7) and one version older than that are supported from features point of view. As of opening this issue:

4.7 is the latest and fully supported issue
4.6 is also fully supported
4.5 is in maintenance mode and release of 4.8 will cause its EOL

When 4.8 is released, 4.6 will enter maintenance mode and release of 4.9 will cause EOL of 4.6. So on and so forth.
Periodically testing odo against versions other than two latest versions (4.7 and 4.6 at the time of writing this) makes no sense. It's as good as wasting resources. We need to disable these periodic jobs.
/area testing
/priority high

PR https://github.com/openshift/release/pull/16813 will disable unsupported periodic jobs. Plan is to run periodic jobs on all the ocp supported version 4.5, 4.6 and 4.7, also the upcoming version 4.8 . Yes, ofcourse 4.5 will break until 4.8 GA comes out, but thats ok it will only fail for SBO.


Sprint Challenge Completion

Completed the following:

Answered questions on readme.md
Styled the pages to match the designs
Added media queries to restructure the menu and about-page items on mobile/desktop
Animated in the menu

Rubric

[x] Best practices: code is adequately commented with frequent, descriptive commits; it's readable, and proper git workflow followed.
[x] Home page matches design files.
[x] Navigation appears.
[x] Header appears.
[x] Boxes accurately styled.
[x] About page matches design files.
[x] Navigation and header match Home page.
[x] Header image has About page image.
[x] Home navigation links back to index.
[x] Can walk me through how code made files match, sharing at least one concrete programming decision.
[x] Stretch attempted: CSS animations fade in the beautiful header, media queries.

Comments:

Great job with commits! After every major feature is helpful.
Great job getting as far as you could with stretch, adding media queries and everything.
-You've got mobile responsiveness and CSS animations down. Consider getting ahead on Javascript!


Add ScaleLimitsAnalyzer using bluejay to function-runner

#gsd:37875
Addresses:

https://github.com/Shopify/script-service/issues/7502

Description
Current scaling implementation: https://github.com/Shopify/shopify/pull/518219/files#diff-bef9ccfcca30dfc391c6ad9d0a3e0739bf8a2ab27e659473894e4e62d43bad08
We currently scale our function run limits based on the directive scaleLimits with an argument rate on cartLines. We scale by the length of the field. We multiply the directive rate found on the fields definition, by the length of that fields (seem by either array length or string length) to determine how much to scale limits our default limits by.
This PR adds an analyzer that will determine the maximum scale factor from all fields with the scale limits directive on it.  We chose to use this implementation because we want to ability to add directives for scale limits of different fields in the future. Currently we only scale on cart lines.
Notes on Visitor implementation:

The ScaleLimitsAnalyzer is used to dynamically adjust resource limits for function executions based on data provided in GraphQL queries. It does this by analyzing the query and associated input JSON, calculating a scaling factor based on the lengths of fields specified in the query that have an associated @scaleLimits directive.

Avoiding Double Counting
A key feature of the ScaleLimitsAnalyzer is its ability to avoid double counting fields when calculating the scale factor. This is crucial for ensuring that the scaling adjustments are accurate and reflect the true resource needs of the function execution. Here’s how double counting is avoided:
Path Tracking: The analyzer uses a path_stack to keep track of the current path within the query during traversal. This helps in uniquely identifying each field's location within the query structure.
Unique Path Identification: Each field's path, combined with its index in case of arrays, is used to create a unique identifier (PathWithIndex). This ensures that each instance of a field, even if the field name is the same, is treated uniquely based on its context and position in the input data.
Rate Aggregation: When calculating the scale factor, the analyzer aggregates rates using these unique identifiers. If a field appears multiple times in different parts of the query or within nested structures, each occurrence is treated independently based on its unique path and context.
Maximal Increment Strategy: For fields that appear multiple times in the same context (e.g., duplicated fields in a query), the analyzer only considers the maximum scale increment calculated for these fields. This approach ensures that the scale factor reflects the maximum resource requirement for repeated fields without cumulatively adding the increments.
Tophat

can be seen via the tests, it will be implemented in the next PR.

PathWithIndex

No, we can close that I believe (will verify), added a PathWithIndex in the scale limits analyzer that we can use to uniquely identify fields with same name to avoid the overcounting :)


[Feature Request] improve reporting for missing/incorrect examples

💡 Idea
Today, RESTler does not provide detailed diagnostics on which request types do not have associated examples or which examples did not match the schema of the spec (and hence were only partially used / may contain errors).  This is useful to have in order to more quickly fix examples to improve coverage.
Design Notes
One way to improve this is for the compiler to produce an output file with any detected problems in examples, which would contain this information.  For example, as a starting point the file could simply include requests which do not contain examples and for which examples do not match the schema.
{
  "/customer": {
    "post": {
           "examples": {
              "first example": {
                  "matches_schema": false
              }
          }
        }
   },
  "/customer/{id}": {
     "get": {
         "examples": {}
     }
  }
}

One confusing case that was hit recently: if the example is using an incorrect name for the body parameter, or incorrectly includes only properties from the body, RESTler will not send a body (since the schema does not match).  Then, subsequent payloads generated from the schema do not work because there is a missing Content-Type (due to a current RESTler limitation that this is constant for all of the payload variants).


[Feature] 支持多模态对话功能：对话的问题和回复都支持文本、图片、音频

你想要什么功能或者有什么建议？
支持多模态对话功能：对话的问题和回复都支持文本、图片、音频。
随着官方 ChatGPT 多模态的推出，期待未来 ChatGPT-Next-Web 有计划支持多模态的对话输入输出。
有没有可以参考的同类竞品？
官方 ChatGPT 多模态的功能

希望支持多模态对话功能：对话的问题和回复都支持文本、图片、音频。

希望支持生成图片，语音，

GPT-4 Turbo with vision
https://openai.com/blog/new-models-and-developer-products-announced-at-devday

希望支持多模态对话功能：对话的问题和回复都支持文本、图片、音频。同时支持文件上传，服务器缓存文件功能。

github许愿池

@Yidadaa would you appreciate any work on this (e.g. PoC) that you can leverage?  Or are you in the middle of a major refactoring of the related app architecture?

多模态太重要了,  会带来无限可能.

Multi-modal support is desired: support for external file uploads and server caching, and support for conversations and replies in text, images, audio, and video.

gpt-4-vision-preview 无法显示完整对话，估计是 openai 的 bug。需要传 max_token: 4096
可以参考这里：
https://github.com/xcatliu/chatgpt-next/commit/64e893bc09bcfa5b62bad46fa241a488cbd8dcf1#diff-c92ae8ba732859797d0c2eb76525d66897ec86c7da0a555c871123a0deaba2f6R170

希望支持语音对话的功能。

Same.

希望增加dell-a，还有对图像的支持。

希望增加dell-a，还有对图像的支持。

Model DALL·E must use own storage service for store a image, because when you generating a image, the image will disappear in 30 minute ~ 2 hours (approx)

希望增加dell-a，还有对图像的支持。

Model DALL·E must use own storage service for stored a image, because when you generating a image, the image will disappear in 30 minute ~ 2 hours (approx)

Isn't "own storage" what the app already has built-in: an Upstash Redis DB integration - now for chat messages backup, but could be extended for persisting images, at least if downscaled

希望增加dell-a，还有对图像的支持。

Model DALL·E must use own storage service for stored a image, because when you generating a image, the image will disappear in 30 minute ~ 2 hours (approx)

Isn't "own storage" what the app already has built-in: an Upstash Redis DB integration - now for chat messages backup, but could be extended for persisting images, at least if downscaled

for image
In scenarios where an image is generated by DALL-E, the response is a JSON containing only the image URL, along with the date, time, and revised prompts (specifically for DALL-E 3). Since the image URL has a limited download duration, it would be beneficial if the image URL from DALL-E models could be automatically downloaded and then uploaded to a storage solution that allows for image display in markdown format.

同类竞品: OpenCat

画图和音频功能，后续也会加上。

同求,还希望能有联网功能

+1

+1

已实现dall-e-3画图、gpt4-vision-preview识图、whisper语音转文字、tts文字转语音
https://github.com/vual/ChatGPT-Next-Web-Pro

any update?

大佬,能出个多模态的功能吗,

桌面应用貌似不支持上传图片

许愿+1

可以支持 Midjourney 模型吗？


Chart width does not match page width when printing to PDF

Bug Description
When you click to print a page to PDF, charts on the page will often not line up exactly with 100% of the page width. Most often, it seems that they extend beyond the width of the page (see example screenshot below).
Depending on the width of the page when the PDF button is clicked, the chart may appear as narrower or wider than 100% of page width.
Severity

Low - I'm able to keep using Evidence as normal, but flagging this for the team to fix

Expected Behavior
Charts should take up exactly 100% width.
Error Messages and Screenshots
Chart in screenshot below extends wider than 100% page width:

This one's been happening for a while (mentioned in #273), so it wouldn't have been caused by the resizing changes - but I'm guessing the solution will have something to do with the resizing behaviour.

@csjh


Compile definitions do not get exported to generated pkg-config

We have noticed that the definitions added via add_definitions do not get exported to the Cflags in the generated pkg-config:
https://github.com/ros/catkin/blob/61bc640e8e910ce377e9679a9a4c756012dfe163/cmake/em/pkg.pc.em#L6
I.e., including a catkin package via pkg-config does not pick up the exported definitions correctly, while via CMake we can use CFG_EXTRAS (e.g., as in rosconsole).
Related issues/pull requests:

https://github.com/ros/catkin/issues/610
https://github.com/ros/catkin/pull/842 (definitions, not merged)
https://github.com/ros/catkin/pull/844 (compile options, not merged due to potential issues)

Propositions for discussion

Option A: Add PKG_CONFIG_CFLAGS which get appended after the include directories. This would make sense as a complement to what CFG_EXTRAS is able to do.
Option B: Add ADDITIONAL_CFLAGS (similar to above) that users can access via ${PROJECT_NAME}_DEFINITIONS, i.e., as add_definitions(${PROJECT_NAME}_DEFINITIONS) (and I am not targeting compile options as in #844 here).
Any suggestions you have on how I could export preprocessor directives to the pkg-config, as I can add to CFG_EXTRAS for CMake?

Closing due to inactivity.


Create a custom role instead of edit ClusterRole

Halyard role binding uses default ClusterRole edit, but it allows read/write access to most objects (kubectl describe clusterrole edit). Would it be possible to create a Role object with only required privileges?
https://github.com/OpsMx/spinnaker-helm/blob/2a0f39ec9d6d0b68c1a351b1e6cc6e12fbc5b847/templates/rbac/rolebinding.yaml#L7-L10
Best.

I have a fix for this, I'll be creating a PR soon

Hey @abhinaybyrisetty. Thanks for picking this up! Do you have an update?


Nito.AsyncEx V5 dependencies for .NET Framework are wrong

Updating from 4.0.1 to 5.0.0-pre-02 results in new smaller Nito dependencies (which is OK), but also results in various .NET core System.* packages dependencies, which is not appropriate when targetting .NET Framework. This is caused by .NET core dependencies being propagated to both .NET core and .NET Framework.
You will need to do something similar to this by properly specifying .NET core dependencies only for .NET core variant.
Thank you in advance.

I believe the .NET tooling will (eventually) resolve this. But I'll keep this issue open, just in case.

Hi,
Just wanted to add to this - your Nito.AsyncEx.Interop.WaitHandles project has an explicit dependency on NETStandard.Library (>= 1.6.1). Is this required? I have a project targeting NETStandard 1.6 and the NuGet package is being brought in, however after reading here, I'm lead to believe explicit references to this library shouldn't be made?
Thanks btw for a great library.

That one hasn't been updated to the latest (VS2017) tooling yet. I'm hoping to get to that soon.

Does v5.0.0-pre-03 work for you?

Nope, there are still .NET Core dependencies being installed when targetting .NET Framework.

You can easily reproduce it yourself. Just open new clean .NET Framework project and try to install your package via nuget - if it tries to pull net standard/system packages then it's wrong, because those already exist in .NET Framework itself.

For example this should be properly ifed to be pulled only when targetting .NET standard, see commit I linked in first comment for future reference.

OK, I'm going to change the approach to multitarget netstandard1.3 and netstandard2.0. This is annoying, because the only need for multitargeting is because the tooling doesn't work properly. But oh, well.
However, this is a netstandard library as of v5. I have no plans to also multitarget net. So NETStandard.Library and Microsoft.NETCore.Platforms will always be referenced. That's just the way it is in the new world. System.Threading.ThreadPool will only be included for netstandard1.3 and not netstandard2.0.

Well if you don't want to keep compatibility with .NET Framework 4.6.1, which is the closest API to netstandard2.0 then there is no reason to keep this issue open.

It's perfectly compatible with net461 already. Is there a problem you saw other than the messy dependency situation?
BTW, 5.0.0-pre-04 is out now, which fixes the System.Threading.ThreadPool dependency.

I was going to try v5 after updating to v4 last week from a custom v3 which had a fix for issue #57
However with v4 I think I've run into issue #57 again in production.  So trying v5 results in the massive set of dependencies.  From what I understand here it's a NuGet issue which will get resolved at some stage (I'm using latest non-prerelease version of VS 2017).
I think I'll roll back to my custom v3.x build for the moment and see if that solves my deadlock issue.  I didn't need anything from v4 - it was just a matter of being well behind and not wanting to fall too far behind when v5 was eventually released.


feat: Support IPv6 parameters when creating / updating interconnection virtual circuits

This PR adds support for the newly available IPv6 parameters when creating / updating interconnection virtual circuits. To allow this feature to also be used with shared interconnections, some changes to the create logic of the interconnection virtual circuit resource were made.
With shared interconnections, the customer does not create virtual circuits, but rather they are created for them by the metal API. Attempting to create a virtual circuit on a shared connection will result in an error from the Metal API.
To get around this, an optional virtual_circuit_id parameter has been added to the virtual circuit resource. If this value is present, the terraform create function will issue an update call to the metal API for the existing specified virtual circuit, rather than trying to create a new one.
Additionally I have added support for the already existing IPv4 parameters in the update function which seemed to be missing.

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

Project coverage is 34.47%. Comparing base (503d9e1) to head (86c0b10).
Report is 84 commits behind head on main.

Files
Patch %
Lines

...ternal/resources/metal/virtual_circuit/resource.go
16.17%
114 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #717      +/-   ##
==========================================
- Coverage   37.91%   34.47%   -3.44%
==========================================
  Files         120      151      +31
  Lines       19476    20707    +1231
==========================================
- Hits         7384     7139     -245
- Misses      11884    13406    +1522
+ Partials      208      162      -46

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


add _utils.py

Sorry, I forgot to add the _utils.py file from the last PR

@aidinbii could you also check for duplication. I see extractor in trainers/scgen/utils


[CPU] Propagate scalable flags for compute Ops

Makes sure that when computing the lowering config for compute Ops
(based on the corresponding root Op), scalable flags for tile sizes are
propagated correctly.
There's a few caveats:

ATM IREE will only use scalable sizes for linalg.matmul, hence
testing is limited to that Op (i.e. we can't really use other Ops as
the root Op),
As DT is not yet available for scalable vectors, updates for
tensor.pack are left as a TODO.

In the forthcoming patches we will gradually make other Ops ready for
scalable vectors and update the tests accordingly.
In addition, a couple of extra debug logs are added and missing CHECK
lines restored (those were accidentally omitted in #16322)
Fixes #16334.

cc @c-rhodes

I will take a look in a couple days. Relying on lowering config to get scalable input_vector_size is still a red flag to me. I wonder what's the plan to infer them from IRs. Have we considered to teach ValueBoundsConstraintSet about it?

Not sure I understand the concern. We use lowering_config to pass tile size information and scalable tile sizes have been supported for a while. We need that information not only for vectorization but also to apply scalable tiling. ValueBoundsAnalysis is an expensive analysis that we used in the past as a gas stopper when lowering_config was not in a good state but I not sure why we would use that analysis to try to infer the information from the IR when that information is already in lowering_config (now working properly).

I will take a look in a couple days.

Thanks! Please, could you bump it on your list? This is quite a blocker for scalable vectorisation.

Relying on lowering config to get scalable input_vector_size is still a red flag to me. I wonder what's the plan to infer them from IRs.

To add to Diego's points, we have been using this mechanism to specify "scalable" flags since https://github.com/openxla/iree/pull/15108 (Oct 2023), so quite a while. I don't really recall anyone raising any concerns about that design, so this is rather surprising. Also, please note that this patch merely implements the existing design (this is not proposing anything new).

I think the concern is mostly about now all tiling configuration settings need to account for scalable vector sizes as well and it is not a "you dont need to know about it if you dont care about it" kind of thing. Now every tile size decision needs to account for scalable tile sizes. This is just an observation from someone sitting on the sidelines, and watching things here.
To the original point, at some point I remember having a discussion (and agreement?) that we were going to rely on looking at the IR + target info to get the vector sizes (ideally on target info). It seems from your previous comment that this is not a direction this is headed in.  But looking at the PR itself, it seems its just adding to the propagation (which itself I dont think is a good idea, but it is what we do today). So that leads to the question of, now everything added to the tile size selection logic needs to account for scalability as we go forward, so thats an extra burden on the whole eco system.
What I am really curious about is, what was not working lowering_config and what changed to it now working. I am not sure I have a handle on what changed

Well, we have to deal with scalable vectors if we want to support them but, as Andrzej mentioned, that support in lowering config happened already in the past and there were no concerns. There are explicit field in lowering_config to hold this information.
I think the conclusion was that the translation unit approach wasn't feasible as multiple ops within the dispatch may need different tile sizes and have different tile levels. Instead, we decided to go from having one lowering_config per dispatch to having one lowering_config per op.  ValueBoundsAnalysis was actually covering some bugs related to lowering_config and pack/unpack ops. We were putting the wrong information in lowering_config and luckily not using it. We moved to a much better state once that was fixed and I think that's the direction that we ended up following. Hopefully this provides more context although I think this is orthogonal to the problem discussed here.
The added complexity seems ok to me as we evolve the system to support more cases. Another example: we would need the concept of "tile size is multiple of X" or even dynamic tile sizes when using the number of threads at runtime to compute the tile sizes for distribution.

Thanks for getting back to me! It's quite late for me, so replying briefly.

I think the concern is mostly about now all tiling configuration settings need to account for scalable vector sizes as well and it is not a "you dont need to know about it if you dont care about it" kind of thing. Now every tile size decision needs to account for scalable tile sizes.

That's a fair point, but it's the first time I'm hearing this feedback (I went through previous discussions and couldn't find anything related). Also, as I mentioned above, this PR merely implements the design that we have today.
Now that I understand your concern I know what needs fixing :) We can abstract this whole logic away in future PRs, that shouldn't be a problem.  In fact, we have been trying something similar in MLIR (re scalable vectors), but couldn't really agree on the right approach.

To the original point, at some point I remember having a discussion (and agreement?) that we were going to rely on looking at the IR + target info to get the vector sizes (ideally on target info).

Something at some point needs to decide what dimension are suitable to be scalable and what dimension are not. Scalable vectors allow Vector Length Agnostic (VLA) programming, but that doesn't mean that any dimension can be scalable. There are various limitations (due to hardware and LLVM implementation) and also some configuration simply don't make sense (due to perf consideration). A compiler driver (IREE in this case) needs to make that decision.
Specifically, we cannot infer information from IR that's not present there. It's for the compiler driver to drive the compilation and to set these things up. As for target info, we know that for SVE we can only have 1 scalable dim and for SME we can have 2 scalable dims. For operations like linalg.matmul that have 3 dims that gives us 3 possibilities to choose from for both extensions (in practice only 1 option makes sense).

Well, we have to deal with scalable vectors if we want to support them but, as Andrzej mentioned, that support in lowering config happened already in the past and there were no concerns. There are explicit field in lowering_config to hold this information.

Yes, they were added but they were "optional" fields. If you were on a path that wasnt related to SVE or SME, then you just ignore that field.

I think the conclusion was that the translation unit approach wasn't feasible as multiple ops within the dispatch may need different tile sizes and have different tile levels. Instead, we decided to go from having one lowering_config per dispatch to having one lowering_config per op. ValueBoundsAnalysis was actually covering some bugs related to lowering_config and pack/unpack ops. We were putting the wrong information in lowering_config and luckily not using it. We moved to a much better state once that was fixed and I think that's the direction that we ended up following. Hopefully this provides more context although I think this is orthogonal to the problem discussed here.

Different discussion for sure, but there is probably some nuance from the previous discussion missed here. Some things are for the whole dispatch. For example, tile and fuse is "common" for all operations. By common, I mean it only matters what the tiling for the consumer is, the same values at producers dont matter, they just get pulled in based on indexing maps. This need to be moved to the translation unit. For individual tiling decisions, yes those are operator specific, but we only need those for vectorization, and if we deduce them based on hardware you dont really need them to be in lowering config, but its OK if we need it. Those need to be per op..

Well, we have to deal with scalable vectors if we want to support them but, as Andrzej mentioned, that support in lowering config happened already in the past and there were no concerns. There are explicit field in lowering_config to hold this information.

Yes, they were added but they were "optional" fields. If you were on a path that wasnt related to SVE or SME, then you just ignore that field.

While the "scalable flags" are always present, they default to false. In this sense they are optional. I'm not sure whether we can do better than that. Also, it is safe to ignore them for all targets not supporting scalable vectors.

ValueBoundsAnalysis was actually covering some bugs related to lowering_config and pack/unpack ops. We were putting the wrong information in lowering_config and luckily not using it.

This looks like on an opposite side to me. The issue is that something is missing and we rely on lowering_config.

OK, this definitely requires more thought. I wasn't aware of these discussions.

We can discuss it either on the issue/PR, or one of Mai-Tai meeting after 2/18. (I'll be on vacation next week)

The earliest I can do is 3/5. I'll add an item to the agenda so that we don't forget.

Can you share some IRs? What is missing in the IR?

This will be pretty simple. We start with something like this:
func.func @pipeline(%A: tensor<1020x1020xf32>, %B: tensor<1020x1020xf32>, %C: tensor<1020x1020xf32>) -> tensor<1020x1020xf32>{
  %1 = linalg.matmul ins(%A, %B: tensor<1020x1020xf32>, tensor<1020x1020xf32>)
            outs(%C: tensor<1020x1020xf32>) -> tensor<1020x1020xf32>
  return %1 : tensor<1020x1020xf32>
}

At what point should IREE select which dimension to tile using scalable sizes? ATM that comes from lowering_config.

The code looks okay to me. Thanks for the waiting.

Thank you for reviewing 🙏🏻 This is very important and very timely for us! If there are no new comments, I'll land it tomorrow.


It's difference between native and shim

When I run the following code in browser（chrome v66） that support promise native
let promiseA = new Promise(resolve => resolve('A'))
let promiseB = new Promise(resolve => resolve(promiseA))
let promiseC = new Promise(resolve => resolve('C'))

promiseB.then(arg => console.log(arg));
promiseC.then(arg => console.log(arg));

the result is C A
but when I run the same code with es6-promise，the result is reverse: A C
which one is right?

Both are correct — callback order is unspecified.


A new Medical Image AI Custom Environment

Description of changes:
Created a new folder in custom-environment for medical image AI research using itkWidgets and MONAI libraries. Sample notebooks using TCIA open data is available.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[x]I have read the CONTRIBUTING doc and adhered to the example notebook best practices
[x]I have updated any necessary documentation, including READMEs
[x]I have confirmed secret codes are not included in the example.
[x]I have tested my notebook(s) and ensured it runs end-to-end


Improve code coverage in soul-admin for SelectorServiceImpl (#802)

Improve code coverage in soul-admin for SelectorServiceImpl (#802)

Codecov Report

Merging #836 (9b28350) into master (07d62b3) will increase coverage by 0.07%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #836      +/-   ##
============================================
+ Coverage     72.31%   72.39%   +0.07%
+ Complexity     1589     1587       -2
============================================
  Files           275      275
  Lines          6304     6304
  Branches        710      710
============================================
+ Hits           4559     4564       +5
+ Misses         1367     1361       -6
- Partials        378      379       +1

Impacted Files
Coverage Δ
Complexity Δ

...l/plugin/divide/balance/spi/RandomLoadBalance.java
68.42% <0.00%> (-10.53%)
6.00% <0.00%> (-1.00%)

...a/soul/admin/service/impl/SelectorServiceImpl.java
95.55% <0.00%> (+7.77%)
20.00% <0.00%> (+1.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 07d62b3...9b28350. Read the comment docs.

RandomLoadBalance'a coverage is lower 10 percent


chore(cli): unify debugging routines into a single command

Description
Unify the debugging routines into a single command.

Codecov Report

Merging #2849 (d4750a4) into main (318107e) will decrease coverage by 55.74%.
The diff coverage is 0.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@             Coverage Diff             @@
##             main    #2849       +/-   ##
===========================================
- Coverage   71.24%   15.50%   -55.74%
===========================================
  Files         511      512        +1
  Lines       66402    66406        +4
===========================================
- Hits        47309    10298    -37011
- Misses      19093    56108    +37015

Flag
Coverage Δ

integration-tests
15.50% <0.00%> (-1.95%)
:arrow_down:

unit-tests
?

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

Impacted Files
Coverage Δ

bin/reth/src/cli.rs
0.00% <0.00%> (-20.49%)
:arrow_down:

bin/reth/src/debug_cmd/execution.rs
0.00% <0.00%> (ø)

bin/reth/src/debug_cmd/merkle.rs
0.00% <ø> (ø)

bin/reth/src/debug_cmd/mod.rs
0.00% <0.00%> (ø)

bin/reth/src/lib.rs
0.00% <ø> (-100.00%)
:arrow_down:

bin/reth/src/stage/mod.rs
0.00% <ø> (ø)

... and 378 files with indirect coverage changes


Add thead and tbody to the createTable function

The two thead and tbody put the header row and body rows into groups. This is not required but can improve accessibility for screen readers and can help with styling for libraries like bootstrap

@Criptic sorry for the delay on this.  We'll get this reviewed soon.


[Coder] Support moving and copying methods by the means of drag and drop

try this
https://mega.co.nz/#!9vE0jIrD!nkSuAAbrT1Sjn01VjaQfVQGAFLqvdIF4EkMeSLuKCWw
I put the necessary dlls in the archive

This would be a big step forward! This combined with multiple selection would eliminate a big reason currently needing to drop into Morphic


Could not run inference with tiny set

When running the inferernce, the following error shows up:
Download language model ...
download_lm_en.sh: 8: [: 099a601759d467cd0a8523ff939819c5: unexpected operator
--2018-10-18 19:16:48--  http://paddlepaddle.bj.bcebos.com/model_zoo/speech/common_crawl_00.prune01111.trie.klm
Resolving paddlepaddle.bj.bcebos.com (paddlepaddle.bj.bcebos.com)... <IP_ADDRESS>
Connecting to paddlepaddle.bj.bcebos.com (paddlepaddle.bj.bcebos.com)|<IP_ADDRESS>|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2018-10-18 19:16:49 ERROR 404: Not Found.
Looks like the file is not present at the mentioned folder. Can you let me know how I can download the pre-trained network for me to run inference?

Looks like the english language model has been moved to another location and hence the one pointed to by the code is invalid. Can you please fix this issue?


Updates to add primary key constraint for QuantitySearchParam and Num…

…berSearchParam
Description
This PR updates the column LowValue and HighValue as NOT NULL and populate SingleValue in both the columns if not range for quantity and number search parameters.
And thus, we are adding primary key constraint for QuantitySearchParam and NumberSearchParam tables with the combination of NOT NULL columns that uniquely identifies row in the table.
Related issues
Addresses [#86362].](https://microsofthealth.visualstudio.com/Health/_boards/board/t/Olympus/Stories/?workitem=86362)
Testing
Existing tests continue to pass.
Tested manually by upgrading the schema and then

POSTing Observation resource with value-quantity and valueRange to validate the changes in dbo.QuantitySearchParamt table
POSTing RiskAssessment resource with probabilityDecimal and probabililtyRange to validate the changes in dbo.NumberSearchParam table

FHIR Team Checklist

[x] Update the title of the PR to be succinct and less than 50 characters
[ ] Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
[x] Tag the PR with the type of update: Bug, Dependencies, Enhancement, or New-Feature
[ ] Tag the PR with Azure API for FHIR if this will release to the Azure API for FHIR managed service (CosmosDB or common code related to service)
[x] Tag the PR with Azure Healthcare APIs if this will release to the Azure Healthcare APIs managed service (Sql server or common code related to service)
Review squash-merge requirements

Semver Change (docs)
Patch|Skip|Feature|Breaking (reason)

Are any test changes needed for this update?

Are any test changes needed for this update?

Since the functionality is intact, and its a matter of the change in database columns (lowValue and highValue) to make it non-nullable, existing tests should still hold true.

INCLUDE(SystemId) WHERE IsHistory = 0

I don't understand these indicies.
Why ResourceSurrogateId is part of index, and not part of include, and why systemId is part of Include and not part of index?

Refers to: src/Microsoft.Health.Fhir.SqlServer/Features/Schema/Migrations/23.sql:388 in ec0d2fd. [](commit_id = ec0d2fdf7d6f6d18f3e885af08fd24568734a373, deletion_comment = False)

INCLUDE(SystemId) WHERE IsHistory = 0

I don't understand these indicies.
Why ResourceSurrogateId is part of index, and not part of include, and why systemId is part of Include and not part of index?
Refers to: src/Microsoft.Health.Fhir.SqlServer/Features/Schema/Migrations/23.sql:388 in ec0d2fd. [](commit_id = ec0d2fd, deletion_comment = False)

This is the existing design of fhir tables. ResourceSurrogateId is the timestamp of when the record is created and is part of almost all the indices to narrow down the search or join related searchParam tables with Resource table. While SystemId is included in index only for non-historical records.

/azp run

It's a good PR, and it does what it say it does in a right way.
But I don't understand why we doing this. Is this yield better results? Is this in preparation for more changes?
To be honest, I don't know why schema looks like it looks right now, but I have hopes what whoever design it had benevolent intent, and put some effort (they even add word SPARSE for low,high values, so looks like person did that deliberately).
It's quite scary to accept schema changes, especially with GA around corner, so can some justification for changes can be produced?

It's a good PR, and it does what it say it does in a right way. But I don't understand why we doing this. Is this yield better results? Is this in preparation for more changes?
To be honest, I don't know why schema looks like it looks right now, but I have hopes what whoever design it had benevolent intent, and put some effort (they even add word SPARSE for low,high values, so looks like person did that deliberately).
It's quite scary to accept schema changes, especially with GA around corner, so can some justification for changes can be produced?

Thanks Ivan for your thoughts and questions.
This is in preparation to be able to add primary key for all fhir tables and be able to uniquely identify rows. Adding primary keys  is not necessarily expected to yield better results but its more towards aligning with best practices to have schema designed. Though this change is not tested with performance test plan but since query plan hasn't changed much, we would atleast get the same performance as of today.
And we might achieve better results with foreign keys implementation in future.
The motivation behind adding primary keys before GA as to do it sooner rather than later. It would be faster to do index changes, rebuild and backfill rows with smaller sizes of databases in production.
However, I am happy to discuss if you see any red flag in these changes and discuss through.


Check user role

What Changed?
ClientController now checks User admin capabilities from the user table in the database. Then directs the user to the appropriate html locations. Created three different html's and jsx's to represent the different available locations.
Why Did it Change?
Without it all users would be directed to the same location whether the user was an admin or not.
What's Affected?
The process is now developed that will take the user to the correct landing page.
How Can I Test?
Change user Admin in the User Table to test admin capabilities, or delete user to test not authorized user.

Another branch got merged into this so it is no longer good to be merged into develop...bell ringing retracted.


CASSANDRA-18355 Avoid serializing full TxnData instances to Accord state tables

patch by Caleb Rackliffe; reviewed by ? for CASSANDRA-18355

https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-18355

Note: Locally, AsyncLoaderTest and AsyncOperationTest seem to pass for me.

Committed as https://github.com/apache/cassandra/commit/56e218638db6816f9a6fa66fa2b6fc35977a92a2


Do not show 'add to garden' control on a guide if the user does not have a garden

It simply generates a JS error; which may or may not be related
application-422078f….js:15 Uncaught TypeError: Cannot read property 'getBoundingClientRect' of undefined

Hmm, as I just mentioned on the other issue, users do automatically get a garden added on sign up. (a garden gets added if one doesn't already exist). I wonder if that's related.

This error was not present till some weeks ago. I am working to fix it by trying to find when this functionality was changed.

I think the "getBoundingClientRect" error is a red herring, for what it's worth.

Yeah, I think so too. I googled the error and it doesn't make much semse. I will try reverting to old code. Let's see what happens.

getBoundingClientRect

Yeah, it cropped up in another area after I wrote this one up.
I wasn't sure why it occurred and didn't show 'Your First Garden'; similar controls were visible later on - it mislead me into thinking there was no garden at all.
This one might be either a wontfix (as new users have a garden) or might be better to narrow in on just the getBoundingClientRect problem.

This issue is only occurring when we call _add_to_gardens.html from a crop's guide, not when we call it from the crop itself. Meaning that there is some error in the view or functionality for 'add-to-gardens'. So I just commented some HTML as in here:
<div class="add-to-garden center">           <!-- <% if current_user && current_user.confirmed? %>             <div add-to-gardens               crop-object=guide               object-type="'guide'"               user=currentUser>             </div>           <% end %> -->         </div>
And voila! It works. Still don't know why this was happening. My best guess is making the first div class 'add-to-garden' was somehow messing things up by rendering our addToGarden functionality.


in series_by_lead_wrapper.py, update FHR_INC to LEAD_SEQ (not FHR_INCREMENT)

In the series_by_lead_wrapper.py script, INIT_INC was replaced by INIT_INCREMENT to explicitly differentiate from INIT_INC (for init INCLUDE) in other MET tools.  For consistency, the same needs to be done for VALID_INC.  This should be updated to VALID_INCREMENT to remove any confusion.

I just add functionality to specify start, end, and increment of a list in the LEAD_SEQ config file. Instead of:
LEAD_SEQ = 3, 5, 7, 9
you can now write
LEAD_SEQ = list(3,9,2)
We can change the name from 'list' if we'd like. This functionality currently differs from the python function range in that the end value is included in the list generated by 'list' instead of excluded.

I propose the following changes to conform to the naming conventions of the other wrappers:
Add a boolean METplus config variable called SERIES_BY_LEAD_GROUP or something similar. If it is set to false, we don't group the forecasts and we read the forecast list as
SERIES_BY_LEAD_GROUP = False
LEAD_SEQ = list(0,96,6)
This replaces the case where:
FHR_BEG = 0
FHR_END = 96
FHR_INCREMENT = 6
and the FHR_GROUP_BEG, FHR_GROUP_END, FHR_GROUP_LABELS variables are not set.
If SERIES_BY_LEAD_GROUP is True, we use LEAD_SEQ_[N] and LEAD_SEQ_[N]_LABEL to specify the forecast group lists.
SERIES_BY_LEAD_GROUP = True
LEAD_SEQ_1 = list(0,18,6)
LEAD_SEQ_1_LABEL = Day1
LEAD_SEQ_2 = list(24,42,6)
LEAD_SEQ_2_LABEL = Day2
LEAD_SEQ_3 = list(48,66,6)
LEAD_SEQ_3_LABEL = Day3
LEAD_SEQ_4 = list(72,72,6)
LEAD_SEQ_4_LABEL = Day4
will replace:
...
FHR_INCREMENT = 6
FHR_GROUP_BEG =  0, 24, 48, 72
FHR_GROUP_END = 18, 42, 66, 72
FHR_GROUP_LABELS = Day1, Day2, Day3, Day4
Please let me know if this sounds good or if you have any suggestions.

I don't see why this shouldn't work.  Thanks for looking into this.
-Minna
Minna Win
NCAR
Research Applications Lab
Phone:<PHONE_NUMBER>
Fax:<PHONE_NUMBER>
On Fri, Apr 12, 2019 at 9:05 PM georgemccabe<EMAIL_ADDRESS>wrote:

I propose the following changes to conform to the naming conventions of
the other wrappers:
Add a boolean METplus config variable called SERIES_BY_LEAD_GROUP or
something similar. If it is set to false, we don't group the forecasts and
we read the forecast list as
SERIES_BY_LEAD_GROUP = False
LEAD_SEQ = list(0,96,6)
This replaces the case where:
FHR_BEG = 0
FHR_END = 96
FHR_INCREMENT = 6
and the FHR_GROUP_BEG, FHR_GROUP_END, FHR_GROUP_LABELS variables are not
set.
If SERIES_BY_LEAD_GROUP is True, we use LEAD_SEQ_[N] and
LEAD_SEQ_[N]_LABEL to specify the forecast group lists.
SERIES_BY_LEAD_GROUP = True
LEAD_SEQ_1 = list(0,18,6)
LEAD_SEQ_1_LABEL = Day1
LEAD_SEQ_2 = list(24,42,6)
LEAD_SEQ_2_LABEL = Day2
LEAD_SEQ_3 = list(48,66,6)
LEAD_SEQ_3_LABEL = Day3
LEAD_SEQ_4 = list(72,72,6)
LEAD_SEQ_4_LABEL = Day4
will replace:
...
FHR_INCREMENT = 6
FHR_GROUP_BEG = 0, 24, 48, 72
FHR_GROUP_END = 18, 42, 66, 72
FHR_GROUP_LABELS = Day1, Day2, Day3, Day4
Please let me know if this sounds good or if you have any suggestions.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/NCAR/METplus/issues/175#issuecomment-482722809, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADlEngHlApVHBQSeBrHB65dw4-4jiOblks5vgPUCgaJpZM4aIg4i
.

This functionality has been implemented and added to the develop branch. Leaving this issue open until the documentation has been updated to reflect the changes.

New section in documentation called Common Config Variables describes this functionality. Closing.


Adding multistage tutorial

Adding a tutorial about how to create a multistage deployment using Keptn and Prometheus.

Thanks - will have a look!
For reference, this is the preview: https://deploy-preview-137--keptn-tutorials.netlify.app/tutorials/keptn-multistage-qualitygates-08/index.html?index=..%2F..index#0

Please add a link to your blog in the beginning of the tutorial


Full names are not shown

This -> Shows user's full name in comments doesn't work anymore for me.
I think I last saw it a week ago.
Probably something in the DOM structure changed?

OK, to clarify - it is obviously working somewhere.
I see it on the current issue, but not on this PR for example.

It fails on line 131.
I believe it's because that line is checking for an element only present on PRs from a fork, but that pull request is just from a different branch.

I think the issue is now fully resolved. Probably from #333. Please re-open if you spot it somewhere.


'NoneType' object has no attribute 'has_file'

I'm trying to diff a couple of files generated by python coverage tool and converted to XML.
I get an exception here:
    383 def file_source(self, filename):
    384     """
    385     Return a list of namedtuple `Line` for each line of code found in the
    386     given file `filename`.
    387
    388     """
--> 389     if self.cobertura1.has_file(filename) and self.cobertura1.filesystem.has_file(
    390         filename
    391     ):
    392         lines1 = self.cobertura1.source_lines(filename)
    393         line_statuses1 = dict(self.cobertura1.line_statuses(filename))

AttributeError: 'NoneType' object has no attribute 'has_file'

Somehow the 2nd clause, self.cobertura1.filesystem is None.

Thanks for reporting. Can you provide the command line you used to get this error?

Not a command, I tried https://github.com/aconrad/pycobertura/blob/22b6d34d828cd6dedf8b69203e5f8e158086a802/README.md?plain=1#L393
In the end I've worked around it by passing a filesystem smth object to the cobertura constructor.
I guess the readme can be updated

Ah, I see. I'll take a look at the README this coming week.

Here's a reproducer
reporter = HtmlReporterDelta(cobertura1, cobertura2, show_source=True)
reporter.generate()

works if we set show_source to False

FTR, it works if the cobertura instantiation has filesystem arg
cobertura1 = Cobertura(xml1, filesystem=filesystem_factory(xml1, source_prefix))
cobertura2 = Cobertura(xml2, filesystem=filesystem_factory(xml2, source_prefix))
reporter = HtmlReporterDelta(cobertura1, cobertura2, show_source=True)
HTML(reporter.generate())


Version control merge tsv

Git is processing diff/merge on a line/row based approach. If we can manage this at cell level for tsv files, we can avoid some git pull conflicts.

redundant: #34


Compilation error for master 0.2.5-dev223

Hi, I'm trying to compile the amalgamation version of 0.2.5-dev223.
I compiled duckdb.cpp/hpp with my application code without using the dll. I don't known if this is correct.
The error is: C1083 Cannot open include file: pcg_uint128.hpp: No such file or directory	duckdb.cpp 42707.
Maybe I have to set some preprocessor define or something?
Thanks.

Ah this is indeed a bug. Thanks for reporting, will fix.

I'm compiling on windows 7, vs2015 64bit.

Should be fixed on master now. Could you verify that it's fixed?

Ok, the #include problem is fixed.
Now the compilation stops with the error: C2872 idx_t: ambiguous symbol
Version 0.2.5-dev235, but I found the same error also in 0.2.4

I think we need a more complete description of what you are doing here. Could you please try to compile a minimal reproducible example of the issue you describe? Thanks!

Sure! I'm working on windows 7, vs2015 64bit.
Just right now I downloaded the 0.2.5-dev276 amalgamation version from https://github.com/cwida/duckdb/releases/download/master-builds/libduckdb-src.zip
The I created a new project (console application) and added duckdb.cpp and duckdb.hpp to it.
I defined _WIN32 and DUCKDB_BUILD_LIBRARY in the preprocessor definitions.
The main is simply

#include "duckdb.hpp"
using namespace duckdb;
int main()
{
DuckDB db(nullptr);
Connection con(db);
auto result = con.Query("SELECT 42");
result->Print();
return 0;
}

The compiler error is C2872 idx_t: ambiguous symbol.
I can found two definitions for idx_t: duckdb.hpp line 91 and line 7524.
Cheers

Aha indeed duckdb.hpp inlines in duckdb.h (the C API) which also defines idx_t. The inlining there probably should not happen in the first place.

This should be fixed now.


fix(curriculum): enhance calorie counter step 45 test flexibility and accuracy

This fix enhances the flexibility and accuracy of the checks done for step 45.
Checklist:

[x ] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #57090

The 3 asserts in this step were all changed as follows:

the first one was changed to allow single or double outer quotes and single or double inner quotes.
the second one was simplified to not repeat the full regex pattern that was in the first and instead to focus on checking the length property is there and is not followed by any other character (like parenthesis). The check optionally allows the presence of semicolon at the end of the line.
the third check was changed to allow single or double outer quotes and single or double inner quotes plus the length property check was enforced (to not allow any character after the property - like parenthesis - but spaces and/or a final semicolon are accepted)

Thank you for your review.

If it's okay, instead of removing it, I will rephrase it (that way we keep that useful hint there):
So from this:

Remember that you will need to use single quotes for your string, so that you can use double quotes within.

I will rephrase to this:

Remember that if you use single quotes for your string, you must also use double quotes within it (or vice-versa).


Follow-up Intents

Issues

If you're having trouble with Articulate we definitely want to help you. If you can provide a little bit of information it will make our troubleshooting job easier.

Please describe the issue you are having here and answer the question below.

Did you download a release or pull from Master? Which release?
What operating system are you running?
Are you running locally or in the cloud?
Which browser are you using?

Feature Request

If you've got a feature request we want to hear it

Please desribe the feature you would like us to add.
Follow-up intents. I'm guessing this is already on the road map, but will be useful.
If possible provide the use case for the feature and how you would use it.
For my case,  I would like a follow up intent where the bot asks the user if he's sure of something e.g. ("are you sure you don't want to order?"), Because a user may change his mind either way when conversing with the bot.

This is being discussed in #223


Needs smarter caching

Reload Github assets in the background, instead of punishing some random request with seconds of latency.

What about a frontend varnish with 24h cache time? So no own caching logic.
So we hit github and all apis once a day.

That would be equivalent to just setting the existing RepoCacheTime to 24h. I'd suggest a but quicker refresh than that (every couple of hours maybe), but above all the issue is that fetching the github data shouldn't be synchronous with a user request, as it takes several seconds. :) This is an easy thing to fix, this is mostly a todo item.

What about that? https://serverfault.com/questions/517963/let-varnish-send-old-data-from-cache-while-its-fetching-a-new-one/517966#answer-517966
https://www.varnish-cache.org/docs/3.0/tutorial/handling_misbehaving_servers.html#grace-mode

related: #5


Never show external images inline.

The Travis run finished (and succeeded) at least 10 minutes ago, not sure why GitHub still has this yellow but it's good to go.


Adding Sudoku game

PR Description 📜
I build a sudoku game using html,css,javascript with new features(provided with clear desciption in the newely added readme file) and I successfully added the new game( sudoku ) assigned to me.
Fixes #256

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[ ] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @lakshmiprasannakusumanchi ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

@kunjgit Could you please check it out and merge it to the main branch

@lakshmiprasannakusumanchi LGTM

we already have this game on gamezone !!! 🎮

Thank you  @lakshmiprasannakusumanchi , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀

@kunjgit But I have done this first know this is my 2nd PR regarding sudoku game I resolved all conflits.


[Usage]: Gemma-2-9b is not supported

Your current environment
This is my vllm versions
vllm                              0.5.0.post1
vllm-flash-attn                   2.5.9
vllm-nccl-cu11                    <IP_ADDRESS>.4.0
How would you like to use vllm
I want to run inference of a gemma-2-9b, which appears in the supported models list in the website.
This is the code
from vllm import LLM, SamplingParams
model_name = "google/gemma-2-9b"  # You can change this to any other supported model
llm = LLM(model=model_name, dtype=torch.float16, device="auto", tensor_parallel_size=2)

I'm getting the error:
(VllmWorkerProcess pid=225845) ERROR 07-01 10:50:45 multiproc_worker_utils.py:226] ValueError: Model architectures ['Gemma2ForCausalLM'] are not supported for now. Supported architectures: ['AquilaModel', 'AquilaForCausalLM', 'BaiChuanForCausalLM', 'BaichuanForCausalLM', 'BloomForCausalLM', 'ChatGLMModel', 'ChatGLMForConditionalGeneration', 'CohereForCausalLM', 'DbrxForCausalLM', 'DeciLMForCausalLM', 'DeepseekForCausalLM', 'FalconForCausalLM', 'GemmaForCausalLM', 'GPT2LMHeadModel', 'GPTBigCodeForCausalLM', 'GPTJForCausalLM', 'GPTNeoXForCausalLM', 'InternLMForCausalLM', 'InternLM2ForCausalLM', 'JAISLMHeadModel', 'LlamaForCausalLM', 'LlavaForConditionalGeneration', 'LlavaNextForConditionalGeneration', 'LLaMAForCausalLM', 'MistralForCausalLM', 'MixtralForCausalLM', 'QuantMixtralForCausalLM', 'MptForCausalLM', 'MPTForCausalLM', 'MiniCPMForCausalLM', 'OlmoForCausalLM', 'OPTForCausalLM', 'OrionForCausalLM', 'PhiForCausalLM', 'Phi3ForCausalLM', 'QWenLMHeadModel', 'Qwen2ForCausalLM', 'Qwen2MoeForCausalLM', 'RWForCausalLM', 'StableLMEpochForCausalLM', 'StableLmForCausalLM', 'Starcoder2ForCausalLM', 'ArcticForCausalLM', 'XverseForCausalLM', 'Phi3SmallForCausalLM', 'MistralModel']

It's been merged into main already but hasn't been part of a release yet. If you want to run it you'll have to build from source.

This will be supported in the next release this week https://github.com/vllm-project/vllm/issues/5806

It's been merged into main already but hasn't been part of a release yet. If you want to run it you'll have to build from source.

how to build from source, could you please teach me the method?

It's been merged into main already but hasn't been part of a release yet. If you want to run it you'll have to build from source.

how to build from source, could you please teach me the method?

You can find it in the vLLM docs.


feat(tizen)!: Migrate Google Container Registry to GitHub Container Registry

Google Container Registry is imposing more painful restrictions on us, so we are migrating the Tizen Studio TV docker image from GCR to GHCR (GitHub Container Registry).  This should be simpler overall for an open source project hosted on GitHub, and should also work well for forks.
Because the older registry is being shut down, this is a breaking change, and the Tizen v1.x packages will be marked as deprecated.

v1 releases have already been marked as deprecated: https://www.npmjs.com/package/tizen-webdriver-server/v/1.1.5
Containers have already been migrated to GHCR and tagged as 2.0.0: https://github.com/shaka-project/generic-webdriver-server/pkgs/container/tizen-studio-tv-3.0
Googlers, see b/355703080 for context


bump version in README to 0.13.0

Small update to bump the version in the README
Is spire working with Scala 2.12? If so, I'm happy to update that too

Current coverage is 48.34% (diff: 100%)

Merging #615 into master will decrease coverage by 0.05%

@@             master       #615   diff @@
==========================================
  Files           170        170
  Lines         11097      11097
  Methods        9563       9559     -4
  Messages          0          0
  Branches       1534       1538     +4
==========================================
- Hits           5371       5365     -6
- Misses         5726       5732     +6
  Partials          0          0

Powered by Codecov. Last update 8eb8ab1...9ff01ab


Add option to use jest instead of ava

I'm submitting a ...
[ ] bug report
[ x ] feature request
[ ] question about the decisions made in the repository
[ ] question about how to use this project

Summary

Tried to use this generator and switch from ava to jest but completely stuck as per this issue.
What gives?

Hey @kristianmandrup, thanks for opening an issue!
I'd love to take a PR to add Jest as an option. I don't really use it outside of React projects myself, so I've not bothered adding it here.
If you haven't tried AVA, I really recommend it – the API is imported like a normal package, rather than being injected into the global context. I find it usually makes tests cleaner and easier for new contributors to jump right in.
Other than that, you might like this starter project which is also structured in more the "Jest way": https://github.com/alexjoverm/typescript-library-starter

Hey, @bitjson I came from ava and switched to jest some time ago when I got back into React.
Seems to be the standard in the react community. Never looked back. Jest has huge JS community support, with fancy editor plugins and more. I'll look at the lib you recommended as an alternative.
Cheers.