Variable explorer viewers too small on high DPI

On both Spyder 3.3.6 and Spyder 4.0.0rc1, when I tried to view some variable by double-clicking a variable from the variable explorer, I found the popup window is too small (in terms of the proportion to the whole screen).
I am using Ubuntu 18.04 on a 4k monitor, with a system-wide 200% zoom.
I tried to play with Spyder's high DPI scaling options (setting it to auto, or to manual 1.5, or to manual 1), and did not see any significant changes.

I think our viewers have a fixed size, and that was adjusted for non-high resolution monitors.
This is a very low priority issue for us, so maybe you or someone else in the community would like to tackle it.

Could you point me to the place in the code base? I may try to fix it, but I need some pointers first :)
Thanks!

Our viewers are placed here
https://github.com/spyder-ide/spyder/tree/master/spyder/plugins/variableexplorer/widgets

Hi @ccordoba12 , I found the hard-coded window sizes in this folder. Those numbers were written down 10 years ago, when the mainstream screen resolution was around 1024 x 768. That's why the variable explorer windows look so small on today's monitors.
I can manually increase the window sizes and submit a pull request.
One question: I also found that some dialog box (such as "Open file...") to be also very small. Shall I also fix it?  If so, please point me to the directory.

I can manually increase the window sizes and submit a pull request.

Well, perhaps we should detect if the window is high resolution or not and adjust the sizes accordingly. I say it because the current sizes are still fine for me in regular screens.

One question: I also found that some dialog box (such as "Open file...") to be also very small. Shall I also fix it? If so, please point me to the directory.

Is not that defined by the operating system? How does that dialog look in other applications?

Could you tell me how we can detect screen resolution? Are there any Python libraries?
A few things we need to consider:

Cross platform
Real time detection? (If I have two monitors with different resolutions, and I could potentially more Spyder from one monitor to another any time.)

If we don't want to dynamically adjust the variable explorer window size, we can use some hard-coded window sizes that are more suitable for today's standard.
For example, I think most Spyder users use 1920 x 1080, 2560 x 1440, 3840 x 2160, and in-between resolutions (such as macbook pros). Very few people may still use low resolutions such as 1366 x 768, so we won't let our hard-coded window exceed 1200 pixels in length and 760 pixels in height. Then I feel like we can find a happy middle ground for most people.
===============
As for the "Open file" dialog box, I suppose you are right: its size is defined by the OS, so we can't do anything about it.

Could you tell me how we can detect screen resolution?

That's when things get complex. @dalthviz, please give @jsh9 a hand on how to detect the resolution of the screen in which Spyder is running.

For example, I think most Spyder users use 1920 x 1080, 2560 x 1440, 3840 x 2160, and in-between resolutions (such as macbook pros)

I don't think you could find a size that goes with both high and regular screens. Besides, very few in our team have screens with such resolutions (I certainly don't), so you have to submit a PR that works for us too.

Are all of your screen resolutions between HD (1920 x 1080) and 4k (3840 x 2160)? If so, then the static numbers that I have in mind will work fine for you.
Detecting screen resolutions seems a bit of an overkill: current Spyder doesn't do it for variable explorer windows, so there isn't really a big reason for us to suddenly start doing so. All I think is necessary is to upgrade the size to to a larger standard.

Are all of your screen resolutions between HD (1920 x 1080) and 4k (3840 x 2160)?

No, they aren't, they are smaller. That was my point precisely.

Do you know how much smaller?

Whatever number I can give would be arbitrary, i.e. there could still be people using Spyder with 1366x768 screens.
Look, you're not going to get away with a fixed size, sorry to put it plain and simple. As I said, you need to detect the screen resolution and generate the size dynamically.

For example, I think most Spyder users use 1920 x 1080, 2560 x 1440, 3840 x 2160, and in-between resolutions (such as macbook pros). Very few people may still use low resolutions such as 1366 x 768, so we won't let our hard-coded window exceed 1200 pixels in length and 760 pixels in height. Then I feel like we can find a happy middle ground for most people.

Please see this from my previous reply. I don't plan to go above 760 pixels in height.
The current implementation in Spyder can get away with a fixed size, so I don't see why the proposed new plan has to use a dynamic size. Do you have some special considerations?

In any case, I'll wait for @dalthviz 's input on how to detect screen resolution, and I'll push two versions (fixed size vs dynamic size) for you all to take a look.

Hi @jsh9 just in case here is the comment about a possible way to set the dialog size dynamically


Support for Uncached ArcGIS Server tiles

@JCSanford asked: Yes, that looks promising! Does that expect a tile cache to exist for that service or can it be uncached?
https://twitter.com/JCSanford/status/524205272257269760

The latest build is using the https://github.com/JasonSanford/tileify-ags library which provides support for non-tiled services.


Unrecognised RecurrenceTimeZone in imported Recurrence Range

While importing events from a calendar, we are seeing the following Recurrence Range: recurrence_range({"Type"=>"NoEnd", "StartDate"=>"2018-06-25", "EndDate"=>"0001-01-01", "RecurrenceTimeZone"=>"Customized Time Zone", "NumberOfOccurrences"=>0})
The Graph documentation on RecurrenceTimeZone doesn't indicate how we should handle "Customized Time Zone". How should we map this value?

I'm having this exact issue too... 🏆 for opening this @MrJakeReid

@MrJakeReid Thanks for the question. We are investigating the issue and will update you shortly.

@MrJakeReid This repo is primarily for doc feedback. Your question might be better suited for the developer forums like MSDN or StackOverflow where there is a community of developers that can help.
If you need urgent support please create a support ticket so you can get one on one help from a support engineer.
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Emails not sent/received

Describe the bug
I know that in the beginning of the month there are typically report emails sent by OC to collectives that I manage, but this month I haven't seen any. I also wrote an update to a collective, and published it. A friend who backs that collective said they received the email, but I haven't (I typically receive them, even if I publish it).
I have checked my spam inbox, and they're not there either. It seems to be a problem on your server side, but on the other hand, some people are receiving emails correctly.
To Reproduce
Steps to reproduce the behavior:

Go to some collective's Updates page
Create and publish an Update
Go to your email inbox
In some seconds or minutes, an email should arrive

Expected behavior
I see an email with the contents of the Update that I wrote and published.
Actual behavior
I don't see any email, in hours since I published.

We use Mailgun for delivering email. I looked in the dashboard and noticed your personal email address was in the "Complaints" list there since "07/08/19 08:45 AM".
Since this date, you're not receiving any email from opencollective.com, we can see such error in the logs "Failed<EMAIL_ADDRESS>→<EMAIL_ADDRESS>'August 2019 update' Not delivering to a user who marked your messages as spam".
I'm removing you from this list and we now need to understand how that happened.

Thanks for investigating it! By the way, I'm also very interested in the stats that are in the monthly report email, is there anyway I could get that?

Looks like Mailgun is tracking openings, so the data is there, but we unfortunately don't have any report we can share.


Xcode doesn't launch after packaging for dist-appstore

Describe the Bug
When packaging for the dist-appstore target Xcode does not launch, when packaging via the running the command in the terminal it does. It's possible the SDK build code is choosing to not launch due to the environment we're running in (a command spawned via child_process).
Steps to reproduce the Bug

Package for dist-appstore via the build explorer - Xcode does not launch
Package for dist-appstore via running the command in terminal - Xcode does launch

Changing from bug to a feature as this is down to us passing --output-dir, we probably want to add a new output choice to allow opening Xcode instead of to a directory


fixed a NPE error for no permission case

Verified that @myothiha09 has signed the CLA. Thanks for the pull request!


refactor: remove "deployAndExecuteFor"

Closes #111.

Thanks for the review and good catch re gas snapshot - however, I will prefer to do it just once, at the end of all refactors.


Support for nginx timer count

The current plugin does not record nginx timers running.
Can we add a gauge to track ngx.timer.running_count() and ngx.timer.pending_count()
Let me know if this makes sense. I can pick this up and raise a PR.

@rishabh-gupta2 I agree that could be a valid feature. PR is welcomed!

Sure Thanks @fffonion , Will raise the PR for this


[dv] Wait no outstanding access on rand_reset

Instead of just checking whether there is no outstanding request, wait until there is none. Although this is already done in the wait_to_issue_reset() function before, there still coud be a request scheduled in between.

This probably requires a discussion before merging this change, @rswarbrick.
The issue is that the sram_ctrl_stress_all_with_rand_reset test fails very rarely because this wait here gives the other sequences enough time to again issue a new access. Then, this check fails:
### Test Results
|  Stage  |            Name            | Tests                                |  Max Job Runtime  |  Simulated Time  |  Passing  |  Total  |  Pass Rate  |
|:-------:|:--------------------------:|:-------------------------------------|:-----------------:|:----------------:|:---------:|:-------:|:-----------:|
|   V3    | stress_all_with_rand_reset | sram_ctrl_stress_all_with_rand_reset |      26.360s      |     3.302ms      |     0     |    1    |   0.00 %    |
|   V3    |                            | **TOTAL**                            |                   |                  |     0     |    1    |   0.00 %    |
|         |                            | **TOTAL**                            |                   |                  |     0     |    1    |   0.00 %    |

## Failure Buckets

* `UVM_ERROR (cip_base_vseq.sv:771) [sram_ctrl_common_vseq] Check failed (cfg.can_reset_with_csr_accesses || !has_outstanding_access()) Trying to trigger a reset with outstanding CSR items.` has 1 failures:
    * Test sram_ctrl_stress_all_with_rand_reset has 1 failures.
        * 0.sram_ctrl_stress_all_with_rand_reset.1151777013931167853633100155329607191575615254501552955960027151287581882848\
          Line 168, in log /home/dev/src/scratch/master/sram_ctrl_main-sim-vcs/0.sram_ctrl_stress_all_with_rand_reset/latest/run.log

                UVM_ERROR @<PHONE_NUMBER> ps: (cip_base_vseq.sv:771) [uvm_test_top.env.virtual_sequencer.sram_ctrl_common_vseq] Check failed (cfg.can_reset_with_csr_accesses || !has_outstanding_access()) Trying to trigger a reset with outstanding CSR items.
                UVM_INFO @<PHONE_NUMBER> ps: (uvm_report_catcher.svh:705) [UVM/REPORT/CATCHER]
                --- UVM Report catcher Summary ---

However, with the change in this PR, the tests pass:
### Simulator: VCS

### Test Results
|  Stage  |            Name            | Tests                                |  Max Job Runtime  |  Simulated Time  |  Passing  |  Total  |  Pass Rate  |
|:-------:|:--------------------------:|:-------------------------------------|:-----------------:|:----------------:|:---------:|:-------:|:-----------:|
|   V3    | stress_all_with_rand_reset | sram_ctrl_stress_all_with_rand_reset |      27.920s      |     3.417ms      |     1     |    1    |  100.00 %   |
|   V3    |                            | **TOTAL**                            |                   |                  |     1     |    1    |  100.00 %   |
|         |                            | **TOTAL**                            |                   |                  |     1     |    1    |  100.00 %   |

Another possibility would be to remove or reduce the wait time here.

Is there some specific test that is failing for this?  See https://github.com/lowRISC/opentitan/blob/master/hw/ip/sram_ctrl/dv/env/seq_lib/sram_ctrl_base_vseq.sv#L231 for an example. Under the hood when we intend to send a random reset a flag is set in dv_base_env_cfg and this causes stop_transaction_generators to return true. See code around https://github.com/lowRISC/opentitan/blob/master/hw/dv/sv/dv_lib/dv_base_env_cfg.sv#L119. cip_base_vseq.sv calls cfg.set_intention_to_reset() to activate this mechanism.
What this does is shorten the time waiting for transactions to stop, which in some cases leads to extremely long tests, and some timeouts.

