refactor(cli): move crates/oxc_cli to apps/oxlint

We need to split the cli crate up to reduce dependencies,
the current cli crate is pulling in oxc_prettier, which is redundant
for the linter.

#3413  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Boshen and the rest of your teammates on  Graphite

Merge activity

May 26, 12:50 AM EDT: Graphite rebased this pull request after merging its parent, because this pull request is set to merge when ready.


chore(main): release 1.0.0

:robot: I have created a release beep boop
1.0.0 (2024-07-07)
Features

init (2012e9a)

Bug Fixes

remove sha-self (9a75a80)
update temlate (7fe272a)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.0.0
:sunflower:


Add my new Raycast extension: Dropstab Crypto Toolbox

Description
Get crypto coin data and navigate to official sites or X. Instantly view your wallets via blockchain explorers.
Features
Search
Dropstab Crypto Toolbox displays the price, market capitalization, and rank of any cryptocurrency, and also allows quick access to the project's page on Dropstab.com or its X (Twitter) profile.

Wallets
Dropstab Crypto Toolbox allows you to instantly find and view any crypto address in the blockchain explorer.

Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Good afternoon,
I am a representative of the DropsTab team. We would like to add an extension from our organization, but we are unable to enable the "Allow edits from maintainers" option because the PR is coming from the organization. Is there a way to add our extension from the organization, or do we need to fork it to a personal account and then create the PR?

If you can compress all the images and make the corrections I tell you, then we can proceed with that 🙂

If you can compress all the images and make the corrections I tell you, then we can proceed with that 🙂

I have compressed the images. What corrections do I need to make?

Can you add icons to all actions in the panel?

I have added icons to all actions in the panel and removed the unnecessary code.

I have renamed the folder to dropstab, checked the imports in the project, and updated the CHANGELOG.md file.

I think it would be nice with an argument for Wallet Address, what do you think? Then it would be even faster

Great idea! I have added an argument for Wallet Address. Thank you!

I have fixed the Empty State Flicker issue. The other fix will be included in the next major update.

Thank you for acknowledging my contribution🤝 I kindly request you to double-check the profile @Motion-Up, as it is registered on Raycast.


Refresh token question

Not sure how this refresh token is supposed to work. When is _refreshToken called? And even if it's called at some point it doesn't set anything after http request to tokenUrl. Shouldn't it set the token received by the request.
function _refreshToken () {
        var _this = this;

        if (_getToken.call(this) && this.getOption('tokenType') === 'jwt') {
            _http.call(this, {
                url: this.getOption('tokenUrl'),
                method: 'get',
                success: () => {
                    var tokenJSON = _decodeToken(_getToken.call(_this)),
                        expireTime = _getTokenExpirationDate(tokenJSON).valueOf(),
                        nowTime = new Date().valueOf(),
                        offsetTime = this.getOption('tokenTimeoutOffset'),
                        timeout = expireTime - nowTime - offsetTime;

                    clearTimeout(_tokenRefreshTimeout);

                    _tokenRefreshTimeout = setTimeout(function () {
                        _refreshToken.call(_this);
                    }, timeout);
                }
            });
        }
    }

Also.. not sure when _refreshToken  decides to kick in but after some idle time the page started sending tokenUrl url requests non stop. Turns out if you set token expiration date to more than ~24 days... the representation in seconds is bigger than the 32bit integer that setTimeout expects .. so it fires as if timeout is 0 milliseconds. Can be fixed by sth like timeout = Math.min(expireTime - nowTime - offsetTime,<PHONE_NUMBER>)

After we logged in then refresh page, then this package automatically trying to fetch and calling _refreshToken if this.loaded === false on line https://github.com/websanova/vue-jwt-auth/blob/master/vue-jwt-auth.js#L427
The problem is..this process is async, so _refreshToken and _fetch will called parallel.
This is the summary

User logged in, save token A in local storage
User refresh page
Package always run fetch on initial load
Since this is initial load, then this.loaded will false, so package will run _refreshToken with token A and in parallel call _fetch with token A too
_refreshToken make token A as blacklist (on server side) and get new token B
_fetch then will has unauthorized access because token A already blacklisted
_refreshToken didn't update new token B in local storage

I think we need to call _refreshToken as series ..
Thanks

Will have to look into it again. Will update the docs with the workflow/reasoning soon. There is also a related issue with expired tokens not being removed. So it tries to use it giving an auth error on load which is not necessary.
Will look into it next week, swamped with some client projects at the moment.

I did some changes and its work for replacing old token when reload page
  function _refreshToken (cb) {
    cb = cb || function () {}

    let _this = this

    if (_getToken.call(this) && this.getOption('tokenType') === 'jwt') {
      _http.call(this, {
        url: this.getOption('tokenUrl'),
        method: 'get',
        success: (res) => {
          _setToken.call(this, res.json()[this.getOption('tokenVar')])

          let tokenJSON = _decodeToken(_getToken.call(_this))
          let expireTime = _getTokenExpirationDate(tokenJSON).valueOf()
          let nowTime = new Date().valueOf()
          let offsetTime = this.getOption('tokenTimeoutOffset')
          let timeout = expireTime - nowTime - offsetTime

          clearTimeout(_tokenRefreshTimeout)

          _tokenRefreshTimeout = setTimeout(function () {
            _refreshToken.call(_this)
          }, timeout)

          return cb()
        },
        error: (res) => {
          return cb()
        }
      })
    } else {
      return cb()
    }
  }

...

    fetch (cb) {
        cb = cb || function () {}

        if (!this.loaded) {
          _refreshToken.call(this, () => {
            this.setLoadedAsTrue(cb)
          })
        } else {
          this.setLoadedAsTrue(cb)
        }
      },

      setLoadedAsTrue (cb) {
        if (this.authenticated === null && _getToken.call(this)) {
          if (!document.cookie.match(/rememberMe/)) {
            _removeToken.call(this)

            this.loaded = true

            return cb()
          }

          this.authenticated = false

          _fetch.call(this, cb)
        } else {
          this.loaded = true

          return cb()
        }
      },

Hello @ghprod , I think your solution isnt working when you want to /register /login , refresh the page because as the install function is being called on every refresh, function _fetch isnt being triggered  so no user is set. Please check your response.

This has now been reworked a bit in the new v1.0.x-dev version.
However by default it will still do a refresh on each init. If you want to disable it you must override the expiredToken method.
expiredToken: function () { return false; }

If you set the token in the header or via param during the user (or any other) request it will automatically get sniffed out and set. So you could put it wherever you like if you wanna go some other route.
Or you could also call $auth.refresh() manually.


fixed bug to delete files from /usr/local/bin directory in centos.

@RaghavBabu please take a look at the code review and address the changes, thanks!

@RaghavBabu any update here?


kamithanthanh

hello world in python
What does the program do ?
----hello world in python
In what programming language it is written?
python

Thank you for participating  in hacktoberfest ❣ if you liked working on this repo you can share it with friends and star this project for helping others


Support unavailable and obsoleted attributes on extensions

Resubmit #24997. The blocking issue should have been resolved. Previously review by @slavapestov.

@swift-ci Please smoke test

@swift-ci Please test source compatibility


Allow IParagraphPortion.Font to be null

In our usage, we found instances where TextFrame.ShrinkText would throw a null reference exception due to ContentFrames not having font's for every portion. Changed IParagraphPortion to be nullable and cleaned up code so that it can skip null fonts

PR-Codex overview
This PR updates nullable references in text handling classes for font properties.
Detailed summary

Made Font property nullable in IParagraphPortion.cs.
Updated font property access to handle nullability in IParagraph.cs.
Adjusted font property access to handle nullability in TextFrame.cs.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@drasmith, thank you for the Pull Request!
Could you please provide a unit test for these changes.


Unbox not parser a simple String

I had a problem with Unbox if I have a 'response JSON with a simple string instead of an array or an object in swift 2.2
Error Domain=NSCocoaErrorDomain Code=3840 "JSON text did not start with array or object and option to allow fragments not set." UserInfo={NSDebugDescription=JSON text did not start with array or object and option to allow fragments not set.}

Class Model
struct TokenModel: Unboxable {
    let id :String
    let name :String
    let token :String
    let urlAccess :String

    init(unboxer: Unboxer) {
        id = unboxer.unbox("id")
        name = unboxer.unbox("name")
        token = unboxer.unbox("token")
        urlAccess = unboxer.unbox("urlAccess")
    }
}

JSON Response API
 null({"id":7,"name":"uniplam","token":"uniplam","urlAccess":"https://X.XX.XXX.0:8082/uniplam/"})
The Object Parse will try to parse a JSON to a model using the Unbox framework
public class ObjectParser<T: Unboxable>: NSObject {
    let jsonData :NSData
    required public init(jsonData data:NSData) {
        jsonData = data
        super.init()
    }

