[Feat] Order and Size methods are missing out of the box

Hello,
Thanks for this cool library. However there are some methods missing on the graph:

Order: the number of vertices in the graph.
Size: the number of edges in the graph.

These methods are really important for certain use cases. For instance

Size: one can use GetAllEdges and apply len on it. However this can be a performance bottleneck. The same applies to Order


Feature/picker

Made a basic picker to sort of look like AGL, but added three slots instead of two.  Maybe we should just switch out to icon buttons looking for some feedback.

@germboy Thanks for the feedback. I just fixed up the Spotlight stuff and some of the nitpicks. I don't think we want to add a scrolling like behavior right now just because of time. But eventually we can add something like that in.


Updated to tensorflow 1.5 and spark 2.3.

Current version is not compatible with graphs generated by tf1.5 and it's preventing us from releasing dl-pipelines with tf1.5 support.

updated protobuf files and regenerated their java sources.
few minor changes related to Tensor taking a type parameter in tf1.5.

@tomasatdatabricks does this update maintain compatibility with tf1.4?

I am not sure, we should find out from tf documentation.
Anecdotally based on my experience with dl-pipelines - yes it is, but only sort of. I was able to load ans score models outputed by tf1.4 but the result will be slightly different (~4th digit diff). I found out because our DeepImageFeaturier test failed with minor inconsistency in results. Took me a while to remember that those use model files pre-generated with tf 1.4. the difference in results is not big so I am not sure how much that matters.

@sueann tensorflow is best effort only. Some Ops have been deprecated and removed, which means that some older graphs may not even load in recent TF versions.

Thanks for the review Tim! Yeah I mostly wanted to unblock switching to tf1.5 in spark-dl.
I suspect that the tests error out because I used not-yet supported ubuntu16.04 in the travis config. Unfortunatelly tf1.5 does not work on ubuntu14.04 or so I found out via a quick internet search. I'll try get the tests to run somehow.

@tomasatdatabricks it looks like the build has timed out for a number of jobs, let's retry to launch it. Also, we are testing a very large number of configs now. I am happy to have 2.0.x releases commented out for example. We cannot test old versions forever.

Otherwise the changes look good to me.

@thunterdb Thanks Tim. I'll rerun the tests but I am worried that the reason for the timeouts is travis itself, or us using not-yet-officially-supported ubuntu16.04. We'll see. The tests run fine locally at least.

@tomasatdatabricks thanks a lot for the work. Some tests are failing because of some travis beta feature issues, but I agree the changes are more important. Merging.


PRAW - The TREES Update!

Abstract
When using the get_submission method on a permalink, the root of the comment forest starts at that comment. Instead of treating this as a bug, since it is actually in the FAQ, it should be treated as a feature and expanded on.
Status
Complete, but Annoyances need to be addressed.
Resolves

May fix #362  and #391 though I've not tested it. Nevermind, I mistook something.
#475
#479
#500
#511

Adds

A way to get a submission object with the root of a comment and the submission id so that the comment forest starts at that comment
A way to get the Comment object's context, parent, improved way to get the submission, and tree.

More functionality when getting the tree, and that functionality is also included in the above

Documentation regarding comments

Annoyance(s)
For the new comment object related methods, sometimes the user may not want to get the submission object with the special forest root, but instead, just that special forest itself. While certainly possible, after doing such one can not use the replace_more_comments function due to the fact that it is a method of the Submission object.
Proposals
Move replace_more_comments to be a helper, and allow it to work on trees instead, since there are other versions of the "load more" objects, such as in modmail. I would do this but I lack the comprehension as to how to do so.
If this is actually impossible, an alternate proposal would be that I could add a boolean keyword argument to the new methods on Comment objects.
Neither of the above are actually needed, but may provide some convenience for users

@sprt I specifically didn't do that because #475 was asking how to use the site_name. I provided how to use it in the method, and added an example of a new site_name in the praw.ini, which that doc does not mention.

@13steinj I don't have a great deal of time to check this out at the moment but I have a few suggestions that would make this simpler to review:

48 commits is a bit much for a pull request. That's perfectly fine for work in progress, but when it comes down to reviewing it would great to have the commits grouped into logical chunks as best you can. That may not be trivial to do, but at least you can squash commits with similar commit messages.

The simplest way to do this is to git rebase -i master and then change pick ... to f ... on the lines where the commit messages are the same as the one above it. That will combine those commits into a single commit.
There's a lot more you can do with git rebase -i master. In the event you mess up the commit hash of this pull request is 878603df66ae16038be40c0dd0a7db3c4d2bd66e. Thus you can always get back to it by doing git reset --hard 878603df66ae16038be40c0dd0a7db3c4d2bd66e.

There appear to be format based documentation changes. I understand you probably changed them along the way, however, these sort of changes belong in their own pull request.

Otherwise, thanks for the work to make this PR happen. I'll provide additional comments as time permits.

Well it turns out I did have time to gloss over the PR. I think this is an awesome start.
We need to be careful of adding confusion. Previously the ability to get submission submission objects that had different "trees" for the same submission was confusing. I think these changes make it more confusing.
One way to handle the Submission with "context"-based trees, is to make a Submission subclass. Perhaps it could be named PartialSubmission or ContextSubmission. Doing so we can Maintain backwards compatibility as every PartialSubmission is a Submission.
I think this is the first step that we need to complete and verify that we don't break anything (1st pull request).
After that, I think we can add the other components of this pull request.
What do you think?

I'm prefectly fine with such a PartialSubmission distinction, and can start soon, but considering that, should a get_partial_submission method be made to UnauthenticatedReddit to return that partial submission or should that stay as it is and instead if comment_root is defined in get_submission it returns that partial submission instead?

Here's my thoughts on it. There should be a single get_submission function as you have modified it to be here.
If comment_root is provided (along with submission_id) or a URL containing a second thing_id then a PartialSubmission is returned. Otherwise a Submission is returned. Make sense?

@bboe But then that complicates things with url in praw.UnauthenticatedReddit.get_submission. If url is a comment permalink, it would return  a partial submission but still be considered a regular Submission object. Plus, with there being multiple ways to actually give a comment permalink, it would be hard to error check for each of them.
I'd say for the sake of less complication that  there shouldn't be a PartialSubmission subclass, but rather better docs to show that the submission objects can be retrieved in ways to only get a partial forest, such as with a comment permalink as url or (a submission_id AND comment_root) or the various newly added methods to the Comment object.

I see your point. I think it's feasible and we can error on the side of making Submission objects for things we don't recognize. Alternatively, we could create the Submission or ParialSubmission object once we have the data as the root comments will all either have a parent id which is the submission or not. The latter case would indicate a PartialSubmission.
Maybe we're still not thinking of the best way to represent the information so here's what should happen:
A submission object contains the information about a Submission, and should always have a permalink that links to the Submission without any sort of context. It should have no parent because a Submission cannot be nested under anything.
From a submission one can obtain its forest of comments (they're conveniently provided when making the request). Each comment belongs to a submission, and has some location within that submission's forest of comments. Thus each comment's parent can either be another comment or the submission.
This presents the problem of obtaining a partial view of a Submission's forest, a single tree in this case (sense I don't think any endpoint will return more than one tree). Perhaps the solution is separate these trees from the submission object they happen to be returned with, and finally just provide a standalone get_comment function that returns a comment along with all of its children.
With the presence of such a method we can modify get_submission to only take in top-level submission urls (or just the submission_id) and have them use get_comment when they want something more specific. Calling get_comment and then trying to fetch its parent should be permitted, but it'll certainly be inefficient. The other inefficient thing would be to do get_comment(...).submission.comments as another request would need to be made to the Submission to fetch it's actual comment forest.
Overall the Submission object was never intended to support partial comment trees. It was simply a work around. Yes, we'll need to deprecate the current use, but I think it's totally worth it to provide the functionality you want in a clear way. Thoughts?

I can't comment right now because I'm on mobile, but I think in the long run it's not a good idea. When I get home I'll sit down and say (err, type) my peace.

@bboe
I'm at a hotel with semidecent wifi, so please excuse any errors that may be caused with my keyboards' key syncing.
But then you may be decreasing a lot more support than you think you are. Let me just list the common various permalink formats. Keep in mind there may be even more that I don't know about.

redd.it/id
reddit.com/id
reddit.com/comments/id
reddit.com/comments/id/title
reddit.com/r/subreddit/id
reddit.com/r/subreddit/id/title
some other format with "tb" that I'm forgetting.

(two of the above may be handled with a redirect exception)
Now, for comment permalinks:

reddit.com/id/_/id
reddit.com/comments/id/_/id
reddit.com/comments/id/title/id
reddit.com/r/subreddit/id/_/id
reddit.com/r/subreddit/id/title/id
some other format with "tb" that I'm forgetting

("tb" is for the old reddit toolbar "reference" links, but they still work as far as I remember.)
Now, that's for our lovely lady reddit.com.
Other reddit instances can define/redefine some new permalink formats. As it is, PRAW supports other reddit instances; if they follow the API as close as possible. Instead of someone having to manually edit the source for their new urls to be recognized, using the url parameter as it is is supported regardless if url format is changed from reddit instance to instance because it simply requests the json of those urls and (I think the correct term is) parses them and  "object-ifies" them.

A submission object contains the information about a Submission, and should always have a permalink that links to the Submission without any sort of context. It should have no parent because a Submission cannot be nested under anything.

...Thus each comment's parent can either be another comment or the submission.

Yes; bingo, totally agree with the above, and that's how it currently is, even if you take the PR's added functionality into account.

From a submission one can obtain its forest of comments (they're conveniently provided when making the request). Each comment belongs to a submission, and has some location within that submission's forest of comments.

This presents the problem of obtaining a partial view of a Submission's forest, a single tree in this case (sense I don't think any endpoint will return more than one tree). Perhaps the solution is separate these trees from the submission object they happen to be returned with, and finally just provide a standalone get_comment function that returns a comment along with all of its children.

This is where the perspective should be changed. Instead of a forest of comments, what is in fact conveniently provided is the "stump"(s) of the comment tree(s), and that stump's maturity, branches, stems, leaves, etc. Specifying a comment id allows one to choose a stump/branch further up a tree. With no stump specified, what is conveniently provided is either multiple trees, or in fact, under rare occasions, only one tree (some submissions can only have one comment tree by the fact that a user doesn't make a new one)
, or enough trees to be considered a forest.

With the presence of such a method we can modify get_submission to only take in top-level submission urls (or just the submission_id) and have them use get_comment when they want something more specific. Calling get_comment and then trying to fetch its parent should be permitted, but it'll certainly be inefficient. The other inefficient thing would be to do get_comment(...).submission.comments as another request would need to be made to the Submission to fetch it's actual comment forest.

Like mentioned above, this is probably difficult to modify in such a way due to the various urls, or if you take urls out of the equation completely, you put limits on the support for modified reddit instances (which is another thing that I want to get to later[1]), as well as put limits on the "ease of access" aspect.