You run into this problem in the sram_ctrl_stress_all_with_rand_reset. This will run one of the tests in sram_ctrl_stress_all_vseq's vseq_names. Some of the loops over a bunch of transactions are already instrumented with cfg.stop_transaction_generators(): see https://github.com/lowRISC/opentitan/blob/master/hw/ip/sram_ctrl/dv/env/seq_lib/sram_ctrl_base_vseq.sv#L231 for an example.
The log of the test that fails will print the name of the sequence that is started in the loop at sram_ctrl_stress_all_vseq when the virtual_sequencer start method is called. That message is pretty generic, so it is simple to spot.
Knowing the sequence in question can indicate what to instrument with stop_transaction_generators.

Thanks @matutem for looking into this. Yes, the error mentioned in the PR is triggered by running the sram_ctrl_stress_all_with_rand_reset test, e.g.:
./util/dvsim/dvsim.py hw/ip/sram_ctrl/dv/sram_ctrl_main_sim_cfg.hjson -i sram_ctrl_stress_all_with_rand_reset -t vcs --reseed-multiplier 0.0001 --fixed-seed<PHONE_NUMBER>7740875896141410375175346636044647228047463201638952946603882718178
I followed your advice and  had a look into the logs, it seems that this message.
                UVM_ERROR @<PHONE_NUMBER> ps: (cip_base_vseq.sv:771) [uvm_test_top.env.virtual_sequencer.sram_ctrl_common_vseq] Check failed (cfg.can_reset_with_csr_accesses || !has_outstanding_access()) Trying to trigger a reset with outstanding CSR items.
                UVM_INFO @<PHONE_NUMBER> ps: (uvm_report_catcher.svh:705) [UVM/REPORT/CATCHER]
                --- UVM Report catcher Summary ---

Only gets triggered when the run_tl_errors_vseq sequence runs. Regarding the cfg.stop_transaction_generators(), it seems that this is already in the code:
https://github.com/lowRISC/opentitan/blob/22168a3d42febfca725b36dd0d1554b68cf5783e/hw/dv/sv/cip_lib/seq_lib/cip_base_vseq__tl_errors.svh#L286-L289


Error when running test.py

Hi! Thanks for the good work!
I met a problem when I tried to run test.sh. The error said, "cannot import name 'Resize' from 'utils'". I have checked utils.py, there is no function or class called 'Resize'. Is the code missing this part?
Looking forward to your reply.

Hi @Sun-XH,
Thanks for your interest in LSeg and thanks for pointing this out!
Just updated the file. Hope this helps.
Best wishes for your research!
Best,
Boyi


Key for rest Tuple argument missing when mapping tuple type

🔎 Search Terms
"tuple", "tuple type"
🕗 Version & Regression Information

This changed between versions 5.3.3 and 5.4.2

⏯ Playground Link
https://www.typescriptlang.org/play?ts=5.4.2#code/C4TwDgpgBA4hwBUCuYA2EDSEQGcA8ya0EAHsBAHYAmOUSFA1hQPYDuFA2gLoB8UAvFADeHDFACWFKA2zMAZlELouALigYAvhxkh5ilMoDcAKGMB6M1ACSUgKwA6ACz2ATFFbQA5vCgADCkgAtgBGEABOUAA+UABEAAwxvuaWNlAOAMz26e5ePv5BoRHR8TFRsQCMicZCoJBQ5DjAArDwSpjY+ByNYZKeADRQ9kMBIeHcvBrJUNNQAHoA-KYW1nZOrjlQ3k2+JWVuxZW+UAAUrAAW4gDGZxK0EACOSOIAbgCG6BRNrxQgrK+4AEopqkMlkNls-LsDqVoi4kjVwNAGk1BHBEAZ2rg8F1gD0KP0oCNChMpjMFsYgA
💻 Code
type GetTupleKeys<Tuple extends unknown[]> = {[K in keyof Tuple]: K}[keyof Tuple];

// In 5.4.2 we get `number | "0"`
// In 5.3.3 we get `number | "0" | "1"`
{type test = GetTupleKeys<[string, ...number[]]>}
//    ^?

// In 5.4.2 we get `"0" | 2 | "1"` (which is equivalent anyways)
// In 5.3.3 we get `"0" | "1" | 2`
{type test = GetTupleKeys<[string, number]>}
//    ^?

🙁 Actual behavior
In 5.4.2, rest arguments in tuples no longer get a dedicated key/index when mapping the tuple type. In the above example, the tuple type [string, ...number[]] effectively produces the keys number | "0"
🙂 Expected behavior
No regression. The above example should be as 5.3.3 and resolve to the keys number | "0" | "1"
Additional information about the issue
This is specifically impacting the following code:
https://github.com/sindresorhus/type-fest/blob/main/source/set-parameter-type.d.ts#L7
As reported in:
https://github.com/sindresorhus/type-fest/issues/831

It works as intended as per the change in https://github.com/microsoft/TypeScript/pull/57031


fix: add one more condition to check vm is stopped or not

Problem:
There is a difference between Stopping vm inside vm and Stopping vm from GUI

Stopping vm inside vm remains the VMI and virt-launcher, and VM.Spec.RunStrategy is not changed.
Stopping vm from GUI deletes the VMI and virt-launcher, and VM.Spec.RunStrategy is changed to Halt.

The webhook validates VM is stopped or not by VM.Spec.RunStrategy: Halt only.
Solution:
After discussing with @FrankYang0529 , I think we should add one more case to pass webhook validator. It would be better not to change resource status because it's existing kubevirt issue here https://github.com/harvester/harvester/issues/2265#issuecomment-1125758792 until fixed.
Related Issue:
https://github.com/harvester/harvester/issues/4778
Test plan:
These two test cases are already tested successfully.
Stop inside VM case

Create VM in harvester UI and add one more disk like following example. Here I use alpinelinux to boot VM.

Start VM
Login to node and run lsblk to check additional disk size is 3G.
Run poweroff command to stop inside VM instead of GUI.
Resize additional disk size to 4G
Start VM
Login to node and run lsblk to check additional disk size is 4G or not.

Stop from GUI case

Create VM in harvester UI and add one more disk like following example. Here I use alpinelinux to boot VM.

Start VM
Login to node and run lsblk to check additional disk size is 3G.
Stop VM from GUI
Resize additional disk size to 4G
Start VM
Login to node and run lsblk to check additional disk size is 4G.

@Mergifyio backport v1.2


parse latest weekly pdf and get number of tests for GE

Related to #863, but parses another document (since the mentioned doesn't really contain any text, but just images).
Not 100% sure if things are fine as is, but it should parse the latest pdf and extract the number of tests

AFAWK, the BAG is going to publish updated numbers of tests p. all Cantons. We will check by the beginning of next week. Best, Andreas

AFAWK, the BAG is going to publish updated numbers of tests p. all Cantons. We will check by the beginning of next week. Best, Andreas

Sure, that would be nice as well!


Chinese langs

Hey I have just translated the new strings recently. Can you guys kick off the build and make a sync? Thanks

Built. Can you open a PR with the changes please.


Dropping foreign key columns

Hi
When dropping foreign key columns using alter table statements, dbdiff uses "DROP CONSTRAINT". Instead, it should use "DROP FOREIGN KEY".

@majdzadeh Could you please explain the difference and implications for us so we're clear? Thanks

According to official documentation, to drop foreign keys we should use DROP FOREIGN KEY instead of DROP CONSTRAINT

This is be part of the same cleanup as #41


Add support for Python 3.12 and drop EOL 3.7

The second Python 3.12 release candidate is out! :rocket:

Call to action
We strongly encourage maintainers of third-party Python projects to prepare their projects for 3.12 compatibilities during this phase, and where necessary publish Python 3.12 wheels on PyPI to be ready for the final release of 3.12.0.

Python 3.12.0 final is due out in two weeks: 2023-10-02.
See also https://dev.to/hugovk/help-test-python-312-beta-1508/

Python 3.7 is EOL and no longer receiving security updates (or any updates) from the core Python team.

version
released
eol

3.11
2022-10-24
2027-10-24

3.10
2021-10-04
2026-10-04

3.9
2020-10-05
2025-10-05

3.8
2019-10-14
2024-10-14

3.7
2018-06-26
2023-06-27

https://devguide.python.org/versions/

Building this PR worked for me with 3.12.0, and ODBC queries functioned as expected against an existing SQL Server instance.


Make functors macros hygienic and works outside NumericFuncs module.


Correcting the modules path in order to support other distros

This patch fixes #539. Not all supported distros have /lib as a symlink of
/usr/lib. For example, Ubuntu 18.04 doesn't. This causes an issue with
tcmu-runner; which requires target_core_user and other modules to be able to
build.
In order to fix this, we just need to mount /lib/modules instead so all of
the supported distributions are capable of the build.

This change is

I am experiencing the same issue on Ubuntu 18.0.4.
The PR fixes it allowing to deploy glusterfs

I experienced the same issue with a on-premise Kubernetes cluster. Changing the paths of the volumes in the shown way fixed the issue for me too.

I ran into this as well, on Ubuntu 16.04.05 running Kubernetes 1.13.1-00, and changing the modules path fixed it.

Fixes: #572

@jarrpa @nixpanic are we able to merge this?


Improve Slack message when candidates sign up

Context
The signup messages currently look like this:

Changes proposed in this pull request
Make them look like:

✨ Candidate #982 just signed up

This is more typographically pleasing, provides a visual queue that about the type of message and uses a meaningful number in the message (so we can celebrate the 1000th real sign up).
Guidance to review
However you want.
Link to Trello card
https://trello.com/c/mGLdC4yg/185-post-new-sign-ups-to-slack-every-10th-candidate
Things to check

[x] This code doesn't rely on migrations in the same Pull Request
[x] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[x] API release notes have been updated if necessary
[x] New environment variables have been added to the Azure config

@mnacos @tvararu updated!


FizzBuzz using recursion

FizzBuzz algorithm using recursion

Thank you for your PR!
Unfortunately a solution similar to yours has already been submitted :/
The goal is to find creative/abstract new solutions to FizzBuzz.
See The top 5 samples here.
Thanks anyway! :)


Light theme

I really miss the light theme on obsidian, it was by far my favourite theme to use - I really don't like dark themes - please bring back the light theme!! I'd do it myself but I barely have enough knowledge of coding to make an account here. <33

hi aishias, thank you very  much for your kind appreciation in the light theme. I've jusct proceeded submitting the light theme to the Obsidian community. You will find it soon (after the approval) with the name Sparkling Day.
Enjoy the light theme! 😊

Now online🙂
Il Mar 13 Feb 2024, 10:24 aishias @.***> ha scritto:

Thank you so much!!!

On 10. Feb 2024, at 10:49, isax785 @.***> wrote:
hi aishias, thank you very much for your kind appreciation in the light
theme. I've jusct proceeded submitting the light theme to the Obsidian
community. You will find it soon (after the approval) with the name
Sparkling Day.
Enjoy the light theme! 😊
—
Reply to this email directly, view it on GitHub <
https://github.com/isax785/obsidian-sparkling-night/issues/1#issuecomment-1936970447>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/BGA2RXLXMKUS26FQAZWBDULYS5GCRAVCNFSM6AAAAABDAPVCPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZWHE3TANBUG4>.