    public func parsedResponse() -> (response :T?, error :ErrorType?) {
        do {
            let object :T = try UnboxOrThrow(jsonData)
            return (object, error: nil)
        }
        catch (let error) {
            return (nil, error: error)
        }
    }

I believe that Unbox don't prepare for parser a simple String, or not?

Hi @douglasalexandre,
If the string that makes up your NSData that you pass when initializing your ObjectParser starts with null( (as in the example), then it's not valid JSON. Valid JSON must have either an Array or Dictionary as its root object - and it looks like the server you're getting the data from is using JSON-P to wrap the returned JSON in a Javascript function call (that in this instance is null).
I'd recommend either looking into if you can get a standard JSON response from your server, or manually stripping out the null( at the beginning and ) at the end.

Hi, @JohnSundell
Thanks for the answer. I checked the JSON and it's wrong!
This is correct Json
  "id": 7,
  "name": "Uniplam",
  "token": "uniplam",
  "urlAccess": "https://xx.xx.xx.x:8082/uniplam/"
}

But anyway, the error still occurs.

First time using Unbox (already loving it)...It'd seem that you defined the model incorrectly.
let id :String but the server returned an Int. So either the response is wrong or id's type is.

ok, @JohnSundell I will try. Thanks for the answer! :)

@douglasalexandre Yeah, what @bre7 says is right - if you're expecting an Int value then your property should be an Int as well, optionally you could also do:
self.id = String(unboxer.unbox("id"))

@JohnSundell @bre7 Ok. Thanks for help me. Really the server is returning a JSONP, so, it isn't valid JSON. I modify my model like you spoke, with right types. We will modify our server :)


Not versioned

This is really useful, however the package isn't versioned correctly so Swift Package Manager cannot constrain it correctly.

Thanks for the report, it has now been correctly versioned to 1.0.0.


Is there any way to create a multidocument yaml?

Hello @TomWright ,
Is there a way to create a multidocument yaml from several yaml files?
Thanks again.

Hey,
Sadly there's no way for dasel to merge multiple files at the moment.
If you have an idea on how this might look then feel free to raise a feature request!

Ok, thanks!


ISSUE: 'ascii' codec can't encode character '\u0142'

Error searching emails: 'ascii' codec can't encode character '\u0142' in position 365: ordinal not in range(128)
Error searching emails: 'ascii' codec can't encode character '\u0119' in position 374: ordinal not in range(128)
Error searching emails: 'ascii' codec can't encode character '\u0142' in position 117: ordinal not in range(128)
Error searching emails: 'ascii' codec can't encode character '\u017c' in position 48: ordinal not in range(128)

https://stackoverflow.com/questions/9942594/unicodeencodeerror-ascii-codec-cant-encode-character-u-xa0-in-position-20

U mnie to samo. Mam maila z DPD a błędy takie:
2022-01-14 10:12:45 ERROR (SyncWorker_0) [custom_components.mail_and_packages.helpers] Error searching emails: 'ascii' codec can't encode character '\u0142' in position 147: ordinal not in range(128)
2022-01-14 10:12:45 ERROR (SyncWorker_0) [custom_components.mail_and_packages.helpers] Error searching emails: 'ascii' codec can't encode character '\u0142' in position 147: ordinal not in range(128)
2022-01-14 10:12:45 ERROR (SyncWorker_0) [custom_components.mail_and_packages.helpers] Error searching emails: 'ascii' codec can't encode character '\u0142' in position 365: ordinal not in range(128)
2022-01-14 10:12:45 ERROR (SyncWorker_0) [custom_components.mail_and_packages.helpers] Error searching emails: 'ascii' codec can't encode character '\u0119' in position 374: ordinal not in range(128)
2022-01-14 10:12:46 ERROR (SyncWorker_0) [custom_components.mail_and_packages.helpers] Error searching emails: 'ascii' codec can't encode character '\u0142' in position 117: ordinal not in range(128)
2022-01-14 10:12:46 ERROR (SyncWorker_0) [custom_components.mail_and_packages.helpers] Error searching emails: 'ascii' codec can't encode character '\u017c' in position 48: ordinal not in range(128)

Unstale

@adorobis have you tried the original repo on the dev branch? My stuff have been merged there and it seems it works pretty well. I didn't encounter these at least.
Cheers

Thanks for update, I gave up on this integration as I don't see much value anyway...


Completers should detect context in a top-down manner

e58e5a4e56bb1fcce0d461a9ff3789eaf2e414fa greatly simplified how context is detected by completers.
In retrospect the context necessarily has to be detected in a bottom-up way; it was the multi-level if nesting that was a problem for the maintainability of the code. So closing.


chore: upgrade docs dependencies and fix warnings

Current dependencies on/for this PR:

main

PR #217   👈

PR #218

This comment was auto-generated by Graphite.


all Karma test failed

when i use angular-trello modules into my service,
all my karma test is failed with below error code
Failed	should return task description group list. if empty, return empty	Filter: taskGroupToMe
TypeError: 'undefined' is not an object (evaluating 's.parentNode') at /home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular-trello/src/angular-trello.js:111 at invoke (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4523) at /home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4344 at forEach (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:340) at createInjector (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4344) at workFn (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular-mocks/angular-mocks.js:2428)
Failed	should return task description group list with ascending order input.	Filter: taskGroupToMe
TypeError: 'undefined' is not an object (evaluating 's.parentNode') at /home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular-trello/src/angular-trello.js:111 at invoke (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4523) at /home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4344 at forEach (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:340) at createInjector (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4344) at workFn (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular-mocks/angular-mocks.js:2428)
Failed	should return task description group list with descending order input.	Filter: taskGroupToMe
TypeError: 'undefined' is not an object (evaluating 's.parentNode') at /home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular-trello/src/angular-trello.js:111 at invoke (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4523) at /home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4344 at forEach (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:340) at createInjector (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4344) at workFn (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular-mocks/angular-mocks.js:2428)
Failed	should return date group list. if userId has assigned task, add completedAt property the task	Filter: taskGroupToMe
TypeError: 'undefined' is not an object (evaluating 's.parentNode') at /home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular-trello/src/angular-trello.js:111 at invoke (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4523) at /home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4344 at forEach (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:340) at createInjector (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular/angular.js:4344) at workFn (/home/comtin/.jenkins/jobs/dev-deploy-dooray-was/workspace/src/main/webapp/client/app/bower_components/angular-mocks/angular-mocks.js:2428)

I think you need exception code like in angular-trello.js
...
}]).run([function(){
		var script = document.createElement('script');
		script.type = 'text/javascript';
		script.async = true;
		script.src = 'https://api.trello.com/1/client.js?key=' + options.key;
		var s = document.getElementsByTagName('script')[0];
		s && s.parentNode.insertBefore(script, s);
	}]);

here is pr #7


JSON Schema for simple 1000 genomes searchable metadata

Create a JSON schema for simple, searchable metadata of 1000 genomes samples. See the Data Portal for fields that can be included. This data model/schema will be used for the ISMB 2022 tutorial.
Potential fields we can include are:

Sample name
Sex
Biosample ID
Population code
Population name
Superpopulation code
Superpopulation name
Population elastic ID
Data collections

Also, there will need to be a field in the schema called wgs_cram_drs_uri or something similar. This field will contain a DRS URI to a DRS object that will reference a WGS CRAM file for that individual/sample.

closing as #18 and #17 were merged


Add error handling to event docs

Fixes #527
It's better practice to handle the errors, and it was throwing a lot of people off as the errors could crash applications if not handled correctly - sort of like an unhandled rejection.

either alan or suufi review when you get a chance please


Delta for adding TCP support?

What would you like to be added?
Support for TCP connections (instead of HTTP-only)
Why is this needed?
Interested in downscaling pods that accept TCP connection and don't make use of HTTP
I saw in another ticket (about gRCP and HTTP2) that Osiris relies on L7 proxies and thus only supports HTTP currently. What work would be needed in order to support TCP? Are there any known blockers or limitations that make it impossible altogether? If so, why/why not?
Assuming that it's possible, I'd be interested in helping out

I'm going to close this because plain TCP, at least w/out TLS+SNI, isn't something we can accomodate.

I'm looking to learn a bit more about what makes this unachievable without TLS+SNI. Is there a lurking assumption or implementation detail that's generating this constraint?

@ajbouh a TCP connection, by itself, doesn't include sufficient metadata for the activator to know which deployment needs to be scaled up from zero.
With HTTP, we get this information at L7 instead-- i.e. from the HTTP Host header. With HTTPS (HTTP over TLS), we can get this information from headers in the SNI extension to the TLS protocol.
For all other TCP connections, where the L7 protocol could be anything, we cannot know if sufficient information even exists to activate (and route traffic to) the correct deployment.