Overall the Submission object was never intended to support partial comment trees. It was simply a work around. Yes, we'll need to deprecate the current use, but I think it's totally worth it to provide the functionality you want in a clear way.

I don't feel it's worth it considered what was mentioned above when a change of perspective allows the same to occur.
In total, the ideology needs to be changed from "a forest of comments" to the fact that each and every single tree of comments has the complete ancestral base stump of the submission itself, and at the same time each (non top level) comment has a comment parent.
Each Submission object will always represent the submission itself. What is conveniently provided is either all the trees (or at a minimum all trees that can be provided) or a specific tree based on the user's decision. It's up to a user to decide how he handles that specific tree, what s/he does with it, how s/he handles it in reference to getting the rest of the comments in the other tree (which is technically inefficient but it is possible and is allowed), and whatever else.
What do you think?
[1] Something that I'd like to see in the long run, if possible, is to somehow move the API PATHS dictionary to be in some form of config.ini file, and when one (initializes?) a reddit instance via praw.reddit('useragent', site_name='someotherreddit'), praw checks a page on said instance such as /praw.json and that allows said site to overwrite the paths, making it even more compatible with modified reddit instances.

First, we don't have to handle everything. If we fallback to existing behavior that's suitable, so I'm not concerned about URLs different people may be using.
Second, I'm not at all concerned about custom instances of reddit that deviate from the standard URLs. Again the existing fallback for unrecognized URLs would be suitable. I am not reading your [1] post.  My initial thought is that the use case here is incredibly small and not worth the effort, but perhaps I'm wrong.
Regarding our perspectives, I don't really see a difference. Overall I think we're getting away from your pull request. I've been focusing on using Submission objects for things I don't think they're intended for, and you haven't even modified Submission objects at all. Thus, I think what is needed is to break this pull request up into smaller components. Let's add one feature that you want at a time. And I would really love the documentation updates to be in their own PR. Can we start with that?
Thanks for the conversation.

Sure, I'll separate things up.

@bboe as it turns out after some testing with all of the redirect and oauth exceptions, there are only 4 valid submission url formats; and from that, only 2 valid comment permalink url formats. Since with that it is possible to check the url and give errors / change the return value; I'll implement said check and add a PartialSubmission subclass, as well as add/fix any other underlying issues.

@13steinj what's your thoughts on this pull request now?

@bboe Oh sorry, somewhat forgot about this. I made most of the changes you recommended already on my local branch but after the tests randomly broke I stopped. I'll finish it off sometime tomorrow.

@13steinj some of my original comments look like they should be addressed. Also it looks like a rebase is needed. With that the betamax cassettes will probably need to be regenerated to create the "pretty" formatted cassettes.

I'm closing this PR as I don't think even if it were updated it would make sense to add to PRAW3. With that said, we should once again revisit the behavior you'd like to see and see if it makes sense to add to PRAW4.


Update documentation: website is moving to ghostery.com/whotracksme

The website has been integrated into https://www.ghostery.com/whotracksme now.
Data dumps are not affected, but the links to the old whotracks.me website should be updated to use the new links:

https://www.ghostery.com/whotracksme
https://www.ghostery.com/whotracksme/trackers
https://www.ghostery.com/whotracksme/websites
https://www.ghostery.com/whotracksme/explorer

Also, the README could do a better job at explaining the interaction between the related projects:

https://github.com/whotracksme/whotracks.me (this repository)
https://github.com/ghostery/trackerdb

In a nutshell, TrackerDB provides the meta-data (e.g. company descriptions), while the whotracks.me repository is for the actual data (both in its raw form as CSV files, but also in visualization form as shown on the website).
Note: The website migration has no implication on other aspects like licensing or the way we publish monthly data dumps. Building the website with locally will be still possible, even if the transition to the new website is completed.

Changed now: whotracks.me redirects now to https://www.ghostery.com/whotracksme/


Set deployment target to iOS8

@mono0926 Any particular reason for this change? Alamofire supports iOS 7 as shown in the README.
# Requirements

iOS 7.0+ / Mac OS X 10.9+

Sorry, this PR is mistake...


Page objects created via PDF Issue upload should have same permissions as parent

User story
As an admin user
When I create a new NewspaperIssue work via the admin UI
And I upload a PDF as an attachment to that work
The NewspaperPage objects that are created representing the pages of the issue
Should have the same access/edit/visibility permissions as the parent Issue object
Discussion
Current permissions discrepancy exists where child Page objects are set to visibility_ssi:"hidden" in Solr, even if parent Issue has visibility_ssi:"open".
Both Issue and Page have the same depositor info.
This ticket will be complete when:
Automatically-created Page objects have same access/edit/visibility permissions as parent Issue.

@ebenenglish to clarify, my read is that the scope of this ought to include not only synced permissions at creation time, but also after updates/changes to the visibility of the issue?  Can you confirm that is the intent?
My latest commit takes care of creation-time permission sync but not yet the update of NewspaperIssue permission sync.
Effect of leaving it with only create-time sync (copy permissions) is to require getting permissions right on initial upload or ingest.  OTOH, there may be corner cases where certain child pages should have distinct permissions from their parent issue, but I cannot yet contemplate the particulars.

I think that the scope of this is only creation-time permission sync.
We can create a backlog issue for non-creation/ingest update/change permissions propagation to child Page objects.

Fixed via #127.


The attention mask is not set and cannot be inferred from input because pad token is same as eos token. As a consequence, you may observe unexpected behavior. Please pass your input's attention_mask to obtain reliable results.

使用 Qwen2.5-7B-Instruct FastApi 部署调用 文档部署 Qwen2.5-32B-Instruct 模型，在最后的服务启动后，尝试使用 curl 测试推理，但是发送curl 命令后，服务打印 The attention mask is not set and cannot be inferred from input because pad token is same as eos token. As a consequence, you may observe unexpected behavior. Please pass your input's attention_mask to obtain reliable results. 后边没响应了。

兄弟，解决了吗？我也卡在这儿


lsq_linear hangs/infinite loop with 'trf' method

I have found several cases where scipy.optimize.lsq_linear with non-negative bounds (i.e. (0, numpy.Inf)) hangs, seemingly stuck in an infinite loop in some C code (LAPACK?) that can't be terminated via ctrl+c. It ran for at least two days the first time I noticed it. The non-default 'bvls' method and scipy.optimize.nnls() both work on the same data, one example of which I have attached:
x.txt
y.txt
Reproducing code example:

import numpy as np; import scipy.optimize as spopt
x = np.loadtxt('x.txt')
y = np.loadtxt('y.txt')
print(spopt.nnls(x,y))
print(spopt.lsq_linear(x, y, bounds=(0, np.Inf), method='bvls'))
print(spopt.lsq_linear(x, y, bounds=(0, np.Inf), method='trf', verbose=2))

Output:

In [1]: import numpy as np; import scipy.optimize as spopt
   ...: x = np.loadtxt('x.txt')
   ...: y = np.loadtxt('y.txt')
   ...: print(spopt.nnls(x,y))
   ...: print(spopt.lsq_linear(x, y, bounds=(0, np.Inf), method='bvls'))
   ...: print(spopt.lsq_linear(x, y, bounds=(0, np.Inf), method='trf', verbose=2))
   ...:
(array([ 2.09932938,  0.        ,  0.        , 14.74758632]), 1.1295995521670104)
 active_mask: array([ 0., -1., -1.,  0.])
        cost: 0.6379975741279486
         fun: array([-0.003566  , -0.00431135, -0.00317054, ...,  0.00151165,
        0.00256816,  0.00488628])
     message: 'The first-order optimality measure is less than `tol`.'
         nit: 3
  optimality: 4.209012793594848e-15
      status: 1
     success: True
           x: array([ 2.09932938,  0.        ,  0.        , 14.74758632])
   Iteration        Cost      Cost reduction    Step norm     Optimality
       0         5.9926e+01                                    6.86e+01
       1         9.5818e+00      5.03e+01       2.39e+00       1.62e+01
       2         1.5210e+00      8.06e+00       1.07e+00       3.26e+00
       3         8.3612e-01      6.85e-01       3.31e-01       3.94e-01
       4         7.9232e-01      4.38e-02       6.33e-01       7.22e-02
       5         6.9727e-01      9.51e-02       9.96e+00       4.75e-02
       6         6.9645e-01      8.16e-04       1.43e-02       7.09e-02
/software/lsstsw/stack_20181012/python/miniconda3-4.5.4/envs/lsst-scipipe/lib/python3.6/site-packages/scipy/optimize/_lsq/common.py:321: RuntimeWarning: invalid value encountered in add
  y = a * t**2 + b * t + c
/software/lsstsw/stack_20181012/python/miniconda3-4.5.4/envs/lsst-scipipe/lib/python3.6/site-packages/scipy/optimize/_lsq/common.py:362: RuntimeWarning: invalid value encountered in double_scalars
  return 0.5 * q + l
       7             inf            nan            inf            inf

Scipy/Numpy/Python version information:

1.1.0 1.14.5 sys.version_info(major=3, minor=6, micro=6, releaselevel='final', serial=0)

I have also reproduced this on a different machine with 1.0.0 and 1.2.1.

I can reproduce this as well. x has magnitudes in the range (1e-192, 0.65) while y in range (1.4e-7, 1.64). So this is pretty pathological. Still, infinite loops should never happen.

@taranu thanks for finding this bug!
I quickly checked your example and found that the (final) reason it failed was returning a position of nan when calling np.argmin. After I changed this call to np.nanargmin it converged to the same solution. However, I want to investigate whether such case is handled correctly at all. Getting nans is not a good thing generally.

I don't know if it is of interest, but the same behaviour persists with ill-conditioned matrices. For example, consider the following:
A = np.array([[0.8854232310355122, 0.0365312146937765, 0.0365312146836789],
[0.3742460132129041, 0.0130523214078376, 0.0130523214077873],
[0.9680633871281361, 0.0319366128718639, 0.0319366128718388]]),
b = np.array([0.0055029366538097, 0.0026677442422208, 0.0066612514782381]), and
bounds = (np.array([0.0, 0.0, -np.inf]), np.array([np.inf, np.inf, np.inf])),
where the 2nd and the 3rd column of A are practically collinear.
Then lsq_linear(A=A, b=b, bounds=bounds) never returns.
If, however, you round the entries of A and b to 8 digits beyond the decimal point, then lsq_linear succeeds.
Thank you for implementing lsq_linear. It has been a life saver. The issue I describe above can be avoided in client code by checking A's condition number before calling lsq_linear.
Best regards.

@isaiahpantelis
Thanks for this test! I'm going to check that after the latest fix it is solvable by lsq_linear.

So the results.
Using bvls:
   Iteration        Cost      Cost reduction    Step norm     Optimality
       0         3.2528e+13                                    1.09e+07
       1         1.0162e-08      3.25e+13       1.61e+08       3.83e-18