You are receiving this because you authored the thread.

—
Reply to this email directly, view it on GitHub
https://github.com/isax785/obsidian-sparkling-night/issues/1#issuecomment-1940884982,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOSO647GLTEFDSTGEYQHZWDYTMWMBAVCNFSM6AAAAABDAPVCPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBQHA4DIOJYGI
.
You are receiving this because you commented.Message ID:
@.***>

Thank u icon!!

On 13. Feb 2024, at 18:28, isax785 @.***> wrote:
Now online🙂
Il Mar 13 Feb 2024, 10:24 aishias @.***> ha scritto:

Thank you so much!!!

On 10. Feb 2024, at 10:49, isax785 @.***> wrote:
hi aishias, thank you very much for your kind appreciation in the light
theme. I've jusct proceeded submitting the light theme to the Obsidian
community. You will find it soon (after the approval) with the name
Sparkling Day.
Enjoy the light theme! 😊
—
Reply to this email directly, view it on GitHub <
https://github.com/isax785/obsidian-sparkling-night/issues/1#issuecomment-1936970447>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/BGA2RXLXMKUS26FQAZWBDULYS5GCRAVCNFSM6AAAAABDAPVCPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZWHE3TANBUG4>.

You are receiving this because you authored the thread.

—
Reply to this email directly, view it on GitHub
https://github.com/isax785/obsidian-sparkling-night/issues/1#issuecomment-1940884982,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOSO647GLTEFDSTGEYQHZWDYTMWMBAVCNFSM6AAAAABDAPVCPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBQHA4DIOJYGI
.
You are receiving this because you commented.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub https://github.com/isax785/obsidian-sparkling-night/issues/1#issuecomment-1942153061, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGA2RXPI6PO37F2OV7A2AZ3YTOWEPAVCNFSM6AAAAABDAPVCPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBSGE2TGMBWGE.
You are receiving this because you authored the thread.


HttpClient.AddCertificate does not work for adding Keystore (.Key) file

This is the first Web Service call I have written where I need to send certificates so apologies if I am not describing this 100%

Describe the bug
When adding a Keystore certificate using the HTTPClient.AddCertificate, the following error occurs:
"Cannot find the requested object".

A large US bank requires a Pem certificate and a Key certificate to be sent when calling their web service. Basically this is what the cURL looks like if it helps:

I am able to successfully call the WS using Postman and as you can see Postman caters for a Key and a Cert (here I use the Pem certificate) certificate.

In AL I am using the following code to to add the certificates in the hope that I can add the two certificates, however when I get to loading the Key Certificate, it throws out a message “Cannot find the requested object” when hitting the code lClient.AddCertificate(lKeyCert,‘’)
local procedure CallforValidation(pBody: Text; pToken: Text) rResponse: Text;
var
lClient: HttpClient;
lRequest: HttpRequestMessage;
lResponse: HttpResponseMessage;
lRequestHeader: HttpHeaders;
lRequestContent: HttpContent;
lResponseTextOut: Text;
lJObject: JsonObject;
lToken: Text;
lBase64: Codeunit "Base64 Convert";
lInstreamCert: InStream;
lInstreamKey: InStream;
lSetup: Record SetupTable
lPemCert: Text;
lKeyCert: Text;
begin
    lSetup.Get();

    lRequestHeader.Clear();
    lRequest.GetHeaders(lRequestHeader);
    lRequestHeader.Add('Authorization', 'Bearer ' + pToken);
    lRequest.SetRequestUri(lSetup."Account Verification URL");

    //Add Content
    if pBody <> '' then
        lRequestContent.WriteFrom(pBody);

    lRequestContent.GetHeaders(lRequestHeader);
    if lRequestHeader.Contains('Content-Type') then
        lRequestHeader.Remove('Content-Type');
    lRequestHeader.Add('Content-Type', 'application/json');
    lRequestHeader.Add('gateway-entity-id', lSetup."Gateway Entity ID");
    lRequestHeader.Add('client-request-id', 'xxx-xxx-xxx-xxx-xxx-xxx-xxx');

    lRequest.Content := lRequestContent;
    lRequest.Method('POST');

    lClient.Clear();
    lSetup.CalcFields("Certificate File");
    lSetup."Certificate File".CreateInStream(lInstreamCert);
    lPemCert := lBase64.ToBase64(lInstreamCert);
    lClient.AddCertificate(lPemCert, '');

    lSetup.CalcFields("Key File");
    lSetup."Key File".CreateInStream(lInstreamKey);
    lKeyCert := lBase64.ToBase64(lInstreamKey);
    lClient.AddCertificate(lKeyCert, '');

    if lClient.Send(lRequest, lResponse) then begin
        lResponse.Content.ReadAs(lResponseTextOut);
        IF NOT lJObject.ReadFrom(lResponseTextOut) then
            Error('Invalid response, expected a JSON object');
        exit(lResponseTextOut);
    end;
end;

Is there another method I should be using to load a Keystore certificate?
2. To Reproduce
This may be really difficult to reproduce
3. Expected behavior
The .Key certificate will load
4. Actual behavior
When adding a Keystore certificate using the HTTPClient.AddCertificate, the following error occurs:
"Cannot find the requested object"
5. Versions:
AL Language v9.3.646020
BC On Prem Version: NA Business Central 17.2 (Platform 17.0.19353.19730 + Application 17.2.19367.19735)

Hi, this issue is out of scope of for this repository. You should do one of the following:

Open a support request to CSS through the PartnerSource portal
Open a bug in Collaborate
Contact your Service Account Manager (SAM) in your local subsidiary to understand what is included in your contract as of support incident and PAH (Partner Advisory Hours). Your SAM might also direct you "step by step" how to open a support request or how to get credentials, if this is the first time for you or your company

As a reminder, this repository only handles issues to do with the compiler or VSCode development experience for AL.

Regardless of whether this is out of scope for this repository, for the unfortunate soul who comes across this issue, this was resolved by combining the PEM certificate and the KEY certificate into one PFX certificate.
By downloading and installing openSSL and then using command prompt to convert the certs using the following command line:
openssl pkcs12 -export -out “Path to Certs\Cert.pfx” -inkey “Path to Certs\Cert.key” -in “Path to Certs\Cert.pem”
The PFX cert can then be stored in a blob field in a table and then sent with the Web Service request as follows:
lClient.Clear();
lSetup.CalcFields("Certificate Store");
lSetup."Certificate Store".CreateInStream(lInstreamCert);
lPemCert := lBase64.ToBase64(lInstreamCert);
lClient.AddCertificate(lPemCert, '');

Regardless of whether this is out of scope for this repository, for the unfortunate soul who comes across this issue, this was resolved by combining the PEM certificate and the KEY certificate into one PFX certificate.
By downloading and installing openSSL and then using command prompt to convert the certs using the following command line:
openssl pkcs12 -export -out “Path to Certs\Cert.pfx” -inkey “Path to Certs\Cert.key” -in “Path to Certs\Cert.pem”
The PFX cert can then be stored in a blob field in a table and then sent with the Web Service request as follows:
lClient.Clear();
lSetup.CalcFields("Certificate Store");
lSetup."Certificate Store".CreateInStream(lInstreamCert);
lPemCert := lBase64.ToBase64(lInstreamCert);
lClient.AddCertificate(lPemCert, '');

Thanks for the solution, it was indeed a great help, I was smashing my head into different thing to make it work, previously we had a certificate with the password, recently the third party has changed the communication protocol and out functionality was not working. Now they have provided a security certificate and a key file. Using your command, I was able to generate the certificate, but we also need to set the password as well, my adding an extra parameter, I was able to generate a certificate and use it in the AL, here is the updated command,
openssl pkcs12 -export -out "D:\Cert.pfx" -inkey "D:\IT_auth.key" -in "ITSSL.cer" -name "Client Certificate" -password pass:your_password


Specificity minimum AKS configuration (NodesCound, Memory/CPU on VMs)

As I see, we will create bunch of resources (pods) on  AKS.
Could you explicitly specify- the minimum recommended cluster size to successfully run Istior on AKS?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 68b5d00d-529b-a8be-47bf-773c967f0e72
Version Independent ID: 0cf044ef-b26f-a8fa-213f-1e3fffaf53d6
Content: Install Istio in Azure Kubernetes Service (AKS)
Content Source: articles/aks/istio-install.md
Service: container-service
GitHub Login: @paulbouwer
Microsoft Alias: pabouwer

@SychevIgor Thanks for your feedback.
I will submit a PR to include the minimum requirements.

@SychevIgor PR is merged and the changes will go live in few hours.


IDEA: unify rust neon_local and python test fixtures

Since now neon_local is meant only for local development and not for distribution we can unify them. What about having a python class to handle compute and storage start/stop and rewrite neon_local in python?

WDYT @hlinnaka ?

A wild idea: rewrite test fixtures to Rust instead :)

That's not a crazy idea either. pytest is a nice framework, but I think doing more with Rust would allow us to do more "white-box" testing.

AFAIK there were some reasons against using rust for integration tests, so back then they were rewritten in python, and that's the reason why we have this split between rust that remained in the local control plane and python tests. I like both ideas. If people are ok with recompiling test code I'm more towards using rust everywhere. (No more problems with
different python versions and virtualenvs yay). So in general I vote for having local control plane/cli and tests written in the same language so the code is shared through some library. If the language is rust we can share even more with actual binaries.

That said, I'd also love to have Helm chart that installs the whole shebang into a kubernetes cluster. Including pageserver, safekeepers, proxy, mock S3 server, etcd, and the cloud console.

This would be super useful, and should be a separate issue.

Works for me.
That said, I'd also love to have Helm chart that installs the whole shebang into a kubernetes cluster. Including pageserver, safekeepers, proxy, mock S3 server, etcd, and the cloud console. If we had that, we could perhaps replace our python test harness with that too. That's a more ambitious goal, though.

When I wrote charts for proxy and console I had idea to write charts for all components and one uber chart that includes all them  as subcharts (so you all install whole stack by single command). It useful for tests and for community who wants to try  Neon locally. But what to do with console? It couldn't be public chart. But without console how to create/start/delete projects? I have no answer.

Works for me.
That said, I'd also love to have Helm chart that installs the whole shebang into a kubernetes cluster. Including pageserver, safekeepers, proxy, mock S3 server, etcd, and the cloud console. If we had that, we could perhaps replace our python test harness with that too. That's a more ambitious goal, though.

When I wrote charts for proxy and console I had idea to write charts for all components and one uber chart that includes all them as subcharts (so you all install whole stack by single command). It useful for tests and for community who wants to try Neon locally. But what to do with console? It couldn't be public chart. But without console how to create/start/delete projects? I have no answer.

We have got to make the web console public too, or at least extract all the needed parts and publish them. Need to discuss the exact mechanics of that..

My view - for hobby projects and local tests I prefer have/use some cli tool to manage computes instead of make console public.


Dual plugins for PyCharm and WebStorm

It would be nice to have dual plugins for PyCharm and WebStorm that autotranspile, read warnings and errors from WebStorm then map them to the piece of python code in PyCharm, highlight and display.
Such checks can be made manually but such automation would be convenient.

I actually have a personal bulletpoint list of what I would like to see in a Transcrypt plug-in for PyCharm, and have considered creating one. The plug-in would likely have to be created using Kotlin and from what I've seen, the PyCharm plug-in architecture has a bit of a learning curve. Regardless though, it would have to be done as a separate project from Transcrypt itself.


Done : Removed alt text from Github Images

Removed all the alt texts from the github images

