Click Drag Functionality + Refactor Interaction Interfaces

Requires https://github.com/space-wizards/RobustToolbox/pull/1132
Fixes #200 , also moves the various interaction interfaces / messages out into separate files because they were previously all in one file and that file was getting really big, also it puts them in the place where all the other component interfaces are for easier discoverability. Most of the "files changed" are just due to moving those interfaces to a different namespace.
Implemented drag and drop for storage objects, dragging a backpack in the world onto a table will empty the contents onto the table. Not sure this is particularly useful but it at least shows this system in action.
Main entry point for the new logic is in DragDropSystem.OnUse
Click Dragging works like this:

MouseDown over a draggable object, consumes the mousedown event (saves it to be replayed later)
Waits to see if you keep the mouse over that object and don't move it away. If you mouseup before that time, it consumes the mouseup and re-fires the original mousedown event (as if you clicked normally)
If you held down long enough, shows the drag shadow and highlights objects that can be dropped on within the viewport. Objects out of range are highlighted red. You are allowed to move around while dragging the object as long as you don't go out of range.
Upon dropping the item, it sends a DragDropMessage to the server which fires the appropriate hooks on the objects involved in the interaction.

You can change "Depends on" to "Requires" to have your engine PR be included in the build. Then you can uncommit the submodule changes.
I'm going to change the action so you can also say "Depends on" in the future.

@Zumorica should be good to go now
@ComicIronic I changed it to Requires but I'm not sure there's a good way I can "uncommit" the submodule change without rewriting history, and at this point the history has become a big mess because it includes commits from another PR that were already merged. I've tried cherry picking and interactive rebasing so I'm just going to give up and make it build by updating the submodule to the latest.

the submodule mess only happened because the old set of commits was from before I realized I'm not supposed to commit submodule changes, so it shouldn't happen again going forward

Ready to review again, fixed conflicts

fyi that failing integration test also fails on master

@ComicIronic fixed the conflicts again

Merge this poor man PR, he has worked so hard.

if you guys really need me to I can close this and put together a new "clean" PR for this work, cleaning up the history

If you want to do that go ahead but PJB always squash the PRs before merging

I would change two things

Reduce the time necessary to start click dragging something, right now is way too high
When you click drag near Clickable things the outlines appear

"Having to stay on the drag position before the drag starts is really annoying and it's unlike any other program ever."
Fair point. I'll remove that and leave it as just a deadzone (once you drag a certain distance from the origin the shadow appears). This may become an issue when more things become draggable and players are trying to click things while moving (accidentally triggering a drag when they meant to click) but that should be easily solved with some smarter deadzone logic.

@AJCM-git
"When you click drag near Clickable things the outlines appear"
The outlines show the things that the currently dragged object can be dropped on. It doesn't just outline every clickable thing. What do you want to change? I think the outlines are helpful to show players what their options are.

Oh, i assumed it was a bug if it is intended leave it be then


Added sciter js example

Hi Pravic, attached the sciter js minimal example
fixes #50

#50

Cool. Thanks!


renamed lib to src for core-http

Looks like you missed a rename:
samples/node-sample.ts(6,27): error TS2307: Cannot find module '../lib/coreHttp'.

There looks to be another tsconfig file it uses: tsconfig.es.json

Hmm this is interesting since I know we don't do this consistently. I thought the generated maps contained the file contents?
@bterlson

I don't know more than a high-level of how source maps work, but I do notice that the rollup version of the source map includes a sourcesContent member, whereas the source maps for the ES (module) output does not. So I imagine the TS files are at least needed for the modularized output. I don't know how hard it would be to change that.

Looks like we can fix this with the compiler option inlineSources - can we open an issue to track moving to this instead of reshipping all source files?

Opened the issue - https://github.com/Azure/azure-sdk-for-js/issues/7544

Awesome, I think we're good to go on this one then.


TLS origination for egress traffic example does not work

(NOTE: This is used to report product bugs:
To report a security vulnerability, please visit https://istio.io/about/security-vulnerabilities/
To ask questions about how to use Istio, please visit https://discuss.istio.io
)
The example service entry documented here: https://istio.io/docs/tasks/traffic-management/egress/egress-tls-origination/#tls-origination-for-egress-traffic does not work. It actually breaks all egress https traffic out of port 443 because of issue: https://github.com/istio/istio/issues/16458
Affected product area (please put an X in all that apply)
[ ] Configuration Infrastructure
[X] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Steps to reproduce the bug
Apply example in document:
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: edition-cnn-com
spec:
  hosts:
  - edition.cnn.com
  ports:
  - number: 80
    name: http-port
    protocol: HTTP
  - number: 443
    name: http-port-for-tls-origination
    protocol: HTTP
  resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: edition-cnn-com
spec:
  hosts:
  - edition.cnn.com
  http:
  - match:
    - port: 80
    route:
    - destination:
        host: edition.cnn.com
        port:
          number: 443
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: edition-cnn-com
spec:
  host: edition.cnn.com
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    portLevelSettings:
    - port:
        number: 443
      tls:
        mode: SIMPLE # initiates HTTPS when accessing edition.cnn.com
EOF

then
$ curl https://www.google.com
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol.

Version (include the output of istioctl version --remote and kubectl version)
istioctl version --remote: 1.2.0
kubectl version: 1.14
Environment where bug was observed (cloud vendor, OS, etc)
AWS EKS+Istio

Also see: https://github.com/istio/istio/issues/17314 and https://github.com/istio/istio/issues/16458


Clickable title

I use Asciidoctor 1.5.8.
I wanted to create a link in the main title. So I declared some attributes:
= {myurl}[{mytitle}]
:mytitle: Manufacture of liquid glue
:myurl: https://patents.google.com/patent/US1394654A/en

This is the corresponding line in html5:

https://patents.google.com/patent/US1394654A/en[Manufacture of liquid glue]

I expected more like this:

Manufacture of liquid glue

Is this a bug or did I miss something?

Sorry, wrong Asciidoctor.


Istanbul University mail address extension fixed

Istanbul University Web Page in English: https://www.istanbul.edu.tr/en/_
The student mail addresses specified with @ogr.iu.edu.tr
You can follow the link of Istanbul University Student Mail System the mail address extension top of the page.

@ErtugrulKra Thank you for the update! Pull request merged.


Clearer error on "change tips: never" with no tip on pipette

overview
"Change tips: never" usually means "reuse the tips carried over from the previous step for this pipette". But when there is no previous step for that pipette, it isn't a viable option.
current behavior
On the first step a particular pipette is being used, "change tip: never" gives an error like "tried to aspirate with no tip on pipette"
expected behavior
Since the only way to fix the problem is for user to change the "change tip" dropdown on that particular form, maybe this should be a form-level error that comes up immediately when "change-tip: never" is selected, on a step form using a given pipette for the first time in the protocol?
@howisthisnamenottakenyet

@IanLondon Would it be possible to disable the 'never' option in that scenario?

@howisthisnamenottakenyet
We couuuld but then if a user deletes upstream steps (Step 1: always, Step 2: never, delete number 1) we still have to deal with it. And if later we allow copying and re-arranging steps, disabling options in general based on where the step is in the timeline makes that process more complicated.

Fair! I'll add it as an on-blur warning in our errors doc.
Ideally down the line when we have time it'd be nice to add more complex disabling logic.


Add cloudwatch log group terraforming

Adding @mikeurbanski1 's contribution to the main fork as well

@googlebot  I fixed it.

@googlebot I consent.

@googlebot I consent.

@googlebot I fixed it

@googlebot I consent


Support for two-factor when using Jwt

Here is my Startup.cs
services
                .AddAuthentication(options =>
                {
                    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                    options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
                    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
                })
                .AddJwtBearer(cfg =>
                {
                    cfg.RequireHttpsMetadata = false;
                    cfg.SaveToken = true;
                    cfg.TokenValidationParameters = new TokenValidationParameters
                    {
                        ValidIssuer = Configuration["Tokens:Issuer"],
                        ValidAudience = Configuration["Tokens:Issuer"],
                        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(Configuration["Tokens:Key"]))
                    };
                });

My login action:
[HttpPost]
        public async Task<object> Login([FromBody] LoginViewModel model, string returnUrl = null)
        {
            var result = await _signInManager.PasswordSignInAsync(model.Email, model.Password, false, false);

            if (result.Succeeded)
            {
                var user = await _userManager.GetUserAsync(User) ;
                return GenerateToken(model.Email, user.Id);
            }

            if (result.RequiresTwoFactor)
            {

                var user = await _signInManager.GetTwoFactorAuthenticationUserAsync();
                var result2 = await _signInManager.TwoFactorAuthenticatorSignInAsync(model.TwoFactorCode, false, false);

                if (result2.Succeeded)
                {
                    return GenerateToken(model.Email, user.Id);
                }
                else
                {
                    return BadRequest("Invalid two-factor token");
                }
            }

            return BadRequest("Invalid login attempt");
        }

GenerateToken():
private object GenerateToken(string email, string userId)
        {
            var claims = new[]
            {
                new Claim(JwtRegisteredClaimNames.Sub, email),
                new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()),
                new Claim(new ClaimsIdentityOptions().UserIdClaimType, userId),
            };

            var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_config["Tokens:Key"]));
            var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);

            var token = new JwtSecurityToken(
                issuer: _config["Tokens:Issuer"],
                audience: _config["Tokens:Issuer"],
                claims: claims,
                expires: DateTime.Now.AddDays(30),
                signingCredentials: creds
            );

            return new JwtSecurityTokenHandler().WriteToken(token);
        }

If I enable two-factor login for user, GetTwoFactorAuthenticationUserAsync() returns null.
When testing example MVC app that comes with --auth option, I saw it's putting a cookie named Identity.TwoFactorUserId when logging if two-factor login enabled, how can I reproduce this using Web Api & Jwt?
Thanks.

The current TFA support is only intended for cookies flows

Are there any plans to integrate it to Jwt authentication?

The 2fa in this case should really be at the JWT issuance point, that's where login takes place, that's what needs protected.

@jatarga Hello, I am having the same issue. Can you please share how did you get this to work? My code has very similar flow as yours. Currently, when I run var user = await _signInManager.GetTwoFactorAuthenticationUserAsync(); it is returning null. Is there another function we can use? I even tried to SignInAsync(user,...) prior to running the GetTwoFactorAuthenticationUserAsync() and same issue.
Thank you!