The first-order optimality measure is less than `tol`.
Number of iterations 2, initial cost 3.2528e+13, final cost 1.0162e-08, first-order optimality 3.83e-18.
 active_mask: array([ 0., -1.,  0.])
        cost: 1.0162165864391485e-08
         fun: array([ 1.31158645e-05, -1.36031441e-04,  4.05925211e-05])
     message: 'The first-order optimality measure is less than `tol`.'
         nit: 2
  optimality: 3.828413007130446e-18
      status: 1
     success: True
           x: array([ 0.00968836,  0.        , -0.08382538])

Using trf:
   Iteration        Cost      Cost reduction    Step norm     Optimality
       0         1.3011e+14                                    1.30e+14
       1         7.5081e-05      1.30e+14       3.21e+08       1.81e-04
       2         1.6610e-06      7.34e-05       2.42e+09       3.40e-06
       3         4.0532e-07      1.26e-06       1.46e+09       8.42e-02
       4         3.9860e-07      6.71e-09       9.36e+03       1.80e-01
       5         3.9860e-07      4.12e-12       4.45e+03       7.59e-10
       6         1.0162e-08      3.88e-07       1.19e+09       8.64e-11
The first-order optimality measure is less than `tol`.
Number of iterations 7, initial cost 1.3011e+14, final cost 1.0162e-08, first-order optimality 8.64e-11.
 active_mask: array([0, 0, 0])
        cost: 1.0162165948984031e-08
         fun: array([ 1.31157643e-05, -1.36030700e-04,  4.05950391e-05])
     message: 'The first-order optimality measure is less than `tol`.'
         nit: 7
  optimality: 8.643008744116252e-11
      status: 1
     success: True
           x: array([ 0.00968837,  0.64085948, -0.72468519])

The solution points differ somewhat, but as you can see the final costs are very cost. For small number of variables using bvls is perhaps preferable because it clearly reveals active constraints.
I'm going to add your example as a test.

Great, thanks for the prompt response.


[WIP] audit: Port audit_keg_only to RuboCop and add tests

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

Addresses #7392. Still a WIP.

Tests seem to be failing due to a brew style check on a formula in homebrew-core.

@BrewTestBot test this please

@BrewTestBot test this please

That doesn't work with GitHub Actions 😭. You can do that by rerunning from https://github.com/Homebrew/brew/pull/7460/checks (which I've done for you).

Looks like some Linux issues: https://github.com/Homebrew/brew/pull/7460/checks?check_run_id=632955505#step:21:49

Thank you for the heads up @MikeMcQuaid! All tests pass now and I've marked this PR ready for review. I will be addressing other audit rules in separate PRs. Thanks again!


Code for CLIP score after masking

Thanks for releasing the code! I would like to reproduce the results of the paper on the medium scale.
From my understanding, the code released generates text detection bounding boxes for each image in the metadata.
However, to reproduce the results in the paper, we need to re-compute CLIP score after masking. I do not see the new CLIP score saved in the metadata. What am I missing?

We saved the CLIP scores separately by masking the images based on the bounding boxes. This was done because the evaluation of CLIP score (only forward pass) can be done much faster than the detection process. We will be adding code to do the same shortly, but this should be straightforward (running a forward loop through the dataset, and masking images with mean color before sending to the CLIP model). Thanks for pointing this out.

Thank you for the prompt reply. Will be looking forward to the code release for recomputing CLIP score.
Meanwhile, are you planning to publish the uids for the medium scale? Also, have you attempted T-MARS on the large scale?

Hi @nazMahmoud ,
Thank you for your interest in our work.
Here are the data UIDs and Checkpoint for TMARS trained on DataComp medium scale.
Thanks


Gen-Plugin for 3rd Party Plugins generates an incorrect entrypoint

Gen-Plugin for 3rd Party Plugins generates an incorrect script entrypoint.
When a 3rd party plugin is generated, installed, and the aac -h command is run the following error appears:
Traceback (most recent call last):
  File "/workspace/AaC/python/venv/bin/aac", line 33, in <module>
    sys.exit(load_entry_point('aac', 'console_scripts', 'aac')())
  File "/workspace/AaC/python/src/aac/cli/execute.py", line 16, in run_cli
    arg_parser, aac_plugin_commands = _setup_arg_parser()
  File "/workspace/AaC/python/src/aac/cli/execute.py", line 47, in _setup_arg_parser
    aac_and_plugin_commands = get_plugin_commands()
  File "/workspace/AaC/python/src/aac/plugins/plugin_manager.py", line 89, in get_plugin_commands
    return list(flatten([plugin.get_commands() for plugin in get_plugins() if plugin.get_commands()]))
  File "/workspace/AaC/python/src/aac/plugins/plugin_manager.py", line 79, in get_plugins
    return get_plugin_manager().hook.get_plugin()
  File "/workspace/AaC/python/src/aac/plugins/plugin_manager.py", line 22, in get_plugin_manager
    plugin_manager.load_setuptools_entrypoints(PLUGIN_PROJECT_NAME)
  File "/workspace/AaC/python/venv/lib/python3.9/site-packages/pluggy/_manager.py", line 287, in load_setuptools_entrypoints
    plugin = ep.load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
    module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 984, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'test_plugin.test_plugin'

The expected entrypoint in setup.py.jinja2 should be:
"aac": ["{{plugin.name}}={{plugin.implementation_name}}"],

AC:

[ ] Gen-Plugin generates 3rd party plugin entrypoints correctly
[ ] Gen-Plugin moves 3rd party plugin yaml files into the generated plugin files
[ ] The 3rd Party Plugin integration test attempts to run aac -h after the 3rd party plugin is installed

[ ] The stage must fail before the plugin is fixed
[ ] The state passes after the plugin is fixed

@Coffee2Bits is there already a test written for this where it can be tested locally or will the changes need to be tested in the GH pipeline? I am making some changes and I am wanting to make sure things are still stable before I commit if it is possible.

Rolling to Sprint 4.

AC-1, and 2 seem to be met. I am going to reach out to see if the AC-3 is in regards to the pipeline in GH or if it is something to be checked locally.


Question: does Helium version of MFCC bitmatches with Python from x86 server?

@olegkhr The answer is no for reasons explained here (for FFT):
Issue : https://github.com/ARM-software/CMSIS-DSP/issues/196
Same explanation applies to MFCC since it is relying on the FFTs.


Upgrade golang.org/x/net for security fix

Change Overview
The Go team announced a security vulnerability in the golang.org/x/net/html package. The vulnerability allowed an attacker to craft an input to ParseFragment that would cause it to enter an infinite loop, causing a denial of service.
This issue has been addressed in version v0.0.0-20210520170846-37e1c6afe023 of the golang.org/x/net module.
Tracking ID: CVE-2021-33194
Announcement: https://groups.google.com/g/golang-announce/c/wPunbCPkWUg
Pull request type

[X] :bug: Bugfix

Issues

N/A

Test Plan
N/A

[ ] :muscle: Manual
[ ] :zap: Unit test
[ ] :green_heart: E2E

Thanks for looking at this, @vkamra and @julio-lopez! :bow:


All warnings cleared

Both the avalanche of warnings from dotnet run and dotnet test has been cleared.
I've added a ArgumentNullException for NewCheep.Message, i.e. when the cheep is empty it'll show that exception message, this should be done more refined where the user is stopped all together in the html from posting empty cheeps. I will fix this in another branch.
Resolves #201

@JonasSkjodt

I've added a ArgumentNullException for NewCheep.Message, i.e. when the cheep is empty it'll show that exception message, this should be done more refined where the user is stopped all together in the html from posting empty cheeps. I will fix this in another branch.

To this I would like to add that this is already another issue on the project board and there is currently an open PR that fixes just this issue that you are talking about #214


Wierd custom onSubmit behavior

Hi,
My react app sends formio forms to camunda bpe. I’m having a bit of an odd issue using @formio/react: sometimes it doesn’t call the provided onSubmit handler. That seams to happen in two cases: 1. when I set the form submission; 2. when I have subForms in the form. When the anomaly happens, I see a POST request that tries to persist the submission to the apiBaseUrl (and fails, obviously, because there’s no backend there).
Could someone help me understand what triggers the “default” submission as opposed to the custom one? I think that is the use case for the nosubmit=true option of the formio.js but I think it is not present as an option for the Form component.
thanks

To better help you with your issue could you please provide the form json for both of your cases? I am also unsure what you mean by "Could someone help me understand what triggers the “default” submission as opposed to the custom one?" What do you mean by custom one?


Sysmon v10.0, Autoruns 13.95, VMMap 3.26

Docs Build status updates of commit 9c15884:
:warning: Validation status: warnings

File
Status
Preview URL
Details

toc.json
:warning:Warning

Details

bread/toc.json
:warning:Warning

Details

sysinternals/downloads/autoruns.md
:white_check_mark:Succeeded
View

sysinternals/downloads/index.md
:white_check_mark:Succeeded
View

sysinternals/downloads/sysmon.md
:white_check_mark:Succeeded
View

sysinternals/downloads/vmmap.md
:white_check_mark:Succeeded
View

sysinternals/index.md
:white_check_mark:Succeeded
View

toc.json

[Warning] Error happen when converting toc.json to Pdf. Details: Could not find file 'T:\pt5k\toc.json'.

bread/toc.json

[Warning] Error happen when converting bread/toc.json to Pdf. Details: Could not find a part of the path 'T:\pt5k\bread\toc.json'.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


WIP: MRT Proof of concept

What issue is this addressing?

https://github.com/hajimehoshi/ebiten/issues/2930
What this PR does | solves

This is a proof of concept of MRT (multiple render target), to investigate if the concept could be integrated to ebitengine, this is not a merge candidate for now.
go run ./examples/mrt