@krancour how does Osiris currently register itself to handle incoming HTTP traffic?
Perhaps we can listen on many host ports, one per TCP service? If we route each scaled-down service to a unique port, then we can use a simple lookup table to determine the correct deployment. Obviously there are some limits to this approach, but perhaps it would work well enough?

how does Osiris currently register itself to handle incoming HTTP traffic?

Osiris is made up of many components. I suspect this question is really about how traffic is redirected to the activator?
There is an endpoints controller that, for each Osiris-enabled service, watches the pods for that service. When none are in a ready state, it substitutes activator endpoints for application endpoints.
It's probably relevant to discuss how the activator works today:
The activator maintains map of all the different ways an Osiris-enabled service can be addressed (e.g. private and public IPs, DNS names, etc.) to deployments that should be activated when a request it serves is addressed accordingly. The activator sniffs all connections to figure out whether they are HTTP or HTTPS (TCP+SNI, really) and based on which it is, it knows how to figure out what the real destination of the request is and that becomes the input to that deployment lookup.

Perhaps we can listen on many host ports...

There's no reason to involve host ports in this. That one detail put aside, your idea isn't terrible.

Perhaps we can listen on many host ports, one per TCP service? If we route each scaled-down service to a unique port, then we can use a simple lookup table to determine the correct deployment.

If I may echo your proposal in more detail: The activator would listen on many ports. (Not one per Osiris-enabled service as you suggest, but actually one per port of each Osiris-enabled service. So, for the sake of illustration, if you have an Osiris-enabled service that listens on two ports, the activator would open two, available, unprivileged ports.) The mapping you have proposed would be a simpler one than the one we use now. It would say "when we get a new connection on a given port, activate this corresponding deployment."
Indeed, we already considered this very architecture at one point. It's attractive in that it would obviate any need to sniff the connections to find information about the destination from the connection itself-- which is a somewhat complicated process. The reason we did not use this approach is that getting the activator and the endpoints controller to agree on which activator ports map to which ports of a given service is a major, major hurdle.
I will elaborate.
Upon scale-to-zero, with the architecture you have proposed, the endpoints controller, unlike today, would have to rewrite the service's endpoints to direct traffic to specific ports on the activator. How would we get these two components to agree on which ports?
To solve for this, the first thing to consider is: Who decides which ports to use in the first place? The obvious answer is that the activator must be the one to make this decision because it knows which ports it currently has available to allocate for use with a given Osiris-enabled service. Two problems pop up immediately:

How does the activator inform the endpoints controller of which of its own ports it has allocated to each port of each Osiris-enabled service? I do not have a satisfactory answer for this yet.

What happens If the activator itself is scale to n > 1 replicas, how do you get all n replicas to independently allocate their ports in the same way? We wouldn't want, for instance, two activator instances where one has allocated port 5555 for service x port 80 activation while the other has allocated port 7777 for the same purpose.

I will make no claim that these challenges are unsolvable. But they're not solvable without a lot of new complexity. I also believe this is a very deep rabbit hole. I haven't thought past the challenges above enough to predict what new problems will be introduced by the added complexity. There are, for sure, many, such as (but not limited to) : Are we going to let the activator modify its own Service and/or Endpoints resources? We'd pretty much have to make those endpoints discoverable and usable by Osiris-enabled services that are scaled to zero. But then what would happen, for instance, on helm upgrade when all of the activator's modifications to its own Service or Endpoints resources would be obliterated. 🤷♂
I'll reiterate that I don't think any of this is impossible. It's simply a rabbit hole that I do not have the bandwidth to fall down. If someone else wants to pursue this, I would certainly entertain a detailed proposal and a PoC.

Thanks for the detailed write-up!
I don't understand the intricate interplay between the endpoints controller and the activator, but here's a an outline of something that might work without being too complex and without requiring too much coordination.
I say might because it depends on how much we can assume about clock drift.
Assigning a unique, bounded integer to every key in a set appears to be a solved problem in the world of open addressing (for hash tables). As long as each actor in the system uses the same hash function for the mapping, everything can work without additional coordination.
Of course, arriving at the same hash function is only possible if all actors have the same view of keys that require mapping.
One way to do this is to only handle services that have existed for some minimum quantity of time that is much greater than the propagation time for new kubernetes resources (for example resources updated on or before the second-to-last 5 minute mark). Then we can assume that all services will be mapped to the same offset in the available port range.
To avoid race conditions it would probably be best to support two different port ranges and alternate which is actually updated. This way it is always unambiguous which "version" of the map the activator is expected to use.
There are of course still open questions around how to modify the service to point to the activator, but I'm unfortunately ignorant to how the problem is solved in the current implementation.

I don't understand the intricate interplay between the endpoints controller and the activator

There is no interplay. Both components work independently of one another.
As to the rest of what you propose...
I've concluded through my own due diligence that we cannot support plain TCP connections without incurring an undesired level of complexity and I'll ask you to trust that I didn't arrive at that lightly. Apart from new complexity being undesired, I've previously noted I do not have the bandwidth to implement such a solution or to mitigate the new failure modes that will arise from that complexity.
I recognize that your suggestions are aimed at reducing the complexity to the point where the solution becomes tenable and I cannot emphasize enough that your ideas are welcome. At the same time, please do recognize that "it might work if if we do x, but I'm not sure", while well-intentioned, shifts the burden back to me to either explore your suggestion further or explain in detail why it cannot work. With my bandwidth being what it is, that's not a sustainable model for pursuing this further.
If you are serious about pursuing this, my best suggestion is that you take the time to understand the existing architecture, take the time to explore the unknowns in what you are suggesting, paying special attention to new failure modes and race conditions that may be created, then come back with a detailed proposal that leaves no stone unturned. Ideally, working code is even better.

Thanks for clarifying your perspective here.
Apologies for wasting your time. In my experience it's considered poor form to show up with a design and implementation without first soliciting input from the existing maintainer(s).
At the very least my comments here were intended to help plant seeds for a future implementation that might support this use case. I think the design I've outlined is both simple and correct as-is. I couldn't find any documented guarantees about worst-case-time-to-scale-down or about how existing edge cases are handled, so I made my caveat regarding clock-slew explicit.
Are there any docs that outline the existing architecture and  assumptions for the current implementation?  E.g. how is the existing system expected to handle event notifications falling behind? My searching of the current repository didn't yield much along these lines.
I'm motivated to help with implementation and testing, but I can't see it succeeding without support along the way from the existing maintainer(s).
Based on the conversation above, perhaps the project is currently too early/bandwidth constrained to support external contributors making major architectural changes? I can certainly relate to that sort of limitation.
Please correct me if any of the above is incorrect. Either way, I appreciate your quick and thorough responses.

Apologies for wasting your time.

No apologies necessary. No time was wasted. And again, I cannot emphasize enough the ideas are appreciated.

In my experience it's considered poor form to show up with a design and implementation without first soliciting input from the existing maintainer(s).

Certainly true. Coming to the table to with an implementation without some discussion occurring first could result in you wasting a lot of time on something that won't be accepted. That is in no one's interest. Let's say a design alone (i.e. without implementation) is a good starting point, but note that "if we do x it might work" falls short of what might reasonably be considered a design.

I think the design I've outlined is both simple and correct as-is.

I think the root issue here is that you haven't actually convinced me of this.

I couldn't find any documented guarantees about worst-case-time-to-scale-down

Not entirely sure how this is relevant. In any event "scale down" is achieved by setting desired replicas to zero. Kubernetes' own replication controller takes it from there. Your only guarantees are whatever it guarantees to you. But again... not sure why this is relevant.

so I made my caveat regarding clock-slew explicit

tbqh, I didn't (and still don't) understand the caveat about clock skew. I especially don't understand it as it relates to "worst-case-time-to-scale-down." And I don't understand how either of those things relate to port allocation on the activator. It's possible I am overlooking some obvious things here. I guess I have to own up to possibly having prematurely dismissed this idea due to a perception that you haven't connected the dots for me. Having said that, clearly connected dots are a reasonable expectation when major architectural changes are proposed.

Are there any docs that outline the existing architecture and assumptions for the current implementation?

The readme explains the architecture at a high level. For greater understanding, admittedly, you've got to get into the code. The code is, at least, liberally commented. I'm sorry that I don't have a more satisfying answer for this.

how is the existing system expected to handle event notifications falling behind?