@antoinecfmws I didn't implemented.

@jatarga thank you for your response. @blowdart do you agree that the JWT should not be issued until the 2FA code has been verified? If so, there has to be a way to validate the 2FA code using SignInManager and be able to pass in an instance of the user object or the user Id. Thoughts?
Thank you!

@jatarga, I found a good workaround for now, I was looking at the implementation of SignInManager.TwoFactorAuthenticatorSignInAsync(..) and noticed that it uses UserManager.VerifyTwoFactorTokenAsync(...) internally. So I was able to use that as well:
var codeValidated = await _userManager.VerifyTwoFactorTokenAsync(user, new IdentityOptions().Tokens.AuthenticatorTokenProvider, model.Code);


A way to close a popover from parent's component

Hello, the popover component opens and closes based on the trigger mode only (click, focus, etc).
But, I'm trying to close an opened popover differently, for example, after clicking a button inside the popover's content (slot).
I can't for example:
import { popover } from 'vue-strap'
// ...
this.popover.show = false

Is there a way to close it from a parent?
Thanks in advance!

I have had luck giving the popover a ref and using that to call the toggle() method on the popover.
In the template:
<popover ref="myPopover" ...

Then, in your component code:
this.$refs.myPopover.toggle()


Fix Sleep and HDMI update RTL8111 for Macos 11.4

Add DeviceProperties for RX640, fix HDMI and sleep
Update RTL8111 kext for 11.4
Update WIFI and Bluetooth kext

Hey @Zer0xPoint what hardware are you working on?

ThinkPad E14 10210U + RX640 + Intel 7260
Sent from my iPhone

On 7 Jun 2021, at 9:08 PM, Anish Kulkarni @.***> wrote:

Hey @Zer0xPoint what hardware are you working on?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Also find out that the TypeC port can be used as a HDMI output
Sent from my iPhone

On 7 Jun 2021, at 9:44 PM, Riley Lee @.***> wrote:
ThinkPad E14 10210U + RX640 + Intel 7260
Sent from my iPhone

On 7 Jun 2021, at 9:08 PM, Anish Kulkarni @.***> wrote:

Hey @Zer0xPoint what hardware are you working on?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Hello there! I've tried applying your fixes to my machine, that has only has the integrated graphics, the HDMI is still not working

That’s weird, what about sleep?with the lid closed and unplugged, my machine works fine.
Sent from my iPhone

On 7 Jun 2021, at 11:57 PM, fdbsilva @.***> wrote:

Hello there! I've tried applying your fixes to my machine, that has only has the integrated graphics, the HDMI is still not working
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

That’s weird, what about sleep?with the lid closed and unplugged, my machine works fine.
…
Sent from my iPhone
On 7 Jun 2021, at 11:57 PM, fdbsilva @.***> wrote:  Hello there! I've tried applying your fixes to my machine, that has only has the integrated graphics, the HDMI is still not working — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

When I close the lid, the red light does not flash as when in Windows, it stays lit, but the notebook entered sleep mode apparently, when opened the lid back, it asked me for password. The trackpad and keyboard worked fine after the wake. Thanks again

I think the process was not completed, tested again, and this time the light started flashing. When I opened the lid, it asked for the password. After that, the trackpad stoped responding, just the keyboard works

that's really weird, sleep works every time on my E14

I don't install win10, so I can't test the sleep in win10. can you find rx640 under macOS's system report-Graphic/Displays?

I don't install win10, so I can't test the sleep in win10. can you find rx640 under macOS's system report-Graphic/Displays?

Actually no, my E14 has no extra GPU, only the onboard graphics, but since the hackintosh normally can´t use GPUs, I've tried it anyways, with no success regarding the HDMI or the sleep. Thanks for your effort and for sharing your work

I think the process was not completed, tested again, and this time the light started flashing. When I opened the lid, it asked for the password. After that, the trackpad stoped responding, just the keyboard works

Yes. This is the exact problem I'm facing :(
The notebook goes to sleep well. But after waking, the TrackPad just stops working until I restart.

I see that there are a lot of conflicts while merging this pull request. I'll basically make the changes manually and create my own pull request for this.


Problem: Liveness probe too aggressive

Whats the issue here caused by liveness probe being aggressive ?

Sometimes, failures are caused by network delays or tendermint recovers itself. So keeping it a bit laid back.

I wanted to better-understand what periodSeconds means, so I looked it up. Apparently it is how often the kubelet performs a liveness probe.
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes
timeoutSeconds is "Number of seconds after which the probe times out." Maybe we should be increasing that?

We already have a max timeout of 10 seconds here(https://github.com/bigchaindb/bigchaindb/blob/master/k8s/bigchaindb/bigchaindb-ss.yaml#L139), which should be sufficient because it is being resolved over localhost.  I am just changing the frequency of the the probe.


Maya: Deadline asset dependencies not working properly

Describe the bug
We have a feature of checking asset dependencies turned on by default for Maya jobs submitted to Deadline

In many cases, it is creating issues with checking all the assets used in the Maya scene and not starting the render indefinitely waiting for dependencies to be fulfilled.
Maybe the issue is with the tokens in file names

I would definitely suggest turning this off by default and leaving it optional as it is creating more troubles at the moment and it makes sense only in cases when uploading the render scene to the cloud or other RARE cases.
[cuID:2fexvep]

I agree that it's given us more trouble than it's worth too. :)

Also we have had cases with an empty entry popping up in the list with both asset name and full path just being empty. Not sure why yet - but those also keep the job from starting.

Was this issue resolved with this PR https://github.com/ynput/OpenPype/pull/4242?

Was this issue resolved with this PR #4242?

I don't think so. There was a different issue of setting wrong dependency between render and tile assembly job. (assembly job should be dependent on render job to finish first)


Introduce procedural @implements tag..

This suggestion is based on an observation in Drupal 7.
It is becoming less of a problem with more and more code being OOP (e.g. moving to Drupal 8), but it might still apply to some people or more, for some time or longer.
Problem: The framework (or CMS) forces a specific parameter signature for functions with a specific role.
In Drupal 7 these are hooks, theme functions, form builder functions, etc.
The IDE does not know this, and complains about unused parameters.
For a class method overriding an interface method, it does not care if parameters are unused, because it understands that the parameters are required. But for procedural, this does not work.
The official way to document this in Drupal 7 is "Implements hook_foo()". But this is too much of a Drupalism to suggest support by the IDE or phpDocumentor. Also, it only applies to hooks, not to theme functions or form callbacks.
So I am going to suggest an @implements doc tag for functions, methods and closures - equivalent to the native "implements" statement, but on function level.
The @implements tag would indicate that the function has the same (or weaker) signature as the one it implements, in the same way that a class method must have the same (or weaker) signature as the interface method it implements.
An IDE that understands this could

Complain about signature mismatch.
Stop complaining about unused parameters in the implementing function.

This is how it would look like:
function hook_eat(Food $food) {}

/**
 * @implements hook_eat()
 */
function my_eat(Food $food) {
  // No need to actually use the $food parameter.
}

/**
 * @implements hook_eat()
 */
$f = function(Food $foo) {
}

class C {
  /**
   * @implements hook_eat()
   */
  static function eatQuietly(Food $foo) {}
}

Old discussion on drupal.org: https://www.drupal.org/node/983268 (I am not promising anything about whether the Drupal community will pick this up)
Doxygen has something like it, but I don't quite understand how it is meant to be used..
http://www.stack.nl/~dimitri/doxygen/manual/commands.html#cmdimplements

EDIT: I just realize there is a github user with this name :)
Code formatting of @implements helps.

Hi @donquixote,
To ensure that we have a single place for this discussion I am going to close this item for now. Not because it is rejected or anything but because it helps to gather as many opinions as possible on the mailing list and prevent duplicate discussions or any mismatches resulting from discussing this item in two places

I just wrote a topic on discussing things on the PHP-FIG mailing list but this is the phpDocumentor issue tracker itself; which is home to experimental stuff ;)

I invite anyone here to comment on this issue but I am interested in the opinion of other FIG members before diving too deep into this request right now

I don't speak for them, but I guess WordPress should be interested in this, since most of the application's architecture is based on hooks.  Due to their backwards-compatibility policy, that's most probably going to stay for many years to come.
There are probably several other legacy systems with similar architectures that could benefit from @implements, so :+1: for setting up a simple standard way for documenting these kind of procedural function relationships.

+1 to @implements

Reading the discussion on PHP-FIG: https://groups.google.com/forum/?fromgroups=#!topic/php-fig/49ZfuJ1iisg
I think the best would be to use @signature instead of @implements
Or @implements_signature
or @function_signature
or @method_signature
or something like that
@implements indeed could be mixed with interfaces and especially {@inheritdoc}.

Please have a look at the linked issue as well. The @implements tag could make sense in situations where we actually want to refer to an interface; e.g. traits that implement interfaces.

I like @signature. It seems unfamiliar as a docblock tag, but the meaning is 1:1 what we want.
I do not trust my own memory here, but at least https://en.wikipedia.org/wiki/Type_signature says that it specifies parameters, return type and errors (exceptions), so I assume this is the most common understanding of the term. It is interesting to see how other languages do it.
The other option I see is using something that works with @type/@var and @param, and that we still have to specify in more detail.
This is less intuitive at first, but the advantage would be that it can also be used on variables.
function fooProto(X $x) {}

/**
 * @param X $x
 *
 * @ŧype function:fooProto()
 */
function fooImpl(X $x) {}

/**
 * @var function:fooProto()
 */
$callback = 'fooImpl';

/**
 * @param function:fooProto() $callback
 * @param X $x
 */
function callFoo($callback, X $x) {
  $callback($x);
}

Otherwise we would have different constructs for callback variables and the actual function declaration.

Other interesting questions:

Is there some kind of inheritance?
E.g. with interfaces, the parameter signature of a method can be equal or weaker / more permissive than its parent, and the return type and @throws can be equal or more committed / specific.

Are two methods with the same parameters, return type and @throws, but with different @signature tags, considered to be compatible, or not?

Example for the second question:
function fooProto(X $x);
function barProto(X $x);

/**
 * @param function:fooProto $callback
 * @param X $x
 */