dsts = [4]*ebiten.Image{
		ebiten.NewImageWithOptions(image.Rect(0, 0, 128, 128), &ebiten.NewImageOptions{Unmanaged: true}),
		ebiten.NewImageWithOptions(image.Rect(0, 0, 128, 128), &ebiten.NewImageOptions{Unmanaged: true}),
		ebiten.NewImageWithOptions(image.Rect(0, 0, 128, 128), &ebiten.NewImageOptions{Unmanaged: true}),
		ebiten.NewImageWithOptions(image.Rect(0, 0, 128, 128), &ebiten.NewImageOptions{Unmanaged: true}),
}
shaderSrc = []byte(`
//kage:units pixels

package main

func Fragment(dst vec4, src vec2, color vec4) (vec4, vec4, vec4, vec4) {
	return vec4(1,0,0,1), vec4(0,1,0,1), vec4(0,0,1,1), vec4(1,0,1,1)
}
`

{
      ebiten.DrawTrianglesShaderMRT(dsts, vertices, indices, s, nil)
      // screen.Draw all 4 images to assess that they've been written to with the same geometry / draw call
}

[x] OpenGL
[x] DirectX 11
[x] DirectX 12
[x] WebGL => A bit more problematic due to the glsl compatibility between desktop
[ ] Metal

Notes:

It only seems to make sense with unmanaged *ebiten.Image (as in different internal textures).

dst images could be moved to separate atlases if they're not ebiten.unmanaged: https://github.com/hajimehoshi/ebiten/issues/2930#issuecomment-2041157459
dst images, if moved to new textures or existing (available) ones should share the same region (rectangle) as they originally do, because of scissor, viewport definition but mostly because the triangles define the logical destination position, moving to an arbitrary region would make the triangles target the wrong rectangle
dst images should have the same sizes probably, since the triangles, scissor and viewport should target the same region for all destination textures

I set the max dst images count to 8, since 8 seems to be the guaranteed minimum by all drivers
The example found in examples/mrt is probably to be removed and changed for a more relevant example, I put it there so that we can see a minimal reproduction of the feature temporarily

Please rebase your PR, thanks!

Let's close this PR, since we require more 2D use cases and user requests regarding this feature: https://github.com/hajimehoshi/ebiten/issues/2930#issuecomment-2214822950


Migrate flutter_webview to the new embedding

Description
This depends on a new bugfix on the engine for text input to work with
the new embedding (flutter/engine#13015).
This also introduces some interesting and strange new failure cases.
With the new embedding, a FlutterView can be attached and detached from
the plugin at any point. It "should never" but technically can happen
that the plugin gets into a state where there is an active proxy adapter
view but no valid FlutterView to use for input proxying. For now I've
mostly added error logs and guards against NPEs detecting whenever we've
gotten into one of this situations. But I think we should probably
rigorously test this in an a2a specific situation to truly vet for a2a
support.
DO NOT MERGE until we can land tests for this.
Related Issues
flutter/flutter#41851
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[ ] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[ ] I updated CHANGELOG.md to add a description of the change.
[x]  I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

I haven't decided how to handle the fact that we need a new version of the engine for this work with the new embedding yet. Naively we can try to check the version and then log the error but that's not great. Without the engine patch text input doesn't work on older Android versions at all with the new embedding.

I believe this PR is ready to merge, after review. The latest commit added the new e2e tests and updated the pubspec.yaml.


[Q] Format date ehen writing to xlsx

💬 Questions and Help
Hi,
I'm writing to a workbook using workbook.xlsx.write().
My dates are formated like YYYY-MM-DDT00:00:00.000Z in my data due to it being fetched from a SQL server.
I would like to get them formated as a date in Excel.
Using CSV there  seems to be a possibility to format dates using the option property.
workbook.csv.writeFile(filename, options)
Is there something like this for the xlsx.write function?

@Curium1
You can make use of styles (numFmt) when specifying the worksheet columns:
ws.columns = [
  { header: 'Id', key: 'id', width: 10 },
  { header: 'Name', key: 'name', width: 32, style: { font: { name: 'Arial Black' } } },
  { header: 'D.O.B.', key: 'DOB', width: 10, style: { numFmt: 'dd/mm/yyyy' } }
]

That way, any cell under the DOB column will be styled with that date format.
numFmt style prop serves as formatting for numbers, dates and strings. Yeah, really bad naming!

Thanks!

I was just about to write the same thing to add to the answer just in case anyone else wondered :)
Once again thank you!

@Curium1 I verified that there is NO need to set useStyles to true for styling to work, even though it defaults to false. That flag may play another role in the lib.

@Curium1
You can make use of styles (numFmt) when specifying the worksheet columns:
ws.columns = [
  { header: 'Id', key: 'id', width: 10 },
  { header: 'Name', key: 'name', width: 32, style: { font: { name: 'Arial Black' } } },
  { header: 'D.O.B.', key: 'DOB', width: 10, style: { numFmt: 'dd/mm/yyyy' } }
]

That way, any cell under the DOB column will be styled with that date format.
numFmt style prop serves as formatting for numbers, dates and strings. Yeah, really bad naming!
BTW, in most recent version of exceljs, it seems that one has to enable styling (defaults to false):
excel.xlsx.write(stream, {useStyles: true})
excel.xlsx.writeFile(path, {useStyles: true})

Hi,
Dates are coming as string type, can you please tell me hos to fix? Please refer the issue rinsed i.e. https://github.com/exceljs/exceljs/issues/1666 for reference.
Thanks.


Added Dropbox.Dropbox version 127.4.4265

PS C:\Users\WDAGUtilityAccount\Desktop\manifests> winget install -m "C:\Users\WDAGUtilityAccount\Desktop\manifests\d\Dropbox\Dropbox\127.4.4265"
Found Dropbox [Dropbox.Dropbox]
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://edge.dropboxstatic.com/dbx-releng/client/Dropbox%20127.4.4265%20Offline%20Installer.exe
  ██████████████████████████████   134 MB /  134 MB
Successfully verified installer hash
Starting package install...
Successfully installed

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@denelon @ChuckFerring I believe this needs the Azure-Pipeline-Passed label for a Moderator to approve and merge it.


cc-wrappers inconsistently treats -idirafter between native and cross-compilers

Describe the bug
This works:
$ printf '#error "DO NOT INCLUDE ME"' > stdio.h
$ nix shell nixpkgs#stdenv.cc
$$ printf "#include <stdio.h>" | gcc -E - -o - -idirafter . >/dev/null; echo $?
0

This does not:
$ printf '#error "DO NOT INCLUDE ME"' > stdio.h
$ nix shell nixpkgs#pkgsCross.aarch64-multiplatform.stdenv.cc
$$ printf "#include <stdio.h>" | aarch64-unknown-linux-gnu-gcc -E - -o - -idirafter . >/dev/null; echo $?
In file included from <stdin>:1:
./stdio.h:1:2: error: #error "DO NOT INCLUDE ME"
    1 | #error "DO NOT INCLUDE ME"
      |  ^~~~~
1

Expected behavior
Both should work: -idirafter should have a preference below system headers (as it does for ~unwrapped gccand~ other linux distributions).
~It's a side-effect of cc-wrapper using -idirafter to inject libc headers into a reasonable place. But this fails this override semantics.~ UPDATE: I'm not sure what exactly causes it. Maybe it's a --with-headers= or --with-native-system-header-dir= side-effect. Needs a research.
Practically this causes issues in other packages like ubootTools and various attempts at using include injection like https://github.com/NixOS/nixpkgs/pull/219421
Additional context
Add any other context about the problem here.
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.4.3, NixOS, 23.11 (Tapir), 23.11.20230725.4076c4f`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.16.1`
 - channels(root): `""`
 - channels(slyfox): `""`
 - nixpkgs: `/run/current-system/sw/share/nixos-flakes/inputs/nixpkgs`

And it does seem to be a regression. 22.05 does not fail:
$ nix shell github:NixOS/nixpkgs/release-22.05#pkgsCross.aarch64-multiplatform.stdenv.cc
$$ cat stdio.h
#error "DO NOT INCLUDE ME"[nz] /tmp:
$$ printf "#include <stdio.h>" | aarch64-unknown-linux-gnu-gcc -E - -o - -idirafter . >/dev/null; echo $?
0

Bisected down to https://github.com/NixOS/nixpkgs/pull/219811 gcc: do not install sys-include headers for cross-compilers
Proposed the revert in https://github.com/NixOS/nixpkgs/pull/245550

Can we close this now that's merged?
Then I should be able to adapt #219421

Sounds good. Closing.


Fix multiple dispatch problem with async servlet timeouts.

Servlet containers with async context will redispatch after a timeout. In Jettys case the default seems to be 30 secs. I think it is part of the three steps discribed here: https://docs.oracle.com/javaee/6/api/javax/servlet/AsyncContext.html
The provided testcase fails without the fix.
This might also be the cause of what we are seeing in #52

Yes. About 2.8 seconds.

A temporary workaround:
System.setProperty("org.eclipse.jetty.server.HttpChannelState.DEFAULT_TIMEOUT","0")

@spand merged, thanks!


ACC problem

Hello! Thanks for the great work.
I ran your example CIFAR100, but the acc obtained in the test is inconsistent with that in your paper, can you help me find out the reason
thank you for your patience.

您好，你是怎么跑通这个代码的？


[BUG] Missing parameters for kamelet defined in URI

Describe the bug
Missing parameters for kamelet defined in URI.
in combination of removal of unknown properties, it means that it is removing parameters specific to the kamelet when using sync code
To Reproduce
Steps to reproduce the behavior:

Open Source code editor
Paste

- from:
      uri: kamelet:timer-source
      id: from-d428
      parameters:
        period: 2
        message: hello
      steps: []

Click on 'Sync code'
--> parameters are removed:

- from:
    id: from-d428
    uri: kamelet:timer-source:null
    steps: []

or

Add a step kamelet
Provide template id timer-source

Expected behavior
maybe as iteration 0, to remove the kamelet from the catalog and mention that it is not supported.
as first iteration to not lose the data
as second iteration to allow to edit the parameter values in the UI
Logs
If applicable, add logs to help explain your problem.
Environment (please complete the following information):
OperateFirst
Additional context
used for instance in Quarkus super heroes example: https://github.com/pprosser-redhat/quarkus-super-heroes/blob/6528f5ee69a1bfaec16b79747f62c574e6f8360a/camelkfordebezium/camelformessaging/messaging.camel.yaml#L5

Add parameters as a parameter object to the kamelet component so the parameters are not lost (even if they can't be configured via the canvas).


ts type PermissionName is missing many permission names

Many permission names such as 'camera', 'microphone', 'clipboard-read', 'clipboard-write' are missing in the type PermissionName type in the lib.dom.d.ts file, please refer to https://developer.mozilla for details .org/en-US/docs/Web/API/Permissions

This type comes with TypeScript and should be reported in TS repo.
Also see https://github.com/microsoft/TypeScript/issues/33923#issuecomment-1111598837 for criteria how items are added lib.dom.d.ts

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


Added setting of the window title under Cygwin

Common method for setting window title using escape sequences works under Cygwin on Windows too (for example in mintty, ConEmu and even in plain cmd.exe). But Cygwin sets TERM environment variable to "cygwin" by default. Therefore I have added "cygwin" to the TERM testing condition. Tested in ConEmu, mintty and cmd.exe.

I tested on Cygwin under Windows 7. It works. It's largely unneeded with current Cygwin versions, because MinTTY declares itself as xterm and that's the main "prompt" option installed for users now. But this makes it work in cmd.exe/regular Windows console windows too (what's known as the "plain" Cygwin prompt), and it's good to have for completeness.
:+1:

@apjanke Not only regular Windows console, but mainly ConEmu. I think that ConEmu is used much more than MinTTY, which even doesn't support multiple tabs. I have ConEmu running constantly with a lot of opened tabs (the most of them are Cygwin, sometimes Git-Bash, PowerShell, or even plain cmd), everything inside one window. Cygwin is designed to work with TERM environment variable set to "cygwin", so would be great, if oh-my-zsh would support it.

Oh, cool. I didn't know about ConEmu. Checked it out today. This looks a lot nicer than MinTTY. Thanks @ferenczy !
Tested on ConEmu on Windows 7 with Cygwin zsh. Works there too.
This looks good to merge after a rebase.

Ping... want to rebase this so we can merge?


Documentation for separate imports for client/server bundle

Obviously this package is a WIP, but as an eventual documentation (or maybe feature) request:
Having some guidance on how to load different code on the server vs on the client would be helpful. Vite has a generic mechanism for adding conditional SSR logic, but that method won't work for switching out static imports on the client vs the server (e.g. providing a client version of a service on the client and a server version of a service on the server). Angular CLI handles this by allowing the user to specify file replacements per build environment (e.g. dev vs prod vs test).
Vite has instructions for creating a conditional config based on the build settings, unfortunately this doesn't appear to help (in development at least) because the config is only called once with the following environment object: { mode: 'development', command: 'serve' }. As such, it doesn't appear possible to use this feature to provide a file replacement pattern just for the server build.
It seems possible that this is a feature request for the solid-start plugin.

It doesn't work on static imports? I guess I should try again with Vite specifically. I mean technically solid-js/web has isServer that I've been using. Rollup is smart enough to treeshake out ESM modules.
So I was relying on this mechanism working.

Well the conditional config option doesn't work for the reasons described above, and the method for adding server/client conditional logic won't work for static imports for several reasons
1)
You might be thinking that this would work
import { ServerPkg } from 'server-pkg';
import { ClientPkg } from 'client-pkg';

const service = import.meta.env.SSR ? new ServerPkg() : new ClientPkg();

because tree shaking would turn it into something like
import { ClientPkg } from 'client-pkg';

const service = new ClientPkg();

Except I don't think tree shaking will happen if server-pkg / client-pkg has side effects
2)
You  can't make an explicitly side effecting import work (so far as I know)
import "server-pkg"
// or
import "client-pkg"

3)
Relying on something like option (1) would also mean that development code vs production code would be slightly different because, theoretically, tree shaking wouldn't be happening in development. Maybe this wouldn't be a problem though.