Like the rest of Kubernetes, eventual consistency is the name of the game. Consider, for instance, what would happen to Kubernetes' own endpoints controller if it were not promptly notified that a certain pod was no longer in a ready state. The effect would be that traffic might be routed to an endpoint that isn't actually available. The effect on our endpoints controller would be identical. Or consider, for instance, what would happen to an ingress controller if it were not promptly notified of changes to a service that it uses as a back end for an Ingress. The effect would be misdirected traffic. The effect on our activator would be the same. I'm afraid I really do not have a good answer for how a component can compensate for the delayed delivery of an event it doesn't even know it's expecting. This isn't an Osiris problem. It's a Kubernetes problem.

Based on the conversation above, perhaps the project is currently too early/bandwidth constrained to support external contributors making major architectural changes? I can certainly relate to that sort of limitation.

Fair to say both. This is early-- note there hasn't even been an alpha release. We've made this public, but never formally released anything with even minimal guarantees of any kind. Anyone using this is using edge code at their own risk. At the same time, interest from the community has been, shall we say, minimal. With maintainers having other responsibilities as well, it's fair to say this project isn't highly prioritized right now... this does, however, mean there is an opportunity for community members to step up and make big contributions...
It was never my intention to take the wind out of your sails. I hope I haven't and I apologize if I have. I can only re-iterate that ideas are welcome, but for a suggestion of this scope (if I were sizing this, it is an epic), your proposal needs to be informed by the current architecture, framed in that context, and have all the dots explicitly connected. If that is something you can come back with, I welcome it.


New Analog App (nx v17) fails to build - trpc issue?

Please provide the environment you discovered this bug in.
I tried installing Analog using the NX preset on:
My Macbook and on gitpod.io - same results.
Which area/package is the issue in?
create-analog
Description
After creating a new NX Workspace with the Analog preset the build fails.
Please provide the exception or error you saw
$ npx create-nx-workspace@latest --preset=@analogjs/platform

 >  NX   Let's create a new workspace [https://nx.dev/getting-started/intro]

✔ Where would you like to create your workspace? · my-org
✔ Enable distributed caching to make your CI faster · Yes

 >  NX   Creating your v17.0.1 workspace.

   To make sure the command works reliably in all environments, and that the preset is applied correctly,
   Nx will run "npm install" several times. Please wait.

✔ Installing dependencies with npm
✔ Successfully created the workspace: my-org.
✔ What name would you like to use for your Analog app? · analog-app
✔ Add TailwindCSS for styling? (Y/n) · true
✔ Add tRPC for typesafe client/server interaction? (y/N) · true
Angular has not been installed yet. Creating an Angular application
Fetching @nx/angular...
Fetching @angular-devkit/core...
Fetching prettier...
✔ NxCloud has been set up successfully

 >  NX   Distributed caching via Nx Cloud has been enabled

   In addition to the caching, Nx Cloud provides config-free distributed execution,
   UI for viewing complex runs and GitHub integration. Learn more at https://nx.app

   Your workspace is currently unclaimed. Run details from unclaimed workspaces can be viewed on cloud.nx.app by anyone
   with the link. Claim your workspace at the following link to restrict access.

   https://cloud.nx.app/orgs/workspace-setup?accessToken=[my-access-token]

 >  NX   Successfully applied preset: @analogjs/platform

$ npx nx build analog-app

> nx run analog-app:build:production

node_modules/@trpc/client/src/TRPCClientError.ts:42:18 - error TS4111: Property 'error' comes from an index signature, so it must be accessed with ['error'].

  40 |   return (
  41 |     isObject(obj) &&
> 42 |     isObject(obj.error) &&
     |                  ^
  43 |     typeof obj.error.code === 'number' &&
  44 |     typeof obj.error.message === 'string'
  45 |   );

node_modules/@trpc/client/src/TRPCClientError.ts:43:16 - error TS4111: Property 'error' comes from an index signature, so it must be accessed with ['error'].

  41 |     isObject(obj) &&
  42 |     isObject(obj.error) &&
> 43 |     typeof obj.error.code === 'number' &&
     |                ^
  44 |     typeof obj.error.message === 'string'
  45 |   );
  46 | }

node_modules/@trpc/client/src/TRPCClientError.ts:43:22 - error TS4111: Property 'code' comes from an index signature, so it must be accessed with ['code'].

  41 |     isObject(obj) &&
  42 |     isObject(obj.error) &&
> 43 |     typeof obj.error.code === 'number' &&
     |                      ^
  44 |     typeof obj.error.message === 'string'
  45 |   );
  46 | }

node_modules/@trpc/client/src/TRPCClientError.ts:44:16 - error TS4111: Property 'error' comes from an index signature, so it must be accessed with ['error'].

  42 |     isObject(obj.error) &&
  43 |     typeof obj.error.code === 'number' &&
> 44 |     typeof obj.error.message === 'string'
     |                ^
  45 |   );
  46 | }
  47 |

node_modules/@trpc/client/src/TRPCClientError.ts:44:22 - error TS4111: Property 'message' comes from an index signature, so it must be accessed with ['message'].

  42 |     isObject(obj.error) &&
  43 |     typeof obj.error.code === 'number' &&
> 44 |     typeof obj.error.message === 'string'
     |                      ^
  45 |   );
  46 | }
  47 |