I'm sorry, but unfortunately psycho5 asked if he could work on the issue first. Your code looks good other than that you deleted all of the image alt text, not just the Github images.
Thank you for your contribution though--I'll try and find some other issues that you could work on soon.

@Supriya-shashivasan , would you be interested in helping with issue #9 ?

Or @girishpatil ?

Sure.. ll work on it


Direct Ethernet connection not working

I'm having some difficulty connecting to the notebook server with my PYNQ board.  Here are the symptoms:

It usually seems to book ok to the notebook screen when etherent is connected to my local server.
Cannot connect to http://<IP_ADDRESS>:9090 with a direct ethernet cable after power up or reset

Ping from PC to <IP_ADDRESS> fails
Fails with multiple cables
My windows PC does recognize that it is connected to an ethernet device at 1 gbs..

after connecting a serial port to PYNQ
pinging my PC from PYNQ fails with 'network unreachable'
pinging <IP_ADDRESS> from PYNQ works

Here is the boot log from reset
pynq_boot.txt

When directly connecting you need to ensure that the windows computer is configured to be on the same subnet as pynq. The instructions on how to do this are at http://pynq.readthedocs.io/en/latest/17_appendix.html#assign-your-laptop-pc-a-static-ip-address. If it still doesn't work, can you please provide the output of ipconfig on the windows machine and ifconfig on the pynq?

Thank you Peter - it works fine now. You might note that the PYNQ pictorial quickstart that ships doesn't mention this requirement Thanks for helping me out.


d tracing

WIP Desired LRP Handler
cleaned up trace-id to not use hard-coding
Actual LRP Handler

Thank you for submitting a pull request to the bbs repository!
We appreciate the contribution. To help us understand the context for your pull request, please fill out this template to the best of your ability.
Please make sure to complete all of the following steps

Check the Contributing document on how to sign the CLA and run tests.
Submit your PR to this repo.
Submit an accompanying PR Review Request referencing this PR so the Diego Team knows to review your pull request.

Note: this PR will not be reviewed unless you submit the PR Review Request.

Please provide the following information:
What is this change about?

Please describe.

What problem it is trying to solve?

Please describe.

What is the impact if the change is not made?

Please describe.

How should this change be described in diego-release release notes?

Something brief that conveys the change. See previous release notes for examples.

Please provide any contextual information.

Include any links to other PRs, stories, slack discussions, etc.

Tag your pair, your PM, and/or team!

It's helpful to tag someone on your team or your team alias in case we need to follow up later.

Thank you!

Superceded by: https://github.com/cloudfoundry/bbs/pull/65
Merged!


Fixed scrollResponder's scroll to keyboard for horizontal-scroll pagination enabled scroll views

Motivation: Current implementation always assumes the x offset of the scroll view to be 0 and calculates only the y offset to scroll the view to keyboard. However, for horizontal scroll views, this forces the scroll view to jump back to 0 coordinate in the x direction and consequently hang. The fix addresses this bug.

@nicklockwood would you mind taking a look at this pull request? It's been a while since the last commit was reviewed.

@nicklockwood How are we on this?

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/fixed-scrollresponders-scroll-to-keyboard-for-horizontal-scroll-pagination-enabled-scroll-views
Product Pains has been very useful in highlighting the top bugs and feature requests:
https://productpains.com/product/react-native?tab=top
Also, if this issue is a bug, please consider sending a pull request with a fix.


Unable to contribute because none of the scripts work?

Describe the bug
Thought I would have a look and attempt to contribute to the project, but can't get the tests or the build to work.
To Reproduce
Basically just tried to follow the instructions in CONTRIBUTING.md:

Made sure I had updated node installed<EMAIL_ADDRESS>Installed yarn, as per their instructions<EMAIL_ADDRESS>Made a fork of the project
Cloned it locally
Ran yarn to install dependencies
Ran yarn test to check that things worked, and got 33 failed tests with this error:

Cannot find module '@hookform/resolvers' or its corresponding type declarations.

I thought maybe I needed to run yarn build first, but running that just gives me this:

No matches found: "build:*"

So... not sure what to do now 🤷♂
Expected behavior
Cloning the repo, and following the instructions in CONTRIBUTING.md shouldn't result in any errors.
Desktop:

OS: Windows 10

Node: v18.12.1
Yarn: 3.4.1

Did you solve your issue?

Nope, don't know how

Could you try again from start?

Fork then clone the repo
yarn
yarn test

If issue persist, can you send a screenshot?

Yeah, same issues still:
yarn

yarn test

yarn build

@Svish you can pull the repo, we have switched to pnpm for severals reasons. Can you try?

Yeah, just need to figure out how to install pnpm then... checking it out now 😊

Well, wish you hadn't closed this, because there are still issues it seems.
First of all, just running pnpm just prints out version and usage, so the CONTRIBUTING.md should be adjusted to pnpm install or pnpm i, I'm guessing?
Second, when I ran pnpm i, I get this:

Running pnpm test actually does seem to work now, so that's great. pnpm run check:all also seems to run without errors.
But yeah, the build script, is still not working, unless I'm "running it wrong", or something, which could be a thing, as I'm not familiar with either yarn nor pnpm

Have you tried from a fresh clone? What's your pnpm version?
Mine is 7.29.3

Just tried from a fresh clone, all is working for me 🤔

git clone
pnpm i
pnpm build

log output
 ➜  tmp g clone git@github.com:react-hook-form/resolvers.git
Cloning into 'resolvers'...
remote: Enumerating objects: 2286, done.
remote: Counting objects: 100% (143/143), done.
remote: Compressing objects: 100% (100/100), done.
remote: Total 2286 (delta 46), reused 102 (delta 29), pack-reused 2143
Receiving objects: 100% (2286/2286), 1.74 MiB | 3.02 MiB/s, done.
Resolving deltas: 100% (1249/1249), done.
➜  tmp cd resolvers
➜  resolvers git:(master) pnpm i
Lockfile is up to date, resolution step is skipped
Packages: +817
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Packages are hard linked from the content-addressable store to the virtual store.
Content-addressable store is at: /Users/joris/Library/pnpm/store/v3
Virtual store is at:             node_modules/.pnpm
Progress: resolved 817, reused 817, downloaded 0, added 817, done

devDependencies:
+ @testing-library/dom 9.0.1
+ @testing-library/jest-dom 5.16.5
+ @testing-library/react 14.0.0
+ @testing-library/user-event 14.4.3
+ @types/node 18.15.3
+ @types/react 18.0.28
+ @types/testing-library__jest-dom 5.14.5
+ @typescript-eslint/eslint-plugin 5.55.0
+ @typescript-eslint/parser 5.55.0
+ @vitejs/plugin-react 3.1.0
+ ajv 8.12.0
+ ajv-errors 3.0.0
+ check-export-map 1.3.0
+ class-transformer 0.5.1
+ class-validator 0.14.0
+ computed-types 1.11.2
+ eslint 8.36.0
+ eslint-config-prettier 8.7.0
+ fp-ts 2.13.1
+ husky 8.0.3
+ io-ts 2.2.20
+ io-ts-types 0.5.19
+ joi 17.8.4
+ jsdom 21.1.1
+ lint-staged 13.2.0
+ microbundle 0.15.1
+ monocle-ts 2.3.13
+ newtype-ts 0.3.5
+ nope-validator 1.0.4
+ npm-run-all 4.1.5
+ prettier 2.8.4
+ react 18.2.0
+ react-dom 18.2.0
+ react-hook-form 7.43.6
+ reflect-metadata 0.1.13
+ superstruct 1.0.3
+ typanion 3.12.1
+ typescript 5.0.2
+ vest 4.6.9
+ vite 4.2.0
+ vite-tsconfig-paths 4.0.7
+ vitest 0.29.3
+ yup 0.32.11
+ zod 3.21.4

><EMAIL_ADDRESS>prepare /Users/joris/w/tmp/resolvers
> run-s build:src build && check-export-map && husky install

><EMAIL_ADDRESS>build:src /Users/joris/w/tmp/resolvers
> microbundle build --globals react-hook-form=ReactHookForm

Build "@hookform/resolvers" to dist:
      327 B: resolvers.js.gz
      289 B: resolvers.js.br
      322 B: resolvers.mjs.gz
      290 B: resolvers.mjs.br
      337 B: resolvers.module.js.gz
      299 B: resolvers.module.js.br
      425 B: resolvers.umd.js.gz
      369 B: resolvers.umd.js.br

><EMAIL_ADDRESS>build /Users/joris/w/tmp/resolvers
> npm-run-all --parallel 'build:*'

><EMAIL_ADDRESS>build:yup /Users/joris/w/tmp/resolvers
> microbundle --cwd yup --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:superstruct /Users/joris/w/tmp/resolvers
> microbundle --cwd superstruct --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:zod /Users/joris/w/tmp/resolvers
> microbundle --cwd zod --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:vest /Users/joris/w/tmp/resolvers
> microbundle --cwd vest --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:nope /Users/joris/w/tmp/resolvers
> microbundle --cwd nope --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:io-ts /Users/joris/w/tmp/resolvers
> microbundle --cwd io-ts --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:joi /Users/joris/w/tmp/resolvers
> microbundle --cwd joi --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:src /Users/joris/w/tmp/resolvers
> microbundle build --globals react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:class-validator /Users/joris/w/tmp/resolvers
> microbundle --cwd class-validator --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:ajv /Users/joris/w/tmp/resolvers
> microbundle --cwd ajv --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:computed-types /Users/joris/w/tmp/resolvers
> microbundle --cwd computed-types --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:typanion /Users/joris/w/tmp/resolvers
> microbundle --cwd typanion --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

Build "@hookform/resolvers" to dist:
      327 B: resolvers.js.gz
      289 B: resolvers.js.br
      322 B: resolvers.mjs.gz
      290 B: resolvers.mjs.br
      337 B: resolvers.module.js.gz
      299 B: resolvers.module.js.br
      425 B: resolvers.umd.js.gz
      369 B: resolvers.umd.js.br
Build "@hookform/resolvers/superstruct" to dist:
      276 B: superstruct.js.gz
      222 B: superstruct.js.br
      284 B: superstruct.modern.mjs.gz
      237 B: superstruct.modern.mjs.br
      289 B: superstruct.module.js.gz
      236 B: superstruct.module.js.br
      373 B: superstruct.umd.js.gz
      310 B: superstruct.umd.js.br
Build "@hookform/resolvers/nope" to dist:
      318 B: nope.js.gz
      266 B: nope.js.br
      299 B: nope.modern.mjs.gz
      261 B: nope.modern.mjs.br
      333 B: nope.module.js.gz
      282 B: nope.module.js.br
      407 B: nope.umd.js.gz
      350 B: nope.umd.js.br
Build "@hookform/resolvers/typanion" to dist:
      297 B: typanion.js.gz
      242 B: typanion.js.br
      283 B: typanion.modern.mjs.gz
      239 B: typanion.modern.mjs.br
      307 B: typanion.module.js.gz
      257 B: typanion.module.js.br
      389 B: typanion.umd.js.gz
      322 B: typanion.umd.js.br
Build "@hookform/resolvers/joi" to dist:
      566 B: joi.js.gz
      508 B: joi.js.br
      463 B: joi.modern.mjs.gz
      409 B: joi.modern.mjs.br
      580 B: joi.module.js.gz
      513 B: joi.module.js.br
      668 B: joi.umd.js.gz
      589 B: joi.umd.js.br
