@joaquimrocha I'm only on mobile atm sorry, but if it helps it was when looking at HPAs


Sorry for the late reply. So I am thinking of something a "competitor" of yours if offering on Pod level

image

This would really help tracking down resource issues. As of now, I always have to use something like for example k9s to get the current metrics of the pod. Maybe this calrifies a bit where I was originally coming from.

Best regards


Looking back over this, once we have #12681 in people's hands to try it out, I feel like most of the "hard" decisions will be resolved with and that we'll be ready to get post a RFC for approval. Concurrent to that, we can still work on finishing up the last of the tasks as I don't expect them to uncover new information.


Thanks for the pointer @weiglszonja. I still would like to see more confusions that arise from this use. This is the only case that we have for Paul's second point.


Hi @abdoofathy95,

Thanks for reaching out and raising this issue.

We'll take a look at this and keep you updated as we investigate.

In the meantime, could you provide the following additional information if possible?
- Driver logs, which can be enabled as seen here.
- A bit of sample code, to get a better idea of how you're using the driver.

Thank you for your patience!


To give my two cents, regarding the direct three backticks proposal, personally I like it way more than the doc comment plus three backticks proposal. I could live with the naked three backticks. Most importantly it's shorter and doesn't piggy back on the existing concept that exists for documentation.

My preferred solution would still be sth like `/*% */` or `/*~ */` that would otherwise work the same to the three backticks (special first line that has the optional filename which is also just a reserved feature for now). It doesn't have to compile down to attributes (although they don't seem like a bad option), it could also compile down to `builtin # toml ("toml here")` or something like that: I and I think most users would be more interested in the end result. Whether it's temporarily an attribute or something different seems like an implementation detail to me, even if that is mentioned in the reference.

Existing highlighters will highlight `/*% */` or such as *something* and not be disturbed by the construct itself or the sudden toml. It would also be supported by the compiler. But to repeat, backticks are definitely major progress to me. They are character count wise even cheaper than `/*% */`. Latter would fit better into existing rust programs however.


This work has been completed and is in GB 16.7 which will be used in the 6.4 beta release


There is one more question
Can I see the response size in kilobytes?


Partial. I tried it on another Docker host, no problems here. Where the problems occur, I was able to remedy the situation by setting the network mode to host. In bridge mode it can not download the jdownloader.jar. I don't understand why. Other containers on the same host can access the internet in bridge mode without problems.
I have completely removed the container and rebuilt it, always without success. only the network host mode works.


Hey @workmichsem,

regarding the maximum number of connections: since I'm using `Sytem.Net.Http.HttpClient` under the hood, this is probably the default value for `System.Net.Http.HttpClientHandler.MaxConnectionsPerServer`, which defaults to `int.MaxValue`: URL

This might change due to #107, but I haven't had the time to work on that yet.

The maximum waiting time, or rather the `HttpClient` timeout, defaults to 100 seconds, but can be changed: URL

The response size in bytes can typically be found in the `Content-Length` header of the response. You can write a verification against it: URL (this uses the actual response body length, by the way, not the value of the `Content-Length` header). You can also calculate the length yourself by extracting the response body as a `string` and calculating its value. See also #92.

Hope that helps, if not, feel free to ask :)


Thank you very much for your answers!

Regarding the number of threads. So there is no way to change this value now? If not, will it be possible in the future?


No, there is no way to change this at the moment. What is your use case for this? It shouldn't be too hard to add a method to configure this, but I'm curious to see why you would need it.

Also, once I start working on #107 this might become possible, too.


Just trying to understand what the limitations are
Thank you very much for the information


No problem!

I just remembered something: you _can_ configure the maximum number of connections yourself by injecting an `HttpClient` of your own and configuring the `MaxConnectionsPerServer` property on the `HttpClientHandler` associated with the client.

See URL

If this is enough information for you, please close the issue. If not, leave it open and ask away :)


Hi @crystall-bitquill,
* for the driver logs, as mentioned above, the Opened Connections Tracked log shows a list that keeps growing (never shrinks), or are you interested in another bit of the log ?
* a sample code:

spring:
 datasource:
 type: com.zaxxer.hikari.HikariDataSource
 url: ${DB_URL}
 username: ${DB_USERNAME}
 driver-class-name: software.amazon.jdbc.Driver
 hikari:
 data-source-properties:
 wrapperPlugins: auroraConnectionTracker,efm,failover,iam
 wrapperDialect: aurora-pg
 wrapperLogUnclosedConnections: true
 wrapperLoggerLevel: ALL
 exception-override-class-name: software.amazon.jdbc.util.HikariCPSQLException
 max-lifetime: 300000
 connection-timeout: 1200
 validation-timeout: 1000
 maximum-pool-size: 15

class Repository {
...
private final JdbcTemplate jdbcTemplate;
 public int[] query(paramArray) {
 return jdbcTemplate.batchUpdate("SQL", paramArray);
 }
}
....


Closing this out as we have converted reusable blocks to synced patterns and categories are now possible/slated for 6.4: URL


Maybe you have some privileges issues with this docker host? Maybe try the `--privileged` flag ? URL


its not an arm, its an i5 proxmox host with vm ubuntu 22.xx -> docker -> jdown

the privileged mode doesnt work. only the network host mode works for the moment


Thanks @SquupS . We'll take a closer look and see how we can improve our metrics display.


BTDigg has started actively blocking Jackett and Prowlarr traffic from linux platforms.
This follows a period in March URL which went on until August. While windows traffic is a smaller percentage of total Jackett users, linux (via docker or native) is a much larger user base.
There seems little point trying to access this site from Jackett so I shall remove this indexer.


Not down for me at the moment, is there some dark magic going on?


There are no sig labels on this issue. Please add an appropriate label by using one of the following commands:
- `/sig `
- `/wg `
- `/committee `

Please see the group list for a listing of the SIGs, working groups, and committees available.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the `triage/accepted` label and provide further guidance.

The `triage/accepted` label can be added by org members by writing `/triage accepted` in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Or maybe a bug with m'y new release i will do some checks this night


I just want to notice I just fixed the logs with a new release


i try, but the same result, i pull the new releases, same error with latest and alpine.
what i say, it works on this docker host until 1 wekk. my watchtower pull an update last week after this i have to use the netwprk host mode to run


ZDP-Planning:
- pushing into the inbox of ZPA to get an update on this as it relates to #14003


Hey @apurva-1403 👋!

 @kunjgit here,
 Hope you are doing extremely well 😇
 It's confirmed 🥳, GameZone is taking part in hacktoberfest and ready to have another 💥
 Ready to have some amazing contributions once again also thank you for you support in GSSoC23 you have took us on top 5 ❤🔥
 if you still haven't joined us join us on Discord
 See you soon 😊


The ZPA-team discussed this issue again and now considers this a bug. Originally, I felt it was a feature, as we have never supported many timers triggering at once (i.e., there's always a limit somewhere). However, the team feels that outages should not occur from existing features, irrespective of how they are used. Add to this that we don't have documentation about some artibrary limit to the number of timers. Lastly, users feel that this is a bug, and so should we.

As a bug, it may be easier to prioritize and release a fix for this as we can backport and patch previous versions.


I didn't change anything in network.
Maybe a bug in this docker host or in the lastest alpine and ubuntu images I use to build this new releases?


@yuisotozaki @oanyahuru
Seeking UX assistance to improve the phrasing in the Error Dialog:
Current error dialog is like:
Private Zenhub Image

I suggest replacing the highlighted text with something along the lines of: 'The Name Request is currently under examination and editing/canceling is not available. For assistance, please contact BC Registries staff:


I would go further and update the title for this scenario.

Title: "This Name Request is being examined by BC Registries staff"
Description: "This Name Request is currently under examination. It cannot be edited or cancelled until the examination is complete. For assistance, please contact BC Registries staff:"

If we know more about how long a typical examination takes, we can include that in the message so that the user knows how long to wait before checking on the NR's status. For example, if name examination + system synch time is around 30 minutes, we can use the following message.

Description: "This Name Request is currently under examination. It cannot be edited or cancelled until the examination is complete. The approval status will reflect the result of the examination. This process typically takes about 30 minutes. For assistance, please contact BC Registries staff:"


Examples:
* Function signature + open parens => generate full function body (even for long functions)
* Struct definitions => line by line (see how this affects CAR)


first again many thanks to your support. i can't understand it yet, but i have redone the whole configuration of the docker with regard to ip and dns. now it works. what i don't understand is why the network host mode worked. i have in another docker pihole with unbound running, that also works great. only as soon as container wanted to access "internally" i.e. jdown -> pihole it came to problems. a reconfiguration helped. although in the end the settings are the same. it's currently inexplicable to me. have in any case many thanks


That put me in the same state... still on the loop of a VPN i dont even use


Hey, this seems related mainly to using efm plugin, when disabled and instead using the following plugins
`auroraConnectionTracker,failover,iam` not OOMs are observed. I didn't get the time to properly look at the exact root cause tho.


If you deleted the container completely it wouldn’t have a git cache of
downloaded profiles..

On Tue, 26 Sep 2023 at 22:10, Xsatc77 ***@***.***> wrote:


@Xsatc77 if you delete the config from the opt/transmission/config directory the configuration gets freshly cloned and the issue disapears :)
You have mapped the config as volume and therfore just recreating the container does not work.


Exactly, the clones repo is stored in config so check that the git clone
deleted

On Wed, 27 Sep 2023 at 07:10, Niels Morf ***@***.***> wrote:


I don't think the previous word in Error dialog (for payment) works for the scenario. After discuss with Yui, I opened URL for UX to review and decide the error message.
The modifications in error.vue may be temporary, with the hope that they will suffice until UX provides further guidance.


Even outside `cargo script`, I find that having to add `publish = false` *and* keep a meaningless version around is pointless boilerplate. I don't think there should be a lint about a missing `publish = false` if the version is absent; it will be obvious when attempting to publish that it's not possible because of the missing version (writing a description error message should be simple) and adding one at that point is simple as well. Maybe we could / should lint if `publish` is set [to something other than `false`] and the version is unset though.


Thanks Dr. Bivand. I just finished building my house, moved in, and found my laptop chord the other day. I will get working on this in the mornings. Shall I use this channel to ask questions?


I believe that sunrise is the only map tools function the package uses in the.

The suntools package seems to have this function.

I will migrate in the next week.


@eve-git I tested following the steps you outlined earlier (in your comment on June 28th). The 'edit' and the 'cancel and refund' buttons did not work once the NR status changed to "In Progress" on NameX. it rather displayed an error.

Private Zenhub Image

When I refreshed the page on Name Request, only the download receipts button was displayed when the request status was 'in progress'. As expected, clicking on it produced another error message

Private Zenhub Image