It does introduce potential for client and server not to match. I have an idea though for server data components/files that hopefully achieve similar goal. But I'd if possible encourage the view code to be the same.

I should also mention you can brute force it for the few places you have libs with side effects. You can tell Rollup to mark them as external and then there is a treeshaking option that completely removes external modules. I haven't done this through vite yet but it worked fine in pure rollup to remove the stream lib from a build I was doing where CJS version was getting pulled in (so couldn't be treeshaken). A bit manual but the idea is very few libraries would fall under this category.

First of all: @ryansolid solid start is unbelievably awesome. The concepts are so easy to understand and it's so intuitive to use for an Angular dev like me :D  It's way easier to use than next.js imo.
Now to my problem:
I have a concern that I think plays into this here. I want to implement a very basic authentication system in a solid start app and want to use argon2 for password hashing. The problem is, that I get an error in the server console but it works nevertheless. I guess this is just the client build failing. The error message is:
[vite] error while updating dependencies:
Error: Build failed with 1 error:
node_modules/.pnpm/argon2@0.30.2/node_modules/argon2/argon2.js:6:32: ERROR: No loader is configured for ".node" files

I tried putting the logic that uses argon2 in an api route instead of a server action but still the same error appears.
I suppose this is only the client build having fits with the imported package and the server build is fine with it.
I'd love to be able to completely exclude certain imports from the client build so i can be sure nothing is sent to the client that doesn't belong there.
Is this possible currently? And where would logic like hashing passwords be placed ideally, is a serverAction sufficient?

@ChristofFritz You can use optimizeDeps.exclude to exclude any dependency that is incompatible with vite.
I've also personally opted for the following convention: any dependencies under dependencies in package.json gets externalized. The logic for that is that if it can be bundled it won't be needed in node_modules and can therefore be put under devDependencies. So only vite incompatible dependencies are left under dependencies.
const pkgJSON = JSON.parse(readFileSync("package.json", "utf-8"))

export default defineConfig(() => ({
  plugins: [solid()],
  optimizeDeps: {
    exclude: Object.keys(pkgJSON.dependencies ?? []),
  },
}))

@ghalle Thank you for your blazingly fast reply ^^ and thank you for the working solution. You resolved my problem.

In setting up for SolidStarts next Beta Phase built on Nitro and Vinxi we are closing all PRs/Issues that will not be merged due to the system changing. If you feel your issue was closed by mistake. Feel free to re-open it after updating/testing against 0.4.x release. Thank you for your patience.

See https://github.com/solidjs/solid-start/pull/1139 for more details.


split up crate using feature flags

Individual socket types are only implemented when they are requested via
the feature flag. Also, unless the os-poll feature is specified, the
crate is a shell.
This is just a spike to illustrate the idea. A lot of the feature flag separation could be cleaner (probably). Also, the "shell" versions of UDS and UDP are not yet done.

The cargo-hack crate is pretty useful for testing feature flags. I used it w/ the following command:
RUSTFLAGS="-Dwarnings" cargo hack check --each-feature

I also don't expect CI to necessarily pass at this point.

Superseded by #1192


add infer schema functionality

Implemented using InferSchema object which is interchangeable with the normal Schema object
The InferSchema object learns and improves the schema as you add rows

something strange with this PR, will open new one

Coverage increased (+2.2%) to 87.375% when pulling 4c5f975ef96d9527e1095c20022201e8d6986927 on OriHoch:7-infer-schema into 0e3ff026f20f226d4e3c1a58790ceff03629ddb7 on frictionlessdata:master.


binja updates to m68k

Looks like the API for binja changed and it broke your 68k interface. Also, I added the code to register with the Elf loader for machine type 4.

My binary ninja license is no longer current, so I cannot maintain this code.  If the binary ninja folks are interested in helping out with that, then I might be able to maintain it.  Otherwise, someone else will have to take this over as I cannot test against the current version of binary ninja.

FYI, If @wrigjl doesn't want to take over this project, I will take the transfer.


Set wrapped with Ref Ractive, there will be type problems with the has add ... method.

Vue version
3.3.10
Link to minimal reproduction
https://play.vuejs.org/#eNqNUk2P0zAU/CuWL02k1mG1t1LQAtoDHACx3DAHN3lpvcQfsl/SSlX/O8/xNtuW1Yqb35vxzHjkA//gvRh64Eu+inXQHlkE7P17abXxLiA7sACqRj3AnE4tO7I2OMNmdGkmrbS1sxGZY+/YQVrG1DKxiptS2uMzrAhOaws79gBY/HK/S2Kc4PUIZ5d/Oa0LrMjEmrmWKTGorocyGybAdSA6tylmKeBWxdn8RBI0Fa68nOuyfPsU71p7/bJqjvYkvZ5E82mSW1W5QiqPBgTjO4VA06o6G/icYyT9Vm/EY3SWqh8tJa+d8bqD8M2jJn/JlzlMwlTXud2XcYehh/lpX2+h/vPC/jHu007y7wEihAEknzBUYQOY4fuHr7Cn8wQa1/QdsV8BfwB106eMmfaxtw3FPuONaT+PH0jbzc94v0ew8fSoFDQxjyNfcvpKn155+nPcW3E73qO2qcX8QRdG+aseM3ApQh457BbRx2VV1Y2law10egjCAlbWm+qOaFXoLWoDi8aZO3IUN2+qRkc83wuIZrEObkfVCh9cQ1Jnz08qY+lhEcA2EFI5/2d+de0iwBV2ESL5T90c/wK0l0rg
Steps to reproduce

code

log

What is expected?
No type errors.
What is actually happening?
It should be caused by this commit: https://github.com/vuejs/core/pull/8960 This commit resolves the issue with ref (it should behave as expected when accessed), but it does not work correctly in the has method of Set.

System Info
No response
Any additional comments?
No response

This is expected, we either have unwrapped or the original types on collections, to better reflect the code at runtime the #8960 is correct.
for (const c of a.value) {
  console.log('ref has', a.value.has(ref(o).value), a.value.has(ref(c).value));
}

for (const c of b) {
  console.log('reactive has', b.has(ref(o).value), b.has(ref(c).value));
}

if you wrap them into ref they will still log true true.
I don't think this issue should be fixed ATM and should wait for https://github.com/microsoft/TypeScript/issues/43826 to do a revamp on get/set

Thank you for your answer.


[FSDE-676] Update child and grand child data table background color

https://ctl.atlassian.net/browse/FSDE-676

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-55/1/. :white_check_mark:

You can check this PRs instance in https://5cd30384a48807445b1db3fa19b484ad21c6e706-chi-pr.enterprise.ctl.io

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-55/2/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-55/3/. :white_check_mark:

You can check this PRs instance in https://2a7489c55dd0390b7f6dc4e34d571a743cb5051d-chi-pr.enterprise.ctl.io


[FEATURE] Prepare an ADR on type annotations

The current approach to type annotations in Apalache is quite hacky, for several reasons:

we did not want to write own parser for types and introduced a convention, which is okayish but not natural
we wanted to wrap problematic expressions such as {} and <<>> instead of declaring the types of variables, constants, operators, and bound variables.

With the new type inference by Jure @Kukovec (to be integrated), we have to find a good way to integrate type information into TLA+ code without touching SANY (the TLA+ parser). Keeping type information on a side, e.g., in a separate file, is not a nice solution.
I see the following approach. We write our own syntax for the type system (actually, we have one already, just no parser yet) and annotate constants, variables, operators and bound names as in the following example:
EXTENDS Sequences
CONSTANTS Range
Range_type == "set(z)"

VARIABLES list
list_type == "seq(z)"

Mem(e, es) ==
  LET Mem_type == "<a, seq(a)> => Bool" IN
  \E i \in DOMAIN es:
    LET i_type == "Int" IN
    e = es[i]

Init ==
  LET Init_type == "<> => Bool" IN
  list = <<>>

Next ==
  LET Next_type == "<> => Bool" IN
  \E e \in Range:
    LET e_type == "set(z)" IN
    list' = Append(list, e)

It is again "convention-over-configuration". Note that types are specified as strings. What I like about it is that operators are easy to write and they are available almost everywhere. However, we should think about type annotations for set comprehensions.

Just a general question: Why is touching SANY a no-go?

We are still in the exploration phase and it would be a bad idea to change the syntax all the time. As far as I understand, Leslie also wants to keep the syntax minimalistic (kind of).

(I assume that the ratio of type annotations to the actual behavior spec is constant in the size of the spec)
The examples above don't really look minimalistic from a reader's perspective. Our eyes haven't been trained to filter types in TLA+ specs, but the type annotations make it more difficult to understand the true meaning of the spec.  I assume this is Leslie's main reason to keep the language minimalistic.  As a tool developer, I'm worried that types-as-strings will make it hard for IDEs or end up having poor ergonomics.  By the way, how does this work with ASSUME and the adopted best practice of TypeOK invariants?  Will it be the user's responsibility to keep them in sync?