Build "@hookform/resolvers/computed-types" to dist:
      329 B: computed-types.js.gz
      281 B: computed-types.js.br
      279 B: computed-types.modern.mjs.gz
      230 B: computed-types.modern.mjs.br
      341 B: computed-types.module.js.gz
      292 B: computed-types.module.js.br
      422 B: computed-types.umd.js.gz
      370 B: computed-types.umd.js.br
Build "@hookform/resolvers/yup" to dist:
      603 B: yup.js.gz
      512 B: yup.js.br
      540 B: yup.modern.mjs.gz
      459 B: yup.modern.mjs.br
      613 B: yup.module.js.gz
      523 B: yup.module.js.br
      703 B: yup.umd.js.gz
      606 B: yup.umd.js.br
No name was provided for external module 'vest/promisify' in output.globals – guessing 'promisify'
Build "@hookform/resolvers/class-validator" to dist:
      489 B: class-validator.js.gz
      412 B: class-validator.js.br
      447 B: class-validator.modern.mjs.gz
      388 B: class-validator.modern.mjs.br
      510 B: class-validator.module.js.gz
      436 B: class-validator.module.js.br
      590 B: class-validator.umd.js.gz
      509 B: class-validator.umd.js.br
Build "@hookform/resolvers/zod" to dist:
      544 B: zod.js.gz
      485 B: zod.js.br
      493 B: zod.modern.mjs.gz
      439 B: zod.modern.mjs.br
      561 B: zod.module.js.gz
      498 B: zod.module.js.br
      649 B: zod.umd.js.gz
      573 B: zod.umd.js.br
Build "@hookform/resolvers/vest" to dist:
      447 B: vest.js.gz
      383 B: vest.js.br
      350 B: vest.modern.mjs.gz
      309 B: vest.modern.mjs.br
      407 B: vest.module.js.gz
      358 B: vest.module.js.br
      533 B: vest.umd.js.gz
      463 B: vest.umd.js.br
No name was provided for external module 'fp-ts/Either' in output.globals – guessing 'Either'
No name was provided for external module 'fp-ts/function' in output.globals – guessing '_function'
No name was provided for external module 'fp-ts/ReadonlyArray' in output.globals – guessing 'ReadonlyArray'
No name was provided for external module 'fp-ts/Option' in output.globals – guessing 'Option'
No name was provided for external module 'fp-ts/Semigroup' in output.globals – guessing 'SemiGroup'
No name was provided for external module 'fp-ts/ReadonlyRecord' in output.globals – guessing 'ReadonlyRecord'
Build "@hookform/resolvers/io-ts" to dist:
     1255 B: io-ts.js.gz
     1119 B: io-ts.js.br
     1104 B: io-ts.modern.mjs.gz
      987 B: io-ts.modern.mjs.br
     1146 B: io-ts.module.js.gz
     1028 B: io-ts.module.js.br
     1382 B: io-ts.umd.js.gz
     1237 B: io-ts.umd.js.br
Build "@hookform/resolvers/ajv" to dist:
      37 kB: ajv.js.gz
    32.6 kB: ajv.js.br
      37 kB: ajv.modern.mjs.gz
    32.6 kB: ajv.modern.mjs.br
      37 kB: ajv.module.js.gz
    32.6 kB: ajv.module.js.br
    37.1 kB: ajv.umd.js.gz
    32.7 kB: ajv.umd.js.br

><EMAIL_ADDRESS>postbuild /Users/joris/w/tmp/resolvers
> node ./config/node-13-exports.js

Checking export maps...
PASS  package.json
husky - Git hooks installed

Done in 43.6s
➜  resolvers git:(master) pnpm build

><EMAIL_ADDRESS>build /Users/joris/w/tmp/resolvers
> npm-run-all --parallel 'build:*'

><EMAIL_ADDRESS>build:src /Users/joris/w/tmp/resolvers
> microbundle build --globals react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:zod /Users/joris/w/tmp/resolvers
> microbundle --cwd zod --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:joi /Users/joris/w/tmp/resolvers
> microbundle --cwd joi --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:yup /Users/joris/w/tmp/resolvers
> microbundle --cwd yup --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:superstruct /Users/joris/w/tmp/resolvers
> microbundle --cwd superstruct --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:typanion /Users/joris/w/tmp/resolvers
> microbundle --cwd typanion --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:io-ts /Users/joris/w/tmp/resolvers
> microbundle --cwd io-ts --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:class-validator /Users/joris/w/tmp/resolvers
> microbundle --cwd class-validator --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:nope /Users/joris/w/tmp/resolvers
> microbundle --cwd nope --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:vest /Users/joris/w/tmp/resolvers
> microbundle --cwd vest --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:ajv /Users/joris/w/tmp/resolvers
> microbundle --cwd ajv --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:computed-types /Users/joris/w/tmp/resolvers
> microbundle --cwd computed-types --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

No name was provided for external module 'vest/promisify' in output.globals – guessing 'promisify'
Build "@hookform/resolvers/typanion" to dist:
      297 B: typanion.js.gz
      242 B: typanion.js.br
      283 B: typanion.modern.mjs.gz
      239 B: typanion.modern.mjs.br
      307 B: typanion.module.js.gz
      257 B: typanion.module.js.br
      389 B: typanion.umd.js.gz
      322 B: typanion.umd.js.br
Build "@hookform/resolvers/superstruct" to dist:
      276 B: superstruct.js.gz
      222 B: superstruct.js.br
      284 B: superstruct.modern.mjs.gz
      237 B: superstruct.modern.mjs.br
      289 B: superstruct.module.js.gz
      236 B: superstruct.module.js.br
      373 B: superstruct.umd.js.gz
      310 B: superstruct.umd.js.br
Build "@hookform/resolvers/vest" to dist:
      447 B: vest.js.gz
      383 B: vest.js.br
      350 B: vest.modern.mjs.gz
      309 B: vest.modern.mjs.br
      407 B: vest.module.js.gz
      358 B: vest.module.js.br
      533 B: vest.umd.js.gz
      463 B: vest.umd.js.br
Build "@hookform/resolvers" to dist:
      327 B: resolvers.js.gz
      289 B: resolvers.js.br
      322 B: resolvers.mjs.gz
      290 B: resolvers.mjs.br
      337 B: resolvers.module.js.gz
      299 B: resolvers.module.js.br
      425 B: resolvers.umd.js.gz
      369 B: resolvers.umd.js.br
Build "@hookform/resolvers/zod" to dist:
      544 B: zod.js.gz
      485 B: zod.js.br
      493 B: zod.modern.mjs.gz
      439 B: zod.modern.mjs.br
      561 B: zod.module.js.gz
      498 B: zod.module.js.br
      649 B: zod.umd.js.gz
      573 B: zod.umd.js.br
Build "@hookform/resolvers/joi" to dist:
      566 B: joi.js.gz
      508 B: joi.js.br
      463 B: joi.modern.mjs.gz
      409 B: joi.modern.mjs.br
      580 B: joi.module.js.gz
      513 B: joi.module.js.br
      668 B: joi.umd.js.gz
      589 B: joi.umd.js.br
Build "@hookform/resolvers/nope" to dist:
      318 B: nope.js.gz
      266 B: nope.js.br
      299 B: nope.modern.mjs.gz
      261 B: nope.modern.mjs.br
      333 B: nope.module.js.gz
      282 B: nope.module.js.br
      407 B: nope.umd.js.gz
      350 B: nope.umd.js.br
Build "@hookform/resolvers/class-validator" to dist:
      489 B: class-validator.js.gz
      412 B: class-validator.js.br
      447 B: class-validator.modern.mjs.gz
      388 B: class-validator.modern.mjs.br
      510 B: class-validator.module.js.gz
      436 B: class-validator.module.js.br
      590 B: class-validator.umd.js.gz
      509 B: class-validator.umd.js.br
Build "@hookform/resolvers/computed-types" to dist:
      329 B: computed-types.js.gz
      281 B: computed-types.js.br
      279 B: computed-types.modern.mjs.gz
      230 B: computed-types.modern.mjs.br
      341 B: computed-types.module.js.gz
      292 B: computed-types.module.js.br
      422 B: computed-types.umd.js.gz
      370 B: computed-types.umd.js.br
Build "@hookform/resolvers/yup" to dist:
      603 B: yup.js.gz
      512 B: yup.js.br
      540 B: yup.modern.mjs.gz
      459 B: yup.modern.mjs.br
      613 B: yup.module.js.gz
      523 B: yup.module.js.br
      703 B: yup.umd.js.gz
      606 B: yup.umd.js.br
No name was provided for external module 'fp-ts/Either' in output.globals – guessing 'Either'
No name was provided for external module 'fp-ts/function' in output.globals – guessing '_function'
No name was provided for external module 'fp-ts/ReadonlyArray' in output.globals – guessing 'ReadonlyArray'
No name was provided for external module 'fp-ts/Option' in output.globals – guessing 'Option'
No name was provided for external module 'fp-ts/Semigroup' in output.globals – guessing 'SemiGroup'
No name was provided for external module 'fp-ts/ReadonlyRecord' in output.globals – guessing 'ReadonlyRecord'
Build "@hookform/resolvers/io-ts" to dist:
     1255 B: io-ts.js.gz
     1119 B: io-ts.js.br
     1104 B: io-ts.modern.mjs.gz
      987 B: io-ts.modern.mjs.br
     1146 B: io-ts.module.js.gz
     1028 B: io-ts.module.js.br
     1382 B: io-ts.umd.js.gz
     1237 B: io-ts.umd.js.br
Build "@hookform/resolvers/ajv" to dist:
      37 kB: ajv.js.gz
    32.6 kB: ajv.js.br
      37 kB: ajv.modern.mjs.gz
    32.6 kB: ajv.modern.mjs.br
      37 kB: ajv.module.js.gz
    32.6 kB: ajv.module.js.br
    37.1 kB: ajv.umd.js.gz
    32.7 kB: ajv.umd.js.br

><EMAIL_ADDRESS>postbuild /Users/joris/w/tmp/resolvers
> node ./config/node-13-exports.js

➜  resolvers git:(master)

Not here. Tried to clone the repo directly now, to make sure it wasn't my (up-to-date) fork as well:
D:\projects\react-hook-form>npx rimraf resolvers

D:\projects\react-hook-form>git clone git@github.com:react-hook-form/resolvers.git
Cloning into 'resolvers'...
remote: Enumerating objects: 2289, done.
remote: Counting objects: 100% (146/146), done.
remote: Compressing objects: 100% (101/101), done.
remote: Total 2289 (delta 48), reused 105 (delta 31), pack-reused 2143
Receiving objects: 100% (2289/2289), 1.74 MiB | 3.63 MiB/s, done.
Resolving deltas: 100% (1251/1251), done.

D:\projects\react-hook-form>cd resolvers

D:\projects\react-hook-form\resolvers>pnpm i
Lockfile is up to date, resolution step is skipped
Packages: +816
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Packages are hard linked from the content-addressable store to the virtual store.
  Content-addressable store is at: D:\.pnpm-store\v3
  Virtual store is at:             node_modules/.pnpm
Progress: resolved 816, reused 816, downloaded 0, added 816, done