function callFoo($callback, X $x) {
  callBar($callback, $x);
}

/**
 * @param function:barProto $callback
 * @param X $x
 */
function callBar($callback, X $x) {
  $callback($x);
}

Note that the specification of a function/method is already possible with the @param tag since its definition states that any FQSEN is supported. All of the following are valid constructs:
/**
 * @param \global_function $p
 * @param \GLOBAL_CONSTANT $p
 * @param \$global_variable $p
 * @param \GlobalClass $p
 * @param \Name\Spaced\function $p
 * @param \Name\Spaced\CONSTANT $p
 * @param \Name\Spaced\Class::$property $p
 * @param \Name\Spaced\Class::function $p
 * @param \Name\Spaced\Class $p
 */

Note that you could include brackets for the functions if you like. All in all, there is no need for the function prefix.
The problem with the @type tag is that it was/is already in use as an alias for @var by some. This would mean that we give it a new meaning and create problems for some users and tools.
I am still in favor for the @implements tag and extend its scope from traits (as proposed in the other issue of mine) to any structural element. However, I understand that there might be confusion and that the name ties it to the interface data type. After giving it some though I propose @provides. This could be used for any kind of structural element, makes sense in English sentences, and expresses best what the structural element does.

Logger trait provides logger interface.

/**
 * @provides \Psr\Log\LoggerInterface
 */
trait LoggerTrait {}

Implemented function provides prototype's function signature.

function fooProto(X $x) {}

/**
 * @provides \fooProto
 */
function fooImpl(X $x) {}

Callback provides prototype's function signature.

function fooProto(X $x) {}

/**
 * @provides \fooProto
 */
$cb = function (X $x) {}

@donquixote That is why I think that the things are related, we can reuse and combine it. :blush:

@Fleshgrinder

Note that the specification of a function/method is already possible with the @param tag since its definition states that any FQSEN is supported.

This may be true, but so far I don't think there is a common agreement what it means to use a function FQSEN as a @param type specifier. If we want to agree that this can specifies a callback type, fine.

The problem with the @type tag is that it was/is already in use as an alias for @var by some. This would mean that we give it a new meaning and create problems for some users and tools.

Ok. So we could allow function signature type specifiers in @type / @var on callback variables, but we would need a different tag for function/method declarations, to avoid confusing some tools.

I am still in favor for the @implements tag and extend its scope from traits

I am ok with this, but regard it as independent from this discussion.

However, I understand that there might be confusion and that the name ties it to the interface data type.

I understand the confusion (as stated before), although to me it simply means we would be bold and extend the meaning to a new domain. This would be a creative and autonomous action, but I don't see it creating a real conflict - except what I said in my previous comment about inheritance and such.

After giving it some though I propose @provides. This could be used for any kind of structural element, makes sense in English sentences, and expresses best what the structural element does.

I am not very convinced of this term. To me, "provide" is a fuzzy word, and I somehow associate it with "give". E.g. @provides int to me sounds similar to @return int.

/**

@provides \fooProto
*/
$cb = function (X $x) {}

I think here I would work with @type / @var, because a closure IS a variable.

Other interesting questions:

Is there some kind of inheritance?
E.g. with interfaces, the parameter signature of a method can be equal or weaker / more permissive than its parent, and the return type and @throws can be equal or more committed / specific.

Here it gets funny.
In regular use of the terms, an interface can "extend" another interface, a class can "extend" another class, but only a class can "implement" an interface.
On the other hand, if we use this for functions, a function can "implement" another function, which can "implement" yet another function.

Are two methods with the same parameters, return type and @throws, but with different @signature tags, considered to be compatible, or not?

(see code example 3 posts before)
To me, the term "signature" only describes the parameter types, return values and such, so @signature fooProto() would be equivalent with @signature barProto().
On the other hand, "implements" to me implies a semantic meaning beyond just the raw signature. So @implements fooProto() to me would NOT be equivalent/interchangeable with @implements barProto().
@implements fooProto() would be a imply @signature fooProto(), but not in the other direction.

Ummm.. @param does not support aan fqsen. It has a Type as first argument

@mvriel oops you are of course right, it does not support FQSEN. Would it be a problem though? On the other hand, allowing it also creates confusion:
/**
 * @param \Name\Spaced\Class::function $cb
 */
function fn(callable $cb): string {}

Well, what is correct now? How do we verify (statically) that things are as they should be (easy and fast)? I don't know if this is feasible or even possible. Maybe you can shed some light on this matter. Note that the function prefix within @param has the same problem. However, we should think about FQSEN support and other reusable and well known syntax before introducing new kinds of prefixes; e.g. we could use generic syntax:
/**
 * @param callable<\Name\Spaced\Class::function> $cb
 */
function fn(callable $cb): string {}

But I dislike this version compared to the previous one because we repeat callable and did not really solve the problem.

I understand the confusion (as stated before), although to me it simply means we would be bold and extend the meaning to a new domain. This would be a creative and autonomous action, but I don't see it creating a real conflict - except what I said in my previous comment about inheritance and such.

Actually I fully agree with you that it does not create confusion. For me the things with implements is crystal clear because it depends on context, like the extends keyword does.

I am not very convinced of this term. To me, "provide" is a fuzzy word, and I somehow associate it with "give". E.g. ´@provides int´ to me sounds similar to ´@return int´.

I do not share this association but it seems like a bad keyword if it could create such confusion.

I think here I would work with @type / @var, because a closure IS a variable.

You are right and I agree that the @var would be sufficient. However, it has the same problem as described before and we would need to either support FQSEN (and IDEs would need to check on their own what kind it is) or something else that tells the full story. Btw. we could also say that functions actually require the brackets. But that would be different to how FQSENs are currently parsed through most tools and IDEs.

@Fleshgrinder

Well, what is correct now? How do we verify (statically) that things are as they should be (easy and fast)? I don't know if this is feasible or even possible.

Well, first of all, "class" and "function" are reserved words, so i am going to rename them in the example.. Also, I like to add the "()" brackets to the type specifier. So, your modified code sample with some extra stuff:
/**
 * @param \N\C::fooProto() $f
 * @param \Animal\Duck[] $ducks
 */
function fn(callable $f, array $ducks): string {}

For both parameters, the PHP type hint is different from the doc type specifier. For both parameters, the doc type specifier is more specific than the PHP type hint, because phpDocumentor has a higher expressiveness than PHP itself. And in both cases, when analysing, the more expressive version wins.
Or where do you see the problem?

Btw. we could also say that functions actually require the brackets.

Well.. I prefer the brackets, makes it more obvious to everyone on first sight.
Without the brackets, your example with would still be clear. What else can \N\C::fooProto be, if not a method?
On the other hand, a procedural function and a class with the same name can coexist. So yeah, this would be a reason to require the brackets.

But that would be different to how FQSENs are currently parsed through most tools and IDEs.

Currently, my IDE (PhpStorm, who would have guessed) does not support functions in @param, afaik, or at least it does not do anything useful with it.
It does support them in @see, though, and there the brackets allow it to distinguish class vs function.
And if not: What is the worst that could happen, really?
Any decent docblock inspection tool should be robust enough to survive some unexpected and "confusing" stuff.
@mvriel, @Fleshgrinder

Ummm.. @param does not support aan fqsen. It has a Type as first argument

Imo, we should forget about this "everything is an fqsen". In @param, we could say "everything is a type", and then we simply need to say that a callback signature specifier IS a type. Yes, it should be specified with the fully qualified namespace, but I don't care if the complete thing including the brackets is considered an fqsen. It is a type (if we interpret it as such), that is enough.

But, all of this said, this does bring me to a different concern.
If we consider \N\C::fooProto() as a type to be used within @var/@type/@param/@return, then is it really clear enough that this means "any callback that has the same signature as \N\C::fooProto()", or "any callback that has a @implements \N\C::fooProto() docblock"?
Or is this too much of a leap? Would the more natural/intuitive understanding be "the callback that references \N\C::fooProto() itself"? E.g. the string "N\\C::fooProto", or the array ["N\\C", "fooProto"]?

Imo, we should forget about this "everything is an fqsen". In @param, we could say "everything is a type", and then we simply need to say that a callback signature specifier IS a type. Yes, it should be specified with the fully qualified namespace, but I don't care if the complete thing including the brackets is considered an fqsen. It is a type (if we interpret it as such), that is enough.

I am not a big fan of making a FQSEN count as a Type; it seems to me that we're trying to show-horn a desired feature in the wrong place. As I see it, what you want is to provide meta-data about the Type (which is callable).
Have you checked how other languages solve this issue? I can imagine that JSDoc or RDoc may have hit this bump before?
If other languages do not have a similar construct then I propose we use the Inline PHPDoc style together with a new tag to indicate what the expected signature for a callback would be.
For example something like this:
/**
 * @param callable $f {
 *     @signature (int $a, int $b)
 * }
 */

Though I must address that we are now discussing two things at the same time:

being able to hint that a function matches the signature of an invoking entity
being able to indicate the signature of a passed callable

I suggest focussing on the former for now and starting a new discussion for the second since they seem to be only remotely related to eachother

Though I must address that we are now discussing two things at the same time:

being able to hint that a function matches the signature of an invoking entity
being able to indicate the signature of a passed callable

I think these two things depend on each other, and that at least for a while it is better to discuss them in the same issue. But if you disagree, we could open a new one for the @type/@param stuff.

I am not a big fan of making a FQSEN count as a Type

Well.. what I suggest is not that every FQSEN is a Type, but that \N\C::foo() is a type, a specialization of callable. I am not sure that \N\C::foo() is even an FQSEN, and I say it does not matter.
We could change the syntax of this, if people don't like it.

As I see it, what you want is to provide meta-data about the Type (which is callable).

Well.. \N\C[] is a specialization of array, and yet we do not write array<\N\C>, but rather \N\C[], which does not contain the term array. We also don't do object<\N\C>, even though it is a specialization of object.
I am not saying it is wrong to do sth like callable<...>, I just say I do not consider it necessary.

If other languages do not have a similar construct

https://en.wikipedia.org/wiki/Type_signature This is quite interesting.
But I don't see anywhere the idea to use a "prototype function" for documentation. Maybe this is new. Or maybe we need to look more.

Or where do you see the problem?

