Fails to run when python3 is default on system

This computer has python3 as the default python runtime. Trying to run bugjar triggers this error:
    from Tkinter import *
ImportError: No module named 'Tkinter'

From what I can deduce this is because with python3, Tkinter should be all lowercase, i.e. 'tkinter'.

I'm also experiencing this issue :+1:
Traceback (most recent call last):
File "/usr/bin/bugjar", line 9, in
load_entry_point('bugjar==0.1.0', 'console_scripts', 'bugjar')()
File "/usr/lib/python3.4/site-packages/pkg_resources/init.py", line 558, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3.4/site-packages/pkg_resources/init.py", line 2682, in load_entry_point
return ep.load()
File "/usr/lib/python3.4/site-packages/pkg_resources/init.py", line 2355, in load
return self.resolve()
File "/usr/lib/python3.4/site-packages/pkg_resources/init.py", line 2361, in resolve
module = import(self.module_name, fromlist=['name'], level=0)
File "/usr/lib/python3.4/site-packages/bugjar/main.py", line 4, in
from Tkinter import *
ImportError: No module named 'Tkinter'


scoped_routes not effective?

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
<EMAIL_ADDRESS>where the issue will be triaged appropriately.
Title: One line description
Description:

Describe the issue.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: httpconnectionmanager
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: GATEWAY
      listener:
        portNumber: 8080
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: MERGE
      value:
              name: envoy.filters.network.http_connection_manager
              typedConfig:
                '@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                scoped_routes:
                  name: test
                  scope_key_builder:
                    fragments:
                    - header_value_extractor:
                        name: X-Header
                        element_separator: ";"
                        index: 0
                        element:
                          separator: "="
                          key: test
                  rds_config_source:
                    ads: {}
                    initialFetchTimeout: 10s
                    resourceApiVersion: V3
                  scoped_route_configurations_list:
                    scoped_route_configurations:
                    - on_demand: true
                      name: test1
                      route_configuration_name: "http.8080"
                      key:
                        fragments:
                        - string_key: test1
                    - on_demand: true
                      name: test2
                      route_configuration_name: "http.8081"
                      key:
                        fragments:
                        - string_key: test2
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        portNumber: 8080
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
            subFilter:
              name: "envoy.filters.http.router"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.on_demand
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.http.on_demand.v3.OnDemand

I have http.8080 route ,but return 404
[root@node01 ~]# curl http://<IP_ADDRESS>:32406/productpage -H "X-Header: test=test1" -I
HTTP/1.1 404 Not Found
date: Sun, 17 Oct 2021 07:17:00 GMT
server: istio-envoy
transfer-encoding: chunked

[optional Relevant Links:]

Any extra documentation required to understand the issue.

Hi, does it work without the on demand filter?


A section to show upcoming releases with tentative timelines to track new features.

Summary
It would be great to make it clear to the TTS Users about the upcoming features and tentative ETA for the availability of them in V3.
Why do we need this ?

Currently, we are suggesting to the users to track the features through the GitHub links. However, users are requesting the ETA of the new features.
It would be easy for us to set their expectations on the timeline for releases, and it helps users find the latest upcoming in The Things Stack.

What is already there? What do you see now?

We are tracking new features through individual GitHub issues.
Also, there a Release Notes section for the current releases and past releases information. https://www.thethingsindustries.com/docs/whats-new/

What is missing? What do you want to see?
Consolidate upcoming features and their tentative ETA  in The Things Stack documentation.
How do you propose to document this?
...
Can you do this yourself and submit a Pull Request?
No. @benolayinka

I don't think this is going to happen. @NicolasMrad you would be in charge of creating these timelines if so, what are your thoughts?

Currently I don't think is a good idea (and it won't be that efficient). Users should just stick to checking our github for 3 main reasons:

When they check the issues on github, they can add their comment or add a new issue that they might think of that we haven't included it yet
Most of the times we push features to new milestones, or we modify them or just keep them in our current milestone just to keep an eye on them. Some critical features are decided before the release date by a week if they will implemented or not. So we can not commit to a 100% accurate ETA for a certain issue, there a lots of variables
Issues are in milestones, and milestones have a release date so users can know when a feature will be basically implemented from the release date.


[system][Box] Specify with which component it renders by default

When we look at the documentation on the Box API page, the default value for the component property is not specified.
It would be nice to specify it. I never remember whether it is a <div> or <span> that is rendered by default.
But it is actually a div.
We can see it in the following line: https://github.com/mui/material-ui/blob/a1005d6cedcba5731cbf8f0c4837229432ec8d38/packages/mui-system/src/Box/Box.d.ts#L201
Confirmed by this codesandbox.

@brijeshb42 + @siriwatknp just checking whether we need to run any specific commands given a prop description has been changed on the source code of the Box?


(Maybe) change/overhaul the plotting mechanic

Currently have a catch-all plot() function for profiles and sprof classes. The first input of the plot function determines which plot gets made, but also makes keyword arguments a bit complicated, tedious, and difficult to document.
Change that I am thinking is not to remove this, but alias the plots into specific other class functions that could be called on their own if you wanted. So for example sprof.plot('gains') would be equivalent to sprof.gainplot(). This would allow me to re-direct documentation to the specific function, but still leaves the catch-all function.
At the very least I will do the above. I may also just completely get rid of sprof.plot().

Update: low priority right now, will seek feedback on what seems most natural to users later on.

Added wontfix label but leaving the issue open because eventually I think this may be a worthwhile development.

Closing this for inactivity. Will change the plotting mechanic as needed as I use the package operationally now.


Replacing Secrets Manager to SSM to store Grafana API Key

What does this PR do?

🛑 Please open an issue first to discuss any significant work and flesh out details/direction - we would hate for your time to be wasted. Consult the CONTRIBUTING guide for submitting pull-requests.
Motivation

More

[X] Yes, I have tested the PR using my local account setup  (Provide any test evidence report under Additional Notes)
[X] Yes, I ran pre-commit run -a with this PR
[X] Yes, I have added a new example under examples to support my PR (when applicable)
[X] Yes, I have updated the Pages for this feature

Note: Not all the PRs required examples and docs.
For Moderators

[ ] E2E Test successfully complete before merge?

Additional Notes

Will merge this into my branch so I can complete E2E tests


⚠ ClamAV has degraded performance

In db21c7b, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 443 ms

Resolved: ClamAV performance has improved in cac7901 after 538 days, 23 hours, 49 minutes.


HTML

HTML
User story:
As a boot camp student,
I want a Prework Study Guide website,
so that I can review all the information I learned throughout Prework.
Acceptance Criteria
GIVEN a Prework Study Guide website
WHEN I visit the website in my browser
THEN I see four boxes titled HTML, CSS, Git, and JavaScript with associated notes listed

Done.


Autozaps are showing in requests

Happened to me and someone else. For some reason I'm just seeing this for autozaps. Wallet loads and the requests are already there, so I wonder if it tried to pay them before the wallet was fully loaded.

This was a zapple pay bug


Is it going to be free?

I really liked the old onivim, and just wanted to ask if the new onivim 2 is going to be free.

It is already. Every commit in this repository is published in the onivim/oni2-mit repository after 18 months under the MIT license.

How do i compile it on windows? I only know a bit how to do it on linux...

There is some info on the license here in the README: https://github.com/onivim/oni2#license
And we have steps on how to compile it for personal use in the User Manual: https://onivim.github.io/docs/for-developers/building
Public builds are coming soon-ish, we just didn't have them out to start with to help keep the amount of feedback and support requests to a reasonable amount.

What exactly does soon-ish mean? Like in a few weeks, months, years?  I only understand like half of the stuff -.-

Figured it out!


JSON API HTTP error codes

Intention
Our intention is to use HTTP status codes to transmit information when there is a reasonable expectation that intermediate server / services between the client and the API may want to create a return with that status. Any time the API service code is solely responsible for generating the HTTP response, and we cannot foresee a situation where that would change, the response should be a HTTP 200 with embedded error objects.
This should be thought of as the responses and status code our API services return, those that may be generated inside the Astra infrastructure but not by our code, and those that may be generated by intermediate HTTP services between the client and the front door to Astra. We need an approach that covers all these situations, and tells the driver(s) how to handle things.
Changes
Situations where the response status code would not be a 200 with an embedded error object:

401 Unauthorized - when the request has not been successfully authenticated, that is the client is not able to connect to the API. While this may currently be generated from the JSON API code, we can imagine a situation where Proxy / Gateway / Frontdoor of the whole astra platform may check that incoming requests are from customers we want to allow in. e.g. we want to blacklist a customer / tenant at the proxy level and not let their requests be processed because they have not paid their bill, or their services have been compromised and they want to stop all access to data.

404 Not Found - when the prefix path to the JSON API endpoint is incorrect, errors to do with missing namespaces or collections are application errors and returned using the 200 code. e.g. the user tries to access the API at /json/v11 rather than /json/v1

405 Method Not Allowed - Attempt to use the wrong verb on an otherwise valid URL, e.g. trying to run a GET

5XX - Two situations: 1) Any response returned by intermediate servers between the client and our front door, such as 503 Service Unavailable. 2) An unhandled or unexpected server side error in the Astra platform, either in the infrastructure or the API code, could result in a 500 Internal Server Error.

This will require to the API specification, the service implementation and tests, NoSQLBench tests. It may also require changes to the Postman collection and other repositories such as stargate-mongoose.

@maheshrajamani can you help coordinate this work including creating other issues as needed?


pass apikey in restassured test

I am trying to pass api key in restassured. From postman, i got the repsonse data using 'X-Api-Key' with value. But with rest assured, i am seeing null pointer exception
Response res = given()
.header("key","55af7bc105c9c2ee98e2abb32979fee")
.when()
.get ("https://mbaseurl/api/v1/search-listings/").then().
extract().response();
I tried passing key value with .header("X-Api-Key", "value") but was not successful