The error for the receipt shouldn't be there. I will look into it.


/triage accepted
/priority important-longerm
/assign @SergeyKanzhelev


@mmiranda96: The label(s) `priority/important-longerm` cannot be applied, because the repository doesn't have them.

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Looks like the receipt error is from pay-db and not in the scope of this ticket.

2023-09-27 17:39:11,309 - namex - DEBUG in payments:payments.py:13 - get_payment: {'_links': {'collection': '/api/v1/payment-requests?invoice_id=713929', 'self': '/api/v1/payment-requests/713929'}, 'businessIdentifier': 'NR 5795820', 'corpTypeCode': 'NRO', 'createdBy': 'IDIR\\OANYAHUR', 'createdName': 'Oge Anyahuru', 'createdOn': '2023-09-27T17:03:59+00:00', 'details': [{'label': 'NR Number:', 'value': 'NR 5795820'}, {'label': 'Name Choices:', 'value': ''}, {'label': '1.', 'value': 'RIGSHORE AND HORSE POWER TOOLS LTD.'}], 'id': 713929, 'isPaymentActionRequired': False, 'lineItems': [{'description': 'Name Request fee', 'filingFees': 30.0, 'futureEffectiveFees': 0.0, 'gst': 0.0, 'id': 716283, 'priorityFees': 0.0, 'pst': 0.0, 'quantity': 1, 'serviceFees': 0.0, 'statusCode': 'ACTIVE', 'total': 30.0, 'waivedBy': None, 'waivedFees': 0.0}], 'paid': 0.0, 'paymentAccount': {'accountId': '1999', 'accountName': "Ministry of Citizens' Services-BC Registries and Online Services Staff", 'billable': True}, 'paymentMethod': 'INTERNAL', 'refund': 0.0, 'routingSlip': '206462426', 'serviceFees': 0.0, 'statusCode': 'APPROVED', 'total': 30.0}
2023-09-27 17:39:11,309 - namex - DEBUG in payment:payment.py:298 - get: adding temporary receipt details.
Error when calling call_api get ( URL
2023-09-27 17:39:12,767 - namex - ERROR in api_resource:api_resource.py:14 - handle_exception: Error: SBCPaymentException('SBC Pay API exception.')
Error when calling call_api get ( URL
2023-09-27 17:40:42,229 - namex - ERROR in api_resource:api_resource.py:14 - handle_exception: Error: SBCPaymentException('SBC Pay API exception.')


Running with `CXXFLAGS=-fsanitize=undefined`

$ ./asgard -p riemann_1x3v -d 3 -l "7 6 6 6" -x -t 2.3419e-4 -n 210 -m 7 --kron-mode sparse --inner_it 10 --tol 1e-8 --mixed_grid_group 1
Branch: develop
Commit Summary: 6d9cb87cd16c17c0ee53f5037e1f3a9bbdaec9b0
 Date: Fri Sep 22 09:22:33 2023 -0400
 Update OpenBLAS to v0.3.24
This executable was built on Wednesday, September 27 2023 at 3:25 pm
generating: pde...
ASGarD problem configuration:
 selected PDE: riemann_1x3v
 degree: 3
 N steps: 210
 write freq: 0
 realspace freq: 0
 implicit: 0
 full grid: 0
 CFL number: 0.01
 Poisson solve: 0
 starting levels: 7 6 6 6
 max adaptivity levels: 7
--- begin setup ---
 generating: adaptive grid...
 degrees of freedom: 7133184
 generating: basis operator...
 basis operator allocation (MB): 0.0348816
 generating: dimension mass matrices...
 generating: initial conditions...
 degrees of freedom (post initial adapt): 7133184
 generating: coefficient matrices...
 generating: moment vectors...
--- begin time loop staging ---
--- begin time loop w/ dt 0.00023419 ---
 dim0 lev = 7
 dim1 lev = 6
 -- moment_mat map size = 7133184
384
 -- moment_mat map size = 7133184
384
 -- moment_mat map size = 7133184
384
 -- moment_mat map size = 7133184
384
 -- moment_mat map size = 7133184
768
 -- moment_mat map size = 7133184
768
 -- moment_mat map size = 7133184
768
/home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:177:43: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
/home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:178:43: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
/home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:178:30: runtime error: shift exponent -1 is negative
/home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:178:43: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
/home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:177:30: runtime error: shift exponent -1 is negative
/home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:177:43: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
/home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:178:43: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
/home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:178:43: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'


@eve-git, if everything else is ok, I will move the ticket to Ready for Release. Another ticket can be opened for the receipt error.


backtrace

768
asgard: /home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:173: bool asgard::check_connected(int, int, int, int): Assertion `L1 > 0 && L1 ::digits' failed.

Thread 1 "asgard" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007fffee087859 in __GI_abort () at abort.c:79
#2 0x00007fffee087729 in __assert_fail_base (fmt=0x7fffee21d588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5555567dc508 "L1 > 0 && L1 ::digits",
 file=0x5555567dc3a0 "/home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp", line=173, function= ) at assert.c:92
#3 0x00007fffee098fd6 in __GI___assert_fail (assertion=0x5555567dc508 "L1 > 0 && L1 ::digits", file=0x5555567dc3a0 "/home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp", line=173,
 function=0x5555567dc4c8 "bool asgard::check_connected(int, int, int, int)") at assert.c:101
#4 0x000055555605d84f in asgard::check_connected (L1=0, p1=0, L2=0, p2=0) at /home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:173
#5 0x000055555605de92 in asgard::check_connected (num_dimensions=4, row=0x7fffdc08c010, col=0x7fffdc08c010) at /home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:226
#6 0x0000555556061086 in asgard::compute_mem_usage (pde=..., discretization=..., program_options=..., imex=asgard::imex_flag::imex_explicit, spcache=..., memory_limit_MB=0, index_limit=2147483646, force_sparse=false)
 at /home/svh/Documents/asgard/src/asgard_kronmult_matrix.cpp:854
#7 0x000055555601901c in asgard::matrix_list ::make (this=0x7fffffffcc70, entry=asgard::imex_explicit, pde=..., grid=..., opts=...) at /home/svh/Documents/asgard/src/asgard_kronmult_matrix.hpp:787
#8 0x000055555601f5f8 in asgard::matrix_list ::reset_coefficients (this=0x7fffffffcc70, entry=asgard::imex_explicit, pde=..., grid=..., opts=...) at /home/svh/Documents/asgard/src/asgard_kronmult_matrix.hpp:851
#9 0x0000555556009a6d in asgard::time_advance::imex_advance (pde=..., operator_matrices=..., adaptive_grid=..., transformer=..., program_opts=..., unscaled_parts=..., f_0=..., x_prev=..., time=0.00023419000000000001,
 solver=asgard::solve_opts::gmres, update_system=true) at /home/svh/Documents/asgard/src/time_advance.cpp:778
#10 0x0000555556003592 in asgard::time_advance::adaptive_advance (step_method=asgard::time_advance::method::imex, pde=..., operator_matrices=..., adaptive_grid=..., transformer=..., program_opts=..., x_orig=...,
 time=0.00023419000000000001, update_system=true) at /home/svh/Documents/asgard/src/time_advance.cpp:73
#11 0x0000555555d3eb18 in main (argc=22, argv=0x7fffffffd098) at /home/svh/Documents/asgard/src/main.cpp:270


Printing the indexes, we are getting an index of 31. Now digging in the index formation to see what went wrong.


@quantumsteve I don't understand the trace. We count the levels from 0, even though we don't allow the user to work with level less than 1. We need at least two levels to form a "wavelet" basis.


If `L1 <= 0` or `L2 <= 0` the bit shift would be by a negative number.

 URL


Is that considered an `overflow`? The case `L1=0` and `L2=0` exists in absolutely every grid we have ever used and tested.


BTW @stefan-schnake did you enable memory limits in CMake when you compiled this?


There is a small bug that throws us off in the error message, I'll fix that tonight.

Nevertheless, I think we are likely to run out of GPU memory for this problem and we may have to enable the memory limits (which in turn may cancel all benefits of going sparse).


I erased the content of the `vpn-configs-contrib` folder to test, and the error is now:

I also tried removing `OVERRIDE_DNS_1` and `OVERRIDE_DNS_2`, it doesn't seem to change much.


URL
delete vpn-configs-contrib
then delete container and restart..
it's a git thing..


FYI - Engineering opened issue related to usability of the UI for selecting existing SDKs. URL


Yes agreed - we can develop these here and then migrate to other projects.


I'm afraid I haven't worked on this one yet at all - limited on time this week. I do think that once we have the weather story ticket fleshed out, it will heavily inform this one, so I've been prioritizing work on that first. It's ready to be discussed with design and product.


This looks not just limited in the init container with restartPolicy of `Always`, the regular container should have the same behavior.

There is a time gap between the container start and its startupProbe start. If your container exits quickly, it might not run the startupProbe at all.

---

Why do you need to run this command with restartPolicy of `Always`?
I am not getting what this scenario is for.

The init container with restartPolicy of `Always` is supposed to be long-running.


We'll definitely need to do this at some point. I've written a few tests, but I've never set up a testing system before. I'd like to learn how, though, so I'd like to take this one on. I think it would be sensible to start by writing the tests with pytest, then later figure out how to automatically run them with any PR?


I'd be happy to take this one on. I will see if I can replicate how its done with tskit data.


Great. We could probably do a bit better than `tskit` for the interface. For example, it would be good to have something like this:

 URL

It would be much better if we could use `tables.nodes.time[x]` to get direct memory access, rather than the somewhat clunky `ts.nodes_time[x]`. You might well want to talk to @benjeffery about this.

Do make sure, however, that we aren' "prematurely optimising". For the size of datasets we are experimenting on, there's no need to make this fast (yet). It's better to get a slow API that can be sped up later, under the hood.

Once we get to this stage, it's vital to start setting up unit tests, so #20 is important to tackle at the same time.


@scottdotau there is URL that has regular contributions. Those contributions have a TODO, so you could pick something up from that.


@SMillerDev appreciate it, obviously didn't read all the replies 🙃.


The majority of the tasks in this issue is resolved and implemented.
We will issue new tickets whenever new tasks coming up.

Thanks.


looks like python3.11.6 was released today. I haven't tested the fix since I'm waiting for `brew` to support it (to keep my installations manageable).


Hey @kunjgit !
 Thank you for raising an issue 💗
 You can self assign the issue by commenting /assign in comment 😀
 Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
 Don’t Forget to ⭐ our GameZone🎮
 Make sure you join our Discord🕹


Hey @kunjgit 👋!

 @kunjgit here,
 Hope you are enjoying this hacktober 😀
 We are excited to share that we are opening issue from our side where you will be going to add games on our website 🚀
 Work on this issue 🔥
 and help us building GameZone 💗
 if you still haven't joined us join us on Discord
 See you soon 😊


Hey @apurva-1403 👋!

 @kunjgit here,
 Hope you are enjoying this hacktober 😀
 We are excited to share that we are opening issue from our side where you will be going to add games on our website 🚀
 Work on this issue 🔥
 and help us building GameZone 💗
 if you still haven't joined us join us on Discord
 See you soon 😊


@luckajirku @albertoh Navrhuji tohle řešit společně s issue URL - do rozvoje bychom to zahrnuli jako společný bod něcoi ve smyslu rozvoje funkcí stromového zobrazení v klientovi. Souhlasíte?


The infrastructure is basically there now, although the tests aren't. I will leave this open until we've made a few PRs to test that it's all working.


Bonjour Kevin,

Nous n'avons finalement pas récupéré les développements effectués par Atos sur leur dépôt, nous avons préféré attendre une version éprouvée afin d'éviter au maximum les dysfonctionnements.
Nous sommes donc toujours en attente d'éléments concernant la validation de cette fonctionnalité.
Les tests ont-ils été concluants ?
Est-il prévu d'intégrer la pull request dans votre dépôt ?


An easy task is to get coverage up to 100% in tables.py and util.py. See

 URL


The two example tests in test_tables.py should show you (a) how to use fixtures (e.g. if you want to import a standard GIG for testing in multiple tests) and (b) how to use `@pytest.mark.parametrize` to test a range of parameter values. Both of these are useful idioms.


Hi. Is this different from URL ?

@barreiro , the person most likely to approve such a feature, had concern with the approach: URL
Do you have ideas to address those concerns?


All valid concerns, I guess it's the responsibility of the developer to know what they are doing.

The AgroalPoolInterceptor that can be used now also gives access to the underlying connection.
Maybe it has less room for errors, but I'd say there are infinite ways to mess up if not careful :)

For context, I need to make sure that connections are rolled back before they are closed.
Oracle seems to perform a commit when a connection is closed.
We have an issue when quarkus is shut down gracefully while there are long-running tasks running.
I created an issue for this specific problem as well: URL


@janelx are we still waiting on forecaster feedback on this? I don't think we've gotten it, but Sarah might have this prioritized against partner/public needs as well.


Hi @abdoofathy95,

To update you, it seems like the additional connections you're seeing in the connection tracker comes from the Hikari pool. When idle connections reach the maxLifetime, they are closed and new connections are made. The connection tracker is logging these closed connections. However, all of these closed connections are weak references and can be removed by garbage collection. Have you made any changes to any garbage collection settings? If not, it is unlikely that the OOM error was caused by the connections visible in the tracker, as they should be garbage collected before the OOM error occurs. This occurs regardless of which plugins are used.

You mentioned you didn't get the OOM error when efm was disabled. Would you be able to try the following plugin combinations to confirm where the error is?
1. No plugins - this can be done by setting the `wrapperPlugins` property to an empty string (the driver has several plugins enabled by default).
2. EFM only

In addition, I have a few questions:
1. Are you able to see how much free memory you have before and after starting your application?
2. Are you ablt to tell at what rate the amount of free memory you have available is decreasing?
3. Are any failover events occurring?


Still an issue for us.
we don't want to use a 3rd party plugin for this, and flipping videos with ffmpeg is a hudge performance problem.

Can we have a flag to prevent mirroring ? or to get the non mirrored video after record... ?
like iOS does in photo app when recording a video with front camera.


# Notes from Barcelona 2023:
- Consensus that optical channels should be separate Extractors --> need to refactor old stuff to fit
- 2 Main goals for the repo:
 - Make conversion easier
 - Define unified API for users like SpikeExtractors in e-phys
- Guiding Principle: Focus on how it looks for the user (usu. conversions) and then design the API around that
- specify channel_name and plane_name via string at init
- look out for segments in the future if/when we get data
- numpydoc_validation needs some kind of automatic docstring fixer before it's worth adding


@colinmurphy01 I believe we have received enough in from forecasters to begin creating this. I have a good idea of what it will look like and how we might be able to begin testing it. It sounds like there is a large public and partner need for hazard stories (forecaster communication around hazard) and the hazard page in general.


@colinmurphy01 the comment above is for #155 Hazard Forecasts, which I mistook this ticket for. I don't think this ticket requires forecaster feedback at the moment? I'm not sure where that need came from. I created a new ticket for a more detailed wireframe #242. I can review flow and components with POs this Friday and if approved we can close this ticket.


Just found that I implemented pretty similar to this package, but with a bit more features:

1. memoization of returned object is supported by default (and custom equal)
2. no "stale props" problem
3. has deps for "selector" function

 URL


Hi, are you able to check if this is now resolved on insiders? I have made even more edits to the flow to hopefully not delete the UUID pre-maturely which I think was the problem. If not I will have to go a different direction for the investigation. Thanks for your help!


Yeah, we recently implemented `useShallow` in Zustand with `useRef`.
 URL


Currently, the wazuh-puppet repository does not allow a distributed deployment.
It will be included in `4.8.0` with this issue:
- URL


We will continue the distributed deployment development here:
- URL


Problem is still there. I'm getting a ton of these errors:

 The python test process was terminated before it could exit on its own, the process errored with: Code: 5, Signal: null
2023-10-05 13:04:21.392 [error] pytest test discovery error

Once the test refresh finishes, I see the tests for one of my projects, a `pytest Discovery Error` for another that references the error messages above, and none of the other projects in the workspace. If I refresh again, the view clears and a few different projects flicker in the list as their tests get collected, but they're immediately replaced by whatever finishes next and I ended up with the view I had originally.

So... simplified version, if my workspace has projects A, B, C, and D and I refresh tests, the Test Explorer shows:

- A
-- tests
--- unit
---- test_xyz
- pytest Discovery Error [B]

If I refresh tests again, I'll see the tests for C appear instead of A for about a second, then discovery completes on A and I'm back to the view above. It does look like the Discovery Error bounces between B and D with every refresh.

I am able to run the tests for A once the refresh completes.


We had a series of prod. auto-restarts again yesterday. This is definitely caused by solr stopping responding, this is confirmed now.
A bandaid, but hopefully an effective temp. workaround was applied on the solr side, setting up "circuit breaker" config options. This makes solr start dropping new connections with 503 when certain threshold of memory and/or cpu utilization is reached, rather than hanging. (the observed search page freezes were accompanied by the cpu utilization approaching 800% - on the 8-cpu node that is dvn-cloud-solr). Thanks/kudos to @kcondon for researching/figuring out the above.


Also noticed that clicking on basic search with no parameters spikes solr cpu. Clicking multiple times raises cpu use rapidly to where I can simulate the 700+% cpu load on solr. Refreshing the homepage or clicking on facets does not do this beyond an initial spike, then levels off. I was able to trigger the cpu circuit breaker, I think, using this method.


@mrburrito just to make sure, do you have any other pytest plug-ins configured?


I have seen this same problem, BUT, the problem is not exactly that the canonical URL is not added to the `head`. Actually is NOT supposed to be added to the head, but rather to the **response headers** of the page.

The Canonical URL metatag uses the `#attached` method `backdrop_add_http_header` (notice this is NOT `backdrop_add_html_head`).

Still, this is a problem. If you inspect the Response Header with the browser dev tools you'll see that the canonical URL is not included:

<img width="1344" alt="Screen Shot 2023-10-05 at 7 33 06 PM" src=" URL

The main issue is the way Backdrop's metatag module processes the metatag info. Unlike the D7 version, Backdrop's version bypasses the normal way of adding tags to the head (or in this case, adding info to the header) by hard-coding `backdrop_add_html_head()` in `metatag_preprocess_page()`.

This is not right. But rather than making tons of changes, there is a way to avoid this problem. I'll will submit this in a separate issue.


PR ready for review. This is a site that uses Canonical URL metatag. Unlike other basic metatags, Canonical URL is supposed to be sent to the browser in the headers. Before the patch, inspecting the headers, Link is not included:

<img width="1344" alt="Screen Shot 2023-10-05 at 7 33 06 PM" src=" URL

After the patch:

<img width="1407" alt="Screen Shot 2023-10-05 at 9 07 19 PM" src=" URL

I've tested the patch with some of the tags provided by `schema_metatag`, and they work as expected.


I have provided an issue and PR that fixes this. After patching, the header "link" with the canonical URL is sent to the browser. See #110 and #111


I didn't try this locally yet (have to download an Oracle container on a low-bandwidth connection...), but IIUC the main problem is that the interceptor doesn't trigger a rollback before Agroal gets stopped (and connections get closed).

I wonder if the root cause isn't simply that your thread gets interrupted, leading `Thread.sleep` to throw an `InterruptedException`, which, crucially, isn't a `RuntimeException` and thus doesn't trigger a rollback...

See URL

(And yes I agree it's a crazily dangerous default, but that's the spec.)

Could you try annotating your method with this instead, and tell me if it solves your problem?

java
@Transactional(rollbackOn={Exception.class})


Thanks for your reply!

The result is still the same.
I used Thread.sleep in a rest endpoint here to make a simple example.
We noticed the issue with longer running processes combined with redeployment on Openshift.

I also verified this "commit on close" behavior with basic JDBC.
If I don't explicitly roll back, then the insert is committed when closing the connection.
My guess is that Oracle is the only database provider that behaves like this.

 try {
 Class.forName("oracle.jdbc.driver.OracleDriver");
 conn = DriverManager.getConnection(jdbcUrl, username, password);
 conn.setAutoCommit(false);

 String insertSQL = "INSERT INTO D00SREFTPB01.TEST_TABLE (TEST_COLUMN) VALUES (?)";
 try (PreparedStatement pstmt = conn.prepareStatement(insertSQL)) {
 pstmt.setLong(1, System.currentTimeMillis());
 pstmt.executeUpdate();
 System.out.println("Dummy data inserted into TEST_TABLE");
 }

// conn.rollback();
 } catch (SQLException | ClassNotFoundException e) {
 e.printStackTrace();
 } finally {
 if (conn != null) {
 try {
 conn.close();
 } catch (SQLException e) {
 e.printStackTrace();
 }
 }
 }


That's for sure, and from what I can see it's well-known to Oracle users; found this in particular.

I'm not too worried about Oracle's behavior though, more about the fact that the transaction wasn't rolled back by the interceptor (so, before the connection was closed), especially with `@Transactional(rollbackOn={Exception.class})`.

There must be something wrong on shutdown, maybe Agroal stopping before application threads, I don't know. Needs further investigation.


@janelx Updated this story to reflect the concept we talked about of this as a version/view of a weather story. I added a couple examples based on past hazard-based stories, but it might be a bit before I can grab some images to go with them because I'll need to wait for new ones or use wayback machine to find some that match.
With that missing piece in mind, does this otherwise reflect what we talked about? Is anything different or missing?


Note I did fix the issue with a workaround by using a AgroalDataSourceListener.

The code is dirty as there is no out-of-the-box solution to set a custom AgroalDataSourceListener in Quarkus.
I also created a feature request to allow for that ( URL

But in essence I just do a rollback in `beforeConnectionDestroy`
Normally if the transaction was successful, Quarkus should have performed the commit and there would be nothing to roll back.

@ApplicationScoped
public class CustomOracleRollback implements StartupInitializer, AgroalDataSourceListener {
 @Inject
 DataSources dataSources;

 @Override
 @SneakyThrows
 @SuppressWarnings("all")
 public void initialize() {
 DataSource dataSource = (DataSource) dataSources.getDataSource(" ");

 Field connectionPoolField = DataSource.class.getDeclaredField("connectionPool");
 connectionPoolField.setAccessible(true);
 ConnectionPool connectionPool = (ConnectionPool) connectionPoolField.get(dataSource);

 Field listenersField = ConnectionPool.class.getDeclaredField("listeners");
 listenersField.setAccessible(true);
 AgroalDataSourceListener[] listeners = (AgroalDataSourceListener[]) listenersField.get(connectionPool);

 List newListeners = new ArrayList<>(Arrays.asList(listeners));
 newListeners.add(this);

 Field theUnsafeField = Unsafe.class.getDeclaredField("theUnsafe");
 theUnsafeField.setAccessible(true);
 Unsafe unsafe = (Unsafe) theUnsafeField.get(null);

 long offset = unsafe.objectFieldOffset(listenersField);
 AgroalDataSourceListener[] newListenersArray = newListeners.toArray(new AgroalDataSourceListener[0]);
 unsafe.putObject(connectionPool, offset, newListenersArray);
 }

 @Override
 public void beforeConnectionDestroy(Connection connection) {
 try {
 connection.rollback();
 } catch (SQLException e) {
 // ignore
 }
 }
}


Note the issue is only happening on graceful shutdowns.
I'm not sure how this is handled by Quarkus, but my guess is that the interceptor you are referring to never gets executed.
Maybe the executor thread pool is just shut down with a timeout and threads are killed if they take too long to finish.


@nathan-contino Going to reopen this issue as there is still a Wordpress tutorial associated with it to write!


Only one is `pytest-fixtures` which I wouldn't think would interfere with test discovery, but I'll turn it off and see if anything changes.

Local plugins:

DavidAnson.vscode-markdownlint@0.52.0
dsznajder.es7-react-js-snippets@4.4.3
eamodio.gitlens@2023.6.605
ecmel.vscode-html-css@1.13.1
foxundermoon.shell-format@7.2.5
GitHub.vscode-pull-request-github@0.75.2023100509
hashicorp.terraform@2.29.2023100414
iliazeus.vscode-ansi@1.1.6
k--kato.intellij-idea-keybindings@1.5.10
lizebang.bash-extension-pack@0.0.4
mads-hartmann.bash-ide-vscode@1.39.0
marclipovsky.string-manipulation@0.5.7
ms-azuretools.vscode-docker@1.26.1
ms-python.black-formatter@2023.5.11881008
ms-python.isort@2023.11.11881009
ms-python.python@2023.19.12791027
ms-python.vscode-pylance@2023.10.11
ms-vscode-remote.remote-containers@0.317.0
ms-vscode-remote.remote-ssh@0.106.4
ms-vscode-remote.remote-ssh-edit@0.86.0
ms-vscode-remote.remote-wsl@0.81.7
ms-vscode-remote.vscode-remote-extensionpack@0.24.0
ms-vscode.powershell@2023.6.0
ms-vscode.remote-explorer@0.4.1
ms-vscode.remote-server@1.4.3
nickmillerdev.pytest-fixtures@0.3.3
qux-bbb.text-utils@0.1.7
redhat.ansible@2.7.98
redhat.vscode-yaml@1.14.0
Remisa.shellman@5.7.0
rogalmic.bash-debug@0.3.9
rpinski.shebang-snippets@0.1.4
timonwong.shellcheck@0.34.0

Remote Plugins:

DavidAnson.vscode-markdownlint@0.52.0
dsznajder.es7-react-js-snippets@4.4.3
eamodio.gitlens@14.3.0
ecmel.vscode-html-css@1.13.1
foxundermoon.shell-format@7.2.5
GitHub.vscode-pull-request-github@0.74.0
hashicorp.terraform@2.28.0
iliazeus.vscode-ansi@1.1.6
lizebang.bash-extension-pack@0.0.4
mads-hartmann.bash-ide-vscode@1.39.0
marclipovsky.string-manipulation@0.5.7
ms-azuretools.vscode-docker@1.26.1
ms-python.black-formatter@2023.4.1
ms-python.flake8@2023.9.12791029
ms-python.isort@2023.10.1
ms-python.python@2023.19.12791027
ms-python.vscode-pylance@2023.10.11
ms-vscode.powershell@2023.6.0
nickmillerdev.pytest-fixtures@0.3.3
qux-bbb.text-utils@0.1.7
redhat.ansible@2.7.98
redhat.vscode-yaml@1.14.0
Remisa.shellman@5.7.0
rogalmic.bash-debug@0.3.9
rpinski.shebang-snippets@0.1.4
timonwong.shellcheck@0.34.0


That's the thing: if threads are killed, the call to `Thread.sleep` should throw an `InterruptedException`, and if you put `@Transactional(rollbackOn={Exception.class})` on your method, that should trigger a rollback.

And all that should happen before the DB connection gets closed, because why on earth would Quarkus stop DB connection pools before killing application threads...

If it doesn't happen that way, there's something wrong...

Another theory would be that `@SneakyThrows` somehow confuses Quarkus and leads to the interceptor misbehaving. While unlikely, I suppose that's possible.


Hey @crystall-bitquill,
thank you for your reply,
I'm using the following flags
`-XX:+UseG1GC -Xms1536m -Xmx1536m -XX:MaxMetaspaceSize=256M -Xss2m`.

I will try to disable all the plugins and see the behaviour.

1. not sure I get what you mean here by before starting the application, it's a pod that as soon as it gets deployed, the application starts.
2. this is the JVM heap metric URL
3. There are no failover events occurring.


Same behavior with that plugin enabled or disabled. I'm seeing a different set of tests today but still only one of my 40+ modules showing up.


Not sure if this is relevant or if the discovery code accounts for it, but the pytest discovery check is returning the same ` ` top-level element for almost all of my modules.

Sample structure:

/root_dir
 /packages
 /module1
 /module2
 /stages
 /module3
 /module4

Sample output:

============================= test session starts ==============================
platform linux -- Python 3.9.16, pytest-7.2.2, pluggy-1.3.0
rootdir: /root_dir
plugins: dictsdiff-0.5.8, pyfakefs-4.7.0, requests-mock-1.9.3, unordered-0.5.2, mock-3.10.0, cov-2.12.1, pytest_check-1.0.2, smtpdfix-0.4.2
collected 10 items

========================= 10 tests collected in 1.50s ==========================
============================= test session starts ==============================
platform linux -- Python 3.9.16, pytest-7.2.2, pluggy-1.3.0
rootdir: /root_dir
plugins: dictsdiff-0.5.8, pyfakefs-4.7.0, requests-mock-1.9.3, unordered-0.5.2, mock-3.10.0, cov-2.12.1, pytest_check-1.0.2, smtpdfix-0.4.2
collected 10 items

========================= 10 tests collected in 1.50s ==========================
============================= test session starts ==============================
platform linux -- Python 3.9.16, pytest-7.2.2, pluggy-1.3.0
rootdir: /root_dir
plugins: dictsdiff-0.5.8, pyfakefs-4.7.0, requests-mock-1.9.3, unordered-0.5.2, mock-3.10.0, cov-2.12.1, pytest_check-1.0.2, smtpdfix-0.4.2
collected 10 items

========================= 10 tests collected in 1.50s ==========================
============================= test session starts ==============================
platform linux -- Python 3.9.16, pytest-7.2.2, pluggy-1.3.0
rootdir: /root_dir
plugins: dictsdiff-0.5.8, pyfakefs-4.7.0, requests-mock-1.9.3, unordered-0.5.2, mock-3.10.0, cov-2.12.1, pytest_check-1.0.2, smtpdfix-0.4.2
collected 10 items

========================= 10 tests collected in 1.50s ==========================

That output doesn't seem to have any bearing on what gets displayed in the test explorer, though I haven't seen any of the modules with fully qualified paths show up.


Hello, thank you for all your patience and assistance- your help is critical to us being able to deliver the best product to our users! A few things:

1. Can you try switch your log level to trace (you can do so in the command palette) and then running it again and sending me both the logs from the `python` output channel and the `python test output` channel? I have extra error logging I've been adding and it might give some more insight.
2. To clarify on your setup it is a multiroot workspace with multiple modules per workspace? When you talk about projects A,B,C and D are these within a specific workspace? Then where does the 40+ modules come into play?
3. I see from that output you have a few plugins in use, does removing all of those change anything? I know you tried with the pytest-fixtures one already. `plugins: dictsdiff-0.5.8, pyfakefs-4.7.0, requests-mock-1.9.3, unordered-0.5.2, mock-3.10.0, cov-2.12.1, pytest_check-1.0.2, smtpdfix-0.4.2`

Thank you!


I added the following Community Standards:
- Code of conduct
- Contributing guidelines
- Issue templates
- Pull request template
- Introduction to SimVascular GitHub
- License

Please have a look, @alisonmarsden, @MatteoSalvador, @menon-karthik, @ktbolt. These are meant to be a first draft so we have something to start with. The files can be easily edited in the browser.

The files are all in a separate .github repository within SimVascular. This way, all repositories default to those standards (but can overwrite them with their own).

All files are heavily inspired by BioDesign's StanfordSpezi software project (with community files here). **Many thanks to @PSchmiedmayer for the inspiration and GitHub guidance!** 😄


Closing this. Community standards will automatically be adopted once this repository moves to URL (see URL


Ha. I had to delete the entire `vpn-configs-contrib` folder. I had previously deleted the contents only but not the folder itself, which was somehow not helping. Maybe some hidden files I missed. Thanks.


It will be great to have these up on our website before the CZ software grant is due on Oct 17th. This is one of the items they ask about.

From: Martin R. Pfaller ***@***.***>
Date: Friday, October 6, 2023 at 3:47 PM
To: SimVascular/simvascular.github.io ***@***.***>
Cc: Alison Lesley Marsden ***@***.***>, Mention ***@***.***>
Subject: Re: [SimVascular/simvascular.github.io] Add developer guidelines to the website (Issue #8)

I added the following Community Standards:

 * Code of conduct


I will rewrite the `Contributing Guidelines` , get rid of all this

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]

and remove all of the words using all capital letters like `MUST` below

You MUST follow our Code of Conduct.

writing in all capital letters is like shouting


This setup seems to work for me:

[default]
sso_session = my-sso
sso_account_id = 123456789123
sso_role_name = SomeRole
region = us-east-1
output = json

[sso-session my-sso]
sso_region = us-east-1
sso_start_url = URL
sso_registration_scopes = sso:account:access

Not sure if something was changed since this issue was opened.


While using Transform or other post processing might work, with the release of `camera: 0.10.4`, the plugin allows for the camera to be flipped mid video recording. This means that simple flipping of the video post capture will no longer be correct as both parts of the video, those of the front and the back lens would be flipped.

If there are any native APIs that allow for the recording to be saved as previewed, then the camera plugin should probably expose them. Otherwise, recordings with multiple cameras will more or less always be incorrect if the user of the plugin will want to show exactly what was previewed to the user and save the video as such.


Thanks @mrp089! I went through all the community standards. I just have a few suggestions for the moment:
- **Issue templates:** it might be useful to give the possibility to the user to attach several types of files (pictures, scripts, meshes, `XML` configurations) in order to ease the bug fixing process.
- **Pull request templates:** I would clearly state that adding tests for each new feature implemented is mandatory. I would also mention the importance of code coverage during testing, which should ideally always increase after any PR.
- **License:** I have always reported this type of MIT license at the beginning of each `.h`/`.cpp` file. I am particularly referring to the sentence

I am of course happy to keep discussing this!


This looks like a really great first draft @mrp089, thanks for doing this!

I noticed some typos in the `Contributing Guidelines`. Should the rest of us fork/edit/merge the usual way or does this repository work differently?

About the issue and pull request templates, this is probably just me being dumb, but it's not clear to me how this actually works. When a new pull request/issue is created does it automatically open up in the specified template format for the user or does a user have to do something to get that format? If the latter, maybe we should provide instructions.

I like @MatteoSalvador's idea about adding specific instructions for tests and code coverage, but I also think we should actually enforce it by using Doxygen to prevent merging undocumented code. And mention that we are doing this in the instructions. See discussion here. What does everyone else think?


Doesn't work here but I have a different setup with:
`[default]
sso_session = my-sso
sso_account_id = 123456789123
sso_role_name = SomeRole

output = json

[sso-session my-sso]
sso_region = us-east-1
sso_start_url = URL
sso_registration_scopes = sso:account:access`


Ran into this issue on AlmaLinux release 8.6, running Powershell 7.2.6. I upgraded to 7.3.6 and the issue went away for about a month, now the problem is back. This is also on a server running Nagios so pwsh is being called 100+ times per minute. I do have a copy of the corrupt StartupProfileData-NonInteractive file as I simply renamed it go get things working, if that would be of help.


@ssefick R spatial infrastructure packages maptools, rgdal and rgeos will be archived by CRAN on Monday, October 16, 2023. Your package does not pass CMD check when these packages are not available. Expect your package to be archived by CRAN October 17-18 as CRAN checks feed through and your package fails, if not updated by Monday, October 16, 2023.

No grace period is anticipated, as you have had sufficient time to update your package to remove dependencies on maptools, rgdal and/or rgeos.


Thank you very much for the constructive feedback, @MatteoSalvador and @menon-karthik! I'll add my replies below. I'm closing this issue so we can continue the discussion in URL

@alisonmarsden, I've added a brief `Contributing` section to the SimVascular homepage and linked the Contributing Guidelines and the Code of Conduct (#10).


Just emailed that profile data file. It does not seem to matter what is run, I'm running .ps1 files directly from bash that have a #!/usr/bin/pwsh in the first line. But even running a simple command fails:
`pwsh -command Write-Output "ok"
Segmentation fault (core dumped)`


Great idea, please add!

Also great idea, please add!

Happy to discuss in URL


Yes, please!

They come up now when you open a new issue or pull request. You can give it a try and just click through it without adding anything.

I'm all for it! Unfortunately, we have ~1500 Doxygen warning in `svFSI+` so we can't do that anytime soon. But we could try implementing something that the number of warnings must go down in every pull request.

We could do the same for coverage. StanfordSpezi uses Codecov, which @MatteoSalvador and I briefly looked into. However, it's only free for public repositories (`svFSI+` is still private).


Thanks, I can confirm this is happening and it appears to be an issue with the comments / side panel (closed) generally, not just for rich text.

<img width="2001" alt="Screenshot 2023-10-10 at 5 49 28 am" src=" URL

<img width="1997" alt="Screenshot 2023-10-10 at 5 48 25 am" src=" URL


I found a temporary solution to this problem.

Taking the latest version 23.2.2 as an example, find following jar file:

, and use decompression software to extract the Chinese localization attribute file from it:

, and then change the value corresponding to the key `menuCloseAll` to `\u5173\u95ed\u5168\u90e8(&A)`,

Then, replace the original file in the Jar package with the modified file.

<img width="743" alt="2023-10-10_145621" src=" URL


I solved this by upgrading nuxt-seo-kit to @nuxtseo/module.

It does not really solve the issue per-se, but with the new module the problem is no longer there.


Thanks for confirming, will close for now as the v2 is my main focus at the moment.


Live at URL

There will also be a tutorial going into URL at some point soon.


Bonjour,

C'est assez étrange, je ne reproduit pas ce problème.
La 2.101.1 corrige un bug mais ce n'est pas celui-ci.

Il y n'y a pas eu de modification particulière liée au services dans la 2.101. Par contre dans la 2.100 on a corrigé un bug justement lié à datatables et aux Services : URL

Ton erreur me fait un peu penser à ce bug, mais vu qu'il a été corrigé justement ça m'étonne.

Est-ce que sur votre instance il y a un paramétrage particulier (dans le custom.py) lié aux colonnes affichées dans la vue liste ou à datatable ?


Dup of URL as this was happening with previous UI and keeps happening in new UI


Hi @chr-fritz,

Thanks for reaching out and raising this issue.

We'll take a look at this and keep you updated as we investigate.

Thank you for your patience!


Sinon ça peut justement être un problème de cache du navigateur ou du serveur ?


Yes. I don't know the ultimate reason why it is so but it is intentional indeed.
I'm not sure how long it takes to dim out exactly either but it may take a couple of minutes.
However, I seem to understand that the behavior may change in various circumstances.
Unfortunately, I don't have access to specific information at the moment but the described behavior is expected.

Michele Moramarco
Prusa Research


Bonjour,
J'ai vidé tout les caches et ça ne résout pas le problème. Il y avait bien une config pour les colonnes dans le custom.py :

COLUMNS_LISTS['trek_view'] = ['structure', 'practice', 'length_2d']

Je l'ai commenté et restart géotrek, et idem...


Après de multiple tests, j'ai réussi à résoudre le problème par la modification de la ligne URL en supprimant le 'name', et en ajoutant la ligne suivante au custom.py :

COLUMNS_LISTS["service_view"] = ["type"]

Ce n'est surement pas la bonne méthode, mais je n'ai plus d'erreur. Si ça peut aider a résoudre le problème...


Hey `index_add` is missing from this list and here is an issue explaining why it's needs to be added #26801


OK, en effet les services n'ont pas de champs NAME, mais seulement un id et un type.
Donc peut-etre un truc à revoir car ça a en effet été modifié récemment : URL


Oui en effet j'ai l'impression qu'il y a un lien avec ce commit. Mais ce qui est bizarre c'est que le problème ne survienne pas sur d'autres instances ... :thinking:


Est-ce que cela peu venir du fait d'avoir sauté plusieurs versions ?


Non. Lorsqu'on passe d'une ancienne version à une nouvelle la mise à jour repasse chaque migration de base une à une, comme si faisait chaque mise à jour l'une après l'autre, donc normalement ça n'engendre pas de problèmes.


@korthout Hi!

Is there any updates for this bug? I would be nice to have a due date )


It's been a while, I'll close here, assuming there's no interest anymore. Feel free to reopen.


Hi there, there appears to be a bug with the latest version of @swc/core that caused the error. For now, please fix your @swc/core to 1.3.82:

In package.json:

` "@swc/core": "1.3.82",`

I'll dig further into this over the weekend, sorry for the hiccup!


Thanks for your quick reply. I changed `@swc/core` to `1.3.82` and still get the same error. I have also updated the repositories I am testing. I'll be waiting for the weekend.


Try deleting your pnpm-lock and run `pnpm install; pnpm run dev` again.


I deleted `pnpm-lock.yaml` and ran `pnpm i`, but it does not seem to change. Also, I forgot to commit `pnpm-lock.yaml` to the repository, so I committed it.


That's really strange. I am testing on Windows and Mac environment, so I wonder if there's something specific with swc's Linux kernel that's broken. You can try an older version like 1.3.78 and see if that get it working again.

I'll look into migrating the template to `tsx` instead of `ts-node`, hopefully that would sidestep this issue altogether. Sorry for the trouble!


After changing to `1.3.78`, I removed the lock and reinstalled using the same procedure as before, but the error does not seem to change.


I have also checked the operation on Windows, but the error seems to occur in the same way as with Linux.

### How to reproduce

git clone URL
git checkout esm-server.ts

pnpm i
pnpm dev
pnpm dev

### Environment

OS: Windows 11 Pro 22621.2361
pnpm: v8.8.0
node: v20.8.0


I have started working the switch to tsx, you can observe the progress on this branch:

 URL

Feel free to test it out and let me know if it works for you!


I think it is very cool to tsx, but the error still seems to be the same. Do you get any errors with imports like `import { say_hello } from "~utils/hello.js"` in your environment?

Also, importing using relative paths works fine, but the paths that can be set on tsconfig do not seem to be resolving properly.


I've started work on this in the feature-activitypub branch.


Yes, aliasing works just fine in my environment:

image

I'm quite confused and having trouble nailing down what might be causing all these issues for you.

* Does the default template `npx create-remix` have the same issues for you?
* What about the Epic-Stack? URL


<img width="651" alt="image" src=" URL
<img width="237" alt="image" src=" URL

Thank you for your reply. I just wanted to let you know that I noticed that if you do not give the extension (.js) when importing, an error is displayed on the editor, but Remix works fine without error.

As far as I know, when using ES Module in TypeScript, the import must specify the extension `js`, is this wrong?

 URL


You're correct. ESM requires the extension. I was working on the wrong branch when testing above, import { Hello } from "~/utils/hello.js"` is the right syntax.


I have found that by setting the extension to `.ts` instead of `.js`, there are no errors on the editor, and the remix seems to work correctly. I see that the epic stack you mentioned also specifies `.ts`. Is it common to specify `.ts` instead of `.js`?


.js should work as long as you have `allowJs": true` in tsconfig.


You are certainly right about the use of different extensions. This time, hello.ts only provides a function `say_hello` to output `Hello World` using console.log, so I used `ts`. I'm going to close this Issue for now, since it seems that specifying the extension as it is will solve the problem. Thank you for your time. Have a nice weekend!


In Ubuntu you can try;

`sudo apt install libxkbcommon0 libxshmfence1 ca-certificates fonts-liberation libasound2 libatk-bridge2.0-0 libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgbm1 libgcc1 libglib2.0-0 libgtk-3-0 libnspr4 libnss3 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 lsb-release wget xdg-utils` to install all the packages togather


I can confirm that the problem no longer occurs with python 3.11.6 (tested with `Google Cloud SDK 446.0.1` on `MacOS 13.4`). I had the issue with python 3.11.5


I've been testing a patched version of Metatag (#110) with Metatag schema, with the 'article' schema type.

In general, it's working well and I see schema tags in json-ld format appear in the of pages configured to use the article schema type. However, while testing yesterday, I ran into a new error:

`Warning: strtolower() expects parameter 1 to be string, array given in strtolower() (line 2237 of /var/www/html/web/modules/contrib/metatag/metatag.module). `

This happens because the $attr_value delivered to strtolower can be an array for things like the 'organization' and 'ImageObject' that are part of the 'article' spec. I'm not sure why I didn't see this before, but I noticed after clearing caches, the error doesn't always appear right away. If I hack the code to check for a string:

 if (is_string($attr_value)) {
 $attr_value = strtolower($attr_value); // Account for G in generator.
 }

The error goes away.

Let me know if you need more details or if I should open a separate issue.


I can confirm this, I upgraded to pip 23.3 this morning, and get the same log with `pip -o -vv`:

WARNING: There was an error checking the latest version of pip.
See below for error
Traceback (most recent call last):
 File "/home/steffen/.local/lib/python3.9/site-packages/pip/_internal/self_outdated_check.py", line 227, in pip_self_version_check
 upgrade_prompt = _self_version_check_logic(
 File "/home/steffen/.local/lib/python3.9/site-packages/pip/_internal/self_outdated_check.py", line 188, in _self_version_check_logic
 remote_version_str = state.get(current_time)
 File "/home/steffen/.local/lib/python3.9/site-packages/pip/_internal/self_outdated_check.py", line 76, in get
 last_check = datetime.datetime.fromisoformat(self._state["last_check"])
ValueError: Invalid isoformat string: '2023-10-10T08:32:05Z'


This is due to #12006 and was apparently discussed in the PR.


I'm assigning this to 23.3 to keep track of it as an issue caused by the release. This does not mean I intent to do a patch release for this at this point.


Hi folks. Please don't add "me too" style comments here. If you are affected by this issue, add a 👍🏽 reaction to the first comment.


Ce n'est pas le champ 'name' qui pose probleme en temps que tel. Le serializer de la liste se sert de la proprieté name_display, qui affiche un lien et une icone en fonction de plusieurs attributs. le nom, le statut publié etc. dans le cas ou le service n'est pas publié, il va regarder la propriété self.type.review, Or un type de service n'a pas d'attribut review (différence entre PublishableMixin et BasePublishableMixin). Donc çà ne marche pas pour les instances ayant des services non publiés.


Hi @dddpaul, the team plans to spend time on this in our current iteration. There's a chance that we can fit a solution in the upcoming patch releases, but we cannot promise this.

We'll need to consider different solutions. For example, the proposed cache reduces the load on the system in most cases but will not remove the problem completely. Alternatively, ideas like #12560 could help but come with other downsides. The developer(s) working on this issue should consider whether caching is enough or whether another solution might be more fitting. As this is not yet clear, it's possible that a solution will not be ready before the upcoming patch releases. However, we plan to spend time on this issue now.


Thank you. I appreciate what you are doing.

"Do you know if the site is "protected" by a CDN or something like that?"
I do not know - I had to lookup "CDN".

Each time, Zimit took a long time working on the site before issuing the
Failure.

Dave

On Mon, Oct 16, 2023 at 9:14 AM benoit74 ***@***.***> wrote:


Another case this error happens but isn't described here is when you downgrade from 23.3 to 23.2.1.

Which I had to do today to test an issue I am facing today to see if it's the Pip upgrade or something else, and reading the PR I predicted would be an issue.


Oups, si je comprends bien c'est donc mon code qui a tout cassé ... :grimacing:

L'idée du ticket #1669 c'était justement d'enlever cet attribut `review` qui n'avait pas de sens sur le model `servicetype`. Par contre ce que je réalise c'est que j'ai fais le travail à moitié, j'ai oublié de supprimer le code que tu as pointé dans ton commentaire @submarcos .


Also, just a pedantic suggestion... If it is a warning, do not put "error" in the message.
I do some error detection when installing Python packages and the "error" text in the warning caused other issues.


Based on some replies at URL and URL it seems like this might be a current workaround:

 --config-setting="--global-option=--verbose" .

which seems pretty unpleasant but at a glance at least it doesn't look like there would be any delicate quoting issues.

I guess a longer term solution would be to try to switch to use `build` instead, but I am not sure up front how involved that would be.


This seem like maybe just a change to `find_packages` config, e.g. just add `legate.core._lib`. Right now there is a wildcard but maybe that does not (or recently does not) include "private" underscore dirs by default (speculation at this point)


Our team is also facing issues due to this, our CICD pipelines are failing. We have to downgrade pip for reasons but when we do, it throws that error message when we are using devops ubuntu agent.
Even when I tried to pin the version to 23.0.1 both in Devops agent and in our "requirements.txt" to install for our internal library, I faced this error message (which is strange as this approach worked when I tried it locally):
image


As a workaround, setting a `PIP_DISABLE_PIP_VERSION_CHECK=1` environment variable may help.


I have one idea on how this might be supported. I can confirm this is on both Forge and Fabric, and 1.19.x does not work either.

It will probably involve adding a "catch" for injections around certain HUD elements. This mod injects AFTER the renderHotbarItem calls in renderHotbar.


I would recommend in CI/CD pipelines anyway, the chance of this failing is non-zero and not useful when it does.

I think, although haven't checked specifically, the issue when you downgrade is the new datetime format is trying to be parsed by the old parsing logic. I believe running `pip cache purge` will delete the offending cached version but obviously cleans everything else, you can also go into the Pip cache directory and manually delete the JSON file.


I'm not really sure the answer to this one yet. Perhaps it has something to do with its custom Iceberg library. It seems to use that for `drawGradientRect` instead of `fillGradient` from DrawContext or DrawableHelper. That could have something to do with it, my best guess right now.

At the end of the day, this is all stuff that I am unfamiliar with, so my recommendation for now is to just use <=2.x for now.


Okay, I rewrote their mod (never submitted that previous comment so its why its like from a minute before this one) to use the vanilla gradient stuff and that wasn't it. But then I looked around and traced the methods back and bam it hit me like how did I not notice that before.

image
So it doesn't use the stack for the hotbar. I don't know why, but that is the source of the issue here. It is creating a new stack. If you were to make it use the stack (like I did in that screenshot), it would work. This would have to be fixed on their end.

image


The reason this is not an issue with 2.x or earlier is because Raised worked differently back then. Raised modified the Y value which was inherited down the line all the way to the hotbar item's render method which this mod took its Y value from. Now Raised translates the matrix stacks instead. This mod does not use the stack for the hotbar for some reason. The two ways cannot be done at the same time or else it would just double the vanilla stuff.


Removed package selection option and we no longer need to save SDK packages in data verse when onboarding a product to release plan.


From @yuisotozaki :

Here's the preview of the messages:

Scenario 1 - When a user attempts to edit or request refund, if the following conditions are met:

a. the request is in examination or has been examined but the screen the user is viewing does not yet reflect this state,

b. OR the request is being editing by another user.

Message: Please refresh the page or try again later, as there may be simultaneous updates in progress. This can happen if a name examiner is examining this name request. This can also happen if there is another user making changes to this name request or there is another tab on your browser with this name request in edit mode.

Scenario 2 - When a user is about to confirm the NR content and go to payment, to avoid duplicate request, an error shows up when the following conditions are met:

a. there exists an NR requested by the same user,

b. AND all the names exact match the names of the current request,

c. AND in pending for review or payment pending status.

Message: You have already created an identical name request. To request a different name, please go back and change the name to request and try again.


Thanks, this worked for now as a workaround at least to unblock pipelines.


Bonjour, un fix est publié dans la version 2.101.2, merci d'avoir remonté le problème


@manopapad regarding the error from the datetime check in `pip`, this comment suggests setting `PIP_DISABLE_PIP_VERSION_CHECK=1` as an immediate workaround (and also maybe a good setting for CI environments in any case)


Regarding the `global-option` I don't see where we are setting that ourselves anywhere, and it looks like the immediate preceding command is

 [220/221] cd /home/mpapadakis/noneditable/legate.core/_skbuild/linux-x86_64-3.10/cmake-build && /home/mpapadakis/noneditable/env/bin/cmake -P cmake_install.cmake

so I suspect this issue may actually originating in scikit-build


No, AFAIK these should all be used exclusively by cython.

Do you mind making a PR with this, and asking @Jacobfaib to verify it's good?

Presumably the bug has been fixed URL so I'm inclined to just leave this alone.


@argiepiano Thanks for the PR! I'll be taking a look at this shortly. Can either you or @dgbruns provide some steps to reproduce the problem?


Thanks for the data @nitroed01, I'm able to reproduce the issue. Not clear yet where the problems are, I'll investigate.


Another workaround is to delete the pip cache - on Linux this is in `~/.cache/pip`. Pip 23.3 works fine with no warning after you do this.


@quicksketch - just sent over some info and json config. The gist is that I am testing the 'Article' type only at the 'Content' level in Metag with the patched version of Metatag that uses backdrop_render.

It seems that the error above happens when pieces of the json-ld array (the sub-arrays for persons and organizations) hit strtolower.


Anyone know if this issue was resolved with the Retro Gem? I would assume it was but haven't read anything to confirm.


Doubt it. N64 RetroGem = N64 digital. Same device just different branding.


From what I saw in this thread it was confirmed issue was a n64 digital hardware bug. Pixelfx were selling a flex cable specifically for n64digtal, but i see no mention of it for the retrogem.
As for N64 RetroGem = N64 digital. They use different firmware. Also the hardware design and components are not exactly the same. Pixelfx were aware of this bug. Hence why I'm curious if it was taken into consideration. I'll ask on their discord.


As there are several easy workarounds I'm not rushing a patch release.

I plan to do one after the fix for #12361 has landed.


You're right, here it is URL

If you know how to fix this, can you please submit a PR against Legion?


I've already been looking at a few different approached but unfortunately no success yet, the build dir is not getting communicated and results in a compilation error for a missing header


I have tried a bunch of various incantations with `--config-settings` but none have worked. AFAICT it comes down to this bit inside `legion/bindings/python/setup.py`

python
# Hack: I can't get initialize/finalize_option to work, so just parse
# the arguments here...
parser = argparse.ArgumentParser()
parser.add_argument('--cmake-build-dir', required=False)
parser.add_argument('--prefix', required=False)
args, unknown = parser.parse_known_args()
sys.argv[1:] = unknown

*What I think the case is*: to the extent that `--config-setting` can be used to tunnel `--global-setting` through to `setuptools`, that *won't happen via command line options* to an actually invoked-as-script `setup.py` (i.e. handling `sys.argv` here would no longer be effective).

printing `sys.argv` in the the `setup.py` seems to confirm this:

 ['setup.py', 'bdist_wheel', '--dist-dir', '/tmp/pip-wheel-4nb3s7fa/.tmp-i2j3txai']

One way to work around this would be to rely on env vars instead of command line options. This is actually what the folks on DPO Packaging advised me on another project in the last year. But before embarking on that, I guess I'd like to know if there is any expected movement on larger efforts, i.e. IIRC there was some talk of switching legion to `scikit-build` or something.


From @yuisotozaki

Hi Eve, the design team spent a good chunk of time reviewing the scenarios and I have a new text for scenario 1. The designers were OK with scenario 2 proposal.

Scenario 1 Title
Changes Temporarily Unavailable

Scenario 1 Message
Another user may be making updates to this Name Request and this action is unavailable at this time. Please try again later. Typical reasons are as follows:

- Another user may be editing this name request
- BC Registries staff may be currently reviewing this Name Request
- Status of this Name Request has changed


Hi @bobcolner, thanks for making this feature request! This is a great callout - we're currently exploring different ways to address the panel real estate issue and will provide any updates here.


Same issue here. I've found that some workspaces (such as selecting the parent directory) appears to avoid the issue. The "Cannot reconnect. Please reload the window." error only occurs when you actually select a kernel. I don't have any .vscode configuration in either of these workspaces, so I'm not really sure what the issue is.


There is an ongoing discussion about transitioning Legion to a more standards-compliant build workflow URL so let's hold off on doing drastic changes.

In that case, I think all the warnings have been sufficiently addressed (or punted), so I'll close this.


Hello,

I confirm there is an issue most probably linked to some form of protection against denial of service on the website, and this prevents us from proceeding with the content retrieval.

I tested on a server and on my desktop and got the following result:
- I get a systematic error (HTTP 405) on my server machine (even with simple commands like curl, even when I pass a proper user agent)
- it works well on my desktop

I suspect this is linked to some kind of ASN / IP filtering.

I will confirm with the team what we usually do in such a situation.


It is indeed worse than expected. It does not work anymore on my desktop machine. Looks like protection is pretty aggressive.


Naturama and FIMUS has an old version of Specify. While the requested subviews were added to them, minor configuration will be necessary after server move.


@ssefick Thanks for your patience! I sometimes think that we've got used to systems sending push notifications, memory seems to need more support.


OS customisation is now accessible without a keyboard shortcut (and Ubuntu server is in the standard OS list with customisation enabled)


You can use `pip cache info` to get details and `pip cache purge` to clear the cache, no need to hunt for the location 🙂


After downgrading to VSCode 1.83.0, I'm still facing the same issue


You need to first remove the .vscode_server folder on the remote server, then reinstall vscode on your local computer with the older version, and then reinstall the extensions on remote server (Python, Jupyter, etc.). The problems go away after I did these steps


This seems to be working for me. I just fixed an automation I had working.


I'm seeing the same problem when connecting to Remote-SSH as well as WSL. occurs in both "code" and "code-insiders" (from MS App Store). Specifically occurs for me when attempting to "Select Kernel".


I was able to test New-PnPUPABulkImportJob with Managed Identity in Automation Account in Azure and it works fine that way too


Ok, Thanks for looking into this for me.

I appreciate your time.

Dave

On Thu, Oct 19, 2023 at 1:58 AM benoit74 ***@***.***> wrote:


`pip cache purge` doesn't completely purge my pip cache:

ubuntu@raspberrypi1:~$ pip cache purge
Files removed: 208
ubuntu@raspberrypi1:~$ ls -la ~/.cache/pip/
drwxrwxr-x - ubuntu 8 Aug 2021 http
drwxrwxr-x - ubuntu 16 Oct 09:17 http-v2
drwxrwxr-x - ubuntu 13 Oct 17:27 selfcheck
drwxrwxr-x - ubuntu 10 Sep 14:22 wheels

However, `rm -rf ~/.cache/pip` did completely purge the cache and it also fixed the pip version check warning (error).


FWIW, the targeted cleanup step here is to delete the selfcheck directory within the cache.

rm -r $(pip cache dir)/selfcheck


The underlying issue is that a key-value pair in a JSON object, placed in a JSON file in that directory contains a value that can't be parsed by this version of pip, when generated by a sufficiently old version.

Deleting the directory removes specifically the problematic files, which resolves this issue.


I think I can guess the reason. The state file in the selfcheck directory must have contained an "invalid" ISO date and time format that included a trailing Z time zone.

I no longer have a copy of the old selfcheck state file, but the new state file contains an ISO date and time format that has a trailing "+00:00" time zone that Python 3.10 can interpret:

ubuntu@raspberrypi1:~$ \cat ~/.cache/pip/selfcheck/241e69162522ccf5846a2f42ebc24b17464915a155679666b89a9f31
{"key":"/usr","last_check":"2023-10-19T19:47:38.472420+00:00","pypi_version":"23.3"}


@facelessuser actually I cannot get the solution to work, I created the tools folder locally and can never get mkdocs to find the extension. I found a recommendation to use `python -m mkdocs serve` which got rid of the error but the processing never actually occurred. I even put the collapse_code.py in my package folder (i.e., in pip) but still no luck even after getting it to past the error.
I feel like I am missing something basic.


I did some more research and it looks like I have to use the Blocks feature, is there a way to do this without using Blocks?


@facelessuser no specific reason other than its not something I am terribly familiar with. In this case its a syntax I am using just for the collapse code. Regardless, thank you for the help, much appreciated :)


Well, you are free to write your own plugin instead or use raw HTML that matches what the CSS expects.


Thanks @argiepiano and @dgbruns. I've reproduced the problem with the `schema_metatag` module.

@dgbruns I think your little fix is also totally okay.

I'd like to have automated test coverage for the variety of situations we're putting forward, but it seems like the Metatag module tests need some work. I'll put up a combined PR that includes URL plus @dgbruns's fix, and if possible, some test coverage.


affected partition stability in an incident URL
2 partitions got overloaded with message subscription create commands and the backlog was growing at a higher rate than the processing


I diagnosed this a bit further.

This morning I can request the website via curl again, so clearly there is some kind of active protection.

I achieved to start the website crawl (which is the first phase before creating the ZIM) successfully by passing a User Agent.

@DaveD5501 : could you please try again to request the ZIM on youzim.it and use the "advanced option".

image

In the option named "User Agent", input a valid User Agent from a Browser. You might for instance use mine which is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Safari/605.1.15" (without the quotes).

image

This should be enough to make the crawl start successfully, I will monitor this, should it fail I will keep you informed here.


I just encountered the same issue. When I was selecting the Jupyter kernel, the SSH connection began to disconnect. At the same time, I noticed through the 'htop' command in the terminal that the CPU usage began to spike significantly as the SSH connection was interrupted.


I have the same problem since yesterday. I can work on other files via vscode ssh connection. However, when I open any Jupyter notebook, it asks for the password again and the connection times out.


Same issue here, specifically when saving-as a new notebook created with the "Create: New Jupyter Notebook" shortcut. Breaks my connection to WSL in every open window. Only quick fix I've found is to restart VSCode entirely


Have the same problem, but neither reloading, nor reinstall made any impact.


I tried it again using your User Agent setting. Rather quickly, I got a
failure "Youzim.it task 84262 failed".

Thanks for your efforts.

Dave

On Fri, Oct 20, 2023 at 1:25 AM benoit74 ***@***.***> wrote:


Discovered the solution that worked for me (**local**: macOS Ventura 13.6, M1, **remote server**: Ubuntu 22.04.3 LTS x86_64).

1. Backup `settings.json` (if you've made any local configurations).
2. Close VS Code locally and remotely.
3. Completely delete VS Code from your local machine via steps in #42603103.
4. Deleted VS Code server from your remote server via:
- `sudo apt purge code` (deleted VS Code from your remote server)
- `rm -rf .vscode-server` (delete VS Code server folder from your `$HOME` directory)
- `sudo apt autoremove` (delete everything that have not been previously deleted including all dependencies of VS code)
!!**NOTE**!! use this command carefully as it will erase all dependencies that have not been deleted previously from your system.
- _`rm -rf .ipython`_ (perhaps this command is not required, but I executed it in the pipeline)
5. Download version of July 2023 (version 1.81) on your local machine.
6. !!**Disable**!! as VS code make autoupdates in background #50162685.
7. Configure clean VS code as new one (copy `settings.json`, install required extensions, etc.)
8. Establish remote connection with your remote server via ssh from VS Code toolkit.
9. Install all extensions that are required on your remote server.

Again, this solution worked for me, but I cannot assure that it will work for all mac users.


Yep, similar to my solution on windows or linux above. The important thing is to delete the .vscode_server folder from remote and uninstall local 1.83.1 vscode, then downgrade to 1.83.0 and reinstall everything on remote. It sucked because I have to use about 10 remote servers daily.


I'm having this exact same issue, also when ssh-ed in. I can also execute the notebook through code - it's only when it's brought up on the VSCode UI that the disconnect occurs.


This is also happening on version 1.82.2 on a remote connection to a Ubuntu 22.04 host.

- Open ipynb with extensions disabled -> fine
- Open ipynb with extensions enabled -> Crashes right after activating extensions, before even selecting kernel
- Have tried deleting all extensions and reinstalling them, worked shortly at one point but then started crashing again


Although this can be done with the HTTP `Link` header (per Google documentation), I don't think that's the intention of the current code, which intends to an HTML element.

It looks to me like the problem here is a mismatch between `metatag_html_head_alter()` (where the canonical tag is removed) and `metatag_preprocess_page()` (where metatag adds its own tags). The current code is striping out both the canonical tag added by core, and the canonical tag added by metatag, resulting in no canonical tag at all. If the "Always output canonical, shortlink, and generator meta tags" option is disabled, you actually end up with _two_ canonical tags right now.

In `metatag_html_head_alter()` we have this code:

 // Do not remove meta tags provided by Metatag.
 if (strpos($key, 'metatag_') === 0) {
 continue;
 }

But in `metatag_preprocess_page()` no keys are prefixed with `metatag_`. I'll file a PR to fix this specific issue.


Fixed in URL I'm going to follow-up with test coverage in URL


This is a duplicate of URL and we are working on a fix now. Let's track this in URL thank you!


I'm very sorry about that, there is a bug in handling parameters values with spaces.

We will have to fix this before you can proceed, you can track this upstream here: URL


We figured out it was caused by Pylance extension killing the remote extension host process (see details in URL The Pylance team has fixed this issue in Prerelease and it working on a recovery release for stable. To mitigate/workaround this issue before the fix lands:

* Open an empty Remote SSH window (Remote indicator -> Connect to Host ... -> Pick the remote)
* Downgrade the Pylance extension to previous version (a week ago) or disable it for now

We will keep you posted once there is a new Pylance release.


Oh, no, I'm wrong, parameter without quotes is processed properly.

It is just that the User-Agent value is still not working. I will have a look at it on Monday, I suspect I already know the reason.


Ok, thanks for the update.

On Fri, Oct 20, 2023 at 1:27 PM benoit74 ***@***.***> wrote:


@argiepiano I see your point about needing to support `#attached` in `BackdropLinkMetaTag` and possibly other places to add HTTP headers, but I'm also looking at `schema_metatag` and it looks as though the pull request here is not required for that module to function properly? I filed a PR at URL that makes `schema_metatag` return the element directly, without using `#attached` at all. And while I think it's still important we figure this out for other tags, I think `schema_metatag` might be better off if it uses the simplified syntax.


I checked metatag's handling of `#attached` and it looks like it already works correctly. There was a separate issue with Canonical not working #109, but with that issue fixed I have confirmed that the HTTP `Link` header already works properly. The `X-Generator` header is another example of a metatag that exists both in HTML and in the HTTP header. I added test coverage for both in a PR at URL

So in summary to fix this issue, I think we need to do both of these things:

1. Merge URL to make `schema_metatag` act like other metatags.
2. Merge URL which includes @dgbruns's fix and test coverage.


I have never encountered this problem. I assume the other tooltips in the lower region (audience, betty...) do not stop working at this point? Basically, they are all treated identically wrt. update and rendering...
Even if you turn off the TV, you don't get the tooltip for "turning it on again"?


Perfect, and I see you merged URL I've merged URL as well and I'll make a new release shortly.


Let's consider this issue closed by:
1. URL
2. URL

The follow-up work will be tracked here: URL


That's very unlikely. This is an isolated **single HEAD request** that happens prior to the crawler staring and then emitting as much requests as it can, using an odd User-Agent.
Keep in mind that an enormous share of Internet users use a shared IP address with their colleagues, household, or ther devices (phone), etc. I'd eat my arm if it was the reason for #224 😅

Absolutely.


By fixing #226, I finally got the real issue, the server does not like our check of the root URL:

failed to connect to URL 406 Client Error: Not Acceptable for url: URL

Fixing #227 will solve the issue.


While doing this, we may also consider making a `GET` request, stopping after the first bytes received. Some web servers don't implement HEAD and the scrape would fail for an invalid reason.


I hope you are hungry, because I reproduced the issue 🤣

406

And then from this point, any requests (curl, python, whatever) from the same machine (IP, I imagine) fails with 405 errors.

From a different machine:

200

200

Tada ... (yes, I hate this behavior, but I suspect this might even be the root cause of some situations of #185)


Planning:

- Time box 8 hours to propose a solution/breakdown for this

@oleschoenburg and @deepthidevaki will look into it in the next two weeks


😨 Not so fast, the problem is not the one I quoted (ie. different UA from same IP) but the fact that any request with a `python-requests/` prefixed UA blacklists the IP for some time

py
In [1]: import requests
 ...: resp = requests.head(" URL headers={"User-Agent": "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0"})
 ...: print(resp.status_code)
 ...: resp = requests.get(" URL headers={"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X x.y; rv:42.0) Gecko/20100101 Firefox/42.0"})
 ...: print(resp.status_code)
200
200

In [2]:


You are right, sorry 😉

But this still needs to be fixed, and this is still very aggressive (I now know how to prevent a whole company/campus from accessing some websites, just do one HEAD request with `python-requests` UA from their public web browsing IP ...)


Not sure if this is the right place for this note, but `std::env::current_exe` in a `Zscript` script returns e.g. `/home/rhart/.cargo/target/51/634a27a4e923f1/debug/build-`, which isn't very intuitive. `current_exe`'s doc allows for returning a "platform-specific" path in some cases, so it seems it might be nice to return the path to the script being invoked? Not sure if it's possible to override that behavior for scripts.


@novafacing could you create an issue so we can discuss the ins and outs more easily than interspersing in the tracking issue or RFC?


Just curious, but would incremental compilation work with single-file scripts (maybe it can be cached inside `~/.cargo`)? Or would it always be re-compiled from a scratch?


I'm thinking abbot another suggestion..
When we use templates we can put the properties of the entity..
then we put the steps on the template.. to create new repo or push a file etc...

I wonder if is a great idea to use the templates as a structure to edit a entity..
the way i saw this, the editing page will be similar to the create template..
the editing fields will be the same fields as the create.
(if for some reason the editing has more fields, or some fields are different, this can be solved with dedicated template YAML, OR as a new parameters on the existing template. like "editing_parameters: " and "editing_steps:")

I know that backstage has a route to return a entity data, so the entity fields that are store on the database are display on this editing page. the UI can be customizable by using the "editing_parameters:" on the template..

After the user make the changes the entity can be validate and... if everything is right.. this will RUN the "editing_steps:"

For me this make sense, most of the tools to make this backstage have, like: route to validate a entity, steps to push files to a repo, and the UI..

On my take this is "basically" re-create the create page but using different parameters and steps or even a different template.yaml, the KIND and TYPE on the entity will be the key to determine what "editing template" to use...
And the steps will be customizable to.. almost the same as the normal template.

this make sense?
(English isn't my main language, so feel free to ask something)


@eve-git
Scenario 1 updated as requested
image

Scenario 2 - updated as requested
image


Each cargo script keeps a target directory in `~/.cargo/target` with a path determined by a hash of the file path. This makes it so performance optimization done for a regular package would work here, including incremental compilation


I'm implementing the following application side improvements, and hoping to make a PR soon. (more may be added to the list)
- Adding app-side support for the Solr-size circuit breakers. Enabling those makes Solr start dropping requests with 503s (instead of dying) under heavy load. As currently implemented however, the page does not detect that condition and doesn't handle it in any special way, and simply shows zero search results/empty collection page. It needs to show something intelligent, along the lines of "search engine is experiencing heavy load, please try again later".
- Optimizing the second search that the page repeats solely for the purpose of populating the type counts facets for the _unchecked_ types. There is absolutely no need to repeat the **same exact search**, with all its super expensive parts, like all the other facets. There's no need to search for anything other than these one or two total counts; or to even run this second search, if all 3 type facets happen to be checked.
- Adding `nofollow` to all the facet links and such, that we don't want crawlers/bots to touch. This will obviously only help with the nicer bots that take hints and follow rules, but better than nothing.
- An off switch for facets support on the dataverse page. Again, facets are super expensive; it should be far better to be able to display the page with just the search cards and "facets are temporarily unavailable because of load issues" in the left column, than to have an empty page/have a "solr down" error page/have the page load take an hour.


For Scenario 1, there is an extra line above "For assistance..." that should be removed. Low priority though.


Update from McAfee: It took longer than expected to push the release with the fix out, but it is finally deployed to production.
It will take about 2 weeks to rollout it to most of our users.
Please note, with the current implementation after system restart the very first launch of VS Code will be still slow, this will be addressed with our next release in the first half of November.

Thus I am closing this issue as done 👏 Thanks everyone for the patience.

@joaomoreno we can keep it pinned for 10 more days until the McAfee rollout is completed.


My solution is downgrading the jupyter extention to v2023.10.1002931100 (but I dont know my last jupyter version, just downloaded the second version from vscode office website), that works for me.


@DaveD5501 now that code has been merged, could you please try to request the ZIM again (no additional parameter needed anymore, just provide the URL)? I tried to start the task and it worked well, not sure it will complete successfully but at least it made much more progress than before.

Thank you for your patience (and thank you for helping us fix all these issues, we made a good progress)


I thought we agreed to keep Html and Unicode versions based on what @Jamie-SA said about the likelihood of using them in the foreseeable future. See #531 and #959.


If we decided to do this, why did we just create #992
See also #959, #579


Hi @chr-fritz,

We've recently merged some changes (PR #676) that updated our monitoring implementation and added additional logging. I understand that you aren't able to reproduce this consistently, but would you be able to check out our snapshot build with driver logs enabled (logs can be enabled as seen here) and let us know how that goes?

Thank you!


Hi All , try below command . replace package name with required package

pip install xxx -vv --disable-pip-version-check --no-cache-dir --trusted-host pypi.org --trusted-host files.pythonhosted.org


I see the confusion. #992 should be entitled "Deprecate `gist:symbolHtml` and `gist:symbolUnicode` once the names have been changed in this issue. I'll clarify that.


I didn't think we reached a conclusion on this. There is the possibility of implementing them in the SA ontology. It depends on whether we consider the need for them broad enough to include in gist.


Success! I have my ZIM. I clicked around enough to verify the results.

It took 12 hours and finished overnight. I watched it wait for a slot for several hours - so the long time to complete might have been due to slot availability.

THANK YOU very much.


Fix possible mergé. Je sais que c’est plate à faire mais clean install redonnes-moi des nouvelles?


Great it finally worked, and thank you again for reporting this and for your patience, it helped us solve an issue probably faced by other users.


And btw, yes, the 12 hours is just "bad luck". There was other requests in the pipe, and lot of them also took significant time to complete ; you could request it down it would start immediately to process ^^


There was an L1 blocker again because of this URL

Handled by @npepinpe


I have this same problem when I was trying to build my project via AWS Ampify. It is serverless so I guess there's no way for me to add my ssh key there. (The repo I used is a private repo of mine, though.) Does anyone have the solution for a serverless service like that?


Hello and thanks for the app,
I came here because we also need this feature. In our case, the communication team needs to edit the forms that other teams make.
Thanks a lot and have a good day :)


It happened again.

ESC menu is still working as usual.

The other tooltips in the lower center info region are working.

*That* led me to another bug: URL


Kindly assign the below issue to me.

local_response_norm #27187