All concerns I raised are more of a rhetorical nature and not true concerns of mine. All variations work, the question is, which variation is the one that is best for tools and IDEs.

Well.. I prefer the brackets, makes it more obvious to everyone on first sight.

I also prefer it with the brackets to make it more clear. PhpStorm does not care; how does phpDocumentor handle that?

On the other hand, a procedural function and a class with the same name can coexist. So yeah, this would be a reason to require the brackets.

It also collides with namespace and class constants because casing does not matter. However, I do not really see an issue here because tools would need to look the thingy up anyways and display an error if it cannot be found, hence, if it is found and is e.g. a constant or a class or whatever thingy that makes no sense an error needs to be issued as well. No problem there imho.

Have you checked how other languages solve this issue? I can imagine that JSDoc or RDoc may have hit this bump before?

Well, JSDoc has the @callback tag and uses it within the @param tag. We do not really need the @callback tag because all structural elements are automatically addressable via their FQSEN and that is why I would extend the @param type to support FQSENs. I do not think that this is tucking in of a feature, on the contrary. It makes imho absolute sense to allows them because we already allow FQCNs and we simply extend them. This would also allow other interesting things like giving a range of constants that are allowed. However, as always I would like to see support for short names as PhpStorm supports it.

Well.. what I suggest is not that every FQSEN is a Type, but that \N\C::foo() is a type, a specialization of callable. I am not sure that \N\C::foo() is even an FQSEN, and I say it does not matter.
We could change the syntax of this, if people don't like it.

It is an FQSEN, specifically for a method but we would need to support functions as well (PCRE but not necessarily correct):
method = /^(\\[a-z_][a-z0-9_]*)+::[a-z_][a-z0-9_]*\(\)$/i
function = /^(\\[a-z_][a-z0-9_]*)*\\?[a-z_][a-z0-9_]*\(\)$/i

As I see it, what you want is to provide meta-data about the Type (which is callable).

Well.. \N\C[] is a specialization of array, and yet we do not write array<\N\C>, but rather \N\C[], which does not contain the term array. We also don't do object<\N\C>, even though it is a specialization of object.
I am not saying it is wrong to do sth like callable<...>, I just say I do not consider it necessary.

Writing \N\C[] is just a variation of array<\N\C> and writing \N\C is just a variation of object<\N\C>. Both work because there is consensus that their meaning is equivalent. We can introduce the same for callable: Anything that ends with and opening and closing bracket is a callable, e.g. fn(), \fn(), N\C::fn(), \N\C::fn(), ... I actually really like that and it would work nicely together with type hints.
The following example is valid PHP code:
<?php

namespace N {
    class C {
        public function cb() {
            return 'called';
        }
    }
}

namespace {
    /** @var \N\C::cb() $cb */
    $cb = [ new N\C(), 'cb' ];

    /** @param \N\C::cb() $cb */
    function fn(callable $cb) {
        echo $cb();
    }

    fn($cb);
}

/**

@param callable $f {

@signature (int $a, int $b)

}
*/

That would be the other way, when you want to indicate a caller how the callable would be called. I think that is even more useful than the feature described in my last comment. However, I think that the syntax your propose is overly complicated. Why not simply use PHP 7 syntax?

```php
/**
 * @param {callable(int $a, int $b): string} $cb
 */

Note how I use the braces that we are currently discussing to allow specification of the return type as well. The callable cannot clash with any user defined thingy because it is a reserved name and the signature can be parsed with a normal PHP signature parser. Of course, more complex types cannot be expressed, namely any complex type that cannot be expressed with PHP 7. But I think that it is sufficient to keep that in the description than.

/**

@param callable $f {

@signature (int $a, int $b)

}
*/

I have an interesting idea extending this:
> ```php
/**
 * @param callable $f {
 *     @param int $a
 *     @param string $b
 *     @return X
 *     @throws FooException
 * }
 * @return X|null
 */
function foo(callable $f) {
  try {
    return $f(5, 'x');
  }
  catch (FooException $e) {
    return null;
  }
}

This would give us the full expressiveness of phpDocumentor, and allow even explanation text.
Otherwise, if we stick to native PHP signature syntax, I find the syntax suggested in Fleshgrinder's last post shorter and preferable.

In the big picture, I now see the following partial proposals, which can all coexist, mostly, and each have their own specific use case:

Refine a @param callable $f, @type callable or @var callable with..
..an explicit signature specification, native PHP 7 style.
..an explicit signature specification, phpDocumentor style.
..a reference to a prototype function, to specify the callable signature.
..a reference to a prototype function, to specify the callable signature AND semantics.
Enhance a function / method declaration, with..
..a reference to a prototype function, to specify the callable signature.
..a reference to a prototype function, to specify the callable signature AND semantics.

If we can agree on a plan similar to this, we can then discuss the details in separate issues.

May I suggest you use something like @type literal to distinguish between named and anonymous functions? Just an idea. For example:
/**
 * This is a summary
 *
 * @type bound
 *
 * @since 1.0.0
 * @param string $var A pub in London.
 */
function named($var) {
    /**
     * This is a summary
     *
     * @type literal
     *
     * @since 1.0.0
     * @param string $val A restaurant in London.
     * @uses string $var A pub in London.
     */
    return function($val) use($var) {
        echo "I went to $val and then $var";
    };
}

@henrywright

May I suggest you use something like @type literal to distinguish between named and anonymous functions?

I don't quite get it..

Let's move part of the discussion over to #1712.
This leaves for this discussion:

Enhance the "callable" type specifier for @param, @return, @type and @var with..
..a reference to a prototype function, to specify the callable signature.
..a reference to a prototype function, to specify the callable signature AND semantics.
Enhance the documentation of a function / method declaration, with..
..a reference to a prototype function, to declare that the signature of the function/method defined here should match that of the prototype.
..a reference to a prototype function, to declare that the signature AND semantics of the function/method defined here should match the prototype.

@donquixote
@type literal would indicate the element being documented is a function literal (an anonymous, unnamed function), and not a function bound to an identifier such as we see in a function definition:
function my_func() {
    $foo = 'bar';
}

@henrywright
In the example you provide, the "@type literal" is redundant, because it can be seen from the code below that this is a closure.
It would provide more information as part of a @return, @param, @var or @type, to document that the value being passed around is indeed a closure, not just any callable. But for these purposes, there is not really any place for an additional @type tag.
And, isn't this equivalent with simply using "Closure" as the type specifier? Since for any lambda, $f instanceof Closure is true.
Finally, what is the benefit of knowing something is an anonymous function, and not another type of callback?

I see your point @donquixote. Sorry to have derailed the conversion.

The @implements tag could make sense in situations where we actually want to refer to an interface; e.g. traits that implement interfaces.

The trait @implements the methods of the interface then, correct.
A class could additionally denote via @implements that its methods are strictly adhering to the interface, correct.
A disconnected function X that @implements the signature (and possibly even its return type) of function Y, is correct, too.
In fact, it's all one and the same.  (Especially because @implements was invented long before Traits.)
No need to limit this to certain language constructs.  Every case has the identical meaning: fulfilling the specified contract.
Various other PSR-5/PHPDoc constructs accept a mixture of FQSENs, referencing and triggering different meanings.  Exactly the same happens here.
Arguing for this proposal doesn't mean that I'm a fan of the architectural pattern, nor would I advise anyone to base their application's architecture around such loose callbacks today.  Even the OP made these points crystal clear.  The subjective interpretation of @implements to "only make sense for object-oriented code" (here and on the mailing list) is inadequate and simply not true.  Get over it, please.

@sun I mostly agree, just a few comments.

The @implements tag could make sense in situations where we actually want to refer to an interface; e.g. traits that implement interfaces.

For traits, in some cases, it could actually make sense to document specific methods with @implements, instead of the entire trait:

If the methods are going to be renamed in the use statement. So in the trait, the method has a different name than in the interface.
If the trait implements methods from multiple, unrelated interfaces.

A class could additionally denote via @implements that its methods are strictly adhering to the interface, correct.

Generally this would be just a duplication of the native implements declaration, right? So it would be very very rare that this is needed or desirable.

Every case has the identical meaning: fulfilling the specified contract.

Yes. Of course, a method/function can not implement an interface, and a class cannot implement a method/function.
And, a method/function (unless abstract) can be the implementation and the contract at the same time.

Arguing for this proposal doesn't mean that I'm a fan of the architectural pattern, nor would I advise anyone to base their application's architecture around such loose callbacks today.

What we do in Drupal and Wordpress may be a bit rotten indeed. But the concept of "functional programming" is still valid in modern times. Especially with the addition of closures/lambdas.

For some time I have been wondering if we lose semantic information by switching from a one-method OOP interface to a callback signature which only specifies parameter types and return type. Here someone had the same question:
http://programmers.stackexchange.com/questions/286942/is-the-semantic-contract-of-an-interface-oop-more-informative-than-a-function?rq=1
In previous comments I said that we should distinguish @implements for semantic contracts, vs @signature for non-semantic contracts.
The accepted stackexchange answer proposes to use value objects / value types to make a signature more specific and more semantic.
I think we still want both in PHP, because we cannot expect everyone to use value objects / value types. But it is still interesting read related to this discussion :)


Laravel 11.x Shift

This pull request includes the changes for upgrading to Laravel 11.x. Feel free to commit any additional changes to the shift-123569 branch.
Before merging, you need to:

Checkout the shift-123569 branch
Review all pull request comments for additional changes
Run composer update (if the scripts fail, try with --no-scripts)
Clear any config, route, or view cache
Thoroughly test your application (no tests?, no CI?)

If you need help with your upgrade, check out the Human Shifts.

:information_source: To slim down the Laravel installation, Laravel 11 no longer has most of the core files previously included in the default Laravel application. While you are welcome to publish and customize these files, they are no longer required.
Shift takes an iterative approach to removing core files which are not customized or where its customizations may be done elsewhere in a modern Laravel 11 application. As such, you may see some commits removing files and others re-registering your customizations.

:information_source: Starting with Laravel 10, the lang folder is no longer included in a default Laravel application. Laravel now recursively merges any customizations with framework defaults.
Shift streamlined your language files by removing options that matched the Laravel defaults and preserving your customizations. If you wish to keep the full set of language, Shift recommends running artisan config:publish --all --force to get the latest configuration files from Laravel 11, then reapplying the customizations Shift streamlined.