node_modules/@trpc/client/src/TRPCClientError.ts:103:7 - error TS2322: Type 'TRPCClientError<ErrorInferrable>' is not assignable to type 'TRPCClientError<TRouterOrProcedure>'.
  Type 'ErrorInferrable' is not assignable to type 'TRouterOrProcedure'.
    'ErrorInferrable' is assignable to the constraint of type 'TRouterOrProcedure', but 'TRouterOrProcedure' could be instantiated with a different subtype of constraint 'ErrorInferrable'.
      Type 'AnyProcedure' is not assignable to type 'TRouterOrProcedure'.
        'AnyProcedure' is assignable to the constraint of type 'TRouterOrProcedure', but 'TRouterOrProcedure' could be instantiated with a different subtype of constraint 'ErrorInferrable'.

  101 |     }
  102 |     if (isTRPCErrorResponse(cause)) {
> 103 |       return new TRPCClientError(cause.error.message, {
      |       ^
  104 |         ...opts,
  105 |         result: cause,
  106 |       });

Found 6 errors.

 >  NX   Found type errors. See above.

   Pass --verbose to see the stacktrace.

 ———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————

 >  NX   Ran target build for project analog-app (3s)

    ✖    1/1 failed
    ✔    0/1 succeeded [0 read from cache]

Other information
Adding the --verbose flag doesn't provide more information.
Setting noPropertyAccessFromIndexSignature to false in the tsconfig.json removes the TS4111-Errors.
I would be willing to submit a PR to fix this issue

[X] Yes
[ ] No

@goetzrobin ran into this also, the workaround for now is to set skipTypeCheck: true in the build executor options. What's the proposed fix as this is coming from the tRPC library?

@brandonroberts @Pascalmh I did some more digging and for some reason the trpc client and server packages include a src folder with .ts files. Deleting the folder manually allows me to build with the default setup...
I am trying to figure out why that folder is there. I'll see if I can find out what is going on

Weirdly enough I tried to see if I can replicate the issue with the @nx/vite builder and tRPC in a simple nx react application and there I am not getting the same issue... Which makes me wonder what config is causing it to type check node_modules 🤔

any news regarding this issue? I got the same trpc error on my next /react application is there a corresponding issue on trpc side?

@enisze that's interesting! That makes me think that this is a conflict between trpc & some typescript configuration... are you using Nx?

hey @goetzrobin no I am not using nx

I'm seeing this issue as well after following https://www.spartan.ng/stack/installation

I've been digging into this today. I've narrowed down some of the issues.
The Property 'error' comes from an index signature, so it must be accessed with ['error']. error being thrown specifically is happening due to noPropertyAccessFromIndexSignature being set to true in the app's tsconfig.json. Setting to false clears these errors.
This is occurring now as the code in question was just recently introduced in this PR in trpc: https://github.com/trpc/trpc/pull/4796
The above change was released in trpc v10.38.3: https://github.com/trpc/trpc/releases/tag/v10.38.3
Installing @trpc/client and @trpc/server version 10.38.2 doesn't have this issue, confirming an issue with the change above.
Similarly, the Type 'TRPCClientError<ErrorInferrable>' is not assignable to type 'TRPCClientError<TRouterOrProcedure>'. error is also introduced via the above PR. However, it is a bit more complex.
Testing, trpc has no issue compiling the client despite that type error / issue. Experimenting and checking typescript versions, this seems to be due to a type narrowing regression specifically in typescript 5.1.3, which trpc is currently built with. Downgrading to an earlier 5.1.x  version before the regression or upgrading to a newer 5.1.x version after the regression was fixed causes trpc to fail to build.
I didn't see any related issues reported on trpc's issues board, so I just created one: https://github.com/trpc/trpc/issues/5175

Enable skipLibCheck, it also helps ts perf
That said, we should still fix these in trpc

@KATT in this case skipLibCheck is true , but not having an impact during the build. From @goetzrobin 's earlier comment skipLibCheck seems to be running due to the full trpc source being included in the npm packages. According to the typescript docs skipLibCheck will only specifically ignore *.d.ts files: https://www.typescriptlang.org/tsconfig#skipLibCheck

I wonder if this could have something to do with the tsconfig path plugin. If you use the same tRPC in a new Nx workspace with React, do we get the same issue? I'll have to test that

@jeremyhofer it would still do it if it was only .d.ts-files. We ship the TS files with declarationMap so that people can CMD+Click into tRPC source code [and hopefully help with features and bugs]
I'd say most projects should use skipLibChecks, for a boilerplate it makes sense; otherwise, you'll play whack-a-mole on related projects with your project forever. Also, as previously mentioned, it improves TS perf.

By default, TypeScript performs a full re-check of all .d.ts files in a project to find issues and inconsistencies; however, this is typically unnecessary. [..]
— https://github.com/microsoft/TypeScript/wiki/Performance#skipping-dts-checking

(This has been my stance/default for the last few years, but I might be wrong and if I am I'd love to be educated)

I don't know why the build tries to compile stuff inside node_modules if skipLibCheck is off, I'm not aware of how Nx/analog works here but that sounds like something that should be addressed

Thanks for the additional context Katt.
I just raised #805 which looks to fix this. Some of the imports here in analog were importing directly from the src/ folders of the trpc packages, which was causing skipLibChecks to not be respected. I updated these imports to roll them into the standard library imports instead (minus one import into the dist/ folder in one of the libs.
Testing locally this seems to fix the build issues from the analog perspective. @goetzrobin can you take a look and help test the import changes?

@jeremyhofer thanks so much! I'll check this out first thing tomorrow! We do have the e2e test-app for trpc that verifies core functionality! If that still passes it should be good! Great work! I think that was one of the major issues of the trpc story...


Garbage collection removes image layers that are still needed by delta layers

A delta layer depends on the previous image layer, but the GC logic doesn't take that into account. For example, if you have layers like this:
xx_1000      - image layer
xx_1000_2000 - delta layer
xx_2000      - image layer

and the GC cutoff determined by the GC horizon is at LSN 1500, garbage collection would happily remove the xx_1000 layer because it's older than the GC cutoff. However, the xx_1000_2000 is now unusable, as it depends on the xx_1000 layer.

I bumped into this again. I created a branch while pgbench was running, and a 'clog' image layer was garbage collected away that was still needed.
-rw-r----- 1 heikki heikki 11074401 Nov  2 13:43 .zenith/tenants/8c655db247997627102eb67c57fc11e0/timelines/9dc829be5c616c83786c5c902b3d50ee/pg_xact_0007_0_0000000118F1F671_0000000124F74308
-rw-r----- 1 heikki heikki   266394 Nov  2 13:43 .zenith/tenants/8c655db247997627102eb67c57fc11e0/timelines/9dc829be5c616c83786c5c902b3d50ee/pg_xact_0007_0_0000000124F74308

The branch was being created at LSN 118F1F671, but the image layer was already removed:
2021-11-02T11:43:38.861743Z  INFO garbage collection{timeline=9dc829be5c616c83786c5c902b3d50ee tenant=8c655db247997627102eb67c57fc11e0 cutoff=1/22A85C88}: garbage collecting pg_xact/0007.0 1/18F1F670-1/18F1F671 false

The symptom this time was that the page server thread creating the base backup got stuck in an infinite loop while trying to materialize a block from that segment. It got stuck in this loop in materialize_page:

        // Call the layer's get_page_reconstruct_data function to get the base image
        // and WAL records needed to materialize the page. If it returns 'Continue',
        // call it again on the predecessor layer until we have all the required data.
        let mut layer_ref = layer;
        let mut curr_lsn = lsn;
        loop {
            match layer_ref.get_page_reconstruct_data(blknum, curr_lsn, &mut data)? {
                PageReconstructResult::Complete => break,
                PageReconstructResult::Continue(cont_lsn) => {
                    // Fetch base image / more WAL from the returned predecessor layer
                    if let Some((cont_layer, cont_lsn)) = self.get_layer_for_read(seg, cont_lsn)? {
                        layer_arc = cont_layer;
                        layer_ref = &*layer_arc;
                        curr_lsn = cont_lsn;
                        continue;
                    } else {
                        bail!(
                            "could not find predecessor layer of segment {} at {}",
                            seg.rel,
                            cont_lsn
                        );
                    }
                }

It kept looping with PageReconstructResult::Continue result, with the same LSN.
As an escape hatch, we should probably add a check there that you keep making progress, and don't get in an infinite loop if a layer is missing. And we should fix the original garbage collection issue, of course.

Opened a PR to fix that infinite loop: https://github.com/zenithdb/zenith/issues/707. But the original garbage collection issue that this issue tracks remains.

I've managed to reproduce the problem with gc/checkpoint config changes mentioned by @patins. Two tests had failed: test_branch_behind and test_readonly_node.
In test_branch_behind I see this as relation foo doesnt exist in the child branch. At the same time parent branch sees the table normally.
My current hypothesis is that we do not check that layers we delete are not needed by the child branch. So it looks like the sequence is:

Write something in branch A. On disk layers LSN intervals: 0-100
Branch B from A at LSN 105
Continue writing to A. On disk layers become: 0-100 101-200 201-300
Layer 0-100 is deleted by gc
Branch A cannot retrieve data from layer 0-100.

With more debug logs here and there in test_branch_behind I see the following picture:
Table foo is created in branch A.
Some inserts into it.
Branch B from A at LSN 0/16ED720.

Also I see one thing that is suspicious to me. I've printed retain_lsns at every gc run. And this is what I see:
cutoff=0/1CCF368}: retain lsns: []
...
cutoff=0/29E4BF0}: retain lsns: []
cutoff=0/2BF2748}: retain lsns: [0/16ED720]

Retain lsn appears later when gc already run against the layers near that retain lsn. So in my understanging gc can collect layers with retain_lsn. This is possible because we do not hold timelines map lock in branch_timeline.
Also I think that we should shorten GC interval, because with 100 seconds default (currently in main) it is not triggered at all during the test.

Is there anything left here, @LizardWizzard ?

I left this open because during investigation I faced two different issues, and probably this one also remains. As I can see it requires some improvements to testing harness because this pattern with layers is not that common with current code. I have an idea for a workaround though. I'll take a look at it

Yeah, there is bunch of open things left here, but we de-prioritized this in favor of re-balancing -- in tech preview we anyway do not expose branches.
And just to double-check: @LizardWizzard am I correct that issues that are still exist here are only related to branching?

This issue is not entirely related to branching, but in my understanding this problem shouldn't happen unless logic about creation of both, delta and image layer on checkpoint changes.

Actually you might be right! I thought you had to explicitly set a cutoff/checkpoint marker to exclude branching past that point. But it looks like gc cutoff can move independently on each gc run. That's also consistent with readme comments,
https://github.com/zenithdb/zenith/blob/2f784144fe335e30811dca0f86c7ff20ec2978dc/pageserver/src/layered_repository/README.md?plain=1#L338-L342
I trimmed gc params to make it more aggressive but I guess it's also making it move the cutoff point pretty fast.
--- a/pageserver/src/config.rs
+++ b/pageserver/src/config.rs
@@ -34,8 +34,8 @@ pub mod defaults {

     pub const DEFAULT_COMPACTION_PERIOD: &str = "1 s";

-    pub const DEFAULT_GC_HORIZON: u64 = 64 * 1024 * 1024;
-    pub const DEFAULT_GC_PERIOD: &str = "100 s";
+    pub const DEFAULT_GC_HORIZON: u64 = 1024 * 1024;
+    pub const DEFAULT_GC_PERIOD: &str = "1 s";

     pub const DEFAULT_WAIT_LSN_TIMEOUT: &str = "60 s";
     pub const DEFAULT_WAL_REDO_TIMEOUT: &str = "60 s";
diff --git a/pageserver/src/keyspace.rs b/pageserver/src/keyspace.rs
index 9973568b..7cfa3cb1 100644
--- a/pageserver/src/keyspace.rs
+++ b/pageserver/src/keyspace.rs
@@ -3,7 +3,7 @@ use postgres_ffi::pg_constants;
 use std::ops::Range;

 // Target file size, when creating image and delta layers
-pub const TARGET_FILE_SIZE_BYTES: u64 = 128 * 1024 * 1024; // 128 MB
+pub const TARGET_FILE_SIZE_BYTES: u64 = 1024 * 1024; // 128 MB

I've reread the code. The cutoff is calculated independently for each timeline and should move forward for every timeline:
https://github.com/zenithdb/zenith/blob/main/pageserver/src/layered_repository.rs#L690

so, is it correct that you can't branch off a child from its origin LSN once GCs run?

Hmm, the check might be too defensive. If there is already a branch that forces its parent to keep extra data, there shouldn't be any problems in allowing the creation of a branch here. But I think the only safe option is to allow duplication of the branch with precisely the same branch point. Because otherwise, we might've already garbage collected data before the branch point or after it. For the data before the branch point, GC running on the parent can remove something, and after the point, GC on the child can remove something. So it is a corner case :) Currently, we do not perform a precise analysis of what we can remove from the parent branch if the child branch no longer needs it. But I think we eventually should. So because we currently don't, branching creates a "snapshot" at the branch point even for a mutable branch.


[5.5] Add a compileForeign method to PostgresGrammar

With PostgreSQL driver, the methods Schema::disableForeignKeyConstraints and Schema::enableForeignKeyConstraints are in fact deferring the constraints.
In order for them to be deferred, they need to be deferrable, see https://www.postgresql.org/docs/9.0/static/sql-createtable.html :

Checking of constraints that are deferrable can be postponed until the end of the transaction (using the SET CONSTRAINTS command)

This pull request allows to add such a "DEFERRABLE" option in a migration :
Schema::table('children', function(Blueprint $table) {
  $table
    ->foreign('parent_id')
    ->references('id')
    ->on('parent')
    ->onDelete('cascade')
    ->deferrable('DEFERRABLE INITIALLY IMMEDIATE');
});

Possible values are :

NOT DEFERRABLE (Postgres default)
DEFERRABLE
DEFERRABLE INITIALLY IMMEDIATE (default of the previous line)
DEFERRABLE INITIALLY DEFERRED

Is there some standard default value we could give this method rather than forcing you to pass a magic string of commands?

Yes, but it would need to call two mehods :

->deferrable(false) NOT DEFERRABLE (which is the Postgres default if nothing specified)
->deferrable(true) or ->deferrable() DEFERRABLE  (by Fluent default)
->deferrable(true|empty)->initiallyImmediate(true|empty) DEFERRABLE INITIALLY IMMEDIATE  (for Postgres it the default of "DEFERRABLE" alone)
->deferrable(true|empty)->initiallyImmediate(false) DEFERRABLE INITIALLY DEFERRED

Tests have been added to reflect the different cases.


After upgrading to unocss 0.61.7+ (and unconfig 0.3.13 -> <IP_ADDRESS>), unocss-preset-daisyui stopped working.

UnoCSS version
0.61.7
Describe the bug
项目结构
nuxt + unocss +daisyui
unocss-preset-daisyui https://github.com/LeekJay/unocss-preset-daisyui
unocss-preset-component https://github.com/LeekJay/unocss-preset-component
问题描述
在unocss系列是0.61.6版本以下时 项目是可以正常工作的.
当在升级到0.61.7之后发现不能工作了, 主要是unocss-preset-daisyui不能正常工作
查看unocss主要是把unconfig 升级到了0.5.4,  通过强制版本为0.3.13也行
研究了好久, 没找到问题的解决方案, 还望大佬指点一下
"pnpm": {
    "overrides": {
      "unconfig": "^0.3.13"
    }
  },

Reproduction
https://stackblitz.com/~/github.com/kingyang/demo-nuxt-daisyui-unocss
https://github.com/kingyang/demo-nuxt-daisyui-unocss
System Info
No response
Validations

[X] Read the Contributing Guidelines.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Yeah any updates after  0.61.4, anything in my Uno.config.js doesn't work/ not getting loaded.


How do you set a default layout?

I've tried issuing the layout at various points, but i always run it too early as the nodes don't have a height yet.
Basically, I have altered the InputGroups story:

Removed position information from the nodes
Tried calling Dagre layout using useEffect and similar. The idea being to set a default layout if the nodes don't have positions.

I see. My first reaction is that the layout method is probably not what you're looking for. It sounds like we should just pass the nodes through the layout engine if positions are missing before handing them off to ReactFlow. I haven't vetted the idea fully or determined what the API for this would look like, but conceptually would this solve your problem?

Oh, there was another import that wasn't used. Small nit.

Problem is... you don't have height and width of the nodes yet, so it is difficult to layout.

Got it. Then I think we can take advantage of useNodesInitialized to apply the default layout if the position is missing. This hook should let us hook into the process the moment the nodes dimensions are calculated.
Do you have any thoughts or opinions on the API for configuring a default layout? If not, I can take a stab at something that makes sense to me and you can take a look after that.

Not familiar enough yet. Maybe an option to give to the editor: <NodeGraphEditor defaultLayout={LayoutEngine.Dagre} ...>

I have a version working, though I just send the layout function itself instead LayoutEngine.Dagre

Okay I'll take a stab at something. Send me what you did if you'd like and I'll see if it gets any juices flowing.

https://github.com/clarkmcc/ngraph/pull/15
This one is using your Enum for the layout.


[test] GPU bandwidth benchmarks

Refactored the old gpu bandwidth tests from cscs-checks/microbenchmarks/gpu/memory_bandwidth.py. The new benchmarks test H2D, D2H, D2D copies, and also P2P copies (with and without RDMA) across devices. The source code of this test works for both CUDA and HIP. However, the porting of this reframe test to AMD cards is deferred to a future PR.

Hello @jjotero, Thank you for submitting the Pull Request!

In the file cscs-checks/microbenchmarks/gpu/memory_bandwidth/memory_bandwidth.py:

Line 105:80: E501 line too long (86 > 79 characters)
Line 111:80: E501 line too long (85 > 79 characters)

In the file cscs-checks/microbenchmarks/gpu/memory_bandwidth/p2p_bandwidth.py:

Line 80:80: E501 line too long (85 > 79 characters)

Do see the ReFrame Coding Style Guide

Codecov Report

Merging #1539 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1539   +/-   ##
=======================================
  Coverage   87.90%   87.90%
=======================================
  Files          43       43
  Lines        6848     6848
=======================================
  Hits         6020     6020
  Misses        828      828

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a567e70...f5435d5. Read the comment docs.

You could perhaps use templates for your XClasses and specialize for CUDA and HIP, but that's fine.

Apart from my other comments. Would it make sense to set up this as a CMake project?

Yes, but I think it makes more sense to wait until we have the new parameterized tests out there and start building the test library. I'll then add support for HIP and perhaps also do

You could perhaps use templates for your XClasses and specialize for CUDA and HIP, but that's fine.

All good except a minor comment and the PEP unhappiness.

Uops! missed that one, sorry.

@jenkins-cscs retry tsa dom


yafc-ce: init at 2.0.1

Description of changes

New package - YAFC Community Edition, a planner and analyzer for modded Factorio. See https://github.com/shpaass/yafc-ce/ for more details.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Ofborg is having a moment.
@OfBorg eval

Squash the update commit against the init commit, producing a new yafc-ce: init at 0.9.1 commit.

I've built and tested the 2.0.1 package on x86-64 linux, works like a charm. I don't have a Darwin device to test that build, but seeing as it's a simple dotnet build, I assume it'll work.
I've added the Lua library file for aarch64 builds as it wouldn't launch without it when running on arm. I've only tested arm under binfmt.emulatedSystems, where I had display issues that I attribute to qemu. In either case, the upstream package doesn't provide arm linux builds, so it's not officially supported anyway.

I got curious why the x86-64 version didn't need a lua dependency, but the aarch64 version did. Turns out yafc-ce packages the liblua library files in the source repo. This includes Windows, Linux and Darwin, so I'll remove the dependency here (it would only have been used for Darwin builds, that already come prepackaged with the library file). I'm curious whether we should be packaging the lua libraries ourselves for all cases for the sake of reproducibility though.


Validation status fix + API access improvements

Contains #89
Host ns containers are not managed by Calico, but the kubelet will still use the plugin. This ensures that Calico does not fail setup/status calls.
Improve api access in get_pod_config

@caseydavenport care to take another look?

@alexhersh: A couple more comments regarding better log messages, but otherwise looks good.
Once those are fixed up I'll give a LGTM.

LGTM.


[Bug] path.join is not a function | use Node.js in Renderer

Hi, I love your module! Just having a problem getting it all to work. I'm not sure this is a bug on your end, but maybe someone can help me figure this out. I can' use any node modules, like path, fs and os. I'm now getting the following error:
TypeError: path.join is not a function
    at node_modules/electron/index.js (index.js:4:23)
    at __require2 (chunk-TSHM3N6P.js?v=72d195e1:16:50)
    at electron.js?v=72d195e1:6:16

electron/main.ts

  win = new BrowserWindow({
    webPreferences: {
      preload,
+     contextIsolation: false,
+     nodeIntegration: true,
    },
  })

nuxt.config.ts

+ import renderer from 'vite-plugin-electron-renderer'

  export default defineNuxtConfig({
    modules: [
      'nuxt-electron',
    ],
+   vite: {
+     plugins: [
+       renderer({
+         nodeIntegration: true,
+       }),
+     ],
+   },
  })

That fixed it! Thanks!


Code location for calculating mask IOU

Where does your code calculate mask IOU. Because I want to know how you transform the annotation data in the coco dataset and the result obtained by mmdetection into the same type of data.

https://github.com/open-mmlab/mmdetection/blob/d81990802cbd80f6d49fc35cdd255ebc353e4541/mmdet/datasets/coco.py#L386


Requests are very slow when building the app

Hi !
I'm encountering a pretty big issue with next-drupal, the build times are extremely high (on a localhost setup), I tried logging precise times in the built index.js in node_modules/next-drupal/dist and for every fetch I am getting between 1500ms and 4000ms which results in pages taking from 5 to 15 seconds to be built when running next build.
When I am running these requests myself with Postman (for example on /oauth/token which is ran by getAccessToken in next-drupal), it takes a maximum of 400ms. It is the same for every function used by next-drupal, getResourceByPath takes between 1500ms and 6000ms, etc...
The project I am working on needs to build around 2000 pages at build time, if the build of every page took around 2 or 3 seconds that would not be a big problem but the fact that right now it can take more than 10 seconds is just not conceivable.
I do not think it is caused by the fact that at build time it concurrently builds multiple page because when I am adding or editing a page the ISR takes between 5 and 15 seconds to (re)build the new page.
Do you have any idea of the cause ?

Interesting. I'll take a look at this.
How are you testing for the response time?

I take timestamps in and out of the requests Promises. I had the opportunity to do the same requests on the client side (project has some functional caveats that need some requests to be done on client). And those requests (including subrequests) take around 150 to 300ms in a local environment.
I don't think it is caused by the overload of the computer at build time as I thought it would be, since we have the same problem when we run the app in dev mode, even a single page can take around 8 to 15 seconds to load sometimes, depending on the content.
Also, in the case of a Drupal exposing its API publicly (no user accounts, one ruleset - one consumer), we should be able to bypass getAccessToken when not needed, in our case (since the requests are very slow) it only adds to the build time.

Agreed on the getAccessToken bypass. We are calling this for every request.

@Kroonax I'm going to mark this as fixed. It not, feel free to re-open.


Custom query should also have an option to get the raw data

I want to use the compile time option to make sure our queries are always correct and typesafe.
For this query we need to map the data ourselfs to already existing models. Currently this is not possible because there will be a newly generated model for without the option to get the raw data. I would like to see an option to get the QueryRow as a result of the compile time generated queries
@UseDao(tables: [
  DbChatTable,
  DbChatMessageTable,
], queries: {
  'chatWithLatestMessageAndUnreadCount' : '''
   SELECT
     *
   FROM db_chat_table
   INNER JOIN (
     SELECT *
     FROM db_chat_message_table
     ORDER BY date DESC
   ) db_chat_message_table ON db_chat_table.firebase_document_id = db_chat_message_table.chat_id
   LEFT JOIN (
     SELECT COUNT(*) AS "amount_of_unread_messages", chat_id, read
     FROM db_chat_message_table
     WHERE read = 0
     GROUP BY db_chat_message_table.chat_id
   ) db_chat_message_table2 ON db_chat_table.firebase_document_id = db_chat_message_table2.chat_id
   GROUP BY db_chat_message_table.chat_id
   ORDER BY date DESC;
  '''
})

Have you seen nested results? For your query, something like SELECT db_chat_table.**, db_chat_message_table.*, db_chat_message_table2.* should work. The generator will create a dbChatTable field to hold a row of that table, which should make the mapping easier.

The next option will introduce the raw_result_set_data option to do just this.


Handle error "Invalid JWT: Error: Token expired"

If the session has timed out, the user must be forced to log in again.
Need to delete the JSESSIONID token and reload the index.html page.  That will force the user to log in and start again from the top
If the session has expired, before redirecting to the index.html again,  it should put up a warning to the user, in a modal window, saying something like "Your session has expired.  Click the button to log in again"    The modal should contain a button that says something like "Login Again"

I have two questions about token:

Where should it be located? In payloads or in headers?
What error code is returned if token absent or wrong?

I reproduced this bug in Chrome:

I was logout after the session has timed out;
I was redirected to sigh in page (with email address and password fields)
After I clicked sigh in I was forwarded to following page (see image)

As you can see from next image, I got this error after I tried to login:

I have to mentioned, that it happens not everytime.
@robtweed maybe you could help?

Update on 05.07.2018
Regarding the previous bug: it seems I manage to find when it appears.
This bug I could reproduce in Chrome, Firefox, and Chrome (Android). In the first login, I see the Login page. I input email and password. After click Sign in I redirected on the error page.
Also, in Firefox today, after I tried to login under<PHONE_NUMBER>5 user, I got this message:

Update on this one from email trail;
############
thanks Alexandra
thats ok for now
Tony
On 10 July 2018 at 10:26, Alexandra Kuvakina<EMAIL_ADDRESS>wrote:
Hello Tony!
Re: #159
Regarding this one. I'm not with what it related, but for the past two days, I couldn't reproduce this problem. So, for now, I suggest to put in Exploring and return to it if I could reproduce this issue. What do you this about it?
On Tue, Jul 10, 2018 at 1:19 AM, Tony Shannon<EMAIL_ADDRESS>wrote:
thanks
re #159
I dont think this is related to PC turn off
What do you suggest as next steps on this issue please?
thanks
Tony
On 9 July 2018 at 16:03, Alexandra Kuvakina<EMAIL_ADDRESS>wrote:
From Alexandra:
According to  #159 : Handle error "Invalid JWT: Error: Token expired" ( https://github.com/PulseTile/PulseTile-React-Core/issues/159 )
I reproduced this bug in Chrome:
I was log out after the session has timed out;
I was redirected to sign in page (with the email address and password fields)
After I clicked sign in I was forwarded to the following page (see image)
This bug I could also reproduce in Firefox, and Chrome (Android). In the first login, I see the Login page. I input email and password. After click Sign in I redirected on the error page.
After discussing it with Julia (who also found this issue), we think maybe it happens when we turn off the computer before we could forcefully log out when our time run out.
In Chrome:
https://www.screencast.com/t/NFuV3q59hUA
In Mozilla:
https://www.screencast.com/t/NFuV3q59hUA

@kuvakina can you check to see if this is still occurring and comment here please. If you can't reproduce, we'll consider this closed

@PhilBarrett We still have this issue, but at the moment it occurring only in Chrome: https://www.screencast.com/t/1lO74RV9JXq1
Other browsers are fine.

thanks @kuvakina  then this needs further investigation to get to the root cause please

This should be fixed on the main UK Cloud system, but it wouldn't surprise
me if you see these errors on dev.
It's due to the login page having been sitting around for too long, and the
OpenId Connect session and the associated QEWD JWT  have expired in the
background.
To avoid it on dev, do a manual page refresh before logging in if you've
left the OpenId Connect login screen sitting there for more than 10 minutes.
Rob
On Fri, 5 Oct 2018 at 10:41, kuvakina<EMAIL_ADDRESS>wrote:

@PhilBarrett https://github.com/PhilBarrett We still have this issue,
but at the moment it occurring only in Chrome:
https://www.screencast.com/t/1lO74RV9JXq1
Other browsers are fine.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PulseTile/PulseTile-React-Core/issues/159#issuecomment-427305592,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZ6Ytvks80DValzCxL7mJy0NSfG9H1Xks5uhykdgaJpZM4UWRUk
.

--
Rob Tweed
Director, M/Gateway Developments Ltd
http://www.mgateway.com

@tony-shannon yes @robtweed  right, I see this issue on dev

Hi @robtweed , this still appears to be an issue in UK Cloud, see https://www.screencast.com/t/ngO7gkoJV . Could you take a look please?

I don't have Flash on my machine (and won't be installing it), so I can't view that screencast.
Under what circumstances are you seeing this error?  Can you provide me with a set of steps I can take to reproduce it?
Rob