The purpose of these type annotations is not to have them written by the user. Though it should be possible. The goal is to have transparent type information (maybe inferred by different tools) right in the spec. Once we have integrated our new type inference, every tool developer will be able to use them, without extending the TLA+ parser or using an external library. The current approach to developing all analyses in a black box makes it harder to integrate tools at all levels. On second thought, the approach presented here is not that different from Pluscal, where the whole code is written in a huge comment.
Think of these types like types in python. If you really want to write the type annotations, you can. But, ideally, it should be done by a type inference engine.
I think there is really a difference between TypeOK, which is a simple invariant on variable values, and types that are needed to do any kind of static analysis, translation, etc. Perhaps, these latter types do not add much value to the understanding of a specification, but they are absolutely essential for tooling.

So tools would be expected to auto update the specs with inferred types? And/or does the user need to provide some hints?
Why not follow the Pluscal convention and have these types in comments?
And could you give an example of how these type annotations would differ from a TypeOk ?

I gave it a bit of thought. Ideally, the authors don't have to write type annotations at all, like they (almost never) do in OCaml or Isabelle. So the tools should infer the types, as they need them. However, there are three reasons why, I believe, the types must be transparent:

It is much easier for the user to understand which types are assigned to TLA+ expressions by inspecting an annotated TLA+ file.
If somebody is not happy with our type inference algorithm, they can write one of their own and produce a compatible TLA+ file.
Our tools are still buggy. For instance, I know exactly how to fix the problem in #157 with a user annotation (in that case, we are talking about assignments, not types). But instead, we have to wait until the bug in the assignment analyzer is fixed. As a user, I am extremely annoyed by the inability to hack away the problem.

If we are talking about an ideal scenario, I would like to have something like Java annotations or LLVM intrinsics, that is, a way to store metadata right in the code, but without introducing additional code constructs, as metadata depends on the tool. I suspect that it is quite a bit of work on the SANY parser to introduce Java-like annotations. @lemmy, what is your opinion?
As for annotations in the comments, there are two problems:

If we are talking about annotations in one large comment, there is no way to refer to an individual operator/variable name. We solve this problem in Apalache by renaming operators and variables, so every name is unique. But obviously this is too much to ask from the user.
I do not see a simple way of writing an annotation preprocessor similar to javadoc, as modules can be instantiated. So the preprocessor has to understand the semantics of INSTANCE, in order to propagate annotations in the instances.

So the case of Pluscal is simple. You take one language in a large comment and translate it into one TLA+ spec. Here we are talking about type annotations for individual variables, operators, bound variables, etc.
Finally, TypeOK is an arbitrary TLA+ predicate. Even we assume that TypeOK looks like A_1 /\ \dots /\ A_n, where every A_i has the form x_i \in S_i, there is still plenty of freedom on how one writes S_i. For instance, if I write x \in 1..10, is 1..10 a type? Some people say "yes", some people say "no". Some people say, it is a refinement type {i \in Int | 1 <= i <= 10}. If we don't like to go in undecidable reasoning about types (and I don't) and only want to map expressions to simple types, we better write types as terms. For instance, we have this grammar in the OOPSLA paper:
τ ::= Name | Bool | Int | τ → τ  | Set[τ] | Seq[τ] | τ ∗ ... ∗ τ | [h_1: τ, ..., h_k: τ]
(It does not work for operators, but let's ignore that fact.) Then, I would like to have an annotation x_type = "Int". Of course, I can write x \in Int in TypeOK, and that looks fine. But then I like to give a function type from a set of integers to a set of integers, that is, f_type = "Set[Int] → Set[Int]". In TypeOK, it is getting ugly: f \in [SUBSET Int -> SUBSET Int]. I also suspect that this TypeOK also becomes useless for TLC, as it would have to deal with SUBSET Int. So in practice, one would write something like f \in [SUBSET Proc -> SUBSET Proc], as the spec most likely talks only about integers from a constant set Proc. The type annotations in Apalache are actually so weird because I could not find a nice and concise way of expressing the types that derive from τ just by using TLA+ values.
To sum up, TypeOK is a useful predicate and it is a good practice to add one. But TypeOK inevitably talks about types as sets of values (basically, you have no other choice in TLA+). For the analysis tools, especially the symbolic tools, we care less about the precise sets of values, but we need to know variable sorts (integers, Booleans, sets of integers, sequences of sets of integers).
I guess this is actually the beginning of the ADR. Sorry if the text sounds a bit too aggressive or patronizing. I just had all these things for too long in my head. Now I am happy to have them in this issue :-)

EXTENDS Sequences
CONSTANTS Range
(*                     ^@type("set(z)") *)

VARIABLES list
(*                  ^@type("seq(z)") *)

Mem(e, es) ==
(*
^@type("<a, seq(a)> => Bool") *)
  \E i, j \in DOMAIN es:
(*   ^@type("Int")
         ^@type("Int") *)
    e = es[i]

Init ==
(*
^@type("<> => Bool") *)
  list = <<>>

Next ==
(*@
^@type("<> => Bool") @*)
  \E e \in Range:
(*@^@type("set(z)") @*)
    list' = Append(list, e)

That looks completely different from what I expected, but the idea here is that we can introduce annotations graphically right in the comments. Somehow, github preview has a different idea of spaces than the final formatter.

Another solution proposed by Leslie Lamport:
  THEOREM \A a : \A e \in a, es \in Seq(a) : Mem(e, es) \in BOOLEAN

Using the (little-used) TLA+ method of referring to subformulas, this could also be used to provide type declarations for expressions inside definitions.  These type theorems would also be useful in writing proofs.

Assuming I understand you correctly, I think it's a good idea to defer the how of the visualization representation of types to IDEs.  E.g. the Toolbox could show the type annotations on-demand in mouse hovers and basic text editors can show them in-lined.  Pretty-printed specs would simply exclude all type annotations.
As to writing types when necessary, Leslie's idea of using theorems and the method of referring to subformulas would probably require IDEs to provide refactoring support for (positional) references because - contrary to TLAPS proofs - the spec is unfinished /unstable when a user writes type annotations.  On the other hand, it's probably good advice to use labeled references and rely on positional ones only for "glassbox" specs.

I like the approach of using positioned annotations in a comment below an expression. It also gives us a way to introduce all kinds of annotations, not only type annotations. Leslie's idea is interesting, as the theorem could be also proven in TLAPS, if one really wants to do that. But then the types will be far away from the place where they are used.

About types being far away:  The drawback could be alleviated by IDEs showing them in hovers/overlays and commands that navigate the cursor back and forth.

As a vim user, I am a bit skeptical about putting too much trust on IDEs :-)

It's 2020 and vim still can do something like overlays/hovers/...? :-p  Teasing aside, TLA+ has several features (PCal mapping, TLAPS annotations, profiling annotations), which only exist in the Toolbox.
Btw. I intentionally wrote IDEs and not "Toolbox" because all of this should be implemented via e.g. LSP in an IDE agnostic way.

Btw. I intentionally wrote IDEs and not "Toolbox" because all of this should be implemented via e.g. LSP in an IDE agnostic way.

Do you think it makes sense to have TLA+ on the LSP list?
Btw, there are two kinds of annotations: the user annotations (rare but possible) and output annotations. I see how LSP would work for output annotations. Leslie's approach works for both. The approach with comments also works for both, though the formatting is a bit of pain.

I guess, vim's approach is to use folding/unfolding, which works well with comments :)

LSP looks interesting. Maybe we do not need type annotations tightly integrated into the source code.
@shonfeder, you mentioned LSP in other contexts several times. What is your take on that?

Taking a step back, I wonder if it is really helpful to distinguish between user and type annotations. Won't users just care for what the type inference engine makes out of user-provided annotations?  In other words, why not only ever show output annotations regardless from where the type inference engine sourced its information. Taking another step back, I would probably prefer to read the result of type inference as TLA+ expressions instead of a new syntax.
What LSP list are you referring to (note that there exists no LSP yet)?  LSP is not a proposal on its own, but just a suggestion on how to implement any proposal in a way that is sufficiently IDE agnostic to allow for making IDE features part of a proposal.

What LSP list are you referring to (note that there exists no LSP for TLA+ yet)?

That is what I meant. TLA+ is not on that list ;-)

<a, seq(a)> => Bool

This is an operator type. It takes two arguments (a type variable a and a sequence of a elements) and returns a Boolean.

It looked at implementing an LSP for TLA+ last summer and there are many use cases for when an LSP would be useful.  Perhaps, types are the tipping point to finally implement an LSP.

Taking another step back, I would probably prefer to read the result of type inference as TLA+ expressions instead of a new syntax

I understand that wish, but there are two problems: (1) typically type grammars are more concise than the types-as-sets syntax, (2) it is not clear how to nicely express some types, e.g., the type of a function from Int to Int, or an operator over an Int and a high-level operator returning a Boolean.

<a, seq(a)> => Bool

This is an operator type. It takes two arguments (a type variable a and a sequence of a elements) and returns a Boolean.

What I meant is that its new syntax that increases the mental burden, which, perhaps, is fine if I only have to read it rarely but probably an obstacle if I have to type it (especially infrequently).

Sure, but if we put lots of constraints on how to write types in TLA+ syntax, it is also... syntax. Using TLA+ does not automatically mean that you have to learn nothing.

Here is my proposal wrt. type annotations. I think it would be nice when the type annotation are not simply strings, but TLA+ constructs: that way a huge number of errors will be caught already by the TLA+ syntax checker. Besides, this avoids the problem of a separate syntax inside syntax. The proposed syntax builds on the currently used by Apalache syntax for type annotations with <: operator, which I personally find quite appealing. I have the feeling that with such approach we can even arrive at a solution when type errors could be caught by a model checker / theorem prover -- please correct me if I am wrong. But in any case, these annotations should provide a nice input for the type inference engine -- it will not need to parse them separately from comments, they will just arrive as the integral part of the input file.
---------------------------- MODULE types --------------------------

EXTENDS Sequences, Integers

(* We specify types inside of TLA+, and with the means provided by TLA+.
   For that a user can provide type declarations of the form
   decl_t, with the meaning is that decl_t returns the type of decl.

   The type declarations can be parameterized by other types.
*)

(* This is the syntax for type annotations *)

(* The |= operator returns the type of expression expr;
   to be used to define types in type declarations
 *)
type |= expr  == type

(* The =| operator specifies the type of expr inline;
   To be used inside other constructs as conjuncts.
*)
expr =| type == TRUE

CONSTANTS Range

VARIABLES list

Mem(e, es) ==
  \E i, j \in DOMAIN es:
    i =| Int /\ j =| Int /\
    e = es[i]

Init ==
  list = <<>>

Next ==
  \E e \in Range:
    list' = Append(list, e)