:information_source: Laravel 11 no longer requires you to maintain the default configuration files. Your configuration now merges with framework defaults.
Shift streamlined your configuration files by removing options that matched the Laravel defaults and preserving your true customizations. These are values which are not changeable through ENV variables.
If you wish to keep the full set of configuration files, Shift recommends running artisan config:publish --all --force to get the latest configuration files from Laravel 11, then reapplying the customizations Shift streamlined.

:information_source: Shift detected customized options within your configuration files which may be set with an ENV variable. To help keep your configuration files streamlined, you may set the following variables. Be sure adjust any values per environment.
AUTH_PASSWORD_RESET_TOKEN_TABLE=password_resets_tokens
BCRYPT_ROUNDS=10
CACHE_STORE=file
DB_CONNECTION=mysql
LOG_STACK=daily
MAIL_MAILER=smtp
QUEUE_CONNECTION=sync
SESSION_DRIVER=file

Note: some of these may simply be values which changed between Laravel versions. You may ignore any ENV variables you do not need to customize.

:warning: The BROADCAST_DRIVER, CACHE_DRIVER, and DATABASE_URL environment variables were renamed in Laravel 11 to BROADCAST_CONNECTION, CACHE_STORE, and DB_URL, respectively.
Shift automated this change for your committed files, but you should review any additional locations where your environment is configured and update to the new variable names.

:warning: Laravel 11 automatically discovers policies scanning your application's Policies directory at or above the directory containing your models.
Shift detected policies registered with the policies property of your AuthServiceProvider. If any of these policies can not be automatically discovered, you may register them manually using Gate::policy() in your AppServiceProvider.

:warning: Laravel 11 automatically discovers events by scanning your application's Listeners directory.
Shift detected event listeners registered with the listen property of your EventServiceProvider. If any of these listeners can not be automatically discovered, you may register them manually using Event::listen() in your AppServiceProvider.

:information_source: Laravel renamed the password_resets table to password_reset_tokens. While an optional change, Shift detected you have a migration for the original table and created a migration to rename the table. You should check for any additional references to the password_resets table and run php artisan migrate to complete your upgrade.

:information_source: Shift updated your dependencies for Laravel 11. While many of the popular packages are reviewed, you may have to update additional packages in order for your application to be compatible with Laravel 11. Watch dealing with dependencies for tips on handling any Composer issues.
The following dependencies were updated by a major version and may have their own changes. You may check their changelog for any additional upgrade steps.

[ ] barryvdh/laravel-ide-helper
[ ] inertiajs/inertia-laravel
[ ] laravel/breeze
[ ] laravel/sanctum

:information_source: Starting with Laravel 10, PHP type hints were added within classes included in a Laravel application. In an effort to modernize your code, Shift automated this change where Laravel strictly specifies a type. If you prefer not to type hint your code you may revert this commit by running: git revert e8550b4b

:warning: Many first-party Laravel packages no longer load their migrations automatically. Instead, you may need to publish their migrations to your application if you have not already done so. Shift detected you are using Sanctum. You may run the following command to publish their migrations:
php artisan vendor:publish --tag=sanctum-migrations

:warning: In Laravel 11, changing a column now requires you to include all the modifiers you want to keep on the column definition after it is changed. Any missing attributes will be dropped. This change may cause unexpected behavior if you were to run pending or old migrations.
Shift detected potential uses of the change method within your migrations. While you may go back and update these migrations, you may wish to simply squash your old migrations. This will not only avoid rework, but may also improve the performance of your test suite.

:information_source: The base Controller class has been marked as abstract in Laravel 11, with its traits and inheritance removed. This is to prevent using this base controller directly and to use facades instead of the trait methods.
Shift detected your base controller did not have any public methods, so it was safe to mark as abstract. However, since you may be using trait methods within your controllers, Shift did not remove them. If you know you are not using any trait methods or want to refactor to facades, you may remove them manually.

:warning: Previously, Laravel would append a colon (:) to any cache key prefix for DynamoDB, Memcache, or Redis. Laravel 11 no longer appends a colon to your cache key prefix. If you are using one of these stores, you should append a colon to your prefix to avoid invalidating your cache.

:information_source: Laravel 11 now updates the timestamp when publishing vendor migrations. This may cause problems in existing applications when these migrations were previously published and ran with their default timestamp.
To preserve the original behavior, Shift disabled this feature in your database.php configuration file. If you do not have any vendor migrations or have squashed all of your existing migrations, you may re-enable the update_date_on_publish option. If this is the only customization within database.php, you may remove this configuration file.

:information_source: All of the underlying Symfony components used by Laravel have been upgraded to Symfony 7.0. Shift detected references to Symfony classes within your application. These are most likely type hints and can safely be ignored. If you are using Symfony classes directly or experience issues relating to Symfony, you should review the Symfony change log for any additional changes.

:warning: Many of the default drivers changed in Laravel 11. For example, the default database driver is sqlite and the default cache store is database. If you experience errors setting up your environment, be sure you have properly set your ENV variables for these drivers. If you wish to adopt the new defaults, you may follow the documentation to set them up for your application.

:warning: Laravel 11 now includes a database driver for MariaDB. Previously the MySQL driver offered parity with MariaDB. However, with MariaDB 10.1, there are more database specific features available. If you are using MariaDB, you may want to evaluate this new mariadb driver after completing your upgrade to Laravel 11.

:tada: Congratulations, you're now running the latest version of Laravel!
Next, you may optionally run the following Shifts to ensure your application is fully upgraded, adopts the latest Laravel conventions, and easier to maintain in the future:

Laravel Fixer automatically updates your code to the latest Laravel conventions.
Tests Generator intelligently generates model factories, HTTP Tests, and configuration for your application.
CI Generator intelligently generates CI jobs to lint PHP, check code style, and run tests, including Dusk.

You may also use the Shift Workbench to automate common tasks for maintaining your Laravel application.


Set the default adv test params, fix init adv test condition, add rho to plots

bors r+

bors r+

I guess I'm increasing allocations by 3% because I added density to diagnostics?
allocs_limit["flame_perf_target_callbacks"] = 45111592
allocs_limit["flame_perf_target_callbacks"] = 46413904

bors r+


Refactor

Domain change - BREAKING CHANGE

domain should be same as brand named in homeassistant/brands repository
in config mobilealerts has to be changed to mobile_alerts
In UI then you can see icon of this integration
later for configuration via UI this will be displayed

Refactoring - python types, formating, etc..
GitHub actions - on each push code is validate if contains correct manifest.json and hacs.json
native HA attributes and properties - no need to override lot - just write to correct properties
docs improvement