devDependencies:
+ @testing-library/dom 9.0.1
+ @testing-library/jest-dom 5.16.5
+ @testing-library/react 14.0.0
+ @testing-library/user-event 14.4.3
+ @types/node 18.15.3
+ @types/react 18.0.28
+ @types/testing-library__jest-dom 5.14.5
+ @typescript-eslint/eslint-plugin 5.55.0
+ @typescript-eslint/parser 5.55.0
+ @vitejs/plugin-react 3.1.0
+ ajv 8.12.0
+ ajv-errors 3.0.0
+ check-export-map 1.3.0
+ class-transformer 0.5.1
+ class-validator 0.14.0
+ computed-types 1.11.2
+ eslint 8.36.0
+ eslint-config-prettier 8.7.0
+ fp-ts 2.13.1
+ husky 8.0.3
+ io-ts 2.2.20
+ io-ts-types 0.5.19
+ joi 17.8.4
+ jsdom 21.1.1
+ lint-staged 13.2.0
+ microbundle 0.15.1
+ monocle-ts 2.3.13
+ newtype-ts 0.3.5
+ nope-validator 1.0.4
+ npm-run-all 4.1.5
+ prettier 2.8.4
+ react 18.2.0
+ react-dom 18.2.0
+ react-hook-form 7.43.6
+ reflect-metadata 0.1.13
+ superstruct 1.0.3
+ typanion 3.12.1
+ typescript 5.0.2
+ vest 4.6.9
+ vite 4.2.0
+ vite-tsconfig-paths 4.0.7
+ vitest 0.29.3
+ yup 0.32.11
+ zod 3.21.4

><EMAIL_ADDRESS>prepare D:\projects\react-hook-form\resolvers
> run-s build:src build && check-export-map && husky install

><EMAIL_ADDRESS>build:src D:\projects\react-hook-form\resolvers
> microbundle build --globals react-hook-form=ReactHookForm

Build "@hookform/resolvers" to dist:
        327 B: resolvers.js.gz
        289 B: resolvers.js.br
        322 B: resolvers.mjs.gz
        290 B: resolvers.mjs.br
        337 B: resolvers.module.js.gz
        299 B: resolvers.module.js.br
        425 B: resolvers.umd.js.gz
        369 B: resolvers.umd.js.br

><EMAIL_ADDRESS>build D:\projects\react-hook-form\resolvers
> npm-run-all --parallel 'build:*'

ERROR: Task not found: "'build:*'"
 ELIFECYCLE  Command failed with exit code 1.
ERROR: "build" exited with 1.

 ELIFECYCLE  Command failed with exit code 1.

D:\projects\react-hook-form\resolvers>pnpm build

><EMAIL_ADDRESS>build D:\projects\react-hook-form\resolvers
> npm-run-all --parallel 'build:*'

ERROR: Task not found: "'build:*'"
 ELIFECYCLE  Command failed with exit code 1.

Could you try adding locally cross-env

pnpm add -D cross-env
In package.json: "build": "cross-env npm-run-all --parallel 'build:*'"
pnpm build

That seems to have helped actually!
D:\projects\react-hook-form\resolvers>pnpm add -D cross-env
 WARN  deprecated<EMAIL_ADDRESS>This package has been deprecated and is no longer maintained. Please use @rollup/plugin-terser
 WARN  deprecated<EMAIL_ADDRESS>Please use @jridgewell/sourcemap-codec instead
 WARN  deprecated<EMAIL_ADDRESS>Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility
Packages: +1
+
Progress: resolved 839, reused 816, downloaded 1, added 1, done

devDependencies:
+ cross-env 7.0.3

Done in 3.9s

D:\projects\react-hook-form\resolvers>code .

D:\projects\react-hook-form\resolvers>pnpm build

><EMAIL_ADDRESS>build D:\projects\react-hook-form\resolvers
> cross-env npm-run-all --parallel 'build:*'

><EMAIL_ADDRESS>build:src D:\projects\react-hook-form\resolvers
> microbundle build --globals react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:zod D:\projects\react-hook-form\resolvers
> microbundle --cwd zod --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:yup D:\projects\react-hook-form\resolvers
> microbundle --cwd yReactHookForm

kform/resolvers=hookformResolvers,react-hook-form=
><EMAIL_ADDRESS>build:joi D:\projects\react-hook-form\resolvers
> microbundle --cwd joi --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:superstruct D:\projects\react-hook-form\resolvers
> microbundle --cwd superstruct --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:vest D:\projects\react-hook-form\resolvers
> microbundle --cwd vest --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:class-validator D:\projects\react-hook-form\resolvers
> microbundle --cwd class-validator --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:io-ts D:\projects\react-hook-form\resolvers
> microbundle --cwd io-ts --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:computed-types D:\projects\react-hook-form\resolvers
> microbundle --cwd computed-types --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:nope D:\projects\react-hook-form\resolvers
> microbundle --cwd nope --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:typanion D:\projects\react-hook-form\resolvers
> microbundle --cwd typanion --globals @hookform/resolvers=hookformResolvers,react-hook-form=ReactHookForm

><EMAIL_ADDRESS>build:ajv D:\projects\react-hook-form\resolvers
> microbundle --cwd aReactHookForm

Build "@hookform/resolvers" to dist:act-hook-form=
        327 B: resolvers.js.gz
        289 B: resolvers.js.br
        322 B: resolvers.mjs.gz
        290 B: resolvers.mjs.br
        337 B: resolvers.module.js.gz
        299 B: resolvers.module.js.br
        425 B: resolvers.umd.js.gz
        369 B: resolvers.umd.js.br
Build "@hookform/resolvers/zod" to dist:
        544 B: zod.js.gz
        485 B: zod.js.br
        493 B: zod.modern.mjs.gz
        439 B: zod.modern.mjs.br
        561 B: zod.module.js.gz
        498 B: zod.module.js.br
        649 B: zod.umd.js.gz
        573 B: zod.umd.js.br
Build "@hookform/resolvers/superstruct" to dist:
        276 B: superstruct.js.gz
        222 B: superstruct.js.br
        284 B: superstruct.modern.mjs.gz
        237 B: superstruct.modern.mjs.br
        289 B: superstruct.module.js.gz
        236 B: superstruct.module.js.br
        373 B: superstruct.umd.js.gz
        310 B: superstruct.umd.js.br
Build "@hookform/resolvers/yup" to dist:
        603 B: yup.js.gz
        512 B: yup.js.br
        540 B: yup.modern.mjs.gz
        459 B: yup.modern.mjs.br
        613 B: yup.module.js.gz
        523 B: yup.module.js.br
        703 B: yup.umd.js.gz
        606 B: yup.umd.js.br
No name was provided for external module 'vest/promisify' in output.globals – guessing 'promisify'
Build "@hookform/resolvers/joi" to dist:
        566 B: joi.js.gz
        508 B: joi.js.br
        463 B: joi.modern.mjs.gz
        409 B: joi.modern.mjs.br
        580 B: joi.module.js.gz
        513 B: joi.module.js.br
        668 B: joi.umd.js.gz
        589 B: joi.umd.js.br
Build "@hookform/resolvers/vest" to dist:
        447 B: vest.js.gz
        383 B: vest.js.br
        350 B: vest.modern.mjs.gz
        309 B: vest.modern.mjs.br
        407 B: vest.module.js.gz
        358 B: vest.module.js.br
        533 B: vest.umd.js.gz
        463 B: vest.umd.js.br
Build "@hookform/resolvers/class-validator" to dist:
        489 B: class-validator.js.gz
        412 B: class-validator.js.br
        447 B: class-validator.modern.mjs.gz
        388 B: class-validator.modern.mjs.br
        510 B: class-validator.module.js.gz
        436 B: class-validator.module.js.br
        590 B: class-validator.umd.js.gz
        509 B: class-validator.umd.js.br
Build "@hookform/resolvers/computed-types" to dist:
        329 B: computed-types.js.gz
        281 B: computed-types.js.br
        279 B: computed-types.modern.mjs.gz
        230 B: computed-types.modern.mjs.br
        341 B: computed-types.module.js.gz
        292 B: computed-types.module.js.br
        422 B: computed-types.umd.js.gz
        370 B: computed-types.umd.js.br
Build "@hookform/resolvers/nope" to dist:
        318 B: nope.js.gz
        266 B: nope.js.br
        299 B: nope.modern.mjs.gz
        261 B: nope.modern.mjs.br
        333 B: nope.module.js.gz
        282 B: nope.module.js.br
        407 B: nope.umd.js.gz
        350 B: nope.umd.js.br
Build "@hookform/resolvers/typanion" to dist:
        297 B: typanion.js.gz
        242 B: typanion.js.br
        283 B: typanion.modern.mjs.gz
        239 B: typanion.modern.mjs.br
        307 B: typanion.module.js.gz
        257 B: typanion.module.js.br
        389 B: typanion.umd.js.gz
        322 B: typanion.umd.js.br
No name was provided for external module 'fp-ts/Either' in output.globals – guessing 'Either'
No name was provided for external module 'fp-ts/function' in output.globals – guessing '_function'
No name was provided for external module 'fp-ts/ReadonlyArray' in output.globals – guessing 'ReadonlyArray'
No name was provided for external module 'fp-ts/Option' in output.globals – guessing 'Option'
No name was provided for external module 'fp-ts/Semigroup' in output.globals – guessing 'SemiGroup'
No name was provided for external module 'fp-ts/ReadonlyRecord' in output.globals – guessing 'ReadonlyRecord'
Build "@hookform/resolvers/io-ts" to dist:
       1255 B: io-ts.js.gz
       1119 B: io-ts.js.br
       1104 B: io-ts.modern.mjs.gz
        987 B: io-ts.modern.mjs.br
       1146 B: io-ts.module.js.gz
       1028 B: io-ts.module.js.br
       1382 B: io-ts.umd.js.gz
       1237 B: io-ts.umd.js.br
Build "@hookform/resolvers/ajv" to dist:
        37 kB: ajv.js.gz
      32.6 kB: ajv.js.br
        37 kB: ajv.modern.mjs.gz
      32.6 kB: ajv.modern.mjs.br
        37 kB: ajv.module.js.gz
      32.6 kB: ajv.module.js.br
      37.1 kB: ajv.umd.js.gz
      32.7 kB: ajv.umd.js.br

><EMAIL_ADDRESS>postbuild D:\projects\react-hook-form\resolvers
> node ./config/node-13-exports.js

(sorry, no idea how you did that fancy flippy log output thing 😅)

👌🏻 Just opened a PR https://github.com/react-hook-form/resolvers/pull/525
Feel free to comment, contribute :)


promise bug: cannot handle thenable job

var p = Promise.resolve(1).then(function(x) {
    print(x) // will print 1
    return Promise.resolve(2)
  }).then(function(x) {
    print(x) // should print 2, but now this will not be executed
  })

I will fix soon.

Fixed by #2061

I download the latest jerryscript code. Execute correctly. Next, wait for iotjs to change.


[TEST] Test version bumper

For reference
https://github.com/google/brax/pull/12
https://python-poetry.org/docs/


Export Saved modelfiles

how can we export saved model files?
I want to summarize the model files and streamline the current chat context

ollama show --modelfile <savename>

that hasn't been working most likely due to #7600


Extend behavior to stimulus layout 5

Extending to other type of behavioral layout.
Work in progress.

Superseded by #14


Default value

Hi! Love this plugin.
I have a question: how to set default value (start_time) using html, not js. Now it works like this:
$(".js-timepicker").timepicki({
    start_time: ["20", "00"]
});

but it is not convenient. Why not just take default value from value attribute?
<input type="text" value="20:00" class="js-timepicker">

Moreover, divider is now " : ", but I want to use ":", without spaces, but there is no option to change this.
Thanks in advance.