Hi @robtweed , I don't have time to detail the steps, the picture shows all these clearly.
Appreciate you're busy right now, so we'll leave it in the to do column for now.

@robtweed I'll try to determinate when this error appears.
We have a supposition that we can solve it by erasing old token when the user login. But I think it's a frontend part.

Now not able to recreate, closing issue for now


upgrade deps

Codecov Report

Merging #2098 (88388ad) into master (11c6c24) will decrease coverage by 0.18%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2098      +/-   ##
==========================================
- Coverage   95.10%   94.92%   -0.19%
==========================================
  Files         409      409
  Lines        3803     3803
  Branches      458      458
==========================================
- Hits         3617     3610       -7
- Misses         96      101       +5
- Partials       90       92       +2

Impacted Files
Coverage Δ

packages/client/lib/errors.ts
95.65% <0.00%> (-4.35%)
:arrow_down:

packages/client/lib/client/commands-queue.ts
77.41% <0.00%> (-3.88%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 11c6c24...88388ad. Read the comment docs.


Update Zoom module to v1

Removed:

manager.js and manager.test.js files
Models folder

Added:

package.json file
definition.js file
Tests (api.test.js and auther.test.js)

📦 Published PR as canary version: Canary Versions

:sparkles: Test out this PR locally via:
npm install<EMAIL_ADDRESS># or
yarn add<EMAIL_ADDRESS>

This has been merged as part of https://github.com/friggframework/api-module-library/pull/10


Fix image links

Seeing as I am currently overhauling al rule logic I highly doubt this PR will still be valid.


bugfix: Footer: Report this Page tests working! [NP-1173]

So we now do a 3 step check during out wait for switch context

Wait until 2 windows have been detected
Once we have 2 windows (Note that a Tab and window are treated the same in this subsection of the Capybara API), detect which window is not the one we have current browsing context in (Always the other one) - Then switch to it
Wait until the current windows url is not about:blank

This should ensure we are always on the correct window, and that we have the correct loaded context.

So I actually found a way of querying the windows much easier when I dug into the docs #current? returns the handle that is equal to the current window context.
As for new window vs tab, Selenium treats them all as "Windows" with a "handle id". When you call switch_to with an id, it just switches and makes that the top level context


Normal is wrong with scaled mesh

Godot version:

3.3.rc b38a36923a
OS/device including version:

Kubuntu 20.10 / AMD RX570 / both GLES2 & GLES3
Issue description:

Normal goes wrong with scaled mesh.
Left - no scale, Center - 0.2 scaled on Y, Right - 5.0 scaled on Y

it looks Normal of the center and the right one is swapped.
same result on both gles2 and 3.
Steps to reproduce:
scale normal.zip
Minimal reproduction project:

@lawnjelly @clayjohn would you take a look?
it seems to be easy to fix but I have no idea with glsl :cry:

How does it look in Blender (or whatever modelling program it is made in)? Is there any chance your mesh has malformed normals?

@clayjohn
this is how it looks in blender

and ensure correct normal  does not make any changes.

for me, right one looks correct normal for the center one (even without ensure_correct_normal). isn't it?

Without ensure_correct_normals:

With ensure_correct_normals:

yes, I found it works on gles3 but not on gles2.
maybe it's a bug on gles2?

Ah yeah, looks like it was never implemented in GLES2.

Fixed by #47540.


Protect against long URIs

Prevents the non-exiting thread in #362.
This goes by the RFC definition of a request line in order to fail fast without reading the entire InputStream.

Coverage decreased (-0.03%) to 85.16% when pulling 19492e6fc4adac777f616ac6a4eff74d634b27a5 on WilliamDo:long-uri into 0c24a80b87195653b886464bd31ed12ab3652c7d on NanoHttpd:master.

Please add a unit test that fails if the thread hangs up (like it would before the fix).
I suggest not using your fix for the first run of that test, to make sure it works.

Coverage decreased (-0.03%) to 85.16% when pulling e43cda2e38544cd179e79b75c326039fdcd892ef on WilliamDo:long-uri into 0c24a80b87195653b886464bd31ed12ab3652c7d on NanoHttpd:master.

I added a unit test for checking the hanging thread by isolating the causal loop in ClientHandler. Will be adding more unit tests and an update shortly since I discovered the fix mistakenly identifies the case of matching exactly the buffer size as being too long.

Alright, keep going, let me know when you're happy with it so I can give a look at it :)

Coverage decreased (-0.004%) to 85.189% when pulling d3b3648786aeb3e616f63972c7ddbac85a4dea6c on WilliamDo:long-uri into 711b93aa3b4a57075257b0420dc3b2d15682573b on NanoHttpd:master.

Coverage decreased (-0.004%) to 85.189% when pulling a0880eafbf4e5769d604ef08c378bf3f11fed3f6 on WilliamDo:long-uri into 711b93aa3b4a57075257b0420dc3b2d15682573b on NanoHttpd:master.

Coverage decreased (-0.004%) to 85.189% when pulling d89462a88574529b3372ea9f38caab8d5a4887bf on WilliamDo:long-uri into 711b93aa3b4a57075257b0420dc3b2d15682573b on NanoHttpd:master.

Coverage increased (+0.05%) to 85.241% when pulling e641027603043705d5a8e98f0eb24f22a5f72eb7 on WilliamDo:long-uri into 711b93aa3b4a57075257b0420dc3b2d15682573b on NanoHttpd:master.

The approach I decided on was to buffer some extra bytes on the InputStream - I arbitrarily chose 8. The request buffer itself retains the original size. This allows us to inspect the InputStream for additional data. Let me know what you think.

I don't see the purpose of inspecting additional data, but I don't have exactly anything against it, as long as it serves a purpose. Can you elaborate?
This will conflict with a massive PR I am working on (you may see it, it has already been proposed but not yet merged) but once you get this done I can personally merge it.

Yeah I had another think about it and agree with you. In my first approach, I read additional bytes from the InputStream and as a result had to buffer some extra bytes to avoid conflicting with the code that resets to the mark.
After I discovered the available method on the InputStream, I changed the code but forgot that I didn't need to read past the 8KB anymore. I'll keep the call to available but think I will revert that section that reads the extra bytes.

Coverage increased (+0.05%) to 85.241% when pulling 5b72b512bf414056d0ecd3ec05f1b0dbebc185aa on WilliamDo:long-uri into 711b93aa3b4a57075257b0420dc3b2d15682573b on NanoHttpd:master.

Coverage increased (+0.04%) to 85.233% when pulling fa77abc0c537e42e4b2e5675b1c5d3516a604551 on WilliamDo:long-uri into 711b93aa3b4a57075257b0420dc3b2d15682573b on NanoHttpd:master.


More feedback on test 'harness'

Address comments from https://github.com/zettio/weave/pull/505 by @dpw

Coverage remained the same at 33.19% when pulling db9a0d7528bbeca78bdf36cecbc191ff7be812d5 on tomwilkie:coverage into df7836df62afcc2ebc5962271b526071080e4a61 on zettio:master.


Added support for pendulum Dates

This PR adds support for pendulum Date objects.

@Kludex I will merge this PR, as it looks like following all requirements


chore: upgrade deps

:tada: This PR is included in version 1.2.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Question, support android kotlin?

Good evening, I would just like to know if different from the original project that does not support running on android, as it does not have some imageio libraries. This project support android kotlin?

Hi @JhonnySalles !
Thank you for taking interest in the project.
I think there should be no problem using this library on Android. I have some dependencies, but they are ether pure kotlin (common module) or pure java (jvm module)
You can see the dependencies list here https://github.com/Ifropc/Kotomo/blob/695b67066bfdae0d1135a5ad66b9517fdf4fcf39/build.gradle.kts#L46
If you don't mind waiting, I can upload maven artifacts later this week for you to try it out (either today or Wednesday/Thursday)
FYI: the library itself is almost untouched compared to the original project, but I made some major changes here and there.
For example, I completely removed dictionary support.
Please let me know if you need it, I'll consider restoring it for the JVM implementation.
(This feature allows to look up OCR results in JMDict. I believe this specific functionality is most likely implemented by some third library)

@JhonnySalles I didn't have time to setup maven central deploy, you can use this pre-release
(I also haven't sorted out local changes, so it's slightly different from remote. Up to date sources are included)
Please extract it in ~/.m2/repository/io/github/ifropc/kotomo
Example of usage is here
https://github.com/Ifropc/kotomo-examples/blob/master/src/main/kotlin/Main.kt
This code runs OCR on image 1.jpg on point with coordinates [0, 0]
If you want to load image from memory simply wrap it to KotomoImage
val image = KotomoImageImpl(bufferedImage)

@JhonnySalles
I provided a maven package, it's available in the maven central (io.github.ifropc.kotomo:kotomo-jvm:0.1)
You can see example of usages here
https://github.com/Ifropc/kotomo-examples
This code runs OCR on image 1.jpg on point with coordinates [0, 0]
I'll close the issue for now. If you have any troubles with using the library, please feel free to open new issue.

Thank you very much for all the work, I have a manga reader in which I have already implemented tesseract and google vision, and I still need to add the kanji recognition. The kotomo at first did not work on android, but I will test your library.
Thanks again.