What exception to you see?

testStatusCode:56 NullPointer

What is the key name for passing apikey in restassured?

Could you please provide the full stacktrace?

What is the key name for passing apikey in restassured?

Your question doesn't make sense this is specific to your service (or an authentication scheme that it uses). It's the same thing as asking "what's the way to get an entity out of a database". There's no one way, it depends on which database you're using.

The key name i am using in Postman to get the response is 'X-Api-Key' and value of API key. This fetches Json body along with url. Similarly whats the key name i need to use in header declaration of restassured
.header("???","xyz")
I hope the question is clear now

You should use the same header as in postman. But if it's not working with rest assured I suspect that postman sends additional data to the server. Use wireshark to see the differences.

Is there a way i can check from restassured to see what is being passed like a log data?
Also is my syntax correct by placing the api key in header?
Response res = given()
.header("key","55af7bc105c9c2ee98e2abb32979fee")
.when()
.get ("https://mbaseurl/api/v1/search-listings/").then().
extract().response();

https://github.com/rest-assured/rest-assured/wiki/Usage#logging

Restassured Request data:
Request method:	GET
Request path:	https://myurl/api/v1/search-listings
Proxy:
Request params:
Query params:
Form params:
Path params:
Multiparts:
Headers:		X-Api-Key=xyzee
Accept=/
Cookies:
Body:
Jmeter Request data(fetched the response):
GET https://myurl/api/v1/search-listings/
GET data:
[no cookies]
Request Headers:
Connection: keep-alive
X-Api-Key: xyzee
Content-Length: 0
Content-Type: text/plain; charset=ISO-8859-1
Host: listings-xyz.ch
User-Agent: Apache-HttpClient/4.5.2 (Java/1.8.0_111)

You see that there's a difference right? (path, content-length and content-type for example). Try to mimic the jmeter request in RA exactly.