@petrleocompel - should the SensorDeviceClass for MobileAlertsRainSensor be PRECIPITATION rather than DISTANCE?
(I am going to look further this afternoon or tomorrow to debug it as having changed to mobile_alerts, all I get is a warning
WARNING (MainThread) [homeassistant.components.sensor] Setup of sensor platform mobile_alerts is taking over 10 seconds.

and nothing further, entities are all shown as unavailable

@CestLaGalere Oh yeah SensorDeviceClass for MobileAlertsRainSensor should be PRECIPITATION just did not noticed it.
No info about problems on my side from testers.


Expose the setImmediate polyfill so that libraries can use it directly

I have a bunch of setTimeout(..., 0) calls in scalajs-react and I'd like to replace them using this setImmediate polyfill.

Thanks for the PR! I think simply MacrotaskExecutor.execute(...) would fullfill your use-case out-of-the-box, is the concern about overhead?

Yeah, on one hand I'd like to avoid any overhead, on another using setImmediate is clearer to read. :)

on another using setImmediate is clearer to read
Is it? I think that people familiar with Node are likely to know what it is but I think it is a weird name. I'd believe MacrotaskExecutor.execute is a clearer.

Is it?

Yes, it is. More people in the world know what setImmediate is that know about this custom library.
What's the big deal with making this public?

The original goals of this library were to replace the default ExecutionContext in Scala.js and have a minimal surface area in terms of API, which is what we have here.
If we were to expose the "raw" setImmediate there's a number of considerations:

It would probably be nicer if it was exposed as a method rather than an anonymous function.
On MDN and in the original polyfill setImmediate returns a handle. We should probably implement this.
Following (2), we should probably also implement clearImmediate.

These changes would increase our API surface area quite a bit based on something which is not standardized and, since this is a polyfill and not a facade, binary-compatibility is a concern. This may or may not be a big deal.
IMHO if we were to move forward with this, I'd like to see (1)-(3) done. But someone with more experience should weigh in.

FYI I just proposed that we add a facade for setImmediate to scala-js-dom in https://github.com/scala-js/scala-js-dom/issues/652. This can be used with the original setImmediate polyfill, available on npm and also as a webjar. IMO this makes more sense b/c:

A facade can evolve more freely than an API that must maintain binary-compatibility.
Many (virtually all?) Scala.js users creating browser apps are already depending on JavaScript artifacts. One more doesn't seem like a big deal.
We'll get the handle and clearImmediate implementations for free.
As illustrated by @japgolly and @AlexITC, there are different styles of writing Scala.js depending on your background. MacrotaskExecutor and a setImmediate facade will appeal to different users.

As mentioned earlier in https://github.com/scala-js/scala-js-macrotask-executor/pull/37#issuecomment-999280342, exposing setImmediate would indeed require quite a bit of polishing for it, and would outgrow the scope of this library.
This library is only about providing an ExecutionContext that uses macrotasks. It is not about providing setImmediate. The fact that it uses setImmediate or a polyfill thereof is an implementation detail of this library, and should not be exposed in the public API. If something is eventually added to the standard that we can use instead, we will, and we must have the freedom to remove all the code related to setImmediate at that point.

If something is eventually added to the standard that we can use instead, we will, and we must have the freedom to remove all the code related to setImmediate at that point.

So just do it. API breaks. That's why we have versioning strategies.

Whatever.


fixed docsting on invalidate_request_token

fixes https://github.com/idan/oauthlib/issues/375

Thanks for the contribution.


feature: optimize error report in unit test

Closed this issue as fixed in https://github.com/LazyAGI/LazyLLM/pull/91


Automatically replace the external links of pictures in the content with those of your own website

Is your feature request related to a problem? Please describe.
Currently, whether a local markdown file or an article reprinted from other platforms, the image links inside will not be replaced with the website's own links, which may lead to the risk of image failure.
Describe the solution you'd like
I want a function that when publishing an article, I can automatically download and upload external link-type pictures to my own website server, and automatically replace them with pictures from my own server in the article.
I also want a plug-in that can automatically scan all the external link images in my website and do the above.
Describe alternatives you've considered
Considering that when pasting a picture, it will automatically upload the picture and write the address of the picture into the content, I think this function should not be difficult to implement.

i can make a pr for this issue, if the maintainer think this is nessessary :D


Remove "Save As Template" and "Import from Template" from the UI

We should remove Save as Template and From Template in the UI when working with Dashboards, Tasks, and Variables.

https://github.com/influxdata/influxdb/pull/19300


Implement cli tool test mocker for LUIS

Proposed Changes

Created cli test mocker tool

strip process args to get mock file
Leverage nock to intercept external service calls
Feed nock with json files with mock responses
Integrated specs test runner with test mocker
Integrated LUIS CLI test suite with test mocker

Updated mocha.opts to select **/*.suite.js files only
Added sample test mock files (more coming in new PRs to fully disconnect from external service)

Note: once tested and approved this mechanism can be used to test all cli tools disconnected
Testing

Does this PR supersede #597 ?

This PR has a failed build due to a malformed json file somewhere.

Does this PR supersede #597 ?

Yes. But thinking again this, we might want to separate concerns: This PR is specifically to disconnect CLI unti tests from external services. While #597 is meant to simplify the way we create CLI unit tests.

This PR has a failed build due to a malformed json file somewhere.

Fixed. The malformed files was LUIS/package-lock.json

Pull Request Test Coverage Report for Build 1764

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+2.9%) to 69.981%

Totals

Change from base Build 1756:
2.9%

Covered Lines:
4144

Relevant Lines:
5646

💛  - Coveralls

I don't know where this PR is at. It's ancient, so I'm closing it.
@juanar - if we should bring this back, please let me know.


Update jest-cli to 29.7.0

Description

Bump jest and related dependencies to latest major version
Update jsdom
Update snapshots
Skip some focus-related test cases which don't work well in Enzyme/Jsdom

Issues Resolved

Fixes https://github.com/opensearch-project/oui/issues/630
Check List

[ ] New functionality includes testing.
[ ] New functionality has been documented.
[ ] All tests pass

[ ] yarn lint
[ ] yarn test-unit

[ ] Update CHANGELOG.md
[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Setting to draft in favor of https://github.com/opensearch-project/oui/pull/1102


Not all I/O are reachable from nextpnr in the xc7k325t

The toolchain fails when I/O sites outside IOB_X0Yxxx are selected. Inside this range the tool runs without error but only a limited number of I/Os are operational in the resulting bitstream. See PR #7
This is a rough description of the behaviour which needs refining.

Could this be related to how prjxray-db is generated? If so, adjustment of symbiflow/prjxray#1794 such as symbiflow/prjxray#1844 may help resolve this.

(transfer comment from PR)
Connectivity of switches on Genesys2, cf. https://digilent.com/reference/_media/reference/programmable-logic/genesys-2/genesys-2_sch.pdf and https://github.com/Digilent/digilent-xdc/blob/master/Genesys-2-Master.xdc
sw0: bank 17
sw1: bank 16
sw2: bank 16
sw3: bank 17
sw4: bank 15
sw5: bank 15
sw6: bank 14 -- operational
sw7: bank 14 -- operational
Note that all LEDs are connected to bank 14 as well. This supports your hypothesis, @jrrk2
From Xilinx' documentation
https://www.xilinx.com/support/documentation/user_guides/ug475_7Series_Pkg_Pinout.pdf

On the bright side, this would mean that the following I/O is currently available for bitstream configuration on the Genesys2:

Reset button
SD card slot
PMOD headers JA and JB
PMOD header JD (6 out of 8 pins)
Fan control
QSPI

I can confirm the reset button can function as a convenient manual clock.

Investigations in #9 support our current assumptions.

The reset pin may be made bidirectional in order to self-oscillate. This happens at about 64MHz. Now the Genesys2 8-bit counter will self-count. see the ring-oscillator branch of the blinky project.

reset pin may be made bidirectional [...]

Sounds great! How reliable and defined is the clock frequency with this approach? Either way, this is a definite leap for publicity and proving the point that an open-source Genesys2 design is possible! :+1:
Can you rebase your branch to the latest revision of makeit.sh, please?

For details of the approach, see the paper that I previously attached:
https://caslab.csl.yale.edu/publications/burgiel2021characterization.pdf
In short, it’s not great, but for pedagogical purposes it can be used to show how not to do it.
Concerning rebasing, I see no changes of mine that need to be kept in makeit.sh
Regards,
Jonathan
On 3 Feb 2022, at 17:07, unbtorsten<EMAIL_ADDRESS>wrote:
reset pin may be made bidirectional [...]
Sounds great! How reliable and defined is the clock frequency with this approach? Either way, this is a definite leap for publicity and proving the point that an open-source Genesys2 design is possible! 👍
Can you rebase your branch to the latest revision of makeit.sh, please?
—
Reply to this email directly, view it on GitHubhttps://github.com/kintex-chatter/xc7k325t-blinky-nextpnr/issues/8#issuecomment-1029206420, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE6VVMYEEIWLYUK3RU6TF3TUZKY55ANCNFSM5NMS42LQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>

I am just finished building a database for the 160T based on @unbtorsten's branch and I have the same issue.
I can build a blinky, when the pins are in bank 14, but
an assert failure like this otherwise:
[...]
3. Executing JSON backend.

End of script. Logfile hash: 84acb2d8cd, CPU: user 2.36s system 0.02s, MEM: 195.00 MB peak
Yosys 0.13+15 (git sha1 bc027b2ca, gcc 10.3.0-1ubuntu1~20.04 -fPIC -Os)
Time spent: 25% 26x read_verilog (0 sec), 16% 13x design (0 sec), ...
+ nextpnr-xilinx --chipdb /usr/local/share/nextpnr/xilinx-chipdb/xc7k160tffg676-2.bin --xdc blinky-kx2.xdc --json blinky.json --write blinky_routed.json --fasm blinky.fasm --verbose --debug
Info: Packing constants..
Info: Inserting IO buffers..
Info:     IO port 'clk' driven by IBUF '$iopadmap$blinky.clk'
Info:     IO port 'led' driven by OBUF '$iopadmap$blinky.led'
Info:     Constraining 'clk' to site 'IOB_X1Y124'
Info:     Constraining 'led' to site 'IOB_X1Y99'
Info: Generating input buffer for '$iopadmap$blinky.clk'
terminate called after throwing an instance of 'nextpnr_xilinx::assertion_failure'
  what():  Assertion failure: s != -1 (/home/user/HDL/nextpnr-xilinx/xilinx/arch.h:1602)
./makeit.sh: line 29: 409172 Aborted                 (core dumped) nextpnr-xilinx --chipdb ${CHIPDB_DIR}/${PART}.bin --xdc ${PROJECT_NAME}-${BOARD}.xdc --json ${PROJECT_NAME}.json --write ${PROJECT_NAME}_routed.json --fasm ${PROJECT_NAME}.fasm --verbose --debug

I got blinky/picosoc designs working from banks 14, 12, 13, 15, 16.
Not working: Banks 32, 33, 34, 115, 116

I suspect this is due to XRAY_IOI3_TILES, they look like this:

because on the

The Artix7 on the other hand, has RIOI3 tiles on the right hand side:

So I suppose, we probably might have to write a new fuzzer for the RIOI tiles.

This pretty much agrees with my diagnosis that the root cause is no support for the 1.8V I/O in the prjxray Makefile. Even when that is fixed, we still have to understand the behaviour and configuration bits for the 1.8V I/O (and in particular the LVDS crystal 200MHz input that Genesys2 relies on). This is essential to support the DDR memory interface standards also.

@jrrk2 Can you point me to the exact location in the Makefile?

diff --git a/fuzzers/000-init-db/Makefile b/fuzzers/000-init-db/Makefile
index 033ed989..f31c290a 100644
--- a/fuzzers/000-init-db/Makefile
+++ b/fuzzers/000-init-db/Makefile
@@ -49,11 +49,14 @@ DB_SIMPLE=
segbits_cmt_top_l_lower_b
segbits_cmt_top_r_lower_b
segbits_rioi3 \

segbits_liob18 \
segbits_riob18 \
segbits_liob33
segbits_riob33
segbits_hclk_cmt
segbits_hclk_ioi3 \

-DB_SIMPLE += segbits_lioi3 segbits_liob33
+DB_SIMPLE += segbits_lioi3 segbits_liob18 segbits_liob33
BLOCK_RAM_EXTRA_FOR=
mask_bram \

I came across this module which should provide access to a clock on Genesys2 from a 3.3V I/O bank:
TCXO

@jrrk2 I patched nextpnr to print the BEL it is looking for before the failed assert, and I got: IOB_X1Y124/IOB33/PAD

@jrrk2 Oh I wasn't aware you already started working on a iob18 branch. I will try to pull those changes into the kintex-chatter fork.

@jrrk2 In your iob18 branch, shouldn't the IOSTANDARDS also include LVCMOS18?

This is the previous mentioned external oscillator (10MHz) attached to the JB PMOD of the Genesys2. Documentation is a bit scanty but I am confident the signal will appear either on JB1_P or JB3_P which is connected to pin V29 or T25 (conveniently both in Bank 14).
Somebody with better eyesight than me could have soldered it themselves but it only cost £10 including postage from China, see above.

External temperature compensated crystal oscillator module is working on Genesys2. Branch main has been updated with the changes. Blinking is fairly slow at 5/8 Hz or so. This can be speeded up by the use of a PLL as required (if that works yet). I did not go through the pull request process since I was confident my change were small, so feel free to blame me if it breaks your board support.

@jrrk2 We have now working preliminary support for the high speed IO banks. See https://twitter.com/1gkojima/status/1506925318875267072
Since the fuzzers support LVDS it now might be possible to get the clock working on the genesys2 board.
Using these repos: https://github.com/kazkojima/nextpnr-xilinx
And: https://github.com/kazkojima/db-workspace-for-kintex7

Excellent progress. I need to refresh my memory a bit, should I be using branch iob18-trial in the kazkojima nextpnr repo ?

@jrrk2  Yes that should be the branch. I am not shure yet, if nextpnr supports the LVDS IO standard.
If not, let me know, I will try to add it.

I guess that LVDS IOSTANDARD won't work yet for the several missing keys in the segment DBs.
More importantly, it's very likely that the modified nextpnr can't set the correct bits in the bitstream, even if the missing keys are resolved. When there is an external chip connected to the IOB18 pins, that chip or FPGA could be damaged with the wrong voltage or some collision, in the worst case.
I think we should test them with unconnected pins first. Unfortunately, the high-speed IO pins on the QMTECH xc7k325t board are inaccessible except for the pins connected to DDR3 and the two onboard switches.
Maybe I should remove those two switches and their pull-up resistors for that purpose.

Hi, I was trying to get a different xc7k325 board up and running and came across this issue as I have a differential clock is attached at IOB_X1; is there a solution for this issue? If someone could tell me what needs done, I'd be happy to have a go at fixing it.

I think this is the latest progress:
https://github.com/kazkojima/nextpnr-xilinx/tree/iob18-trial
I haven't personally been able to work on it due to hardware unreliability that was only recently fixed.

@JakeMercer
I am working continuously on this, and here is my branch:
https://github.com/kintex-chatter/nextpnr-xilinx/commits/iob18-trial
It is currently identical with @kazkojima s branch
You also can get the database from:
https://github.com/kintex-chatter/nextpnr-xilinx/commits/iob18-trial

The IO bank database bits should be in pretty good shape at this point:
https://twitter.com/hansfbaier/status/1536176892167892992
I didn't test it more than that above yet.
Now it would be worth testing if the differential clock input works.

@jrrk2 @unbtorsten It's been quite a while, but today I got the differential clock input working on my
Kintex 325T board:
https://twitter.com/hansfbaier/status/1541642932070952961
I pushed the changes to this repo. I also updated the make setup commands to pull in the latest database and nextpnr-xilinx.
With the high speed banks I have tested single ended input and output and differential input.

@hansfbaier Great work! I've got your differential blinky example running on my board.  Apologies for taking so long to get back to you; I've been flat out with work but found some time to get back to this, this evening.  Is there anything I can check with my board that you aren't able to that would help progress things? https://digilent.com/reference/_media/netfpga-1g-cml:netfpga-1g-cml_rm.pdf is the reference manual; I'm aiming to get the Ethernet's up and running but I'm not sure what the state of DDR I/O is at the moment? Also is bidirectional I/O special in any way or does it work the same as single-ended I/O?

@JakeMercer Yes DDR3 is the next frontier. I already can build a DDR3 design but it does not work yet. We will have to test the individual primitives to see where the problems are.

@JakeMercer I haven't tested bidirectional IO yet and it would be great if you could whip up a simple test case for that

@JakeMercer  I just pushed my latest version of the database, to ensure we are testing the same thing.

@JakeMercer I also just pushed all my interim changes to nextpnr-xilinx. Please pull again from the iob18-trial branch.

@hansfbaier I've pulled in your latest changes and rebuilt after a make clobber.  I'm using the following to test bidirectional IO with a physical jumper wire between gpio0 and gpio1:
`default_nettype none   //do not allow undeclared wires

module bidir (
    input  wire clk_p,
    input  wire clk_n,
    output wire led,
    inout wire gpio0,
    inout wire gpio1,
    );

    wire clk_ibufg;
    wire clk;
    wire gpio_in;
    wire gpio_out;

    IBUFDS ibuf_inst        (.I(clk_p), .IB(clk_n), .O(clk_ibufg));
    BUFG   bufg_inst        (.I(clk_ibufg), .O(clk));
    IOBUF  iobuf_in_inst    (.I(gpio_in), .O(), .IO(gpio0), .T(1'b1));
    IOBUF  iobuf_out_inst   (.I(), .O(gpio_out), .IO(gpio1), .T(1'b0));

    reg [28:0] r_count = 0;

    always @(posedge(clk)) r_count <= r_count + 1;

    assign gpio_out = r_count[28];
    assign led = gpio_in;

endmodule

Which does not appear to work.  I have isolated both the input and output side by reverting each back to input/output instead of inout and tweaking things to not use the IOBUF instantiations and things operate as expected in the fully reverted case but not when either side uses bidirectional IO.
I have had gpio0 as a normal input and the state is reflected in the LED and I have had gpio1 as a normal output and it changes with r_count.  Having gpio0 as bidirectional and configured as input the LED stays off regardless of what is connected to the pin.  Having gpio1 as bidirectional and configured as an output it remains at a logic 1.

Hi @JakeMercer You swapped I and O in IOBUF

So 'I' of the IOBUF goes to the output, actually.

@JakeMercer I have now the following set up which seams to work
(the key changes the IO direction):
module blinky (
    input  wire clk_p,
    input  wire clk_n,
    output wire led,
    inout wire gpio0,
    inout wire gpio1,
    input wire key,
    output wire key_led
    );

    wire clk_ibufg;
    wire clk;
    wire gpio_in1;
    wire gpio_in2;
    wire gpio_out;

    IBUFDS ibuf_inst        (.I(clk_p), .IB(clk_n), .O(clk_ibufg));
    BUFG   bufg_inst        (.I(clk_ibufg), .O(clk));
    IOBUF  iobuf_in_inst    (.I(gpio_out), .O(gpio_in1), .IO(gpio0), .T(key));
    IOBUF  iobuf_out_inst   (.I(~gpio_out), .O(gpio_in2), .IO(gpio1), .T(~key));

    reg [28:0] r_count = 0;

    always @(posedge(clk)) r_count <= r_count + 1;

    assign gpio_out = r_count[25];
    assign led = gpio_in1 | gpio_in2;
    assign key_led = key;

endmodule

Ah, I knew it would end up being something silly.  I've tested that on my side now and looks good!
I've tweaked the above to use 2 extra pins and IOBUFDS and I'm now hitting:
ERROR: No Bel named 'IOB_X0Y125/IOB33M/OUTBUF' located for this chip (processing BEL attribute on 'iobuf_out_inst$subcell$OBUFTDS$subcell$P')
0 warnings, 1 error

This is my .xdc file:
set_property LOC AA2 [get_ports clk_n]
set_property IOSTANDARD LVDS [get_ports clk_n]

set_property LOC AA3 [get_ports clk_p]
set_property IOSTANDARD LVDS [get_ports clk_p]

set_property LOC E17 [get_ports led]
set_property IOSTANDARD LVCMOS33 [get_ports led]

set_property LOC AF14 [get_ports key_led]
set_property IOSTANDARD LVCMOS18 [get_ports key_led]

set_property LOC W6 [get_ports key]
set_property IOSTANDARD LVCMOS15 [get_ports key]

set_property LOC D19 [get_ports gpio0]
set_property IOSTANDARD LVCMOS33 [get_ports gpio0]

set_property LOC E23 [get_ports gpio1]
set_property IOSTANDARD LVCMOS33 [get_ports gpio1]

set_property LOC D25 [get_ports gpio2]
set_property IOSTANDARD LVCMOS33 [get_ports gpio2]

set_property LOC F23 [get_ports gpio3]
set_property IOSTANDARD LVCMOS33 [get_ports gpio3]

Ah, I knew it would end up being something silly. I've tested that on my side now and looks good!
I've tweaked the above to use 2 extra pins and IOBUFDS and I'm now hitting:
ERROR: No Bel named 'IOB_X0Y125/IOB33M/OUTBUF' located for this chip (processing BEL attribute on 'iobuf_out_inst$subcell$OBUFTDS$subcell$P')
0 warnings, 1 error

Can you give me the source and .xdc file for that?


Not being able to see visuals at all (Linux/)

Other features work visuals dont..

having the same problem, cant see the footstep visuals

i figured it out dont use snap or flatpak steam use native install of steam website for the deb file

this "hack" is a joke guys

Yep I bet 12 year olds in Russia make better cheats, like not even an ESP wtf?


add string functions

Please add tests + docstrings

could've been nice to put them in a string namespace


Displays the quantity of filtered data

example
100.5  47

You mean there are 47 * 100.5?
Want to display the number of duplicates?


Dev

It is now possible to enforce sum rule for the unsymmetrized fermionic Green's function. It improves the accuracy of matfreq2dlr by an order of magnitude.

Codecov Report

Merging #22 (a5138f4) into main (1e1f30d) will increase coverage by 1.70%.
The diff coverage is 91.42%.

@@            Coverage Diff             @@
##             main      #22      +/-   ##
==========================================
+ Coverage   67.92%   69.62%   +1.70%
==========================================
  Files          10       10
  Lines         845      810      -35
==========================================
- Hits          574      564      -10
+ Misses        271      246      -25

Impacted Files
Coverage Δ

src/dlr.jl
80.90% <69.23%> (+1.86%)
:arrow_up:

src/operation.jl
94.59% <96.49%> (-0.24%)
:arrow_down:

src/spectral.jl
80.41% <0.00%> (-1.90%)
:arrow_down:

src/sample/sample.jl
87.87% <0.00%> (-1.60%)
:arrow_down:

src/utility/chebyshev.jl
100.00% <0.00%> (ø)

src/functional/builder.jl
0.00% <0.00%> (ø)

src/functional/findmax.jl
0.00% <0.00%> (ø)

src/discrete/kernel.jl
90.29% <0.00%> (+0.72%)
:arrow_up:

src/discrete/builder.jl
73.91% <0.00%> (+0.94%)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

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


Feature request: Show guide lines only when there are at least N continuous lines in current level

First of all, thanks for making such an awesome plugin!
I especially love the option to colourise the guide lines but sometimes it does look a bit excessive.
So I'm wondering if it's possible to only show the lines when there are at least N continuous lines. For example, cyan lines in screenshot can be hidden since there's only one line on this level.

It is currently not possible, and also not trivial to implement.
I doubt a lot of people would use this, so I don't think I will work on this. But I would consider merging a PR if someone else wants to.

Is there any way to disable guides on blank lines?

Is this the effect you may want? I determine whether to render by follow code
render_info = vim.tbl_filter(function(v)
    return (
        pos2info:has(bufnr, v.lnum - 1, v.virt_text_win_col) or pos2info:has(bufnr, v.lnum + 1, v.virt_text_win_col)
    )
end, render_info)


Handle errors in parsing liveliness tokens

Something to be discussed is how to best handle errors in liveliness token subscriptions. Right now, an error message will be printed but should the node continue to function if transport works? See https://github.com/ros2/rmw_zenoh/pull/70#discussion_r1409742683

Personally I think that we should detect the errors, report them once, ignore it, and then continue on.  That will help deal with the case of a malicious actor intentionally publishing bogus liveliness tokens.

Handled in #even


Add check for ocamlopt since it is used

Found by inspection.
Signed-off-by: Alin Gabriel Serdean<EMAIL_ADDRESS>

bors r+
@johnkord Did we already / are we working to temporarily disable the flaky tests?

bors r+

bors r+

bors r+

bors r+


Decide how to publish CJS bundles

We need to decide how best to create these bundles.
Basically, the current PoC script in the repo does the following (roughly):

Create a new package
Install the target ESM package as a dependency
Create a bundle which exports everything from the ESM package's bare specifier
Copy important package.json fields from the dependency to the new package
Publish the new package

This is easier than forking every repo and doing the CJS build in each individual repo (since we can just run this script with a target module).
However, things where it starts getting sketchy:

How to copy types across? (there may be a types, or exports may have types, and those types may import types themselves)
How to deal with exports? (we don't really care about supporting anything other than the bare specifier at least)

Alternatively, we could just fork each individual package and manually setup a commonjs bundle build, change the name, etc.
To summarise:

Option 1 - download the target package, bundle it, imitate the package.json
Option 2 - fork the target repo, actually add a CJS build script, publish however the target repo publishes

maybe cc @thepassle in case you have any thoughts

Is this on schedule? I want to bundle import-meta-resolve and publish as cjs to use in https://github.com/stylelint/stylelint/pull/7532, I may have to do it manually?

any help would be much appreciated, especially in technical discussion here
basically im trying to decide between these two options:

write a script which bundles the target package as CJS and do best effort to copy any shipped types etc across
just fork the repo, automatically catch it up from the source repo but use esbuild to turn it into cjs

to be honest, there's enough edge cases im leaning more towards just forking the target repos for now at least
ill have a look this weekend at just forking chai as an example, and having it auto-catch up somehow

I would recommend to only bundle and publish first, it would be good enough for most cases.

the difficulty is mapping across various package manifest things.
for example, type definitions in particular are tough.
if a package ships its own types, we would need a reliable way to bundle all the exported types into a single dts file. or follow the tree and copy across all referenced dts files (from the entrypoint)

I was saying that we should not consider type definitions at the first time.

i do agree it should be a temporary fix, and people should be urged to migrate to esm sooner rather than later
i think its important we don't break typescript support though, but do understand it may not be worth the time if it blocks us
ill have another look at the script we already have in this repo this weekend 👍

My two cents, for a pure ESM package, we should transform it as dual instead of commonjs only, so that the ESM entry will still be preferred.
So, my solution would be, download the pure ESM npm package, bundle the ESM entry as commonjs, add it into exports field and then publish it. And then import and types will still be available.

the reason i disagree with that is that it reduces the motivation/need to still move to ESM
we're leaning into maintaining the source package as well as the CJS bundle of it then, too. so it becomes a larger burden on us
i think we should keep it simple. since we already had an esm-bundle in the wild for years now, a cjs-bundle seems to make sense and isn't quite permanent enough for people to give up on moving to ESM

Hmmm... Then what's the purpose of cjs-bundle? It will definitely reduce the motivation/need to still move to ESM already?

the purpose is to provide a CJS bundle of packages which have since moved to pure ESM
importantly, as a temporary solution to consumers who just didn't have the time yet to move to ESM themselves
if we provide dual packages, it will mostly just result in consumers sticking to these bundles indefinitely as there's little motivation to move back to the source package. if we only provide CJS, any ESM migrations will also mean moving away from this project (a good thing).

ok, temporarily at least, im going to manually fork some repos for now so i can get them published.
however, i'd still like to solve scripting this rather than maintaining a fork if possible.
the types are important since many consumers use TS these days and the build will immediately fail when using the CJS bundle unless we solve this (as the types will be missing). that isn't an easy problem to solve since types can reference other DTS files.

@43081j The issue of commonjs only solution is: if I want to support commonjs + ESM at the same time, I can only use commonjs version via your fork then?

the types are important since many consumers use TS these days and the build will immediately fail when using the CJS bundle unless we solve this (as the types will be missing). that isn't an easy problem to solve since types can reference other DTS files.

In my solution with dual package, although the types are only for ESM, but it should be compatible with commonjs at the same time, I believe

So, my solution would be, download the pure ESM npm package, bundle the ESM entry as commonjs, add it into exports field and then publish it. And then import and types will still be available.

The above solution is much easier to maintain.

@43081j The issue of commonjs only solution is: if I want to support commonjs + ESM at the same time, I can only use commonjs version via your fork then?

yes exactly.
we've had esm-bundle for some time to provide ESM-only bundles of CJS-only projects. now this is providing the opposite since many projects are ESM-only but consumers still sit on CJS-only stacks.
providing a dual package is more of a permanent solution, pulling people away from the source package. whereas this is meant to be a very temporary solution while people move to ESM.
ESM users should use the source package. CJS users should temporarily use the cjs-bundle package. Why would we want to provide ESM users with our own ESM bundle when the source package does that itself?

See https://github.com/stylelint/stylelint/pull/7532
stylelint itself is a dual package, so it cant use pure ESM import-meta-resolve, and don't want commonjs only bundle, so I just published @dual-bundle/import-meta-resolve at https://github.com/un-es/import-meta-resolve


Add urls and config for API docs.

Issue Number
Include an issue number if applicable.
Purpose/Implementation Notes
Describe the big picture of your changes.
Types of changes
What types of changes does your code introduce?

Bugfix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)

Functional tests
List out the functional tests you've completed to verify your changes work locally.
Checklist

[ ] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in downstream modules

Screenshots
Please attach any screenshots that illustrate these changes.

I clicked "create PR" instead of the dropdown it hides.


Remove OpenStruct usage

Hello! I'm seeing performance warnings show up when using zxcvbn-rb in Ruby 3.3.0 due to the usage of OpenStruct, which is now discouraged.
Running specs or an application that uses zxcvbn-rb with the following Ruby flag will print the warnings:
RUBYOPT="-W:performance" rspec

zxcvbn-0.1.9/lib/zxcvbn.rb:34: warning: OpenStruct use is discouraged for performance reasons
# ...

This PR removes the OpenStruct in favor of a struct that defines the fields used in the result.

Thank you, @mitchellhenke . ✨

@formigarafa Thanks for the new release ❤

@formigarafa Thanks for the quick review and merge!


[dvsim] Add CTRL-C support

For gracefully handle ctrl-c as request at #1723
Also kill running lsf jobs
Signed-off-by: Weicai Yang<EMAIL_ADDRESS>

Note that for the formatting of the argument list yapf doesn't produce stable output, so it's best to omit these whitespace changes if you don't want to go in circles. (Artifact of #77)

It looks like this is a yapf+change. Can you split the yapf part into a separate commit? Still in this PR, but will make it much easier to review.

Note that for the formatting of the argument list yapf doesn't produce stable output, so it's best to omit these whitespace changes if you don't want to go in circles. (Artifact of #77)

Thanks @gkelly @imphil
I updated the yapf and those whitespace changes are gone now.

It looks like this is a yapf+change. Can you split the yapf part into a separate commit? Still in this PR, but will make it much easier to review.

@gkelly There is no more formatting change in this PR after rebase. Please take a look.


cleaning block/byte pool region upon release

Hi
As far as I see there is no built in option to clean the region of block/byte pool upon release.
I think it is very important compile option. especially when using memory protection so it is data leak source (also, in threadx module the modules manager is releasing the pools including the thread struct, so it is problematic to clean it from the module).
I don't think it is a lot of effort to add this option. I understand it will take a runtime when releasing so I suggest to add it just if some compilation flag is on.

Hi @amgross - we're discussing internally. I think this is a good idea.

Hi @goldscott,
What is the status of this issue?

Hi @amgross - some higher priority bug fixes were ahead of this feature request, so this did not make it into the 6.1.6 release.

For now, we've updated the ThreadX manual with notes in the tx_byte_release and tx_block_release APIs suggesting that users may want to clear this memory to prevent data leaks.

Closing.


Initial load of Events After Login

We need to initial load events after login

Is this fixed? I can't recreate the bug.


msmtp: 1.8.13 -> 1.8.14

Motivation for this change
Update to latest release. Sending mail works.
https://marlam.de/msmtp/news/msmtp-1-8-14/
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

 If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108108 run on x86_64-linux 1

1 package built:

msmtp

This is a semi-automatic executed nixpkgs-review. If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108108 run on x86_64-linux 1

1 package built:

msmtp


scan_interval_seconds not optional

Hi,
i tried switching to the custom integration but seems that scan_interval_seconds is a required value instead of beeing optional.
Invalid config for [sensor.edl21]: expected int for dictionary value @ data['scan_interval_seconds']. Got None. (See /config/configuration.yaml, line 87). Please check the docs at https://www.home-assistant.io/integrations/edl21
Once added to the config it´s working fine now.

Thanx for this info. I will change this with the next update.


Gateway not closed after test completion

Instances of the Gateway are not being closed when a test completes (notably in the consensus tests). This causes goroutines to leak, which may be the cause of some testing instability. We need a way to perform teardown after each test. I suggest adding a Close method to consensusSetTester (and others, as needed) that should be deferred in each test.

:'(
ok

I'll add this in on top of my pr to make things work.

makeOutboundConnections is definitely leaked. Not sure how to best address that.
threadedHandleConn will leak if the peer is malicious (meaning it continues to send muxado heartbeats, but never sends any data).
acceptConn will leak if the peer does not send any data (muxado has not been layered on the connection yet).

all safelocks are leaked.
It will be pretty easy to add a close function to the safe locks.

I believe this specific issue is fixed. The broader issue of things not closing during testing still remains.