Hello, I'm not senthilraj and some months lasted since you posted the answer, but I also wanted to use custom divider and I found a solution.
Option is format_output and it accepts a function like that:
function(tim, mini, meri) {
				if(settings.show_meridian){
					return tim + " : " + mini + " : " + meri;
				}else{
					return tim + " : " + mini;
				}
			}

This is default one, you can find it at top of plugin source js. However, in that contest we don't have settings variable, so if you don't need the spaces and want 24h format, like me, you can modify it in this way:
function(tim, mini, meri) {
                return tim + ":" + mini;
        }

Hope it helps you or any lurker!

Hi, and thanks for a great plugin!
I had the exact same problem and made a hack for a format-string (syntax like strftime)
https://github.com/chroz/TimePick
i - i.e. the current default would be %H : %M : %p,
while i override this in my pickers with "%H:%M"
It's way too hackish to be worthy of a pull request, but I think something like this could be the way to go, maybe making the show_meridian option implicit in the future?

Thank you for your replies, guys, but these hacks do not resolve the issue. I need to set default value from backend. Using your solution, I have to generate JS code right in the HTML, or load it via AJAX. It is nightmare. I have already moved to https://eonasdan.github.io/bootstrap-datetimepicker/, which solves this problem, but unfortunately it needs bootstrap.

I made this it works fine...
function getTimepickiTime(obj) {     var TimeValue = obj.val();     var trimmedTimeValue = TimeValue.replace(/ /g,'');     var resultSplit = trimmedTimeValue.split(':');     return resultSplit; };    $('.timepicker_start').timepicki({          start_time: getTimepickiTime($('.timepicker_start'))      });
This will take the value of the input and use it as default

I know this thread is kind of old, but you can set the default value through HTML by specifying the following attributes on your input tag:
data-timepicki-tim
data-timepicki-mini
data-timepicki-meri
For hours, minutes, and meridian, respectively.
Works just fine without any code changes.

i want to pop up an alert when i change time when value is changed in the textbox i want an alert pop up.how can i accomplish this?

@Istiak1992
You can use this method
$("#timepicker1").on('click',function(){
alert("Hi")
})

I have fixed it by changing code in line 407 of timepicki.js to this:
                                   `var value = ele[0].value.replace(/ /g, '');
				if (value.length === 0) {
					d = new Date();
					ti = d.getHours();
					mi = d.getMinutes();
				}
				else {
					ti = parseInt(value.substr(0, 2));
					mi = parseInt(value.substr(3, 2));
                                   }`


Remove yq install from build-extension-x workflows

Summary
Contributes to #10663
Occurred changes and/or fixed issues

yq should come as default

https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md

Tested via repo containing pkgs pointing at workflows from this PR's branch

https://github.com/richard-cox/extension-testing/actions/runs/9060291972
https://github.com/richard-cox/extension-testing/actions/runs/9060291974/job/24889695939

The output i think is all in https://github.com/richard-cox/extension-testing/tree/gh-pages

I've tested https://richard-cox.github.io/extension-testing can be added as a repo and the extension installed
This requires a thorough confirmation still though

Checklist

[x] The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
[x] The PR has a Milestone
[x] The PR template has been filled out
[x] The PR has been self reviewed
[x] The PR has a reviewer assigned
[x] The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
[x] The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

We do use yq in the sync-charts and bundle-catalog scripts of ui-plugin-charts, but they are not related to these workflows. The installation of yq can be removed from that workflow as well.


Install android misses build.gradle changes

readme improvement by adding:
app build.gradle needs the following line added in dependancies.
compile project(':react-native-fetch-blob')

@pietgk , Thanks for your suggestion ! I'll add this line right away 👍

please correct readme its not android/build.gradle
but android/app/build.gradle


Generic Types Should Be Able to Be Depended and Injected by Implementation Factory repo:DependencyInjection

https://github.com/aspnet/DependencyInjection/blob/4708d11dfe2a3df540578f026fc14d11a4f9ef48/src/DI/ServiceLookup/CallSiteFactory.cs#L36
Also refer to: https://github.com/aspnet/DependencyInjection/issues/634
Where:
if (implementationTypeInfo == null || !implementationTypeInfo.IsGenericTypeDefinition)
{
    throw new ArgumentException(
    Resources.FormatOpenGenericServiceRequiresOpenGenericImplementation(descriptor.ServiceType),
                            nameof(descriptors));
}

if (implementationTypeInfo.IsAbstract || implementationTypeInfo.IsInterface)
{
    throw new ArgumentException(Resources.FormatTypeCannotBeActivated(descriptor.ImplementationType, descriptor.ServiceType));
}

When there's generic type dependency with no concrete generic type injection but instance factory it'll throw the exception. Should be changed to like:
if ((implementationTypeInfo == null || !implementationTypeInfo.IsGenericTypeDefinition) **&& descriptor.ImplementationFactoryWithType == null**)
{
    throw new ArgumentException(
    Resources.FormatOpenGenericServiceRequiresOpenGenericImplementation(descriptor.ServiceType),
                            nameof(descriptors));
}
**else** if (implementationTypeInfo.IsAbstract || implementationTypeInfo.IsInterface)
{
throw new ArgumentException(
                            Resources.FormatTypeCannotBeActivated(descriptor.ImplementationType, descriptor.ServiceType));
}

In the case of using factory declaration of dependency as will be throwing exception "An unhandled exception of type 'System.ArgumentException' occurred in Microsoft.Extensions.DependencyInjection.dll: 'Open generic service type '[name of the type]' requires registering an open generic implementation type.'" in building web host which should be right in where new service descriptor is being added:
public class Startup
{
... ...
    public void ConfigureServices(IServiceCollection services)
    {
        ... ...
        services.Add[lifecycle type](myGenericType, provider => myFactory.GetInstance(myGenericType));
        ... ...
    }
}

And a new method should be provided as:
services.Add[lifecycle type](myGenericType, (provider, requiringType) => myFactory.GetInstance(requiringType));

And FactoryCallSite should be extended or new type of IServiceCallSite for factory with requiring type provided in invoking should be implemented.

I think you're asking for https://github.com/aspnet/DependencyInjection/issues/498? There's also https://github.com/aspnet/DependencyInjection/issues/450 and https://github.com/aspnet/DependencyInjection/issues/474.

Yes, I am. Seems it's a long unsolved problem.
I read the code and think there's fundamentally reconstruction required in storing dependency and invoking implementation injected. Of cause the generic implementation is not required in service descriptor building and passed on when getting the injection. Also in container cache the factory/inject implementation is stored as without parameter of invoking type required.
For a functionality purpose generic type injection may require more in D/I relationships. Such as specific concrete types may required some other injections as user wishes. User may want to do:
service.Add[Life Cycle](typeof(MyGeneric<>), implementation1);
service.Add[Life Cycle](typeof(MyGeneric<SomeType>), implementation2);

I haven't checked the current implementation of generic type D/I with open generic type injected's implementation. So I don't know if this is implemented or designed as another way.
I'd love to do it by my own self but realizing that there's only 2G less in my drive and the DI repo is on unpublished Core 2.1 which means I need to download the whole newest core repo to build it.

User may want to do:
service.Add[Life Cycle](typeof(MyGeneric<>), implementation1);
service.Add[Life Cycle](typeof(MyGeneric<SomeType>), implementation2);

This should already be possible?
Anyway, the reason this is a "long unsolved problem" is that in order for service descriptors include a factory delegate that requires more contextual information, like requiringType in your example above, all ASP.NET Core DI adapters have to be able to provide the same information. It's also a big breaking change.
All of this has been discussed back and forth many many times. I suggest you read through the issues in the DependencyInjection repository.
Oh, BTW, found another issue asking for the same thing; https://github.com/aspnet/DependencyInjection/issues/588 😉

Yes, it is possible. Technically, what needed is to change the hash algorithm of dependencies container cache. But it's more a production decision than tech. There's more works to do to define the behaviour details of contracts. Such as which define go first or which get covered.
Such an example:
···
service.Add[](typeof(MyGeneric<,>), implementation1);
service.Add[](typeof(MyGeneric<MyType1,>), implementation1);
···
Things may go crazy as a product to define clear rules of which go first or last.
Yeah, as you say. The first thing is to get a generic type factory being valid. Above are too early.

We'd recommend using one of the 3rd party containers that supports this feature. Currently it's not part of abstraction and work would have to be done to get all implementations implement this.


fix: extract text concatenation

Currently the extractText function ignores line breaks and adds spaces between every chunk which results in broken results.
This PR is going to fix this.

Nice catch. Thanks!


curl: ldap and libidn support as curlFull

This fixes some of #7248.
Before:
% nix-env -f $HOME/packages/nixpkgs -iA curl
replacing old ‘curl-7.41.0’
installing ‘curl-7.41.0’

% curl -u : --negotiate -I https://example.com
curl: option --negotiate: the installed libcurl version doesn't support this
curl: try 'curl --help' for more information

After:
% nix-env -f $HOME/packages/nixpkgs -iA curlFull
replacing old ‘curl-7.41.0’
installing ‘curl-7.41.0’

% curl -u : --negotiate -I https://example.com
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=604800
Content-Type: text/html
Date: Sat, 25 Apr 2015 19:09:20 GMT
Etag: "359670651"
Expires: Sat, 02 May 2015 19:09:20 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (rhv/8199)
X-Cache: HIT
x-ec-custom-error: 1
Content-Length: 1270

Comments or suggestions are welcome.

Please submit PR against staging branch, because that invokes mass-rebuild.

Closed in favor of #7577


Update Omitted Type to use Hashable Values as Keys for Caching

Closes #6957.
Changes Omitted arguments to use a different key for hashable and non-hashable types. For hashable types, this enables loading cache from disk even if id no longer matches.

@njriasan thank you very much for submitting this. I have queued it for a review by one of the devs.

@sklam Thanks for the feedback! I restructured the code based on your suggestions.

@sklam Can we try get this included in 0.55? I think this is close to being ready.


[SPARK-43005][PYSPARK] Fix typo in pyspark/pandas/config.py

By comparing compute.isin_limit and plotting.max_rows, v is v is likely to be a typo.

What changes were proposed in this pull request?

fix v is v >= 0 with v >= 0.
Why are the changes needed?

By comparing compute.isin_limit and plotting.max_rows, v is v is likely to be a typo.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

By GitHub Actions.

Indeed a bug. It happens to work for values that aren't 0, I think

Merged to master/3.4/3.3/3.2


fix compile failed while setting --disable-cpu-profiler

fix a compile error while setting --disable-cpu-profiler
introduced in f4aa2a435eed63fc047448635f705a9c6037bd97

libtool: compile:  g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -I../gperftools -I./src -I../gperftools/src -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -Wno-unused-result -fno-omit-frame-pointer -g -O2 -MT src/stacktrace.lo -MD -MP -MF src/.deps/stacktrace.Tpo -c ../gperftools/src/stacktrace.cc  -fPIC -DPIC -o src/.libs/stacktrace.o
In file included from ../gperftools/src/stacktrace_impl_setup-inl.h:70:0,
from ../gperftools/src/stacktrace.cc:128:
../gperftools/src/stacktrace_generic_fp-inl.h: In function 'int GetStackTraceWithContext_generic_fp(void**, int, int, const void*)':
../gperftools/src/stacktrace_generic_fp-inl.h:202:33: error: ISO C++ forbids declaration of 'type name' with no type [-fpermissive]
auto uc = static_cast<const ucontext_t*>(ucp);
^
../gperftools/src/stacktrace_generic_fp-inl.h:202:33: error: expected '>' before 'ucontext_t'
../gperftools/src/stacktrace_generic_fp-inl.h:202:33: error: expected '(' before 'ucontext_t'
../gperftools/src/stacktrace_generic_fp-inl.h:202:33: error: 'ucontext_t' was not declared in this scope
../gperftools/src/stacktrace_generic_fp-inl.h:202:44: error: expected primary-expression before '>' token
auto uc = static_cast<const ucontext_t*>(ucp);
^
../gperftools/src/stacktrace_generic_fp-inl.h:202:50: error: expected ')' before ';' token
auto uc = static_cast<const ucontext_t*>(ucp);
^