(* Everything above is just standard TLA+,
   with the exception of two type annotations for i and j.
   Everything below are type declarations.
   When needed for understanding,
   the standard TLA+ of a spec can be intermixed with the type declarations.
*)

list_t(Z) ==
  Seq(Z) |= list

Mem_t(Z) ==
  \A e \in Z :
  \A es \in list_t(Z) :
  [ Z \X list_t(Z) -> BOOLEAN] |= Mem(e, es)

Init_t == BOOLEAN |= Init

Append_t(Z) ==
  \A e \in Z :
  \A es \in list_t(Z) :
  [ list_t(Z) \X Z -> list_t(Z) ] |= Append(es, e)

Next_t == BOOLEAN |= Next

=============================================================================

@shonfeder, you mentioned LSP in other contexts several times. What is your take on that?

I'm very much pro LSP. I have had a great experience IDE experience (in emacs) with languages that implement the LSP, and LSP seems like its pretty clearly the way forward for editor agnostic (and maybe even application agnostic?) intelligence on analyzing PLs. Also, seems like LSP may neutralize the "but vim isn't an IDE" problem? ;) https://www.kieranbamforth.me/post/vim-lsp

Since I was tagged in here, I'll exploit the opening to pitch in my own two cents, from the perspective a currently onboarding developer/user (please counter balance those cents with sufficient grains of salt to account for my newness):
The proposed combination of the _type suffix to indicate ascriptions and types in strings has the feeling of two orthogonal hacks colliding. On a purely aesthetic level, it's pretty off putting to me.
@andrey-kuprianov's suggestions is the most appealing to me for the inline proposals so far. I'd even propose providing a Typing module (akin to the typing module supplied by python for its gradual typing) that include those operator definitions and perhaps some convenient types aliases and definitions. (I'm not sold on those particular operators, but think it's much nicer than
Following @lemmy's good points re: offloading the work to editor integrations, I actually think just using a separate file as the default place for type ascriptions could be quite nice. But I also think interface files can be a nice feature. :)
In my experience, even a simple, non-polymorphic type system can be a very nice aid to thought and development, so I would think its well worth while to invest thought an implementation time into syntax, support, and tooling that will help users feel good about reading and writing the type ascriptions.

Following @lemmy's good points re: offloading the work to editor integrations, I actually think just using a separate file as the default place for type ascriptions could be quite nice. But I also think interface files can be a nice feature. :)

FWIW: It doesn't have to be a separate file but could simply follow the TLA+ module in the same .tla file (I e.g. recently introduced a CONFIG construct into TLC):
---- MODULE Spec ----
...
=====

---- TYPES Spec ----
....
======

@lemmy , re:

FWIW: It doesn't have to be a separate file but could simply follow the TLA+ module in the same .tla file (I e.g. recently introduced a CONFIG construct into TLC)

The solution I proposed was under the assumtion that we can't change the language itself; if we can -- that's a completely different story. E.g., in that case I woud introduce smth like typeof construct, i.e. an operator which you could define multiple times for different declarations: typeof(Mem) == ..., typeof(list) == .... And a separate construct for type annotations inline, like a colon: \E i: Int, j: Int \in DOMAIN es... But, as far as I understand, it's not possible, unfortunately, or am I wrong?

This thread is getting more and more detailed. So I have created a PR: https://github.com/informalsystems/apalache/pull/179
Fell free to comment here and there

In sum, the TypeOK approach does not seem to work for higher-order operators, as operators are not values (surprise!). The term-based approach seems to work, though I am not completely happy about it.

Leslie's comment that "These type theorems would also be useful in writing proofs." paired with his statement that he is more open to amending the proof language, might be another direction that's worth exploring.

Right. Actually, types become theorems, once a type inference engine has found them. If we are talking about user annotations, they are more like ASSUME statements, which does not change much, as the syntax may be the same. I will extend the ADR draft. The real stumbling point in the pure TLA+ syntax seems to be the higher-order operators.

The solution I proposed was under the assumtion that we can't change the language itself; if we can -- that's a completely different story. E.g., in that case I woud introduce smth like typeof construct, i.e. an operator which you could define multiple times for different declarations: typeof(Mem) == ..., typeof(list) == .... And a separate construct for type annotations inline, like a colon: \E i: Int, j: Int \in DOMAIN es... But, as far as I understand, it's not possible, unfortunately, or am I wrong?

@andrey-kuprianov To clarify, I wasn't suggesting to change the language.  I just wanted to hint at the technical fact that SANY poses no restrictions on what precedes or follows the module definition in a .tla file.

I have just added the section on types-as-strings, so there are three solutions to encoding types (TypeOK having a problem with higher-order operators).

I have added the section on four approaches to type annotations, extracted from our discussions.  RFC :-)

Having 3 options of writing types and 4 options of writing type annotations, this gives us 12 options.

I just realized that our type semantics is not always precisely set membership. The reason is, of course, records!
For instance, if we write:
S == {[type |-> "A", a |-> "Foo"], [type |-> "B", b |-> 123]}

Then the expected type of S is a set of records that can be extended to the records that belong to the set [type: STRING, a: STRING, b: STRING]. So the following statement would be simply incorrect:
S \in SUBSET [type: STRING, a: STRING, b: STRING]

This strange behavior of record types is caused by the need to store records of compatible types in sets. An alternative approach would be to introduce sum types. Then, the type of S would be precise, that is:
S \in (SUBSET [type: STRING, a: STRING]) \union (SUBSET [type: STRING, b: Int])

However, this poses another problem. What would be the type of x in the following expression?
\E x \in S:
   ...

We do not have a good answer to that, as TLA+ does not have type deconstructors, similar to, e.g., match in Scala.
So I am now even more in favor of using a special operator <:and types-as-strings instead of set membership and types-as-sets:
S <: "set([type: Str, a: Str, b: Str])"

This notation would tell the reader to understand S as a type that can be extended to a set of records SUBSET [type: STRING, a: STRING, b: STRING] (by using the subtype relation). That might sound a bit too complicated, but the records in TLA+ are complicated.

For the operators, we could also use the inverse notation, as suggested by @shonfeder, e.g.:
A(x, y) == "(Int, Int) => Int" :>
  x + y

This is actually quite similar to Isabelle/HOL. We just use :> instead of where. (We could even think of writing inductive definitions by using CASE.)

Good catch re: typing records! fwiw, string expressions inside a special operator feel pretty good to me.

A(x, y) == "(Int, Int) => Int" :>
  x + y

As a potential user writing type annotations I kind of like that approach -- it looks pretty neat :)

I just realized that SANY rejects assumptions over state variables, so we cannot write e.g. ASSUME(x <: "Str") for a VARIABLE x. This kills yet another neat solution :(

It looks like type annotations in comments are the most stable solution after all. That is, points 1.3 and 2.3 in ADR1 #179. Alternatively, we can use my hack, that is, a combination of 1.3 and 2.4, but I agree that it more of a hack.

Oh well... at least that helps make the decision easier!

It's not easy to extract annotations from the comments unless we really integrate with the SANY lexer. So we might still consider the combination of <:, :> and a type axiom, similar to TypeOK:
TypeAxiom ==
  /\ RM <: "Set(RM)"
  /\ rmState <: "RM -> Str"
  /\ tmState <: "Str"
  /\ tmPrepared <: "Set(RM)"
  /\ msgs <: "Set([type: Str, rm: RM])"

In this example, RM is a global type variable, which can be instantiated with any type. I think this solution is conceptually much simpler than writing an annotation preprocessor.

TypeAxiom looks similar to what an earlier prototype of a symbolic variant of TLC ("BTLC") intended to use: https://github.com/tlaplus/tlaplus/blob/ab14a33e39c78e4c88e81b664b9a8c916b943cab/tlatools/org.lamport.tlatools/src/tlc2/tool/impl/ModelConfig.java#L63-L64

I was actually quite surprised that one can only write ASSUME over constants. This is in contrast with the assume/assert in model checkers.

TLC!Assert

Right. Normally, one would restrict values with assume and check them with assert, e.g., Boogie has it. TLC has assert, but TLA+'s ASSUME is quite restricted.

I have renamed the previous document to 001rfc-types.md, as it contains all available options.
The actual ADR docs/adr/002adr-types.md contains a concrete proposal on the type grammar and type annotations. See PR #179.
I already love these type annotations, even without having any type checker for them :-)

Leslie Lamport proposes to use the proofs syntax for the higher-order operators as well:
THEOREM BarType ==
  ASSUME NEW G(_,_),
         \A x \in Int, y \in STRING : G(x,y) \in Int
         PROVE  Bar(G) \in BOOLEAN

Similar to that, we can write a theorem about the type of Foo:
THEOREM FooType ==
  \A a \in Int: \A b \in STRING: Foo(a, b) \in Int

This looks like a great way of integrating the output of type inference into a TLA+ specification. Theorems like that could be used for the manual proofs with TLAPS.

If we like to write types interactively, that is, in the process of spec writing, ADR-002 gives us a concise way to do that.

Here is a solution to type annotations suggested by Leslie Lamport. The method SemanticNode.getPreComments in SANY returns the comments that are immediately preceding an AST node. Since SANY keeps the comments, we can extract a type annotation from the comments.
This is an interesting approach and it probably increases usability in comparison to what we have in ADR-002. For instance, the user could write:
---- MODULE TypedExample ----
VARIABLE
  \* type: Set(Int)
  S

\* type: (Int) => Bool
Mem(e) == \E x \in S: x = e

\* type: () => Bool
Init ==
  S = {}
...

The syntax in the comments is quite minimalistic and still easy to parse. Interestingly, SANY is keeping comments as an array, so it should be quite easy to extract the above annotations from the comments.

The ADR has not changed much since the discussion. I find it amazing that the type checker is working exactly as we discussed in this issue. There are two-level of annotations: (1) AssumeType and :> (soon to be pushed), and (2) in-comment annotations (to be implemented). The annotations of the first kind are needed for the internal tooling, whereas the annotations of the second kind are needed for better UX.

Just found that :> is also defined by the TLC module. We need a different operator in Typing.tla, before we move to in-comment annotations.

As a temporary solution, I will change :> to ## in the type checker.

The ADR has not been changing for several months. Closing the issue.


ADM-443[Report] [backend] Deployment frequency calculation in Pipeline

Summary

Fetch BuildKite original data
Deployment frequency calculation

After

docs and sequence diagrams
refactor code

docs and sequence diagrams
refactor code

Done.


hugo_stats.json: bad tag if html element is written on several lines

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.82.0+extended darwin/amd64 BuildDate=unknown

Does this issue reproduce with the latest release?
Yes
Description
Steps to reproduce

One markdown file needs to contain an HTML element (e.g. form) declared on several lines, as this example:

<form
  action="[URL]"
  method="post"
>
## Random markdown content
Foo bar

Run hugo server -e production