Now, the issue is resolved and i am getting the values of response.  Also please let me know how can i verify all the key names are present in the response. Like say i have response body
{
"count": "15",
"page": 1,
"per_page": 100,
"data": [
{
"id": "2b81c208a35ce",
"reference": "sergerg123",
"bedrooms": null,
"bathrooms": null,
"habitable": "1'000",
"weighted": "1'000",
"land": null,
"description": {
"en": {
"title": "",
"description": "",
"summary_title": "",
"summary_description": "",
"seo_title": "",
"seo_keywords": "",
"seo_description": ""
}
},
"photo": "",
"main_category": "Flat",
"sub_category": "Flat",
},
Now i need to verify say data[0] and fetch all the values of first data in array. How can i use restassured to fetch them?

Use json schema validation and read the documentation. And please use the mailing list for asking questions in the future.

Hi seema-realforce , could you please help how did it? I m also facing the same issue. Getting status code :401

@sanjay058 Did you resolve this issue? I am getting same 401 now. Can you pls help me in this regard.

@seema-realforce Can you pls help us to resolve this issue?


Add exception handling in WrapsMessageHandlingInTransaction middleware

Hello,
If an exception is thrown in the EntityManager::transactional method, the entityManager becomes unusable for subsequent handlers.
A typical example is when you call the CommandBus in a loop.
We should inject the ManagerRegistry instead of the EntityManager to be able to get a new EntityManager in case of an exception.
We also need to add an option to specify a custom EntityManager. For example, we could inject the name of the EntityManager we want.
The handle method would look like :
public function handle(Message $message, callable $next)
    {
        $entityManager = $this->managerRegistry->getManager($this->entityManagerName);

        try {
            $entityManager->transactional(
                function () use ($message, $next) {
                    $next($message);
                }
            );
        } catch (Exception $e) {
            $this->managerRegistry->resetManager($this->entityManagerName);
            throw $e;
        }
    }

Edit :
Following my example, if we decide to go this road, we'll have to always use the ManagerRegistry to get the EntityManager instead of directly injecting it. I can't find another (and proper) solution at the moment. :/

This has been fixed in 3.0.


[explorer] bug: unable to display big list of aggregation transaction

What was the issue?

Unable to load the significant list aggregation transaction, when there are too many API requests it will have 429 errors.
The explorer will always request mosaic info and namespace for every transaction which included mosaic. It works well in a single transaction, but when coming to aggregation transactions it will have performance issues because it included a list of the inner transactions.

What's the fix?

Instead of calling request every transaction, it will collect all mosaic from the inner transaction, and only make a single request to gather mosaic and namespace info. It will reduce calling API requests, and have better performance.
added new method getTransactionMosaicInfoAndNamespace to request mosaic info and namespace.
added unit test
removed request mosaic info and namespace logic inside mosaicsFieldObjectBuilder

@AnthonyLaw looks good. Big performance improvement for aggregates with multi-inner transactions.


scaleMode not honored when second, different, fromImage invocation is issued.

Say you include a texture from a url and make it gl.NEAREST like this:
PIXI.Texture.fromImage("bunny.png", true, PIXI.scaleModes.NEAREST);

then pixi caches the texture against only the url, so further calls importing the same image from the same url but with a different scaleMode will be wrong:
PIXI.Texture.fromImage("bunny.png", true, PIXI.scaleModes.LINEAR);
// this texture is still in nearest mode

Whichever scaleMode the initial import is done with will last forever.
What's needed is either to cache them keyed against url and scaleMode, or to have some way of changing the scaleMode after the texture has been loaded.
I have searched for the latter and tried everything to no avail. If there is a way to regenerate a scaleMode on an existing texture, I would be most interested (tried unoloadFromGPU, destroy, dirty etc and failed....)

This happens because of how .fromImage() works. It caches textures it creates based on url, so everytime you pass the same url you get the same Texture object back.
Instead, create the image directly:
var tx1 = new PIXI.Texture(PIXI.utils.BaseTextureCache['bunny.png'], true, PIXI.SCALE_MODES.NEAREST),
    tx2 = new PIXI.Texture(PIXI.utils.BaseTextureCache['bunny.png'], true, PIXI.SCALE_MODES.LINEAR);

That way you get two separate textures that share a base texture.
Also, it seems like you are using the v2 way of accessing the scale modes constants, above I used the v3 way of doing it. I suggest you migrate because the v2 methods may not exist forever.

I once had this https://github.com/GoodBoyDigital/pixi.js/issues/620 issue. Its about how to manually decide the names things in your TextureCache end up with, so you could perhaps use it to make a "bunny.png_NEAREST" and "bunny.png_LINEAR"

Imo, the best solution is to stop using the convience methods. Just use the constructors, if you need more than "put in string, get out texture, I don't care at all how it is made" you should use the constructors.

Closing this as it seems resolved. Thanks all! :+1:

This does not seem to be fixed in Pixi V3.0.7
http://jsfiddle.net/j1ujh69e/3/
The texture cache is still getting in the way.
Now, the setting of the second texture filtering mode changes the mode on the first texture.

Hi @retrogradeorbit ,
This is intended functionality. The fromImage uses the texture cache. which returns the same texture each time you use it. This allows for much faster performance as it keeps the number of textures required on the GPU much lower.
What you are trying to do seems very edge case and so the you will need to create your texture in a slightly different way:
var smooth = new PIXI.Texture(new PIXI.BaseTexture('imageURL', PIXI.SCALE_MODES.LINEAR))
var nearestTexture = new PIXI.Texture(new PIXI.BaseTexture('imageURL', PIXI.SCALE_MODES.NEAREST))

thanks

I wouldn't want to remove the cache.
That approach you post doesn't work for me. The textures don't load at all and I just get a blank screen.
http://jsfiddle.net/j1ujh69e/4/
Yes, it is very edge case.

@retrogradeorbit , all good. @GoodBoyDigital just made a typo. PIXI.BaseTexture takes a "source" as its first parameter (so an Image or Canvas object):
var img = new Image();
img.src = 'imageUrl';

var smooth = new PIXI.Texture(new PIXI.BaseTexture(img, PIXI.SCALE_MODES.LINEAR))
var nearestTexture = new PIXI.Texture(new PIXI.BaseTexture(img, PIXI.SCALE_MODES.NEAREST))


WIP-Lbaker/update es 791

Description
[Please describe what this change achieves]
Issues Resolved
[List any existing issues this PR resolves, or any Discourse or
StackOverflow discussions that are relevant]
Check List

[ ] New functionality includes tests
[ ] All buildkite tests pass
[ ] Full omnibus build and tests in buildkite pass
[ ] All commits have been signed-off for the Developer Certificate of Origin. See https://github.com/chef/chef/blob/master/CONTRIBUTING.md#developer-certification-of-origin-dco
[ ] PR title is a worthy inclusion in the CHANGELOG

closing in favor of #2231

closing in favor of #2231


Fix noise analysis for "narrowband" data with no ECORR

In trying to run the process_v1.2 notebook on simulated LOFAR data, @FrancescoIraci ran into an issue (#44) where noise_utils.add_noise_to_model() would raise an exception if "narrowband" data didn't have associated ECORR parameters.
It turns out that this function was written in an unnecessarily inflexible way: with using_wideband = False, it would always try to add ECORR parameters to the model, whether or not they were present in the white noise dictionary returned by noise_utils.analyze_noise(). In this case, not finding any, it would raise an exception. (Similarly, with using_wideband = True, it would always try to add DMEFAC and DMEQUAD parameters, even if none were present.)
This PR changes this behavior to make it more flexible: now, ECORR, DMEFAC, and DMEQUAD parameters should be added if, and only if, they are present in the white noise dictionary, regardless of the value of using_wideband, which now only serves to identify the appropriate noise chain directory. This should make it possible to run the notebook on narrowband data without EFAC, or on wideband data without DMEFAC and/or DMEQUAD.

Hmm. These test failures are confusing. It looks like it's nothing to do with this PR really -- it's failing to create an environment because the available versions of enterprise_extensions, and everything (even the "3.8" test) is trying to use 3.11!

It looks like a GitHub Action thing. @JPGlaser any ideas?


Migrate the image under NPWG Quay repository

The image is still hosted under the original kubevirt org.

Solved via #307


[Bug] fe crash

Search before asking

[X] I had searched in the issues and found no similar issues.

Version
doris-2.0.4-rc02
What's Wrong?
fe crash when doris execute insert with high load

What You Expected?
not crash
How to Reproduce?
no
Anything Else?
no
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Failed to try table detail_err_info's write lock. timeout 10000

我也遇到了这个问题，进行查询某个表A的时候，要获取表A的 write lock，感觉不应该出行这个问题，query的时候要 write lock干什么呢？
类似下面这种：
2024-01-02 11:08:46,873 WARN (tablet stat mgr|30) [Table.tryWriteLock():186] Failed to try table ods_oracle_txtcs_df's write lock. timeout 3000 MILLISECONDS. Current owner: null

Same here.
It happened when I executed the load, occasionally.
Did you find more?


How to make warning of initial value responder more informative?

@xuanxu
Instead of just listing the missing variables, could the message mention the submission template? Something like "Make sure you haven't deleted HTML comments when filling the submission template".
Cc @mpadge

Sure, I can add anything to that message. But I thought it was a message to inform or directed to the editor, more than to the author. Because does the author know how to go back and re-add the deleted HTML comments/missing values?

Good point, I take my feature request back! Thank you!


integrity: block does not equal expected value

Hi,
After a forced unmount due to blocked I/O, I can't remount my UtahFS. Got this error :
integrity: block does not equal expected value
All my data is lost ?
Thank you.

Did you ever delete the local .utahfs folder or anything in it?

Yes I did 😐 all was frozen, so I tried deleting it.
But can't we mount an existing UtahFS without .utahfs dir ?
Le 29 juin 2020 19:48:56 GMT+02:00, Brendan McMillion<EMAIL_ADDRESS>a écrit :

Did you ever delete the local .utahfs folder or anything in it?
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/cloudflare/utahfs/issues/22#issuecomment-651267720

Unfortunately not always. I've documented this in the README now, but the .utahfs directory likely contained data that hadn't been uploaded yet.


Return List objects when scoped to customer

When a customer does not exist this will now raise the correct error.  If the customer does exist it will return a list object.

Awesome, thanks! Will there ever be a case where the Stripe API shouldn't return a list, though?

Do you mean that Stripe::Charge.all should always return a Stripe::ListObject?  That's a good point.  Do you want me to add that to the PR?

That would be great if you could

Fixed in #172

sorry didn't get time.  Seems like you had a more comprehensive solution.


[WFLY-13397] Add the MP config module dependency to the MP REST clien…

…t module.
[WFLY-17695] Add a test to ensure the headers are propagated.

https://issues.redhat.com/browse/WFLY-13397
https://issues.redhat.com/browse/WFLY-17695
https://issues.redhat.com/browse/WFLY-17749

This is going to require a new release of resteasy-microprofile. The fixes are in and I'm working on the release now.

Thanks @jamezp


http pool basePath getter and/or setter?

I'm building a server that uses groupcache, and I would like to be able to conveniently wrap the http pool's handler inside a mux (specifically to add a monitoring status call on the server).
I simply thought of adding a handler func that forwards everything under /_groupcache/ to groupcache's handler. But this will fail if ever the hard coded base path will change.
So I thought of adding at least a getter, if not a setter for the base path. I understand the consistency problem with adding a setter. Will a pull request for GetBasePath() and/or SetBasePath() be accepted?

I just hid this, I'd even be happy if defaultBasePath was DefaultBasePath so that muxer registration wasn't by a copy of the constant.


HCAP-1271: 'Move to archive' bug fix

https://freshworks.atlassian.net/browse/HCAP-1271
HA are now able to move withdrawn participants in hired state to archive

We need Tavy to confirm what behavior should look like here


openresolv not available for ubuntu kinetic

Issue
openresolve is not available for ubuntu kinetic
System:
Kubuntu 22.10
Steps to reproduce
sudo apt-get update -y

sudo apt-get install -y openresolv

This is a ubuntu issue, take it up with them.

Ubuntu has removed the "openresolv" package from Kinetic Kudu 22.10 and relies on "systemd-resolved", which I do not use. As a solution, I have manually edited the "/etc/resolv.conf" file and entered my nameservers that I expected outcome as if I were using "openresolv". After that to avoid any overrides, I used the command "sudo chattr +i /etc/resolv.conf" and the resolver settings are exactly as I need them. They can be checked by simply using "dig A google.com" where you can see which resolver was used in the output. Hope this helps.


Notes and ideas

Ideas

[ ] Add the ability for users to hide an IP address or completely opt-out analytics.
[ ] 🐞 Don't show search input results when returning back from other pages.
[ ] Show GitHub stars if package source code is hosted at GitHub.
[ ] Store pages that a browser has visited and then dynamically present a list of packages and modules on the home page https://github.com/haskell/hackage-server/issues/725#issuecomment-375645114
[ ] interesting metrics https://github.com/haskell/hackage-server/issues/725#issuecomment-375659916
[x] hoogle search widget https://github.com/haskell/hackage-server/issues/725#issuecomment-375816600 Mostly done here https://github.com/visortelle/hackage-ui/commit/1c4b4419c92bbc2f69e3fd856a8b0897c1b1a08f

TODOs

[x] Deployment. - deployed to Vercel
[x] Simple availability monitoring. - should be handled by Vercel.
[x] Data fetching optimizations. Use SSR stuff where possible. Use next.js' swr hook. More: here https://nextjs.org/docs/basic-features/data-fetching#fetching-data-on-the-client-side and here https://swr.vercel.app/
[ ] Highlight code in Hoogle search results.
[ ] Implement error handling react context.
[x] Show loading indicator for SearchInput results.
[ ] "Switch to old design" button.
[ ] Ligatures toggle
[ ] Navigate over the search results using a keyboard. Arrows, Emacs's Ctrl + n/p. Go to the result page by pressing Enter. Hide search results on Esc.
[x] Ctrl + r keybinding for recent searches

TODOs after MVP launch

[ ] Guides content.
[ ] Integration tests using Cypress.
[ ] Careful tests for SearchInput react component, particularly its stateful behavior on page switches.
[ ] Code playground service. Seems like quite a big feature. I see it useful for live examples and to embed runnable Haskell code into educational online resources. Am I the only one here who likes playgrounds?

Need to figure out how many Haskell and estimate server workload. Figure out if haskell.foundation or another organization is ready to provide to compute resources for this feature. Rust playground is supported by a private organization - https://integer32.com/

[ ] Search results client-side filtering. :t servant +:f module. +:f is a special characters sequence here. Looks safe, will see.

[x] Adapt for mobile devices.

[x] Review SEO stuff.

[ ] Styled 4xx and 5xx error pages.

[ ] Store package metrics stats. Uploads, downloads, packages count, etc. It can be interesting infographics in long term.

[x] Embed https://pvp.haskell.org/ content

[ ] Dark mode

Tech debt

[ ] Fix @hackage-ui/react-lib exports mess.
[ ] Remove unused dependencies.
[ ] Simplify npm link development workflow. Maybe switch to lerna.
[ ] Maybe recheck bundle size.
[ ] Global styles?
[ ] Refactor app context

From Gershom B in Slack:

also related though: https://github.com/haskell/hackage-server/issues/986
#986 Implement PackageRank from lib.rs
A very impressive amount of research and thought here: https://github.com/rust-lang/rfcs/blob/master/text/1824-crates.io-default-ranking.md
It would be useful to add this as an explicit metric to sort by. :thinking_face:
https://github.com/haskell/hackage-server|haskell/hackage-serverhaskell/hackage-server | Oct 24th, 2021 | Added by GitHub

Haddock
On JSON format:

https://github.com/haskell/haddock/issues/352
https://github.com/haskell/haddock/issues/1420

Hackage

https://github.com/haskell/hackage-server/issues/986

Some article: https://nunoalexandre.com/2018/02/04/redesigning-haskell-docs
Single Liberal Unified Registry of Haskell Packages
https://mail.haskell.org/pipermail/haskell-cafe/2018-January/128472.html
https://github.com/tfausak/slurp
https://github.com/haskell/ecosystem-proposals/pull/4
https://www.reddit.com/r/haskell/comments/7s58id/slurp_a_single_liberal_unified_registry_of/

Idea : make the suggested searches clickable, such that one can look them up without typing

@ocramz, thank you. It's a nice little thing improvement.
Fixed here: https://github.com/visortelle/hackage-ui/commit/ad61c6fa8e6bac93f0b995ccb733b945fdf36259
Please check, is it what you meant.

What about readmes and chagelogs?

@dpwiz will add soon.

A bit of feedback (in the right place I hope): When searching for a function by name/signature, I find it a bit problematic that initial result view doesn't show the package from which it originates. I know I can expand, but that feels a bit tedious and actually gives me too much information. I would love to just see the name of the package next to the each function.
Specific case: I was looking for withObject function from Aeson package, and I wrote it into the search bar, but then I wasn't sure which one to pick. But maybe this is a bad use case because I should have gone to Aeson package and tried to find that function there? Still, that would require some digging and searching it like this sounds much nicer.
Hope this helps, but certainly take with a grain of salt!

@Martinsos I plan to add scoped search and fuzzy text filtering in found items in further releases.
Hope, it will solve such use cases as this one.
Based on other plans in my backlog, I think it will took about two weeks.

Consider idea 💡

Create a list of common Haskell "scary" 😱 terms like Monad, Semigroup, Monoid, Applicative.

For each term, create a short overview article probably with visual illustrations, example problem, and an analogy of how this problem could be solved in JS or Java.
It should be very brief, links to materials with detailed explanations should be provided.
Store these articles as markdown files in the repository.

When the user types such a term in the search input, suggest to him the overview article at top of search results.

Later this approach can be extended to mini how-to tutorials for search terms like Read a file, SQL, Postgres, Write to file, etc. In other words - things with industry-average engineers deal on daily basis.

It should be something like a GitHub and markdown-driven wiki, targeting novice haskellers audience at the beginning.

Showing these articles in search results should be enabled by default, but optional. Users should be able to disable it at any time.

These articles should be available as a list on a dedicated page.

Writing all these articles seems like quite a big amount of work. I can prepare a list first, then start with a brief article each day. More experienced folks can review it.
Maybe it has the sense to take http://dev.stephendiehl.com/hask/ if the author doesn't mind.
Now it's just an idea. I'm not going to start it tomorrow.

Create a list of "scary" scream Haskell terms like Monad, Semigroup, Monoid, Applicative, etc.
So, Typeclassopedia?

For each term, create a short overview article probably with visual illustrations, example problem, and an analogy of how this problem could be solved in JS or Java.
But in JS...

Well, but how does that concern Hackage, the Haskell package repository?

Well, but how does that concern Hackage, the Haskell package registry?

It doesn't. As well, as search using Hoogle or the Community section that I want to implement on the home page.
Relevant question: https://twitter.com/qnikst/status/1480529992425558017?s=20
I started the project as UI for the Hackage two-three weeks ago, but since that, I decided to switch direction toward - what features a Haskell website should have to be useful for developers on a daily basis.
I'll rename the project at some point in time.

So, Typeclassopedia?

It's a great source of information on some topics, but I see how to make the entrance experience smoother for Haskell newcomers.
Let discuss it when I'll provide example articles for at least several topics. 🙂

Well, but how does that concern Hackage, the Haskell package registry?

It doesn't. As well, as search using Hoogle or the Community section that I want to implement on the home page.
Relevant question: https://twitter.com/qnikst/status/1480529992425558017?s=20
I started the project as UI for the Hackage two-three weeks ago, but since that, I decided to switch direction toward - what features a Haskell website should have to be useful for developers on a daily basis.
I'll rename the project at some point in time.

So, Typeclassopedia?

It's a great source of information on some topics, but I see how to make the entrance experience more smooth for Haskell newcomers.
Let discuss it when I'll provide example articles for at least several topics. slightly_smiling_face

Does that mean that the goal is not any more to replace the existing Hackage UI? If so, that is a shame really, I was looking forward to that a lot, since it would make it much more approachable.
If instead you want to re-do the haskelll website, you should probably get in touch with people behind haskell.org (the haskell.org committee) and sync your efforts, since they are also looking into how to improve it, from what I know. Here is an example of an issue I opened there, the discussion shows which ideas they would like to address: https://github.com/haskell-infra/www.haskell.org/issues/136 .
Personal opinion on the articles -> I think the biggest problem is really writing/curating them and then organizing them, while searching through them is a much smaller problem. Once articles/materials are there, it should be easy to organize them into wiki and put a search on top of it. There already exists a Haskell wiki, however it doesn't feel modern / up to date, so it doesn't really distill a lot of confidence as a learning resource (at least to me).

@Martinsos don’t worry, I won’t stuck with writing articles.
In the my initial idea comment I wrote:

Now it's just an idea. I'm not going to start it tomorrow.

I won’t start it before completing packages and docs UI.

you should probably get in touch with people behind haskell.org (the haskell.org committee) and sync your efforts, since they are also looking into how to improve it, from what I know.

Before starting a discussion on coordinating efforts and involving more people, I’d prefer to have something to show.
I established an initial contact with @myShoggoth and @bodigrim. Both are board members of the https://haskell.foundation/
I think at some point when my project will collect enough useful features, they could coordinate my efforts.

@Martinsos I didn’t read the discussion you linked yet. On the road now. Will do today. 🙂

@Martinsos I read the discussion you linked to. Overall I agree with you about the Getting Started stuff on haskell.org.
There is no goal to replace or improve existing haskell.org. It's a separate project and if it will be useful and will take a broad adoption, maybe this topic can be raised.

Does that mean that the goal is not to replace the existing Hackage UI? If so, that is a shame really, I was looking forward to that a lot since it would make it much more approachable.

Did I ever mention that the party was canceled?
My prioritized tasks now:

In addition to the already releases browser extension, finish VSCode extension. I see it as the fastest way to make to deliver useful stuff to a broader audience.
Finish package page.
Implement docs browsing functionality.
Make the home page useful. Setup community activity feeds, including integration with https://github.com/haskellfoundation/volunteering
Integrate with https://github.com/serokell/hackage-search full-text search. I asked Serokell about using their API https://github.com/serokell/hackage-search/issues/25 , they don't mind if I'll mention that search results are provided by Serokell.

Next step I see implementing Haskell playground to have the ability to integrate live examples to package documentation and education materials. Only after that, I'll start the first experiments with the mini-articles.
If you want to help with code or advice on some of the mentioned stuff, you are welcome. 🙂
If you rather have skeptical feelings about that, better pass by.

@visortelle sounds good! As I said, don't mind me, you should do whatever you feel you are most excited about, but since you are building this is in public I thought you could benefit from an additional opinion/perspective.
Sounds good to me, and I am really excited to see the results!
I will keep an eye on the project and if you create issues that could be taken by others I will try to find one that I can help with, if time permits.

@Martinsos there is one issue that doesn't require any coding: https://github.com/visortelle/hackage-ui/issues/8


[DR] Twist-shift boundary conditions

These boundary conditions are meant for 3D gyrokinetics (though in fact they were also applied to fluids in other codes), and consist of
f(x, y, z_max) = f(x,y-S,z_min)

or viceversa
f(x, y, z_min) = f(x,y+S,z_max)

described, along with its DG algorithm, in M. Francisquez, et al. CPC 298 (2024) 109109 (see eqn 9).
As given in eqn 30 of that paper, the distribution in a the target cell (i,j_tar) is given by a linear combination of mat-vec multiplies including contributions from N_{do}(i) donor cells
f_{i,j_tar} = sum_{q=1}^{N_{do}(i)} M_q f_{do,i,j_q}

So implementing this BC consists of two things:

Constructing the M_q matrices (during initialization).
Performing these matrix vector multiplies, and adding their contributions.

We intend to do this building up the capabilities of zero/bc_twistshift.c, which was created last year just to do 2, assuming 1 was done in g2. We'll mention some initial design intentions about each of these below, and edit it as things evolve:
Constructing M_q matrices
We'll store a flat list of donor matrices, created with
  up->matsdo_ho = gkyl_nmat_new(total_donor_mats, basis->num_basis, basis->num_basis);

for which we'll need to know the total number of donors (matrices or cells, total_donor_mats). This is computed after having a (flat) list of the donor cell indices (cellsDo in g2, currently cells_do in g0). To be precise, cells_do, is a flattened 4D array: for each (i,j) location we store the x-y indices of N_do(i) donors.
After knowing who the donors are for each target, we proceed to populate their elements. This involves a sequence of sub-cell integrals, which we have to craft based on a number of 1D projections (onto a DG basis), root finding, and calling 1 of 3 kernels. In g2 this part of the code made heavy use of Lua tables to store scalars, arrays, functions and maybe even strings; we'll have to figure out how to write the C equivalent without such tables, though in some places we may replace similar those data objects with C structs.
The matrices are computed on the host, and are later copied to the GPU with
  gkyl_nmat_copy(up->matsdo, up->matsdo_ho);

Performing mat-vec multiplies and adding their contributions
Knowing who the donors are, and the map from target cell index to linear index into matsdo, we can easily perform these multiplications (i.e. w/ gkyl_nmat_mv) on the host, in serial, and add their contributions together.
On the GPU this is a little tricker. Part of the challenge is that we call gkyl_nmat_mv, which calls cuBLAS and this is not meant to be called in a kernel.

Our first attempt didn't parallelize over y, or vpar-mu & I think only parallelized over x and N_do(i) (but actually, I think the assignment of the vectors is not parallelized over x). This we found to be slow.
To expose greater parallelism we could:

Parallelize over vpar and mu. Conceptually this should be easy, as the BC has not dependency on vpar,mu.
Parallelize over y. This is trickier since the donors vary with y.
Needless to say, the GPU parallelizes over basis functions by virtue of cuBLAS parallelizing each mat-vec multiply.

In the current approach the mat-vec multiplies are being done with
    gkyl_nmat_mv(1.0, 0.0, GKYL_NO_TRANS, up->matsdo, up->vecsdo, up->vecstar);

and then, the reduction and assignment into the solution vector, are calling gkyl_bc_twistshift_inc_cu in each x cell (so this step is not parallelized over x).
To expose greater parallelism we could do this (a private comment from last year):
i was at first reluctant to batch over vpar,mu also because we'd have to create too many matrices and vectors. This isn't necessarily true. Matrices only depend on x and donorIdx, so it's natural to batch over Nx and ndonor. But when batching over vpar,mu one can create an array of pointers to matrices, where there are only ndonor*Nx matrices allocated, but ndonor*Nx*Nvpar*Nmu pointers (i.e. the extra pointers in Nvpar*Nmu space simply point back to the same Nx*ndonor matrices, without having to allocate more matrices).
The vectors however do have to be allocated, because they need to hold the distinct value of f in those (donorIdx, xIdx, vparIdx, muIdx) cells. So the memory needed to batch over Nvpar*Nmu is only Nvpar*Nmu times greater than what we use now.
An estimate for a 128x96x16x32x12 grid with 15 donor cells at each x (48 DG coefficients):
Memory for vectors, batching over Nx*ndonor = 15*128*48*8 = 0.73 MB
Memory for vectors, batching over Nx*ndonor*Nvpar*Nmu = 15*128*32*12*48*8 = 283 MB
The latter is big, but it's not terrible. It's 1536 times smaller than a 5D distribution function. Furthermore, when we decompose in x and y these numbers will be smaller still.

Some potentially useful info:
I noticed that the gkyl_nmat_mv, which calls cu_nmat_mm has
        cublasHandle_t cuh;
        cublasCreate_v2(&cuh);
...
  // Now do the strided batched multiply
  cublasStatus_t info;
        info = cublasDgemmStridedBatched(cuh, transa, transb, C->nr, C->nc, k, &alpha, A->data, lda, sza.nr*sza.nc,
                B->data, ldb, szb.nr*szb.nc, &beta, C->data, ldc, szc.nr*szc.nc, A->num);
  cublasDestroy(cuh);

and our hackathon mentors/cuBLAS devs said that handle creation is very expensive, and that they strongly recommended maintaining the same handle. We ought to explore this as a later-stage optimization.

Initial inspection of the code reveals that much of the advance method can be done at t=0. The initial phase of prototyping has been focused on moving these things out of the advance method in order to make it clearer how we can parallelize the steps that actually need to happen in the advance method.

A new prototype of the TS BC has been implemented in the gk-g0-app_tsnew-prototyping branch.
Instead of using mat-vec multiplies as in eqn 30 of M. Francisquez, et al. CPC 298 (2024) 109109, we have instead used mat-mat multiplies to perform this operation (for 3x2v)
ftar_{i,j_tar,k,m,n} = (sum_{q=1}^{num_do_tot} ( scimat_q fmat_q )_{n,s}

where

num_do_tot is the total number of donors for a given y-vpar-mu index (i.e. the number of donors at all x added up).
ftar_{i,j_tar,k,m,n} is the n-th DG coefficient of the target distribution in the i,j_tar,k,m (x,y,vpar,mu) cell.
scimat is a num_basis x num_basis matrix with the appropriate subcell integral contribution.
 fmat is a num_basis x (Ny * Nvpar * Nmu) matrix, with the DG coefficients of the donor distributions arranged as rows of the matrix and the various y-vpar-mu cells arranged as columns
the subscript s is used to indicate a linear index running over the x-y-vpar-mu dimensions.

Some comments on the construction of the scimat matrices (formerly M_q) and the mat-mat multiples:
Constructing scimat matrices
We find the donor cells using the same algorithm described in the paper and used in g2.
The scimat matrices however are now computed a little differently. We realized that figure 4 of the paper is not accurate because the spacing between the blue lines should always be Delta y. Using that fact, we simplified the calculation of these subcell integrals in two ways:

They now all use variable y limits, and no variable-x limit integrals are used.
They form some integrals out of two smaller, side-by-side (left-right portions) integrals, unlike for example what is described in figure B.19.
The first of these simplifies some integrals quite a bit, because variable x-limit integrals needed inversion of the y_{j_tar+/-1/2}-S(x) functions, which had more tunable parameters and room for less robustness. The second of these simply reduces the type of code/algorithms needed (it may not reduce the amount of code as the present code still has a fair bit of repetition). Despite these changes, I've been able to reproduce figures 6, 9 and 11, and by checking conservation at different resolutions i've also confirmed what's in figure 16a.

The matrices are computed on the host, and are later copied to the GPU with
  gkyl_nmat_copy(up->matsdo, up->matsdo_ho);

Performing mat-mat multiplies and adding their contributions
Having constructed the scimat matrices, the application of the BC consists of

Assigning the columns of the fmat matrices with entries from the donor distribution.
Calling gkyl_nmat_mm to perform num_do_tot mat-mat multiplications.
At the i-th cell along x, adding up the contribution of num_do(i) mat-mat multiplications, and placing that in the target distribution.

Step 1 uses an index map from the donor distribution to the columns of the fmat matrices (num_numcol_fidx_do). Step 2 uses a black-box N mat-mat multiplication function. And step 3 uses an index map from the result of a mat-mat multiplication, to the target distribution (num_numcol_fidx_tar).
Possible improvements

Presently the BC is applied using volume expansions. We could instead evaluate f at the surface and use surface expansions. This would reduce the number of rows in the matrices by 2X, and thus would reduce the number of FLOPS by at least 4X I think (mat-mat multiplication is an N^2.4 -  N^3 operation).
We are allocating quite a bit of memory to create fmat, i.e. an num_do_totNyNvparNmuncomp chunk of memory, which is somewhere between a 4D and a 5D distribution. It might be advantageous to find a away to reduce this memory need.
The construction of scimat has a bit of repetition now that all scenarios are treated with variable y limits. We should look into writing this even more modularly with less repetition. But we may also not want to do this until we've done some simulations and know the present approach is robust.

I support finding a way to reduce the memory, since @manauref mentioned in the GK meeting today that high resolution LAPD simulations are approaching a memory limit. This will undoubtedly be exacerbated in shaped geometry and if neutrals/impurities are included.
Which 2 kernels are not used that you reference in improvement no. 5? Do you mean that at the sub-cell integral calculation, where 3 kernels were needed, now only one is necessary?

Reducing the memory footprint of TS BCs will not improve our ability to run bigger (clopen) sims on GPUs, because it's the difference between ~5 distributions or 6 (so only a 16.67% footprint). What we really need is parallelization in other dimensions, or a refactoring of many other parts of the code so we allocate fewer arrays.
In g2 there were 3 kernels:

subcell integrals with variable x limits
subcell integrals with variable y limits
integral over the whole cell
we only use one of these now, so we could remove the other 2.

Thanks for clarifying.

Closed as this work is complete. Nice job, @manauref!


Not printing the welcome screen properly

https://github.com/Ostronkex/100-Days-of-Code-The-Complete-Python-Pro-Bootcamp-Solutions/blob/64d6c915f16bea8489ffa880adc297ff3bad27ca/Day10/Calculator.py#L28
Does not print the ASCII art on the same line properly. Also clean up the code and remove random variables that are not used such as temp.

Extremely low priority. Will most likely not be worked on.


Fixes #2559 #2560 - EventTarget and URLSearchParams for react native

Mostly a revert of https://github.com/medplum/medplum/commit/839602435eaa6c59b7282384f5b0228329c75e7d for React Native compatibility

coverage: 94.268% (+0.007%) from 94.261% when pulling 3260d124b881180cffac7230cc23c7533d74ec23 on cody-react-native-compat into 09e27ddda98c70297efb42086b6336213fe5690a on main.


chore: refactor to Deno project

This is sort of a Node project that works on Deno using esm.sh. That is not in line with the rest of the ecosystem, and it hinders us from building good tooling around this plugin.
This PQ refactors this project to be a Deno-first project.

WDYT about using dnt for this instead of deno2node in preparation for the migration to @grammyjs/build?

WDYT about using dnt for this instead of deno2node in preparation for the migration to @grammyjs/build?

There are no plans to move to dnt.


large operators have limits in displays; relations have limits always

Closes #1720
This PR implements the following default policy limit vs. scripts attachments:

MathClass::Large operators that are not a species of integral sign have limit attachments at display sizes.
MathClass::Large operators that are also integral signs have scripts attachments at all sizes
MathClass::Relation characters have limit attachments at all sizes

These defaults can be overridden, of course, with limits and scripts.
Notes
There are 68 different unicode math class Large characters listed in the official data file. Of these, the LaTeX package unicode-math only categorizes 62 of these as type \mathop -- see its categorization table.  The outliers are

U+0606 and U+0607 (arabic script cube and fourth root)
U+221A -- U+221C (square root, cube root, fourth root)
U+27CC (long division, a cousin of the square root glyph)

The first two of these are not included in the unicode-math table, and I suspect this is because they have Unicode script property Arab rather than Zyyy, undetermined, which seems to be what all the other symbols are.  The remaining four are all given class \mathopen, corresponding to MathClass::Open, which seems more reasonable than the official classification.  Regardless, I did nothing to make an exception in any of these six cases.  If you're putting attachments on the long division glyph, no default seems reasonable and best of luck with that. ;-)
The unicode-math PDF list of symbols clearly shows which large operators default to limits and which to scripts.  It's exactly the list of integral-like glyphs and agrees with this PR.
For MathClass::Relation, I chose a limits policy of Always so that inlined text $a =^"def" b$ would typeset with limits.  If showing limits at Display and Text sizes only had been an option, I would have gone with that.

For MathClass::Relation, I chose a limits policy of Always so that inlined text $a =^"def" b$ would typeset with limits
I don't think this is a good idea. They should only default from limits for display math, for the same reasons as for operators. One may quickly run into issues with interference between lines, or inconsistent line distance.

For MathClass::Relation, I chose a limits policy of Always so that inlined text $a =^"def" b$ would typeset with limits

I don't think this is a good idea. They should only default from limits for display math, for the same reasons as for operators. One may quickly run into issues with interference between lines, or inconsistent line distance.

Yup, there's a judgement to be made here, which is why I included this choice explicitly in the notes.  The poster of the original issue seemed to be of a different opinion:

I can't actually think of any usecase where you would want an attachement to be placed as a sub/superscript and writing limits(=) so often is exhausting.

At any rate, relations are, by and large, smaller glyphs than the large operators, and issues with bleeding into the interline space are less serious. Compare:

There's a good reason to not put that 30 on top of the sum.  Doing the same, by default, for the relations seems less compelling, especially given the alternative layout as a script doesn't lead to a ton of space savings and is probably not a desired layout.  But it's for sure a judgement, and reasonable people can differ.  It's easy enough to go with Display if that's what is decided in the end.  And whatever default is set, it can be easily overridden.

It's possibly defensible for some relations that aren't too tall, but it would be highly dependent on too many factors. Even in your example you can see that the def is placed slightly higher than the 30 on the sum. The f would almost touch a descender on the line above. Not to mention if the line above had another relation with a limit below it. They would definitely collide.
Don't get me wrong, I'm all for making limits the default for relations in display math. But I don't see any reasonable alternative to making script the default in inline math.

My understanding of the motivation for the issue (and hence the PR) is the perception that the usual use case for decorating a relation with an attachment is something  like what \stackrel does, and that the alternative of typesetting with a script is usually not what is wanted.  If this is the case, then a reasonable choice for the default would be to do as \stackrel does: inline or display, the decoration goes above/below the decor-ee.  If done in inline mode, the price you pay is that sometimes this results in a bit of extra interline space to prevent collisions.  I think the possible disagreement here is simply over which tradeoff is worse for the default.  One perspective is that trying to keep interline variations to a minimum is more important, the other is that extra interline space is ok (if needed) if the alternative is a layout that is typically not what's wanted.  Both are positions that have their merits.
I'd be curious to see real-world use cases of $ relation^decoration $ or $ relation_decoration $ where for the same relation/decoration pair, if limits are set in display style and if scripts are set in text/inline style, then in both cases the same author is likely to go "yeah, looks good enough, that's my intent".  This is what happens with the large operators; it's not clear to me that the same thing happens when decorating relations.
Regarding interline collisions, Typst should be responsible for automatically ensuring (possibly after certain settings are chosen) that they just don't occur.  It already makes an attempt, but it seems this could be improved, even for the basic case of  inline math large operators with scripts:

TeX's triple of \baselineskip, \lineskiplimit and \lineskip can be set so that they do prevent collisions, but Typst uses a somewhat different model for interline spacing.

The collisions will definitely be prevented in the future, the current implementation is just bad. Regarding the topic of limits vs scripts: I'm not a mathematician but from my limited understanding limits vs scripts on large operators is mostly a matter of style whereas "def" as a subscript seems different enough from "def" as a top attachment for it not to differ just based on display vs inline.

Thanks!


Added overflow hidden styling for round borders.

[x] I have followed (at least) the PR section of the contributing guide.

Can you provide more detail about what do you want to solve? The change broke existing UI on argos.

Hi @siriwatknp I was trying to resolve the following Issue https://github.com/mui-org/material-ui/issues/27418 and as @eps1lon suggested to add the styling in the root Accordion Component I have did that.
Can you help me if I went wrong somewhere.

Thanks for the work.

@eps1lon suggested to add the styling in the root Accordion Component I have did that.
Can you help me if I went wrong somewhere.

I specifically said that this is exploratory work but it seems like the approach with styles at the root breaks existing visuals so we need to take that into consideration.
So when you work on it locally with yarn docs:dev you want to make sure that localhost:3000/components/accordion/ still looks the same as before (e.g. by comparing it with https://next--material-ui.netlify.app/components/accordion/)

Closing for bookkeeping. If there's any progress please ping me and I reopen.


Build error: constant overflows int

When building, I get the following error:
.gopath/src/github.com/docker/docker/daemon/logger/fluentd/fluentd.go:98: constant<PHONE_NUMBER> overflows int

This seems like a pretty big issue. I used .hack/vendor to check out the correct revisions for everything.

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

Hi,
docker version: git, 1.8.0-rc1
uname -a: Linux 3.19.0-22-generic #22-Ubuntu SMP Tue Jun 16 17:15:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Steps to reproduce:

Attempt to compile docker

Results expected: successful compilation
Results received: error:
.gopath/src/github.com/docker/docker/daemon/logger/fluentd/fluentd.go:98: constant<PHONE_NUMBER> overflows int

Your problem is that your math.max is actually bigger than Golang's supported Math.Max.
----------END REPORT ---------

@paralin That's weird, because math.MaxInt32 is smaller, than math.MaxInt64. Seems like you're trying to build on 32-bit arch.

@LK4D4 Okay, some more information:
Building under buildroot, cross-compiling for GO_ARCH=arm. The previous version compiles okay, this problem was introduced between 1.7.1 and 1.8.0-rc1

Thank you!


tests: Limit log output to 10 GB

Limit log output in compat.sh and ssl-opt.sh, in case of failures with these
scripts where they may output seemingly unlimited length error logs.
Status
READY
Requires Backporting
Yes - 2.16, 2.7
Todos

[ ] Tests
~[ ] Documentation~
~[ ] Changelog updated~
[ ] Backported

Rebased to limit to 10 GiB and clarify comment


poetry_install-option fails with ERROR: Hashes are required in --require-hashes mode

Description
Deployment and deployed lambda function works as expected when I use 'source_path' with 'pip_requirements'. But with 'source_path' and 'poetry_install' I get the following error:
Collecting aioboto3==11.2.0
│   Using cached aioboto3-11.2.0-py3-none-any.whl (32 kB)
│ ERROR: Hashes are required in --require-hashes mode, but they are missing
│ from some requirements

pyproject.toml contains the following
[tool.poetry.dependencies]
python = "^3.10"
aioboto3 = "11.2.0"

[x ] ✋ I have searched the open/closed issues and my issue is not listed.

Versions

Module version [Required]: 4.18.0

Terraform version:
Terraform v1.4.6
on darwin_arm64

Provider version(s):

provider registry.terraform.io/hashicorp/aws v5.1.0
provider registry.terraform.io/hashicorp/external v2.3.1
provider registry.terraform.io/hashicorp/local v2.4.0
provider registry.terraform.io/hashicorp/null v3.2.1
provider registry.terraform.io/hashicorp/random v3.5.1

Reproduction Code [Required]
My module definition is the following:
module "python_lambda_function" {
  source = "terraform-aws-modules/lambda/aws"

  function_name = join("-", [var.env, var.prefix, "lambda"])
  description   = "Python Lambda Function"

  handler = "lambda_function.lambda_handler"
  architectures = ["arm64"]
  runtime = "python3.10"
  timeout = "60"

  publish       = true

  # use Poetry and pyproject.toml
  source_path = [
    "../lang/python",
    {
      poetry_install = true
    }
  ]
  # use pip and requirements.txt
#  source_path = [
#    "../lang/python/lambda",
#    {
#      pip_requirements = "../lang/python/lambda/requirements.txt"
#    }
#  ]

  store_on_s3 = true
  s3_bucket   = aws_s3_bucket.this.bucket
}

Steps to reproduce the behavior:
 No (but I'm using terragrunt for deployment)
 Yes
 'terragrunt apply' fails
Expected behavior

Actual behavior

Terminal Output Screenshot(s)

Additional context
Here it's stated that '--without-hashes' should be added to poetry export.
https://github.com/python-poetry/poetry/issues/3472

After taking a more closer look to examples in repository I got my code also working. There were couple of reasons:

For some reason my system poetry had fallen back to an ancient 1.1.12 version. Updated to latest poetry 1.5.1 and regenerated poetry.lock.
I then created lambda layer and then lambda function (python), which referenced to lambda layer.

Nice and easy once got it working.


Can't run 11 billion model on A100 with 80GB

Hi @craffel @muqeeth @HaokunLiu,
We're trying to reproduce T-Few results for a paper, but we're getting  'CUDA out of memory' using an A100 with 80GB (your recommended setup).
This is what we're running:
python -m src.pl_train -c t011b.json+ia3.json+rte.json -k load_weight="pretrained_checkpoints/t011b_ia3_finish.pt" exp_name=t011b_rte_seed42_ia3_pretrained few_shot_random_seed=42 seed=42

We installed according to the README instructions and are using the default settings in the config files.
We are able to run the 3 billion model using the command above, just not the 11 billion.
Is there anything we are doing wrong?
This is the exception:

Thank you

Thanks for your interest in our work!
It's hard to tell from the surface.  Could you share with me the full log?
And if you are familiar with pytorch lightning, mind if add something like print("Memory usage at line [add something here]", torch.cuda.memory_allocated(device=None)) in functions in the start and end of training_step of EncoderDecoder.py?

Hi @HaokunLiu
We added the prints and attached the logs here. Looks like it runs out of memory before starting the training.

(tfew3.7) unso@hf-paris-dgx-station-1:~/t-few$ python -m src.pl_train -c t011b.json+ia3.json+rte.json -k load_weight="pretrained_checkpoints/t011b_ia3_finish.pt" exp_name=t011b_rte_seed42_ia3_pretrained few_shot_random_seed=42 seed=42 > logfile
Using bfloat16 Automatic Mixed Precision (AMP)
GPU available: True, used: True
TPU available: False, using: 0 TPU cores
IPU available: False, using: 0 IPUs
Reusing dataset super_glue (/home/unso/.cache/huggingface/datasets/super_glue/rte/1.0.2/d040c658e2ddef6934fdd97deb45c777b6ff50c524781ea434e7219b56a428a7)
LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0]
Missing logger folder: /home/unso/t-few/exp_out/t011b_rte_seed42_ia3_pretrained/log
 | Name | Type            | Params
-----------------------------------------------------
0 | model | T5ForConditionalGeneration | 11.1 B
-----------------------------------------------------
1.1 M   Trainable params
11.1 B  Non-trainable params
11.1 B  Total params
44,548.801Total estimated model params size (MB)
Traceback (most recent call last):
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/runpy.py", line 193, in _run_module_as_main
  "__main__", mod_spec)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/runpy.py", line 85, in _run_code
  exec(code, run_globals)
 File "/home/unso/t-few/src/pl_train.py", line 86, in <module>
  main(config)
 File "/home/unso/t-few/src/pl_train.py", line 57, in main
  trainer.fit(model, datamodule)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py", line 741, in fit
  self._fit_impl, model, train_dataloaders, val_dataloaders, datamodule, ckpt_path
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py", line 685, in _call_and_handle_interrupt
  return trainer_fn(*args, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py", line 777, in _fit_impl
  self._run(model, ckpt_path=ckpt_path)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py", line 1199, in _run
  self._dispatch()
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py", line 1279, in _dispatch
  self.training_type_plugin.start_training(self)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/plugins/training_type/training_type_plugin.py", line 202, in start_training
  self._results = trainer.run_stage()
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py", line 1289, in run_stage
  return self._run_train()
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py", line 1319, in _run_train
  self.fit_loop.run()
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/base.py", line 145, in run
  self.advance(*args, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/fit_loop.py", line 234, in advance
  self.epoch_loop.run(data_fetcher)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/base.py", line 145, in run
  self.advance(*args, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/epoch/training_epoch_loop.py", line 193, in advance
  batch_output = self.batch_loop.run(batch, batch_idx)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/base.py", line 145, in run
  self.advance(*args, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/batch/training_batch_loop.py", line 88, in advance
  outputs = self.optimizer_loop.run(split_batch, optimizers, batch_idx)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/base.py", line 145, in run
  self.advance(*args, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/optimization/optimizer_loop.py", line 219, in advance
  self.optimizer_idx,
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/optimization/optimizer_loop.py", line 266, in _run_optimization
  self._optimizer_step(optimizer, opt_idx, batch_idx, closure)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/optimization/optimizer_loop.py", line 386, in _optimizer_step
  using_lbfgs=is_lbfgs,
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/core/lightning.py", line 1652, in optimizer_step
  optimizer.step(closure=optimizer_closure)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/core/optimizer.py", line 164, in step
  trainer.accelerator.optimizer_step(self._optimizer, self._optimizer_idx, closure, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/accelerators/accelerator.py", line 336, in optimizer_step
  self.precision_plugin.optimizer_step(model, optimizer, opt_idx, closure, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/plugins/precision/native_amp.py", line 80, in optimizer_step
  return super().optimizer_step(model, optimizer, optimizer_idx, closure, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/plugins/precision/precision_plugin.py", line 163, in optimizer_step
  optimizer.step(closure=closure, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/torch/optim/lr_scheduler.py", line 65, in wrapper
  return wrapped(*args, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/torch/optim/optimizer.py", line 109, in wrapper
  return func(*args, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/transformers/optimization.py", line 528, in step
  loss = closure()
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/plugins/precision/precision_plugin.py", line 148, in _wrap_closure
  closure_result = closure()
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/optimization/optimizer_loop.py", line 160, in __call__
  self._result = self.closure(*args, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/optimization/optimizer_loop.py", line 142, in closure
  step_output = self._step_fn()
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/loops/optimization/optimizer_loop.py", line 435, in _training_step
  training_step_output = self.trainer.accelerator.training_step(step_kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/accelerators/accelerator.py", line 216, in training_step
  return self.training_type_plugin.training_step(*step_kwargs.values())
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/pytorch_lightning/plugins/training_type/training_type_plugin.py", line 213, in training_step
  return self.model.training_step(*args, **kwargs)
 File "/home/unso/t-few/src/models/EncoderDecoder.py", line 62, in training_step
  decoder_attention_mask=decoder_attention_mask,
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
  return forward_call(*input, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/transformers/models/t5/modeling_t5.py", line 1623, in forward
  return_dict=return_dict,
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
  return forward_call(*input, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/transformers/models/t5/modeling_t5.py", line 1020, in forward
  output_attentions=output_attentions,
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
  return forward_call(*input, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/transformers/models/t5/modeling_t5.py", line 696, in forward
  hidden_states = self.layer[-1](hidden_states)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
  return forward_call(*input, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/transformers/models/t5/modeling_t5.py", line 306, in forward
  forwarded_states = self.DenseReluDense(forwarded_states)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
  return forward_call(*input, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/transformers/models/t5/modeling_t5.py", line 285, in forward
  hidden_states = self.wo(hidden_states)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
  return forward_call(*input, **kwargs)
 File "/home/unso/miniconda3/envs/tfew3.7/lib/python3.7/site-packages/torch/nn/modules/linear.py", line 114, in forward
  return F.linear(input, self.weight, self.bias)
RuntimeError: CUDA out of memory. Tried to allocate 80.00 MiB (GPU 0; 79.35 GiB total capacity; 78.13 GiB already allocated; 3.62 MiB free; 78.20 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation. See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF

I remember the code will print out all the args in the beginning. Could you share that with me?

Sorry I think the config might be slightly off as it was meant for the 3B and not 11B versions. For the 11B variants, to fit into memory, we used a smaller batch size but still had an effect batch size of 8. Our hyperparameters werebatch_size=1 grad_accum_factor=8 eval_batch_size=2. Let us know if it still runs out of memory.

thanks!


Styled-components SSR not working with new SC version

Hello!
I'm trying to follow this instruction https://reactjs.net/features/css-in-js.html#styled-components for styled-components SSR.
But it works only for styled-components v4.0.0.
If I try use the latest version - build failed with "window is undefined" error after import { ServerStyleSheet } from 'styled-components';.
Please update SC SSR support.

Sorry, I don’t have time to investigate a fix for this. It’s likely a
problem with SC itself or the webpack configuration. Stick with v4 if you
need support.
On Wed, Dec 9, 2020 at 18:54, Felis Armis<EMAIL_ADDRESS>wrote:

Hello!
I'm trying to follow this instruction
https://reactjs.net/features/css-in-js.html#styled-components for
styled-components SSR.
But it works only for styled-components v4.0.0.
If I try use the latest version - build failed with "window is undefined"
error after import { ServerStyleSheet } from 'styled-components';.
Please update SC SSR support.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/reactjs/React.NET/issues/1232, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHGCFQMT3YL6YUH6EYAA73SUAZ5DANCNFSM4UUMEHAA
.

@dustinsoftware i've tracked this issue down to these lines from styled-components:
https://github.com/styled-components/styled-components/blob/master/packages/styled-components/src/base.js#L41-L55
Using webpack.DefinePlugin to set process.env.NODE_ENV to "production" fixes the issue as the minifier removes those lines with 'window', and server rendered styles works without changing the StyledComponentsRenderFunction.
Obviously setting NODE_ENV like this isn't an ideal solution as we wouldn't want to set it in development.
I've created an issue in styled-components with a possible fix.
From my own tests, it looks like this issue was introduced in<EMAIL_ADDRESS>Downgrading to 5.1 does not encounter this issue as there is a typeof window !== "undefined" check

@dustinsoftware i've tracked this issue down to these lines from styled-components:
https://github.com/styled-components/styled-components/blob/master/packages/styled-components/src/base.js#L41-L55
Using webpack.DefinePlugin to set process.env.NODE_ENV to "production" fixes the issue as the minifier removes those lines with 'window', and server rendered styles works without changing the StyledComponentsRenderFunction.
Obviously setting NODE_ENV like this isn't an ideal solution as we wouldn't want to set it in development.
I've created an issue in styled-components with a possible fix.
From my own tests, it looks like this issue was introduced in<EMAIL_ADDRESS>Downgrading to 5.1 does not encounter this issue as there is a typeof window !== "undefined" check

I can confirm - we are using version 5.1.1 without problems

I can confirm - we are using version 5.1.1 without problems

@dustinsoftware looks like we might be able to close this and #1207. Styled-components released an update couple months back with styled-components 5.3.1 (https://github.com/styled-components/styled-components/issues/3506) that should address this. I haven't tested it myself however (we have projects still on 5.1.x), but thought I'd give this issue a bump.


Names are automatically casted to lower-case, regardless of capitalisation in database

Describe the bug
Source, schema, database, table, and column names are automatically casted to lowercase when generating source yaml files, regardless of the casing of the name in the actual database.
Steps to reproduce
Generate a source yaml file from any database that contains capitalisation in the names of any of the aforementioned.
Expected results
Conservation of capitalisation in the yaml file as it is in the database.
Actual results
All-lowercase names.
Are you interested in contributing the fix?
Yes, as it would just require minor adjustments of a few lines.

This will be really helpful in case of different standards for ColumnName as per project instead of converting to lowercase.

Using the persist_docs configuration to sync the documentation between BigQuery and dbt docs requires matching cases of column names. It makes sense to have the option to keep the original case as in the databases.


can't connect to client on window 7.

Hi guys,
I use quasar and build client on window 11, and client in win 7. But I can't connect to client. I try connect client on win 10 and 11 other, it's working, but on win 7 it's not working. I need help

already tested on windows 7; did not work. I don't think Quasar is compatible with win7.

Supported operating systems (32- and 64-bit)
Windows 10
Windows Server 2019
Windows Server 2016
Windows 8/8.1
Windows Server 2012
Windows 7
Windows Server 2008
Windows Vista
For older systems please use Quasar version 1.3.0

Did you insatall in the Win7 Machine the .NET Framework 4.5.2?

I think so


Microsoft Build Tools 2015 on Microsoft Download Center should be updated

https://stackoverflow.com/questions/35722454/different-versions-of-msbuild-when-installing-directly-or-through-visual-studio
As discussed above, if people want to set up their build servers to match Visual Studio 2015 Update 1 on developer machines, there is currently no separate download package for MSBuild 14.0.24720.0.
The current download is still 14.0.23107.10.

We are tracking this as #480. We've already made the required internal changes, and we expect to publish a standalone Build Tools package with Visual Studio 2015 Update 2 RC (and eventually the final Update 2 when it's ready).


Security scan OpenApi3 definition

Fixes #1000

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: tarokkk:x: pbalogh-saYou have signed the CLA already but the status is still pending? Let us recheck it.


MIRI does not respect operators precedence

const S1: bool = true;
const S2: bool = true;
let s3: bool = MaybeUninit()::uninit().assume_init();
if S1 | S2 | s3{
    // this triggers MIRI, since it tries to access s3
}

if S1| S2{
    // This is OK.
} else if s3{
}

There's no bug here that I can see. | is not the same as ||.

Aren't they the same for bools?

Yes you're right. Sorry for false alarm.

Your UB is already in this line
let s3: bool = MaybeUninit()::uninit().assume_init();

Here you call assume_init even though you didn't init anything.
Nothing after that matters.

It virtually does not exists (never-ever touched, not for read, not for write) under certain static/compile -time condition.
I want that due to lack of template/generics specialization in RUST. (ideally, it would not exists)

That makes no difference at all. If you write the code, and that function is execute, then the value exists, that's all that matters.
Quoting https://doc.rust-lang.org/reference/behavior-considered-undefined.html, it is UB when you do the following:

Producing an invalid value, even in private fields and locals.

Here's a whole blog post explaining why that kind of code has to be UB in an optimizing compiler: https://www.ralfj.de/blog/2020/07/15/unused-data.html.

I see, thank you.


Backup/Sync local images

Once #2 is done, backup/sync can be implemented

Any update on this?

This is the next big feature that will be implemented. I have no timeline unfortunately but it won't be too long i hope


Is userObjectId used anywhere? If not, should it be removed?

Hi,
I can't seem to trace any use of the Parameter 'userObjectId'. a good understanding of what it is for and which user object id this should be.
If it's not used, should it be removed?
If it is used, then can we get a better explanation of what is should be populated here?
Thanks
Nicholas

Hi @nrogoff ,
Please provide a supporting screenshot of where exactly you got this parameter.

I don't think a screenshot is applicable. It's a parameter in the Deployment/parameters.json file!
"UserObjectId": {     "Value": "<<value>>",     "Description": "User Object Id."   },
and described in the documentation at

userObjectId - Object Id of the user to deploy to (If you are not sure how to get Object ID, please check Azure Active Directory in Azure Portal. Under Manage, click Users and select the appropriate user. The Object ID is shown in the Identity section). e.g 98f3ece2-3a5a-428b-aa4f-4c41b3f6eef0.

Hi @nrogoff ,
As per first impression its seems like its not been used, but will confirm after the internal review.

Good morning. This also appears to be required in the custom deployment template but it is not included anywhere in the documentation for certificate deployments. Can you please clarify how this is being used and which user object ID should be inputted?

That doesn't explain what 'to deploy to' means and the previous message confirmed that it is in fact not used at all!

Hi @nrogoff ,
We will review it and post review if that parameter is found as unused, we will remove it in our next release.

Closing out the issue as we have provided the required response. If you have any further queries please raise a new GitHub request.

Closing out the issue as we have provided the required response. If you have any further queries please raise a new GitHub request.

Sorry to reopen this one, but I don't see where in this issue the required response was provided.
Is the userObjectId used anywhere? Could you provide more details on its purpose, if it serves any purpose?


mac - insider version - not getting latest build

I have noticed for the past couple days that my VS Code insider would not get an update.
The version my VS Code is on this commit 473af338e1bd9ad4d9853933da1cd9d5d9e07dc9
which was done on April 30th, so I got this on May 1st.
Screen Recording 2019-05-03 at 10.06.34 PM.zip

Additionally, I attempted to download the insider version from website, but still was same version.

That is the latest insiders. We did not publish one Thursday and there are none on weekends


fix(richtext-lexical): unnecessary isEnabled computations on toolbar items

Fixes #8170

wrapped onActiveChange in useCallback
removed an unnecessary mouseUp event

Note: I put the console.log for debugging in the useCallback called updateStates inside packages/richtext-lexical/src/features/toolbars/shared/ToolbarDropdown/index.tsx.
Before
https://github.com/user-attachments/assets/07d715d4-f6c7-4a4a-91ab-5de418c909d6
## After
https://github.com/user-attachments/assets/2d404d1c-d1a7-46fd-a5b6-7d01c5c16959

🚀 This is included in version v3.0.0-beta.105


ActiveJob instrumentation relies on SDK method instead of API only

This is an outcome form this discussion comment: https://github.com/open-telemetry/opentelemetry-ruby/discussions/1401#discussioncomment-4128761
The ActiveJob instrumentation relies on an SDK method which is not part of the API: https://github.com/open-telemetry/opentelemetry-ruby-contrib/blob/main/instrumentation/active_job/lib/opentelemetry/instrumentation/active_job/patches/active_job_callbacks.rb#L63
The SDK implementation: https://open-telemetry.github.io/opentelemetry-ruby/opentelemetry-sdk/v1.2.0/OpenTelemetry/SDK/Trace/TracerProvider.html#force_flush-instance_method
The API implementation:

https://open-telemetry.github.io/opentelemetry-ruby/opentelemetry-api/v1.1.0/OpenTelemetry/Trace/TracerProvider.html
https://open-telemetry.github.io/opentelemetry-ruby/opentelemetry-api/v1.1.0/OpenTelemetry/Internal/ProxyTracerProvider.html

Impact
Not much, as this code path is only ever hit when the instrumentation is installed from the registry, and this would typically only happen when using the SDK.
However, this is confusing as the gem depends on the API and not the SDK according to the gemspec: https://github.com/open-telemetry/opentelemetry-ruby-contrib/blob/main/instrumentation/active_job/opentelemetry-instrumentation-active_job.gemspec

Waiting on the outcome of https://github.com/open-telemetry/opentelemetry-ruby/discussions/1401 and https://github.com/open-telemetry/opentelemetry-specification/issues/2944 before taking action, but once a direction is established I can clean this up.


Are relative links in Solid-OIDC Client Identifier Document supported?

We recently ran into an situation where a client added some metadata to its Client ID Document, in particular a logo_uri. The value for this property was relative URL, which isn't something that is explicitly prevented by the specification, and can make sense in the context of a dereferencable Client ID.
The Client Metadata semantics in Solid-OIDC are aligned with the underlying OpenID Dynamic Client Registration specification, but in the context of that specification, relative URLs don't make sense, so this isn't called out.
In order to remain aligned with the underlying Client Metadata specification, the Solid-OIDC specification could add another requirement on the Client in its Client ID Document section, such as "URIs provided as values for parameters in the Client ID Document MUST be absolute".
The alternative would be to add a requirement on the OP conformance class to support relative URIs, but I think it moves away from the underlying specification and would potentially open up possibilities for more misalignments.

I think this would be a necessary restriction at the Dynamic Client Registration level too, and could actually be a vector of attack for impersonation of a client (i.e., faking that your client is some other trusted client). Perhaps this is something more for the underlying security recommendations for OAuth?


Localized URL's

For some of our projects we will need localized URL's, so different URL presentations going to the same service.
For example for our recipe page:
https://www.hellofresh.de/recipes/taboule-salat-mit-wurzigem-hallo-58342b3e4348d25f8d3183c2
We want the URL in germany to be:
https://www.hellofresh.de/rezepte/taboule-salat-mit-wurzigem-hallo-58342b3e4348d25f8d3183c2
And both of them should be proxied to the same service, this is of course possible at the moment, but adding all of them will be hard and time consuming.
I would recommend adding a new optional argument to the routes, something like country, and on every request you can map the domain to the specific country and prioritze the routes that have a matching country in its configuration. If none match, use the default.

This is currently supported by setting different proxies to point to the same upstream. I'm closing this issue because of that.


Why useFetch callbacks is not have nuxt

Environment
Operating System: Darwin
Node Version: v18.16.0
Nuxt Version: 3.10.3
CLI Version: 3.10.1
Nitro Version: 2.9.1
Package Manager<EMAIL_ADDRESS>Builder: -
User Config: alias, runtimeConfig, modules, i18n, app, css, vite
Runtime Modules<EMAIL_ADDRESS>Build Modules: -
Reproduction

Describe the bug
When i trying to handling error, on ssr default useFetch callback is not available to using nuxt actions like navigateTo or any composables, i cant call any methods. Then how i can handling errors, and why u added error handling, if i cant using any nuxt actions in them?
Error: [nuxt] A composable that requires access to the Nuxt instance was called outside of a plugin, Nuxt hook, Nuxt middleware, or Vue setup function. This is probably not a Nuxt bug. Find out more at https://nuxt.com/docs/guide/concepts/auto-imports#vue-and-nuxt-composables.
Additional context
No response
Logs
No response

Because the onResponseError interceptor function runs without the Vue/Nuxt context. The docs linked in the error message and this comment give more insights.
As a workaround, you can get the nuxt app and try runWithContext


add version of packages

Could you please add the version of the necessary packages in the .yaml file?

Done.


scaffold chart default values need to be updated to fix tuf secrets names mismatch

Description

https://github.com/sigstore/helm-charts/pull/673/files correctly fixed https://github.com/sigstore/scaffolding/issues/873 and resulted in release of tuf chart 0.1.9
https://github.com/sigstore/helm-charts/commit/ae23b8e187834d5e1ed197612601f7075849aeab updated the scaffold chart to use the tuf chart at version 0.1.9
however the default values for the tuf secrets names are still the old wrong ones

scaffold values.yaml should also be updated to use the correct secret names. I think a temporary workaround is to set your own secrets block as suggested here (I'm going to test this now. If it works I'll open a PR)
CC @sabre1041
Version

scaffold 0.6.38

I've tested that the suggested fix works, I will open a PR

PR: https://github.com/sigstore/helm-charts/pull/679


[Coverity CID :195905]Control flow issues in /arch/x86_64/core/x86_64.c

Static code scan issues seen in File: /arch/x86_64/core/x86_64.c
Category: Control flow issues
Function: _cpu_start
Component: Architectures
CID: 195905
Please fix or provide comments to square it off in coverity in the link: https://scan9.coverity.com/reports.htm#v32951/p12996

Similar to #14394, it's a false positive.  It doesn't like
if (cpu == 0) {
...
} else if (cpu < CONFIG_MP_NUM_CPUS) {

When CONFIG_MP_NUM_CPUS is 1, as is the default in master right now.  But it's a configurable, and it's not always 1, just happens to be in whatever configuration was passed to coverity.


correct lockfile path on Mac

What are you trying to do here? This will break on Windows.

I don't get what you mean. What's broke and why? For me, it still works on both Windows and Mac now.

Ops... sorry for my mistake. Closed.