I am sorry, I have somehow missed your patch. This work doesn't apply anymore. This code is reworked and I've tested it works with disabled cpu profiler


[WIP] Geoserver setup

Add Geoserver workspace creation
Add Geoserver datastore creation
Add shapefile publishing

Specifics points to look at:

The tests are failing right now at the Install dependencies (prior to this PR), looks like it's hanging on docformatter-0.5.6.tar.gz . I haven't investigated yet, in case it's a known problem.

Right now, tests will fail on Github because there is no Geoserver setup for testing. My question is, do we want Github actions to run Geoserver like it does with Mongodb? Geoserver is a somewhat big image (close to 1GB) and I'm not sure if it would be worth it to test at this level vs Birdhouse level.

I implemented shapefile publishing using the structures and mechanisms of the Catalog service, as it seemed the most efficient way of doing it, but I'm open to other implementations if you have ideas/objections.

I have not created tests for shapefile publishing yet as they are a bit more involved (need to have a valid shapefile for the test) and there's no real substitute to a visual inspection to make sure the data is well configured and displays well as a WFS. I could relatively quickly test if the requests runs well and returns the right code but the value of that test is limited.

Again for the shapefile publishing, I'm anticipating a "user-side" problem. Since shapefile is a multi file format, if all parts are not copied/moved to the user's shapefile_datastore folder, there there could be some problems (especially if the .proj file is added later). A simple way would be to make the job wait for a few seconds after it registers a .shp file. The other, more involved, would be to check for the required extensions and only start the publishing process after all the required extensions are present.

The tests are failing right now at the Install dependencies (prior to this PR), looks like it's hanging on docformatter-0.5.6.tar.gz . I haven't investigated yet, in case it's a known problem.

I will let @fmigneault gives its input on this problem.

Right now, tests will fail on Github because there is no Geoserver setup for testing. My question is, do we want Github actions to run Geoserver like it does with Mongodb? Geoserver is a somewhat big image (close to 1GB) and I'm not sure if it would be worth it to test at this level vs Birdhouse level.

I don't think that we want to go there. I really appreciate the tests you added, and they could be helpful while working specifically on geoserver on the dev side, but if we could disable them for the CI it would be perfect. I guess that these kind of tests would be better on a notebook for a full stack test.

I implemented shapefile publishing using the structures and mechanisms of the Catalog service, as it seemed the most efficient way of doing it, but I'm open to other implementations if you have ideas/objections.

I added specific comments on that topic. The current monitoring implementation is, I agree, not efficient, but the internal implementation could monitor paths once and notify multiple observers. In my opinion, that would be a better optimisation than piggybacking the Catalog implementation with Geoserver stuff.

I have not created tests for shapefile publishing yet as they are a bit more involved (need to have a valid shapefile for the test) and there's no real substitute to a visual inspection to make sure the data is well configured and displays well as a WFS. I could relatively quickly test if the requests runs well and returns the right code but the value of that test is limited.

Given the previous answer for tests, I'm ok to wait until we have notebooks to refine the tests.

Again for the shapefile publishing, I'm anticipating a "user-side" problem. Since shapefile is a multi file format, if all parts are not copied/moved to the user's shapefile_datastore folder, there there could be some problems (especially if the .proj file is added later). A simple way would be to make the job wait for a few seconds after it registers a .shp file. The other, more involved, would be to check for the required extensions and only start the publishing process after all the required extensions are present.

Could we first check the integrity of a shapefile and stop the job if the shapefile is not complete. Any new/modified file should trigger a new event. At some point an event should yield a valid shapefile that can be published?

@f-PLT @dbyrns

The tests are failing right now at the Install dependencies (prior to this PR), looks like it's hanging on docformatter-0.5.6.tar.gz . I haven't investigated yet, in case it's a known problem.

I will let @fmigneault gives its input on this problem.

I will need an output log or something to analyze the issue.
Package docformatter has not had any new version since Dec 2020, so I doubt it is (directly) the cause.

@f-PLT @dbyrns

Right now, tests will fail on Github because there is no Geoserver setup for testing. My question is, do we want Github actions to run Geoserver like it does with Mongodb? Geoserver is a somewhat big image (close to 1GB) and I'm not sure if it would be worth it to test at this level vs Birdhouse level.

I suggest using package responses to mock sending requests to a "Geoserver" endpoint to validate basic operations.
You only need to register the expected URLs and the response contents to return instead.
Example below where I mock a WPS-1 server to send GetCapabilities and DescribeProcess requests:
https://github.com/crim-ca/weaver/blob/master/tests/utils.py#L436-L515
For bigger tests, that are closer to the resulting stack with interactions between Magpie/Cowbird/Geoserver, I would use notebooks as suggested by @dbyrns.

@dbyrns
I agree with pretty much everything in your comments and will start working on them later today.

I don't think that we want to go there. I really appreciate the tests you added, and they could be helpful while working specifically on geoserver on the dev side, but if we could disable them for the CI it would be perfect. I guess that these kind of tests would be better on a notebook for a full stack test.

That was my feeling. I'll created a new target in the Makefile to run all tests but Geoserver's, and make the CI use this new target. Or maybe more appropriate to bypass Geoserver requests tests the default test target?

I added specific comments on that topic. The current monitoring implementation is, I agree, not efficient, but the internal implementation could monitor paths once and notify multiple observers. In my opinion, that would be a better optimisation than piggybacking the Catalog implementation with Geoserver stuff.

I wasn't sure how to do that but now that you pointed it out, it really seems the obvious thing to do. I was focused making it work first. I'm pretty sure it will make some of the other corrections easier to implement.

@f-PLT @dbyrns

The tests are failing right now at the Install dependencies (prior to this PR), looks like it's hanging on docformatter-0.5.6.tar.gz . I haven't investigated yet, in case it's a known problem.

I will let @fmigneault gives its input on this problem.

I will need an output log or something to analyze the issue.
Package docformatter has not had any new version since Dec 2020, so I doubt it is (directly) the cause.

The output from the cancelled job, after 6 hours running (https://github.com/Ouranosinc/cowbird/runs/3509241127?check_suite_focus=true) :

INFO: pip is looking at multiple versions of docformatter to determine which version is compatible with other requirements. This could take a while.
Collecting docformatter
Downloading docformatter-1.3.1.tar.gz (16 kB)
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ReadTimeoutError("HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Read timed out. (read timeout=15)")': /packages/35/52/41c0152a44873c8f11f0f9fe21b680588ae0e2b20e4a0a9b4812f8decbdc/docformatter-1.3.tar.gz
Downloading docformatter-1.3.tar.gz (16 kB)
...
INFO: pip is looking at multiple versions of docformatter to determine which version is compatible with other requirements. This could take a while.
...
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ReadTimeoutError("HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Read timed out. (read timeout=15)")': /packages/d9/0d/c642dd005280fcf4ae1927e47bc838bab3aefdb6e3a4555105748535e584/docformatter-0.5.6.tar.gz
Downloading docformatter-0.5.6.tar.gz (12 kB)

Since I didn't add new dependencies, I'm guessing it's because one of our unlocked dependencies changed and it broke something?
From the github actions page, it seems to have happened quite a few times, with the first recent occurrence being this one : https://github.com/Ouranosinc/cowbird/actions/runs/1137547725

@f-PLT
I tried full uninstall of docformatter on my side, followed by make check-docf.
Package docformatter==1.4 got installed and ran without problem.
I have pip 21.2.4 installed, which is the latest one available: https://pypi.org/project/pip/
I'm not able to reproduce the error you are seeing. Maybe setting docformatter>=1.4 will help resolve it?

@fmigneault
I found the problem!
I was able to reproduce the issue with a new conda environment.
It's actually  astroid. Even with the the !=2.7, it still found a way to install this version : astroid-2.7.3-py3-none-any.whl
changing it to astroid>=2.6,!=2.7.*,<3  fixed it locally, will be pushing the change to see if it works server side

Hmm, the change did not seem to take, as I can see the same weird version for astroid in the github actions report. I'll see if it sorts itself with futur commits. If not, I'll try to fix it to <2.7

@f-PLT
I strongly believe it is the new pip resolver that causes issue. I'm facing similar problem as of the last 1-2 days on ReadTheDocs failing because of long resolver memory/times use.
By adding stricter dependencies, sometimes the set of possible versions gets resolved more easily so that it moves on to the next dependency quicker. Probably just happens to be astroid in this case.
Normally, it should resolve the version fast though, because astroid is strongly coupled with pylint, which is set as pylint>=2.7,<2.8 in this case. Maybe the pinned version of astroid mismatches pylint, so it force install 2.7 ?

@f-PLT
Looks to me like things are working as expected with last test run.
Error is related to one of my comment about the 'hardcoded password' in the tests:
https://github.com/Ouranosinc/cowbird/runs/3549388289
Just need to apply  # nosec: B105 next to it.

@f-PLT
Might be of interest: e27ca78 (#465)

Might be of interest: e27ca78 (#465)

Indeed, as it still looks like a problem. I'll look to implement it early next week.

Codecov Report

Merging #17 (db68146) into master (5e3936e) will decrease coverage by 2.00%.
The diff coverage is 65.59%.

@@            Coverage Diff             @@
##           master      #17      +/-   ##
==========================================
- Coverage   75.32%   73.32%   -2.01%
==========================================
  Files          35       40       +5
  Lines        1755     2339     +584
  Branches      261      336      +75
==========================================
+ Hits         1322     1715     +393
- Misses        354      501     +147
- Partials       79      123      +44

Impacted Files
Coverage Δ

cowbird/services/impl/filesystem.py
0.00% <0.00%> (ø)

cowbird/api/home/views.py
57.14% <18.75%> (-32.34%)
:arrow_down:

cowbird/cli/services.py
47.61% <50.00%> (ø)

cowbird/api/webhooks/views.py
77.94% <55.17%> (-13.37%)
:arrow_down:

cowbird/database/__init__.py
57.69% <57.69%> (ø)

cowbird/services/impl/geoserver.py
58.38% <58.16%> (-10.37%)
:arrow_down:

cowbird/database/base.py
60.71% <60.71%> (ø)

cowbird/app.py
77.77% <66.66%> (-7.94%)
:arrow_down:

cowbird/monitoring/fsmonitor.py
63.63% <66.66%> (+1.13%)
:arrow_up:

cowbird/services/impl/catalog.py
69.69% <66.66%> (+69.69%)
:arrow_up:

... and 24 more

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 24c9a50...db68146. Read the comment docs.

There's the Codacy failure I'm not sure how to handle, as we get a warning about storing passwords when in our case it's a key name for kwargs.

There's the Codacy failure I'm not sure how to handle, as we get a warning about storing passwords when in our case it's a key name for kwargs.

@f-PLT
Issue is now ignored.

Same issue as before concerning Codacy, since the variables were moved.

Same issue as before concerning Codacy, since the variables were moved.

I updated the Codacy config. It should not trigger anymore.
A separate sub-tool was flagging security issues, while the bandit tool was ignoring them correctly as per nosec.