Expected:
Tag "form" should be added within the list of tags within hugo_stats.jsonfile.
Actual:
Tag "form\n\taction=\"[URL]\"\n\tmethod=\"post\"" is added within the list of tags in hugo_stats.json file.
Note:
The issue does not happen if the form is declared in one line :
<form action="[URL]" method="POST">

Similar issue already raised here: #7958
Maybe also related to #8396

I am unable to reproduce the problem.
git clone --single-branch -b hugo-github-issue-8417 https://github.com/jmooring/hugo-testing hugo-github-issue-8417
cd hugo-github-issue-8417
hugo server

Also, according to the CommonMark specification, an HTML block must be followed by a blank line. That is why the page renders incorrectly. You can try it here.

Thanks @jmooring for your advice regarding the blank line.
I've managed to reproduce the issue with tabs instead of spaces for indentation.
Note: I'm not sure if it's a good practice or not 🤔
I personally prefer tab vs spaces for indentation, in general, that's why I've set up prettier to format my files that way.. but there might by something wrong here?

Thank you. I've update the minimal reproducible example, and the title of this issue. The simplest failing example is:
<hr[TAB]id=a>

The CommonMark specification provides many examples of using tabs for indentation, so your preference is technically sound.


[PBC Resources Estimates 4/4] Add costing functions

Final part of #821. Builds on previous 3 PRs to add costing estimates for the various factorizations. Also adds documentation and a notebook.

@mpharrigan PTAL

Thanks for slogging through this @mpharrigan!


ModuleNotFoundError: No module named 'qlib.constant

🐛 Bug Description
When running python scripts/data_collector/yahoo/collector.py download_data --source_dir ~/.qlib/stock_data/source/cn_1min --region CN --start 2021-05-20 --end 2021-05-23 --delay 0.1 --interval 1min --limit_nums 10 it returns the following bug
ModuleNotFoundError: No module named 'qlib.constant'

To Reproduce
Steps to reproduce the behavior:

Download qlib repo
Run the command python scripts/data_collector/yahoo/collector.py download_data --source_dir ~/.qlib/stock_data/source/cn_1min --region CN --start 2021-05-20 --end 2021-05-23 --delay 0.1 --interval 1min --limit_nums 10

Expected Behavior

It should return the following bug ModuleNotFoundError: No module named 'qlib.constant'
Screenshot

Environment
Note: User could run cd scripts && python collect_info.py all under project directory to get system information
and paste them here directly.
Darwin
x86_64
macOS-10.16-x86_64-i386-64bit
Darwin Kernel Version 21.2.0: Sun Nov 28 20:29:10 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T8101
Python version: 3.8.12 (default, Oct 12 2021, 06:23:56)  [Clang 10.0.0 ]
Qlib version: 0.8.0
numpy==1.22.0
pandas==1.3.5
scipy==1.7.3
requests==2.27.1
sacred==0.8.2
python-socketio==5.5.1
redis==4.1.0
python-redis-lock==3.7.0
schedule==1.1.0
cvxpy==1.1.18
hyperopt==0.1.1
fire==0.4.0
statsmodels==0.13.1
xlrd==2.0.1
plotly==5.5.0
matplotlib==3.5.1
tables==3.7.0
pyyaml==6.0
mlflow==1.22.0
tqdm==4.62.3
loguru==0.5.3
lightgbm==3.3.2
tornado==6.1
joblib==1.1.0
fire==0.4.0
ruamel.yaml==0.17.20
Additional Notes
I have solved this problem by importing from qlib.config import REG_CN as REGION_CN instead of from qlib.constant import REG_CN as REGION_CN

@igor17400 Hi,
Try using the latest code: git pull

@zhupr Hi!
I have executed git pull and it returned Already up to date..
However, the problem when running python scripts/data_collector/yahoo/collector.py download_data --source_dir ~/.qlib/stock_data/source/cn_1min --region CN --start 2021-05-20 --end 2021-05-23 --delay 0.1 --interval 1min --limit_nums 10 continues returning ModuleNotFoundError: No module named 'qlib.constant'

@igor17400
It's here https://github.com/microsoft/qlib/blob/main/qlib/constant.py
Please make sure you have removed the previous version and installed the latest one.
You can try to re-install it in a clean environment.

Silly mistake here, sorry ;-;
For all those that may encounter the same problem. If you are running your code inside Jupyter Notebook and you have made modifications in QLIB project I believe you need to follow those two steps in order to overcome this problem:

Run pip . inside qlib folder
Restart Jupyter  session

Thanks for the help @you-n-g!


Service compilation error

What would you like to share?
1、使用的go版本和系统

2、执行编译命令
[root@localhost scripts]# ./build_all_service.sh
================> Architecture: x86_64
================> BIN_DIR: /home/chat/scripts/..//home/chat/scripts/../_output/bin/platforms/linux/amd64
=======>SCRIPTS_ROOT=/home/chat/scripts
=======>OPENIM_ROOT=/home/chat/scripts/..
=======>pwd=/home/chat/scripts
===============> Building all using make build binary files

==> bin_dir=/home/chat/scripts/../_output/bin/platforms/linux/amd64
==> logs_dir=/home/chat/scripts/../logs
======> cpu_count=64
=====> COMMAND=rpc
=====> PLATFORM=linux_amd64
=====> BIN_DIR=/home/chat/_output/bin
=====> COMMAND=api
===========> Building binary rpc v1.2.2.dirty	 for linux_amd64
=====> PLATFORM=linux_amd64
=====> BIN_DIR=/home/chat/_output/bin
===========> Building binary api v1.2.2.dirty	 for linux_amd64
syscall
/usr/local/go/src/syscall/syscall_linux_accept4.go:12:6: Accept redeclared in this block
/usr/local/go/src/syscall/syscall_linux.go:549:6: other declaration of Accept
syscall
/usr/local/go/src/syscall/syscall_linux_accept4.go:12:6: Accept redeclared in this block
/usr/local/go/src/syscall/syscall_linux.go:549:6: other declaration of Accept
syscall
/usr/local/go/src/syscall/syscall_linux_accept4.go:12:6: Accept redeclared in this block
/usr/local/go/src/syscall/syscall_linux.go:549:6: other declaration of Accept
make: *** [go.build.linux_amd64.api] 错误 2
make: *** 正在等待未完成的任务....
syscall
/usr/local/go/src/syscall/syscall_linux_accept4.go:12:6: Accept redeclared in this block
/usr/local/go/src/syscall/syscall_linux.go:549:6: other declaration of Accept
make: *** [go.build.linux_amd64.rpc] 错误 2
Additional information
No response

/usr/local/go/src/syscall/syscall_linux.go:549


No key items to progress. Just locked doors

Version
2.2.1 (bd54d6c)
Seed
R620-GT8R-ZHQEAL825J7H27FV6CZZZZZZZZZZ4HZ
Scenario
RE 2 (Claire A)
What happened?
Got stuck 4 rooms in. First two rooms are standard, leaving Kendo's shop through the back brings you to the 3rd story RPD crank and gear room. Leaving though the same door back into Kendo's shop and leaving through the front door brings you into the RPD interrogation hall. All three doors in that hallway were locked and the only herb in that hallway did not yield a key item to progress any further.

Your seed was configured for Leon A / Claire B.


No Button to Create New Event

Description
There is currently no way for a user to create a new event (e.g. there is no "create new event" button on the Event page that would operate similarly to the "new post" button on the Blog page).
Screenshots
Note lack of "new event" button anywhere on page.

Files
A list of relevant files for this issue. This will help people navigate the project and offer some clues of where to start.
To Reproduce
Go to Home > Events. Try to create new event.
Tasks
Include specific tasks in the order they need to be done in. Include links to specific lines of code where the task should happen at.

[ ] Task 1
[ ] Task 2
[ ] Task 3

Remember to use helpful labels and milestones. If you use the "help wanted" label, Code for America will promote it widely.

The new event function should be on events/manage since we want only people with certain credentials to create events.

There is an event button on the calendar page now. So I'm closing this issue.


feat(@vtmn/svelte, @vtmn/react, vtmn/vue): use VtmnAlert as a component

Changes description

Svelte part :

Export the VtmnAlertItem component in order to be used without the VtmnAlert.
Title / description can be set with a slot
Change the <p> to <span> in order to be ISO with other frameworks

Svelte / React / Vue :

Add a new property ariaLabelCloseButton
Remove the id no really necessary
Set the timeout property to 0 in order to keep the alert visible

Also checked https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/examples/alertdialog/
The div with a role alert doesn't need to have a aria-labelledby /describeby

Context

Checklist

[x] Make sure you are requesting to pull a topic/feature/bugfix branch. Please, don't request directly from your main!
[x] Check commits & PR names matches our requested structure. It must follow the https://www.conventionalcommits.org pattern.
[x] Check your code additions will fail neither code linting checks.
[x] I have reviewed the submitted code.
[x] I have tested on related showcases.
[x] If it includes design changes, please ask for a review design-system-core-team-design GitHub team.

Does this introduce a breaking change?

Yes
[x] No (checked on the DKT project, the id is not used)

Other information

Hi @Tlahey, thanks for this PR.
Regarding potential breaking changes, did you check elsewhere than the DKT project but in all repositories of our private GitHub organization?
Thank you 🙏

hi! thanks for this PR @Tlahey and for pinging me @lauthieb . Everything is ok for me here, the use of the slot is nice and allows the component to be more flexible, without bringing any breaking change. The only mini breaking change is that the aria-label of the close button is no longer set to "Close toast" by default, which you can quickly change if you want @Tlahey.
Okay fo me otherwise.

Hello @thibault-mahe I've done the fix on the aria-label ;)


Fix jenv crashing silently

This fixes two issues:

On error, the script was closing the entire terminal so we couldn't even see the error output.
The logic was incorrect, causing the script to close if pwsh.exe didn't exist but powershell.exe did.

Thanks this looks great


Add PPM approve handler for office use [delivers #157646717]

Description
This PR adds an endpoint for setting a PPM's status to APPROVED.
Code Review Verification Steps

[x] All tests pass.
[ ] Code follows the guidelines for Logging
[ ] The requirements listed in
Querying the Database Safely
have been satisfied.
[x] Request review from a member of a different team.
[ ] Have the Pivotal acceptance criteria been met for this change?

References

Pivotal story for this change

@kilbergr Good catch! Want to take another look?


TypeError: Cannot read property '_acceptIsDirty' of undefined

Seeing this in latest, making the PH go crazy:

@jrieken I pushed a workaround, but thats likely not the right fix: https://github.com/Microsoft/vscode/commit/2de359c7d3c3635d565b54e62affbc03f6aedc0e

@jrieken also the integration tests are failing, this might be related: https://travis-ci.org/Microsoft/vscode/jobs/94578250

I will investigate. @bpasero when did this happen? plain modes like JS and TS or mixed modes, like HTML+JS+CSS etc

@jrieken yes in TS selfhost.

Yeah, found it and triggered builds