Update link to show advanced protection plan not the MDC intro

This link does not bring me to the enhanced features of Defender for Cloud
(see the highlighted section below)
Maybe use this link (even though the header says gov and national, it also includes commercial)
https://docs.microsoft.com/en-us/azure/defender-for-cloud/supported-machines-endpoint-solutions-clouds-servers?tabs=features-windows#feature-support-in-government-and-national-clouds
Why is Defender for Cloud alerting me to vulnerabilities about an image that isn’t in my registry?
Some images may reuse tags from an image that was already scanned. For example, you may reassign the tag “Latest” every time you add an image to a digest. In such cases, the ‘old’ image does still exist in the registry and may still be pulled by its digest. If the image has security findings and is pulled, it'll expose security vulnerabilities.
Next steps
Learn more about the advanced protection plans of Microsoft Defender for Cloud.**

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 29434ef1-ac47-9226-c97a-b3ebd76438b1
Version Independent ID: d7ca7e00-09b4-819d-2e8b-f7699024a0e4
Content: How to use Defender for Containers to identify vulnerabilities in Microsoft Defender for Cloud
Content Source: articles/defender-for-cloud/defender-for-containers-usage.md
Service: defender-for-cloud
GitHub Login: @bmansheim
Microsoft Alias: benmansheim

@lmhutch  Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

I'll update that link to a better target. Thanks!
#please-close


Added documentation for subctl unexport

Added documentation for the command itself and a small section in the
user guide.
Signed-off-by: Mike Kolesnik<EMAIL_ADDRESS>

While we’re at it, please follow the guidelines for commit messages and use the imperative rather than past tense (“Add documentation ...”).


Menu window outside screen

Describe the bug
The Alt + P menu is completely offscreen (left side), I can't use anything there which sadly makes this mod useless for me. My resolution is 2560x1440
To Reproduce
Steps to reproduce the behavior (if known):
Possibly higher resolution monitors?
Expected behavior
I expected the menu to still be visible.
Media
N/A
Additional context
N/A

Might be related to #1


Audit Cookbook Support Matrix

Required versions of all components involved in a data collection can be found in the audit cookbook readme.md
Signed-off-by: Steven Danna<EMAIL_ADDRESS>

rebasing on master and force-pushing so we can get this merged in


Errors in .NET 5.0 Example

Describe the bug
The example (Program and Startup) at https://github.com/chkr1011/MQTTnet/wiki/Server#net-50 won't compile (unknown classes and interfaces).
Which project is your bug related to?

Server

To Reproduce
Steps to reproduce the behavior:

Create a new .net 5 console project
Replace contents of Program.cs with code in example Program class
Create new Startup class using code in example Startup class
Add missing nuget packages

Expected behavior
No code errors
Screenshots

Maybe the heading was misleading here, I have changed it: https://github.com/chkr1011/MQTTnet/wiki/Server#aspnet-50.
The example only works in a ASP.Net project, not in a console application as you're missing the ASP.Net specific stuff like the host or routing for controllers, etc.


How to correctly offset elements?

I need to achieve a layout like this: https://github.com/arnauddorgans/InfiniteLayout (watch Custom Layout, 3rd gif)
link:

I guess you would have to make your own LL or try to tweak this one. But I'm not sure that would be an easy work @moffpage


Memory Leak

I started using log4js-node-mongodb, to move logs to my mongodb.
Later I started noticing, the increase in the memory consumption, whenever I switch to log4js-node-mongo appender, this is not the same when I use the console appender.
Any help is appreciated.

We will check this.

For Example:
I'm trying to hit an end-point, that does nothing but log a single statement - hitting that endpoint with around 200 req/s, the memory consumption shoots up like crazy, while logging onto mongo, but not with console.

I can reproduce it. Will check if it's a problem with the code of our module or the mongdb driver module.

:+1: Thanks!

I have done some tests which writes a lot of log entries in the mongo db. The memory usage grows until a certain amount an then the v8 Garbage Collector kicks in. So there is no leak i can found. But at which point the Garbage Collector starts to freeing up memory differs in each node.js version. And in general if there is enough memory in your system then the garbage collection might not even run.
You can find more informations about the garbage collection in node.js here:
https://github.com/nodejs/node/issues/2738
https://github.com/nodejs/node/issues/3370#issuecomment-148108323

Can you tell me, to how much did it grow until the GC kicks in?
Also I wanted to know why is there so much growth in memory while writing to db? Any idea?

On my machine with 8 GB RAM the memory growths up to 1 GB for the node app. Then it was cleaned during the following operations and at the end the memory usage dropped to ~150 MB.
In MongoDB the data is first written to the memory and later to the disk. So if you have a large amount of write operations then the memory increases fast and is freed up later when the data was saved to the disk.


Profile inputs accepting empty values

Describe the bug
On the profile page, we can add/update our bio and social handles. When we are adding or updating the values, the existing code is accepting empty values too, and no validation check is made before submitting an empty value. This is also leading to an unnecessary network call, which is an expensive task.
To Reproduce
Steps to reproduce the behavior:

Login to user-story
Navigate to your profile(Route: '/myProfile')
Click on the pencil icon for any input field (E.g: LinkedIn username, Twitter handle, etc).
This opens up a text field and a save icon beside it.
Keep the input field empty(clear if any prior input was fed).
Click on the save icon, we can notice that there's no validation check made on empty strings.

Expected behavior
A clear and concise description of what you expected to happen.
Ideally, the users should not be allowed to submit an empty string. If the user wants to remove any of the links or values of their profiles, a separate remove function could be added, but accepting an empty string is not a good idea.
Logs
If applicable, add logs to help explain your problem (e.g. the error message and/or exception traceback).
Environment (please complete the following information):

OS: Windows 11
Browser: Chrome

Additional context
Add any other context about the problem here.

@cyntss @mharshita @SundeepChand, I'd like to work on this and get it fixed.


feat: add flag for using generator v2

Description
In this PR I am adding a new Flag to use generator v2+, I am trying to change as little as possible from users original version of CLI. Currently most temapltes are not supporting v2 of generator, so it is better to have flag --use-new-generator, once more templates start supporting v2 of generator we can update the flag.
asyncapi generate fromTemaplate ./spec.yaml @asyncapi/html-template --use-new-generator

Related issue(s)

See also #1388

@Souvikns Please merge if ready.

/bounty

@asyncapi/bounty_team

/rtm


[mgmt] devopsinfrastructure release

https://github.com/Azure/sdk-release-request/issues/5621

API change check
APIView has identified API level changes in this PR and created following API reviews.
@azure/arm-devopsinfrastructure


System tests changes

These changes are for the build_system_test.sh script. There seems to be some issue with SRV files generated but the anonymous type issues are gone with this PR and associated PR in rosidl_typesupport_opendds.

There are still some issues with the azure pipeline setup, but for the purposes of this PR, it's good.


QBasic/QuickBasic support

Hello,
In some of my projects which use QBasic, the .bas files are detected as Visual Basic. So I edited the .gitattributes file and added the followinng line:
*.bas linguist-language=QBasic
This does not seem to work at all. I also tried "qbasic" (lower case), "Basic", "basic", etc. nothing seems to work so far.
Is there any way to show QBasic as the language used in GitHub (which uses Linguist)?
Thank you in advance.

Linguist doesn't have support for QBasic yet. Please see the guidelines to add support for a new language to Linguist. If QBasic meets the requirement on in-the-wild usage, don't hesitate to open a pull request.

@jaboles Looks like it now shows up as "FreeBASIC", which is an improvement, but it certainly be useful to differentiate it from QB64.  It should probably be generically reported as "Quick Basic" in either case, which would certainly meet the in-the-wild usage requirement.


docker/ci: Add workaround for missing skopeo

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

fixing bad merge ...

fixing ci


wasm: enable WAVM's stack unwinding feature

This PR enables WAVM's stack unwind feature, which enhance WASM extension developers debuggability dramatically.
Without WAVM_ENABLE_UNWIND=on, the returned call stack is always empty as you can see here.
The corresponding PR in proxy-wasm-cpp-host is here: https://github.com/proxy-wasm/proxy-wasm-cpp-host/pull/84
The stack trace message is something like this:
[2020-10-28 14:24:10.551][979699][trace][wasm] [source/extensions/common/wasm/wasm_vm.cc:29] Function proxy_on_tick failed:
WAVM message: wavm.reachedUnreachable
wasm backrace:
  1: wasm!helloworld!runtime._panic+7
  2: wasm!helloworld!command-line-arguments.C+2
  3: wasm!helloworld!command-line-arguments.B+0
  4: wasm!helloworld!command-line-arguments.A+0
  5: wasm!helloworld!(*command-line-arguments.helloWorld).OnTick+74
  6: wasm!helloworld!proxy_on_tick+0

Signed-off-by: mathetake<EMAIL_ADDRESS>
cc @lizan @PiotrSikora

@mathetake in the future, you might want to include proxy-wasm-cpp-host update in bazel/repository_locations.bzl that points to your fork while the proxy-wasm-cpp-host PR is still under review. This way, the CI tests the complete change, instead of only the Envoy part, and it signals that this PR is still blocked on the proxy-wasm-cpp-host PR.
In this particular case, the merged PR is a bit useless by itself.


Drop timeseries:postCommit dependency

See https://github.com/apache/beam/pull/15786#issuecomment-1190377753
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run Java PostCommit

R: @reuvenlax

LGTM


Update dependencies to latest

file:         2.3.4   -> 2.3.5
linter:       0.1.38  -> 0.1.39
mockito:      2.2.0   -> 2.2.1
mustache:     0.2.5+1 -> 1.0.0
path:         1.4.2   -> 1.5.1
quiver:       0.26.0  -> 0.26.2
stack_trace:  1.9.0   -> 1.9.1
test:         0.12.26 -> 0.12.28
url_launcher: 0.4.2+5 -> 1.0.1
Adds transitive dependencies of package:image (used in
dev/integration/ui), which appear to have been missed in commit
91bd9bc4f8ced1a1e84e0f8162ce66ea6cf8ae8a:
archive:      1.0.32
browser:      0.10.0+2
petitparser:  1.6.1
xml:          2.6.0

Not submitting. Looks like this is crashing due to an NPE in the analyzer when run over lib/src/backend/invoker.dart in package:test v0.12.28.

Filed dart-lang/sdk#31442.


Update archive.py

Removed a / who made disk space on archive not functioning.
Corrected the rsync url so it do not look for  12000 folder and removed rsync://  to get it to work at the different locations I tested the code.

While this may help your case, it breaks other cases.  See https://github.com/ericaltendorf/plotman/pull/627 for a rework of the archival system that allows customization.  Maybe we can merge it in the next few days...  Hopefully...

If the new archival approach isn't flexible enough for your needs then let's discuss opportunities to improve it.  At this point this PR is not applicable since the code has been significantly reworked.  Thanks for your effort on the project and my apologies for my slowness in handling contributions.


This i becaue of not many seeds? Maybe is a way to identify those and not list them?

Today I'm seeing that i can't load any movie.
I can play only movies that i started to watch in the past. With new movies I get only to looking in the universe... but never to generating conection.
Anyone know why could this be?

One of the main apis has gone down

@santiagoworkana I have pushed a pull request with an updated api

Yeah with the pull request from @RadGade and the most recent update, this issue should be fixed. Feel free to reopen if this issue persists.


Offset method robustness for complex shapes

The offset method for shapes that "close" upon themselves (i.e. enlarged such that the resulting polygon structure has overlapping portions) results in  segmentation fault (SIGSEGV).
As a simple example -- letter C, drawn as a single polygon, and then enlarged using the offset method:
import gdspy
import numpy

cell = gdspy.Cell('CELL')
c_coords = numpy.array([  [ 0.6663    ,  0.32629112],
                          [ 0.6663    ,  0.1669    ],
                          [ 0.4994    ,  0.        ],
                          [ 0.1669    ,  0.        ],
                          [ 0.        ,  0.1669    ],
                          [ 0.        ,  0.8331    ],
                          [ 0.1669    ,  1.        ],
                          [ 0.4994    ,  1.        ],
                          [ 0.6663    ,  0.8331    ],
                          [ 0.6663    ,  0.67370888],
                          [ 0.4994    ,  0.67370888],
                          [ 0.4994    ,  0.76396776],
                          [ 0.43026776,  0.8331    ],
                          [ 0.23603224,  0.8331    ],
                          [ 0.1669    ,  0.76396776],
                          [ 0.1669    ,  0.23603224],
                          [ 0.23603224,  0.1669    ],
                          [ 0.43026776,  0.1669    ],
                          [ 0.4994    ,  0.23603224],
                          [ 0.4994    ,  0.32629112]])
poly = gdspy.Polygon(c_coords)
cell.add(poly)
offset_result = gdspy.offset(gdspy.CellReference(cell), distance=0.1)
offset_cell = gdspy.Cell('CELL_OFFSET')
offset_cell.add(offset_result)

gdspy.LayoutViewer(cells=[offset_cell])

For distance=0.1 (as above), the offset method returns the expected result. The moment the C-shape "closes" upon itself (distance >= 0.18), the call returns SIGSEGV.
Could you please suggest what can be done to avoid this? One workaround would be to break the shape into multiple polygons, but it is not a generic solution. Thank you.

Furthermore to @okianus comment above (and related to issue #1), gdspy offset algorithm does not have an expected behavior. For example, suppose we have two structures that are initially separated but, for a sufficiently large offset number, would merge into a single structure. That is not what is happening, as the gdspy offset method treats each structure separately and enlarges them individually, but only if they are simple, preferably convex hull shapes. Knowing this, one of the solutions to @okianus problem is to fragment complex shapes into a set of simpler shapes and subsequently using 'OR' to unite the shapes. This is not a generic solution though. Because of this gdspy offset algorithm limitations, we are forced to deploy external algorithms for our production layouts that handle arbitrary shapes and unite them into a smaller set of resulting shapes. One note here is that we use offsets not only to make small adjustments to the shape but also to produce large exclusion zones for further boolean operations. It often happens that the amount of offset exceeds the size of the feature, which is exactly when gdspy offset algorithm fails, as demonstrated in @okianus  example.

@okianus : This problem is definitely a bug in the clipping code. To be honest, it might be a while before I can fix it, because those are usually difficult to find. I have to check...
@rosivda : The issue you're describing comes from the fact that the offset function was initially thought of a function operating in individual polygons. Indeed the idea for whole sets of polygons was to merge them afterwards using a boolean OR, as you mention. I cannot see a different approach to simplify this process, but if you have any ideas they'll be very welcome! Otherwise, once the problem above has been fixed, this solution should at least work.

@heitzmann : I am afraid that the problem that we are facing is considerably more complex. The fundamental flaw of the present offset() implementation is that it assumes that:
OFFSET( polygon1 OR polygon2) == OFFSET(polygon1) OR OFFSET(polygon2).
This is incorrect for adjacent or overlapping shapes. I have created an example to illustrate this. Please try zero and non-zero offset. You will observe that, even though the shape on the right is the same thing as the two shapes on the left, the outcome of the offset() algorithm leads to different results. This creates a failure opportunity for any shape that consists of numerous polygons.
import gdspy
import numpy

cell = gdspy.Cell('CELL')

pl1 = numpy.array([[ -1.,  0.], [0., 1.],  [0., 0.]])
pl2 = numpy.array([[ 0., 0.], [ 0., 1.], [ 1., 0.]])
pl3 = numpy.array([[ 2., 0.], [ 3., 1.], [4., 0.]])

cell.add(gdspy.Polygon(pl1))
cell.add(gdspy.Polygon(pl2))
cell.add(gdspy.Polygon(pl3))

offset_result = gdspy.offset(gdspy.CellReference(cell), distance=0.2)
offset_cell = gdspy.Cell('CELL_OFFSET')
offset_cell.add(offset_result)

gdspy.LayoutViewer(cells=[offset_cell])

@heitzmann : I would like to share a bit more general insight about gdspy - from the industrial perspective. gdspy has now been used by our R&D team to create large-scale production layouts, start-to-end. We have adopted 'natively' gdspy object structure and architecture with its approach that uses a dictionary with unique naming convention and cell referencing. gdspy has proven to be robust and scalable to large projects. It also yielded nearly theoretically-optimal gdsii layout files. gdspy has allowed us to bring all of our design tools into a single IDE.
Besides @okianus fixes, there are two areas that continue limiting gdspy from wider adoption as a full-fledged and completely self-contained module:
(1) fundamental implementation issues of offset(), as described above
(2) lack of a more powerful viewer that is able to handle large layouts
While we use separate tools to visualize layout files, the lack of robust offset() algorithm has been, perhaps, the only issue that continues to disrupt our workflow.

I've changed how the offset computation is performed in commit bb43726ad64948a2038a03590d7b5d312f9452b7. The previous implementation was trying to be smart about the shapes but it lacked generality. The algorithm now should be general and more mathematically rigorous with the definition of offset.
The price for that is the computational cost, which has increased significantly due to the new rounded corners, whereas before they were single points.
Also note that similar to boolean, offset also has an eps parameter that can help in case of segfaults.
@rosivda's example now gives the same output in both cases for positive offsets (expansion). Negative offsets (shrinking) take into account internal boundaries, and that is by design. If you don't want internal boundaries showing up in the result, you have to merge all polygons beforehand. Merging the geometry is a good idea for expansion as well, since it reduces the size of the problem.
Please let me know if the new offset works and I'll make an official release.

Thank you for the quick response! Will try the new offset with my test cases as soon as possible.

I tried the modified version of offset on a typical layout. The layout contains some simple but realistic device structures. Prior to the latest commit, the offset operation (enlargement of a collection of structures by a relatively small amount) took approximately 0.5 seconds. After installing the latest commit bb43726, the operation takes an unrealistically long time (about 460 seconds with eps = 1e-9, while the default eps = 1e-13 results in a segmentation fault after about 7 minutes).

@heitzmann : Thanks for looking into this critical issue. Your proposed offset algorithm is based on a rounding corner approach. This may be able to cover some of the aspects of the design but is not generally suitable for our design flow. We rely on miter-style offset rather than rounding. I would not recommend putting this algo in a new release of gdspy. I have no illusions about the complexity of a generic offset algorithm but have encountered successful implementations from vendors that are able to handle all of our cases, even the most complex ones. The link below highlights the complexity of the algorithm but I would not know the exact algorithms that our external packages are based on:
http://doc.cgal.org/Manual/3.2/doc_html/cgal_manual/Straight_skeleton_2/Chapter_main.html

Yes, I thought the new algorithm might end up being too slow for any practical use. The better solution seems to be using an external algorithm dedicated to polygon clipping and offset. I'm currently considering clipper, but I'm open to suggestions as long as they are compatible with the gdspy's GPL licence.

I have looked at the examples of the clipper algorithm - they look quite general with no obvious limitations. However, no one in our group has tried it in practice. Should you decide to proceed with its implementation, we would be glad to test our libraries with your new algorithm and provide you with feedback. Please note that our individual chips (not a wafer) typically contain tens of thousands polygons, and some of them hundreds of thousands polygons. This would provide a hard test for the robustness of the algorithm.

Sounds good! I'll let you know when I have something to test.

@rosivda, @okianus: The clipper library integration is coming slowly. Meanwhile, I've tried to fix the offset function in the master branch to provide the 3 joint types: round (still slow), miter and bevel. In particular, miter should be similar to what the previous offset function used to do (if you set the tolerance high enough), but without the errors you first reported.
If you have time to check it out, it worked fine with my (small) test cases.

Thank you for the recent update. I've tried the updated offset function using the default joint type (miter), and it no longer generates segmentation errors for the letter C case above (once enlarged by distance>=0.18 so that features are lost).
The algorithm still lacks generality though when looking at a case like presented above by @rosivda or when enlarging letter C by a larger amount (e.g. distance=2). I think the skeleton approach to construct an offset curve of a polygon, as described in the link provided by @rosivda, is a rigorous approach that would be able to handle all cases. We look forward to a more generic implementation of the offset algorithm. Thank you for your work on this.

@heitzmann, I have recently tested the new offset algorithm in release 0.8.1 and compared it to the older algorithm in release 0.7.1. With default parameters passed to the offset() function, it is substantially slower than the older algorithm (by at least a factor of 6). Is this expected? If so, is it possible to keep the option of the older (more limited, but faster) algorithm in the upcoming releases?

@okianus, unfortunately that version of offset does not implement a proper offset, as discussed above, so I don't think it is a good idea to leave it available in the official release. If it is only for your use, you could always keep it in a separate module for yourself and import it as needed.

@heitzmann, could you please advise what optional parameters (joint type, tolerances, etc.) in the latest release would resolve the problem described by @rosivda above?
If I understand correctly, you mentioned in your comment on Feb 3 that the new implementation of offset resolves this problem, and the clipper library follows a similar, but more efficient algorithm. However, I've ran some basic experiments with the different joint types, and I still see different outputs whether there is one isosceles triangle, or the same shape formed by two adjacent triangles for positive offsets.
In the case of this simple problem, I could obtain the desired output by running fast_boolean prior to offset. However, for large scale problems, fast_boolean would result in re-segmentation. The segmented structures, when enlarged through offset, would still produce an incorrect result. Would appreciate your input on this.

@okianus, the problem you have is that offset is performed independently in each polygon. So if your shape is composed of many polygons (as in the case of 2 adjacent triangles) each will be offset independent of the other, so their joints might misbehave. The only setting which will give similar results for a single polygon vs  a shape made of adjacent polygons is round joins (that is, if you don't care about overlaps).
I can think of only one feasible solution for this problem, which would be to add a flag in offset to allow it to internally join all polygons before the actual offset is performed. That will have to be implemented in the c extension, though, because that is the only place where polygons with holes can be represented without segmentation.
That should not be hard to do, so as soon as I have the time, I'll try to implement it.

@heitzmann I've tested commit 81a37ea with simple cases that had problems similar to what was described above by @rosivda. With join_first=True, all the cases produced the correct result for positive offset. Thank you for your quick action on this!
A related question -- I've noticed that the performance of the offset algorithm depends on the distance parameter (for example, enlarging the same set of features by distance=20 takes roughly twice the amount of time compared to distance=0.3). Do you know what is the reason for this? (In contrast, the older algorithm in release 0.7.1 did not depend on the value of the required offset.)

@heitzmann Thanks a lot for providing improvements to the offset algorithm! The join_first=True tag in your 81a37ea commit appears to have been a great leap. Preliminary testing indicates that the offset algorithm is now functioning correctly for adjacent geometries; we will now do testing of this algorithm in production environment. The performance issue has been noted but it is not yet clear if it is critical for practical-size layouts.

@heitzmann, could you please offer some insight as to why the execution time of the new offset algorithm increases for larger values of distance (with join_first=True)? Intuitively, larger distance would cause more polygons to merge, reducing the feature set to be passed to the clipper algorithm, but that's not what I am observing.

Does it also happen when join_first = False? This flag forces the offset algorithm to run first with distance = 0 to perform all merging, and then with the actual distance. So, it seems strange to me that larger distances would have this effect only when join_first = True.

@heitzmann, I stand corrected, my previous comment was incorrect. The observation of longer execution times for larger distance values is with join_first=False (not with join_first=True as I had originally written). Here are some rough numbers for a large test case:
distance=0.45, join_first=False: 76 sec
distance=4.5, join_first=False: 444 sec
distance=45, join_first=False: 22472 sec
Even though there is no merging involved, why does the algorithm depend on the value of distance? When join_first=True is used, the times for the three cases above are about the same.

@heitzmann, We have conducted testing of the offset algorithm for polygon sets containing about million vertices each (in join_first=True configuration). The algorithm produces expected results. The introduction of the offset algorithm has dramatically simplified our workflow, which now relies only on gdspy. We took a note that the offset algorithm was the longest (time-wise) operation for us but it was acceptable for the assembly of even the most complex chips. We would like to thank you for implementing it.
This has been discussed with @okianus. Our joint recommendation is to close this issue.

Sounds great! Thank you for your input and taking the time to improve gdspy!


Adding the vector tag

Adding the vector tag.
The dev PR was done from the dev branch, so this PR is done from the master branch (https://github.com/CybercentreCanada/assemblyline-base/pull/386)

Codecov Report

Merging #391 (7b666e9) into master (647f263) will increase coverage by 0.18%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #391      +/-   ##
==========================================
+ Coverage   70.82%   71.01%   +0.18%
==========================================
  Files         118      118
  Lines       10510    10511       +1
==========================================
+ Hits         7444     7464      +20
+ Misses       3066     3047      -19

Impacted Files
Coverage Δ

assemblyline/common/compat_tag_map.py
100.00% <ø> (ø)

assemblyline/odm/models/tagging.py
100.00% <100.00%> (ø)

assemblyline/common/heuristics.py
82.05% <0.00%> (+1.28%)
:arrow_up:

assemblyline/common/backupmanager.py
75.41% <0.00%> (+5.83%)
:arrow_up:

assemblyline/datasource/al.py
96.15% <0.00%> (+15.38%)
:arrow_up:

Continue to review full report at Codecov.

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


npm install should not be called from package.json postinstall

Version
3.4.0 (problem is present in current code as well)
Development Environment
Google Chome, latest
Current Behavior
In the postinstall stanza, the image editor attempts to sneakily install fabric via npm:
 "postinstall": "npm install --no-save --no-optional<EMAIL_ADDRESS>
This breaks projects using yarn. If this package is a dependency, then it should be listed as such and not installed as part of postinstall. If it has to be in postinstal, then you should figure out if the user is running yarn or npm and run the right package manager. This behaviour breaks yarn.
Expected Behavior
Clean package install with proper dependency management.

Previously, if you did not install --no-optional in fabric version 1.6.7, you ran into problems.
The fabric version I currently use has been updated to 3.x.x so there seems to be no problem installing on the dependencies.
Thank you for your feedback and we will test it a bit more and fix it.

It was released in v3.7.3.


Do you know if Steam updated something about live matches?

All websites that uses to get live matches from a user is broken at the moment for CS:GO at least I don't know the rest of the games.
I've put up a bounty for 100$ to the person that could fix it.
https://www.bountysource.com/issues/95824082-is-requestlivegameforuser-no-longer-working
https://github.com/joshuaferrara/node-csgo/issues/81

What is invalid?

What is invalid?

This is a low level thing. Nothing that could be fixed in node-csgo.
CMsgGCCStrike15_v2_MatchListRequestLiveGameForUser
k_EMsgGCCStrike15_v2_MatchListRequestLiveGameForUser
Instead of just saying invalid. Can you instead complain what is invalid? How can we fix the underlaying issue? How can we help you to solve the issue or do you have any ideas how to solve the issue or can you point in a direction?

This is a low level thing. Nothing that could be fixed in node-csgo.
CMsgGCCStrike15_v2_MatchListRequestLiveGameForUser
k_EMsgGCCStrike15_v2_MatchListRequestLiveGameForUser
Instead of just saying invalid. Can you instead complain what is invalid? How can we fix the underlaying issue? How can we help you to solve the issue or do you have any ideas how to solve the issue or can you point in a direction?


Extend route to deal with http.Handle

I would like to extend route to deal with http.Handle("/", http.FileServer(http.Dir(*root)))
route works well for golang app engine apps as in gonawin main.go because you have a app.yaml file where you can define where the root static files are.
example:
- url: /
  static_files: static/index.html
  upload: static/index.html

This is good when you have an appengine angularjs app where you have the client side working with angularjs routes
example.com/#/route1
example.com/#/route2

And an api that you can use that goes into the app engine backend which could respond with some json for example:
example.com/api/something1
example.com/api/something1

However in a non appengine web app like greentros routes is not as useful. Here is why:
This is the entry point for this golang web app that runs in heroku:
var root = flag.String("root", ".", "file system path")

func main() {
    http.HandleFunc("/api/something1", something1Handler)
    http.HandleFunc("/api/something2", something2Handler)
    http.Handle("/", http.FileServer(http.Dir(*root)))
    log.Println("Listening on 8080")
    err := http.ListenAndServe(":8080", nil)
    if err != nil {
	    log.Fatal("ListenAndServe:", err)
    }
}

Here is the current main.go
In this case, http.Handle("/", http.FileServer(http.Dir(*root))) is what handles the angularjs app.
And http.HandleFunc("/aip/something1", something1Handler)is what could handle json responses.
route can deal with HandleFunc but I cannot use route for HandleFunc and http.Handle("/", http.FileServer(http.Dir(*root)))

Serving Satic file with go:
External package solution
Example with Gorilla/Mux
func ServeStatic(router *mux.Router, staticDirectory string) {
    staticPaths := map[string]string{
        "styles":           staticDirectory + "/styles/",
        "bower_components": staticDirectory + "/bower_components/",
        "images":           staticDirectory + "/images/",
        "scripts":          staticDirectory + "/scripts/",
    }
    for pathName, pathValue := range staticPaths {
        pathPrefix := "/" + pathName + "/"
        router.PathPrefix(pathPrefix).Handler(http.StripPrefix(pathPrefix,
            http.FileServer(http.Dir(pathValue))))
    }
}
router := mux.NewRouter()
staticDirectory := "/static/"
ServeStatic(router, staticDirectory)

Notice that using router.PathPrefix will solve the recursive issue above so for example you would be able to load your scripts by using /static/some/path/to/script.js
source: http://www.shakedos.com/2014/Feb/08/serving-static-files-with-go.html

Serving Satic file with go:
External package solution
Example with Gorilla/Mux
func ServeStatic(router *mux.Router, staticDirectory string) {
    staticPaths := map[string]string{
        "styles":           staticDirectory + "/styles/",
        "bower_components": staticDirectory + "/bower_components/",
        "images":           staticDirectory + "/images/",
        "scripts":          staticDirectory + "/scripts/",
    }
    for pathName, pathValue := range staticPaths {
        pathPrefix := "/" + pathName + "/"
        router.PathPrefix(pathPrefix).Handler(http.StripPrefix(pathPrefix,
            http.FileServer(http.Dir(pathValue))))
    }
}
router := mux.NewRouter()
staticDirectory := "/static/"
ServeStatic(router, staticDirectory)

Notice that using router.PathPrefix will solve the recursive issue above so for example you would be able to load your scripts by using /static/some/path/to/script.js
source: http://www.shakedos.com/2014/Feb/08/serving-static-files-with-go.html

maybe I am wrong but if I have to do all that I do not see the benefit of using route, since a http.Handle("/", http.FileServer(http.Dir(*root))) is enough.

I found a solution, I am going to try this out and let you know.

With commit 4da5b74a461d96825847ecc85f9a1ef28e734d9b
you can now have the following app with no 404 on static ressources of backend routes.
Let me know if this is ok , and feel free to merge.
package main

import (
    "flag"
    "github.com/taironas/route"
    "log"
    "net/http"
    "os"
)

var root = flag.String("root", "app", "file system path")

func main() {
    r := new(route.Router)

    r.HandleFunc("/black/?", blackHandler)
    r.HandleFunc("/green/?", greenHandler)
    r.HandleFunc("/blue/?", blueHandler)
    r.HandleFunc("/red/?", redHandler)

    r.AddStaticRoute(root)

    log.Println("Listening on " + os.Getenv("PORT"))
    err := http.ListenAndServe(":"+os.Getenv("PORT"), r)
    if err != nil {
        log.Fatal("ListenAndServe:", err)
    }
}

Nice! That looks fine to me.
I will merge into dev branch, and I will update the test and the doc.

Cool! I don't mind changing the name :+1:


Report from publicapis.dev

Name: Fun Facts
Category: Games & Comics
Issue: Broken link
This report was sent from publicapis.dev.

Removed.


Bending mod won't work.

Mod Name
bending (fabric)
Mod Homepage
https://modrinth.com/plugin/bending
Minecraft version
1.20.1
Describe the bug
doesn't boot.
Steps to reproduce

boot minecraft neoforge
crash

Logs
https://gist.github.com/OrdinaryCloverOC/be7433a9486ae89a18c31c69d3bc271a
Additional context
no other mods aside from no chat reports

Caused by: java.lang.UnsupportedOperationException: ResourceBundle.Control not supported in named modules
at java.util.ResourceBundle.checkNamedModule(ResourceBundle.java:1540) ~[?:?] {}
at java.util.ResourceBundle.getBundle(ResourceBundle.java:1062) ~[?:?] {}
at me.moros.bending.common.locale.TranslationManager.loadDefaults(TranslationManager.java:95) ~[bending-fabric-mc1.20.1-3.4.0_mapped_mcp_1.20.1.jar%23356!/:?] {re:classloading}

The mod's non-standard way of managing localization is not compatible with named modules, which are used by Forge. As such, this cannot be fixed on our side.


Disable DNS cache at docker build instead of entrypoint

Cherry-pick: https://github.com/Alluxio/alluxio/pull/9762

alluxio-bot, merge this please.


Add "Open in File Explorer" commands to context menu & command palette

Fixes #412
This adds a menu entry point to blob container and file share tree items:

As well as a catch-all command to the command palette:

Offline discussion: Combine all "Open in File Explorer" commands into one. Also wait to fix this until progress is made on #431


Sync Usage section in README.md with actual --help output

To prevent --help output and README.md from drifting apart, why not create a CI script that complains when the ## Usage section does not match the output of running the executable? The script could be made such that it either complains or patches the README.md so that updating this section is semi-automatic. (One might consider a CI script that auto-commits to a PR when --help output changes, but I'm not sure I like automated checks causing commits for risk of automation cascades.)

While I generally think it is good to ensure that the documentation and code stay in sync, I am also a bit hesitant to introduce and maintain the complexity for this. I'll close the issue for now and then revisit it later if it becomes a problem.


Add instructions for running Rafiki locally to the README

We have a docker compose file that may be out of date, which allows you to run some of the Rafiki components
The contributing guidelines cover some instructions on running rafiki

#476


accept a path or bytes for Single and Parallel

let _ = Single::from_bytes(); // accepts a vector (or array) of bytes
let _ = Single::from_path(); // accepts a path leading to a .jpg image

let _ = Parallel::from_dir(); // accepts a directory containing .jpg images
let _ = Parallel::from_vec(); // accepts a vector of `Vec<u8>`'s or `&[u8]`'s

This allows for broader use of the crate.

it is decided this crate will not interact with filesystem at all, it will only deal with image bytes.

closed in #23


Awesome book

The project is well designed and clear code.
As an optional if there is popup after the book is added successfully

Well done. 👍
Your project looks good and well organized. 😄
Just an additional optional suggestion:
I think 🤔 it would be fine to adjust or change the background color, or font color; just for accessibility sake, It is difficult to see an active item.
Normal state:

Active state


Multiples code and ph4 memory management

This pull request makes two independent changes:

The AMUSE multiples code now contains all changes made by josh Wall as part of his Torch development.  The Torch version of multiples can be safely discarded.

The memory-management error in ph4 reported by Steven and Aaron Tran has been repaired.

I've tested Steve's 2nd change with:

ph4 only: add 8191 stars, then 10,000 stars to test a two-step buffer increase
Torch (FLASH+Amuse): restart from checkpoint and create up to 8474 stars

I've done a very minimal test of Steve's 1st change by running Torch with:

old AMUSE version of Multiples
Josh Wall's version of multiples
Steve's newly committed version

All run and process one interaction successfully, example stdout below.  No test that the output is correct, though.  Overflow warning occurs in all three versions of multiples, and so is probably not tied to the changes.
interaction at time 2.71617265295e+13 s
initial top-level: 7290 (1.49597870691e+13 m) 7359 (1.49597870691e+13 m)
M = 9.29543699932e+29 kg  Etop = 8.7105823586e+35 m**2 * kg * s**-2
/rigel/astro/users/at3222/code/amuse/src/amuse/units/generic_unit_converter.py:189: RuntimeWarning: overflow encountered in double_scalars
  return new_quantity(number * factor, new_unit)
/rigel/astro/users/at3222/code/amuse/src/amuse/units/generic_unit_converter.py:227: RuntimeWarning: overflow encountered in double_scalars
  return new_quantity(number * factor, new_unit)
after encounter: 2 single(s), 0 multiple(s)
final top-level: 7290 (1.49597870691e+13 m) 7359 (1.49597870691e+13 m)
M = 9.29543699932e+29 kg Etop = 8.7105823586e+35 m**2 * kg * s**-2
checking quadrupole perturbations
x = 2.169639939e+13 m M = 9.29543699932e+29 kg
  8051: r = 2.51184737369e+14 m m = 3.10773379062e+29 kg dphi_top/dphiQ = -1.29313352173
  8149: r = 4.14760628198e+14 m m = 3.17328817629e+29 kg dphi_top/dphiQ = -5.70151795241
  7481: r = 5.79719450442e+14 m m = 7.05829807379e+29 kg dphi_top/dphiQ = -6.99940397185
  6872: r = 6.49981353017e+14 m m = 2.95277236588e+29 kg dphi_top/dphiQ = -23.581974414
  7895: r = 1.24481287761e+15 m m = 1.38225409942e+30 kg dphi_top/dphiQ = -35.3860241552

thanks for testing, I have also run the normal unit tests!

btw, what is multiples_save.py??


Timestamp support

  // TODO(rockwotj): Support timestamps
Timestamp support would be very much appreciated. At the moment it's one of the basic types missing.

WDYT about making this be the google.protobuf.Timestamp message?
This would end up being:
message Example {
  google.protobuf.Timestamp ts = 1;
}

Then this would end up being a check for ts is timestamp

Makes perfect sense to me.

I'm interested in this library as well. Any progress here?

Have a PR open in #22

Created a new release for darwin with these changes. Should have a linux release done Monday when I'm at my Linux machine.


MUMPS.jl

Hey there,
I am becoming a big fan of juliabox! Great job everyone! I am just missing the package MUMPS.jl or a similar support of MUMPS (https://github.com/lruthotto/MUMPS.jl). Do you think you can add it?
A note on the installation: Please look at the issue (https://github.com/lruthotto/MUMPS.jl/issues/2) that discusses problems with installing MUMPS using homebrew (probably due to some conflicting BLAS libraries). Because of that, in our research groups, we compile MUMPS into a static library using the Makefile provided.
I'm really looking forward to testing more on the box!

@tkelman MUMPS 5 is out.


Papercut: mismatch between name and signature

The name of from_slice_dim_stride(dim: D, strides: D, xs: &'a mut [A]) suggests a parameter ordering inconsistent with what it actually expects.
Same goes for pub fn from_vec_dim(dim: D, v: Vec<A>) and related constructors.
I suggest to change the API now despite the breakage, rather than wait to get more users. I don't have good ideas on which ordering to choose.

tricky. Thanks for the report!

This mess of constructors makes me think of the only rust idiom that handles it -- the builder pattern. Not sure it's so nice though.
OwnedArray::new((3, 2)).zeros();
OwnedArray::new((3, 2)).from(vec);
OwnedArray::new((3, 2)).f().from(vec);
OwnedArray::new((3, 2)).strides((3, 1)).from(iterable);
OwnedArray::new((3, 2)).unchecked().from(vec);

It composes it down, but I'm not so sure I like it.

I don't like it much either. Imo a fancy creation api can wait.
On Mar 19, 2016 10:25 AM, "bluss"<EMAIL_ADDRESS>wrote:

This mess of constructors makes me think of the only rust idiom that
handles it -- the builder pattern. Not sure it's so nice though.
OwnedArray::new((3, 2)).zeros();OwnedArray::new((3, 2)).from(vec);OwnedArray::new((3, 2)).f().from(vec);OwnedArray::new((3, 2)).strides((3, 1)).from(iterable);OwnedArray::new((3, 2)).unchecked().from(vec);
It composes it down, but I'm not so sure I like it.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/bluss/rust-ndarray/issues/163#issuecomment-198710872

Another idea is to put the "decoration" on the dimension type
OwnedArray::zeros((3, 2))   // zeros
OwnedArray::zeros((3, 2).f())   // zeros_f
OwnedArray::from_vec_dim((3, 2).f(), vec); // from_vec_dim_f
OwnedArray::from_vec_dim((3, 2).strides((3, 1)), vec); // from_vec_dim_strides

I kind of like the idea of constructing "layout" objects from dimension +
stride information, and then using that in constructing the array. For the
sake of the original bug, though, please change the name so
OwnedArray::from_dim_vec((3, 2).f(), vec);
that is, match the order of arguments with the name of the method. Two
functions seem in order:
OwnedArray::from_dim_vec((3, 2), vec);  // For the simple case
OwnedArray::from_layout_vec((3, 2).strides((3, 1)), vec); // For the
non-default-stride cases
since the first argument is no longer just a dimension.
Daniel
On Wed, Apr 6, 2016 at 9:32 AM, bluss<EMAIL_ADDRESS>wrote:

Another idea is to put the "decoration" on the dimension type
OwnedArray::zeros((3, 2))   // zeros
OwnedArray::zeros((3, 2).f())   // zeros_f
OwnedArray::from_vec_dim((3, 2).f(), vec); // from_vec_dim_f
OwnedArray::from_vec_dim((3, 2).strides((3, 1)), vec); //
from_vec_dim_strides
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

--
Daniel Vainsencher


[DON'T MERGR]Temporary fix message relayers

Codecov Report

Merging #196 (49918e6) into develop (bb7c018) will increase coverage by 17.79%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           develop     #196       +/-   ##
============================================
+ Coverage    71.73%   89.52%   +17.79%
============================================
  Files           68       33       -35
  Lines         2257     1079     -1178
  Branches       335      150      -185
============================================
- Hits          1619      966      -653
+ Misses         638      113      -525

Flag
Coverage Δ

batch-submitter
?

contracts
89.52% <ø> (ø)

core-utils
?

data-transport-layer
?

message-relayer
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

packages/core-utils/src/alias.ts

...ubmitter/src/batch-submitter/tx-batch-submitter.ts

packages/core-utils/src/common/misc.ts

packages/core-utils/src/l2context.ts

packages/core-utils/src/index.ts

...itter/src/batch-submitter/state-batch-submitter.ts

packages/data-transport-layer/src/utils/index.ts

packages/data-transport-layer/src/utils/common.ts

packages/core-utils/src/fees.ts

packages/core-utils/src/coders/sequencer-batch.ts

... and 25 more

Continue to review full report at Codecov.

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


Drag selection syls when highlighting neumes broken

We cannot drag select syllables when highlighting by neume.

Can we replicate this? It doesn't make sense since drag selection and highlighting are totally separate.

Okay so as of 8386f1b we can drag select by syllable but the selection highlight isn't applied to the selection.


Is something holding up 3.2.0?

No particular reason, but is there something holding this up? I use 3.1.0 and am investigating borine's dbus monitor and it requires 3.2.0 which is not available? I guess the git version reports as 3.2.0?

There are no particular reasons not to release a new version right now. However, I'd like to finish my work with LC3plus before making a new release. And the new release will be most likely 4.0.0 because of backward incompatible changes in command like options for bluealsa.
Alternatively, I will restore removed options... and the second release from now will be 4.0.0. I will have to think about that :D

borine's dbus monitor ... requires 3.2.0

Apologies, that was a wild guess at the next version identifier; I did not intend to cause any confusion! I'll change the wording next time I do an update to that project.

Apologies, that was a wild guess at the next version identifier;

There is nothing to apologize for. The next version number is unknown even for me. And after all, it's only an identifier :D The important thing is that at the current stage of master branch the new version will be released sooner than later.

I still have got one item which needs to be  merged into the master before releasing a new version. However, right now I'm waiting for some external tests. I hope that within week or two new version will be released.


Fix various bugs in fame/enclosure assembly

[ ] Holes in pneumatics tray are wrong diameter. They are currently for heat set inserts, which were eliminated. There are constants defined for M4 clearance holes in the global constants file. It should be as simple as switching out one constant for another.
[ ] Screws that connect pneumatics tray to main frame have not been imported correctly  - should be ISO not ANSI, extraneous metadata need not be included (thread pitch? metal type?), but part name should have length, so it can be easily recognized in assemblies, should have link to source (e.g. McMaster). Take example from other imported screws.
[ ] 14mm M2.5 screws for touch screen have the wrong McMaster link - it is currently for M5. Model itself appears to be correct, only link is wrong.

Starting points
Read wiki page on mechanical modeling. That is the minimum standard which all models should satisfy. Follow the example of existing models.

bugs na montagem de fama/invólucro #1244


DRAFT: redesign search bar

Fixes: https://github.com/zulip/zulip/issues/21798

Playing around with this:

We were going to have something that looks like a search box in the closed state, right. Having no boundaries around "Search" feels confusing to me.
This comment from the other PR still applies:

Changing the width of the window opens the typeahead.

As I resize the window, the typeahead width doesn't change at the same speed as the top part of the box, so it looks glitchy.

This comment still applies too; I'm seeing it after I press "Enter" to execute a search:

there's a gray line that should be behind it, but instead cuts across it.

I'm not seeing a hover behavior on the search box in dark theme.

6. I see text spilling out of the typeahead:

7. Names spill out of their pills in a narrow window; in main, I think they just get covered up by the edge of the window, which is differently bad...

That's all I've got at the moment!

We were going to have something that looks like a search box in the closed state, right. Having no boundaries around "Search" feels confusing to me.

Once we change the background color to grey instead of white, there'll be a boundary. #23724

Changing the width of the window opens the typeahead.

fixed this

As I resize the window, the typeahead width doesn't change at the same speed as the top part of the box, so it looks glitchy.

fixed this (same root issue as 2! historic typeahead stuff that doesn't work for this use case)
(working on the others)

4 and 5 -- I'm waiting on Vlad to respond on CZO

I see text spilling out of the typeahead

I'm no longer seeing this, so I think things I've changed since have fixed it

Names spill out of their pills in a narrow window; in main, I think they just get covered up by the edge of the window, which is differently bad...

I'm not super familiar with what we're doing with pills -- do you have a sense of what it should look like in this case?

I'm not super familiar with what we're doing with pills -- do you have a sense of what it should look like in this case?

I don't know if there are places where we solve this well; I see some where we fail to:

Maybe abbreviating with a ... would be best?

Are pills actively being used outside of CZO? Are there engineers/Vlad working on it currently? I'm wondering if labeling the glitch out of scope for this PR would be reasonable.

I've now fixed the border-radius (when search bar is open after a search is complete) and box-shadow issues (simplified it so there's no overlapping shadows) and removed space between search bar and typeahead:

Dark mode now has [correct box-shadow](https://www.figma.com/file/jbNOiBWvbtLuHaiTj4CW0G/Zulip-Web-App?node- id=567%3A51058&t=nulVmvVBfaFHjPB5-0)

remaining known issues:

if I move away from the window with the typeahead window open then come back, the search bar collapses but the typeahead stays -- need to look into that
the border radius under the search bar is only broken in dark mode (which doesn't make sense to me, need to look further into that)

border radius under the search bar

Fixed! Turns out it was also (more subtly) broken in light mode.

The things I see so far:
Cross icon is too big

I think is the different search icon and it is slightly misaligned

Search input and search suggestions should be on a single line:

He click on autosuggestions just closes the search box
In the mobile version lets utilize the full width and cover elements under

something like this:

In mobile version the list box lost the shadow for some reason.
In the dark mode mobile version search button has some weird background
, it should be just an icon.
Don't forget to recolor the cross icon in the dark version

latest push has some pixel perfecting from the Figma mocks, though I also asked several questions here

Not critical. The search icon doesn't look like it is in a center.

I thought of this icon square as 28x28 square with 16x16 icon in the center. There might be some problem with an icon I prepared or it is just rendered this way. Please check.
Another reason could be that the width of this icon square is 31 instead of 28

Dark mode hover state has white text and icon, which wasn't a design suggestion:

But I understand the potential value of it, because just having hover shadow might not be enough in dark mode. I suggest to have icon 0.75 transparency on hover instead of 100. I don't suggest to change color/transparency of the prompt prompt on hover

Why would we need a search icon be a button of itself?

Focused state shadow in dark mode is box-shadow: 0 10px 20px hsla(0, 0%, 0%, 0.25), 0 7px 5px hsla(0, 0%, 0%, 0.1), 0 -7px 9px hsla(0, 0%, 0%, 0.1); but it should be box-shadow: 0px 4px 20px rgba(0, 0, 0, 0.3), 0px 1px 5px rgba(0, 0, 0, 0.3);. In the light theme the focused shadow should be corrected to be box-shadow: 0px 4px 20px rgba(0, 0, 0, 0.25), 0px 1px 5px rgba(0, 0, 0, 0.1); instead of box-shadow: 0 10px 20px hsla(0, 0%, 0%, 0.25), 0 7px 5px hsla(0, 0%, 0%, 0.1), 0 -7px 9px hsla(0, 0%, 0%, 0.1);

Active state placeholder color shouldn't be so bright. Sorry for the confusion. I meant such color for actualy inputed text, while placeholder should be the same as usual:

In the dark mode it's ok to have search icon be a bit brighter (same as in hover state).
Updated Figma component

If I right click on opened suggestions, search bars will be in a weird state:

And between expended and collapsed state it jiggers through such "half width" state which is not pleasant to the eye:

I suggest right now we don't polish the expanding/collapsing animation but make it clean 2 states without anything in between.

Close button is to narrow and doesn't touch the right side of the search input:

It should be 28x28 square and right aligned with right side of input rectangle:

In Figma I suggested to have a lighter suggestions color: #595959; / hsla(0, 0%, 35%, 1), while selected color would be black and highlighted match would be black too. Right now I see that typeahead colors in search are reset to color: inherit; which isn't great. Here is how it could be:

I updated dark theme design to reflect that idea (suggestions are 75% transparent white, while actual input text and matching list item and matching text fragment color is 100% non transparent white):

Prefix "Search for" should be styled as non matching part while the text from user's input should be highlighted as matching part:

I couldn't review NO search result page or regular search match result, since it's impossible to get it (jumps to recent conversations):

👀 1. I can investigate the icon alignment
✅  2. Updated to 0.75 opacity on hover for the icon and removed the text color change.

❓ 3. "Why would we need a search icon be a button of itself?" -- this is for semantic HTML, so that things like screen readers know it's a button that does something. We usually put icons inside containers like this. Do you have any concerns about it?
✅  4. I changed the box shadow to box-shadow: 0px 4px 20px hsl(0deg 0% 0% / 30%), 0px 1px 5px hsl(0deg 0% 0% / 30%); and  box-shadow: 0px 4px 20px hsl(0deg 0% 0% / 25%), 0px 1px 5px hsl(0deg 0% 0% / 10%); -- it would be really helpful if you could always share colors in hsl, since that's what we do in the CSS and there isn't always a clean conversion between color formats.

✅  5. Removed custom color for placeholder text when the search bar is open in dark mode

🤔  6. These are both things I tried to improve, but essentially it's a problem of us using bootstrap code for the typeahead.  I'll ask in design if it's a blocker to shipping the search bar.
✅  7. Updated to 28px by 28px and top/right 0

✅  8a. "have a lighter suggestions color: #595959; / hsla(0, 0%, 35%, 1), while selected color would be black and highlighted match would be black too."
Updated in light mode and dark mode

🤔 8b. Bolding the part of the search item that matches the input text is going to be a lot more involved and also involve changing how typeahead works. I'll look into how hard that will be.
👀  9. "I couldn't review NO search result page or regular search match result, since it's impossible to get it (jumps to recent conversations)"
Oh dang, thanks for catching this bug! I will start by looking into this.

"Why would we need a search icon be a button of itself?" -- this is for semantic HTML, so that things like screen readers know it's a button that does something. We usually put icons inside containers like this. Do you have any concerns about it?

Because icon is for people who can see and icon isn't a button. The whole input is a button. But icon is just a little image in this case. So I don't think it is semantically correct to put icon as a separate button inside another button.
Lets take GitHub as example:

Icon is an svg/font/img and not a button
Also it is not a big problem to make something which isn't a button to act like a button, while default browser styles for a  might be tricky to cancel. I'm not saying we shouldn't use button just suggesting to use it for buttons with a label.
GitHub toolbar in the comments doesn't use  tag... they use custom html tags:

These are both things I tried to improve, but essentially it's a problem of us using bootstrap code for the typeahead.
I guess we could have another pass once we going to deal with compose box and this time that could be postponed, but lets create a follow up issue in this case

8b. Bolding the part of the search item that matches the input text is going to be a lot more involved and also involve changing how typeahead works. I'll look into how hard that will be.
Yes, please, take a look. It is not super critical but since we are doing design pass on this element it would be great to make it work and look nice.

I'm pushing a commit that addresses both the issues in 6 which ended up easier than it felt last time I tried.
I've asked on CZO about tips for implementing 8
Still investigating 9, haven't started on 1 yet.

Just pushed a commit that fixes 9.
I believe the only remaining items are 3 and 8 :)

Addressed 3 by both not renaming the icon container as a button, and also removing that container altogether.

Just pushed a commit that fixes 8 (bold text for the query), though I might end up doing a different technical implementation.
The only remaining comment from Vlad to address is investigating icon centering, which I'm planning to pair on with Karl in the near future.
I'm not currently aware of any other work that needs to be done on this PR.

I removed the commit Anders is worried about and followed up on CZO about finding a better solution.
Icon centering was confirmed and looks okay. All of Vlad's comments are now addressed.
I pushed some nice CSS cleanup (removing some legacy absolute positioning) in these commits that I worked on with Karl today.

I have a bug with a shadow on hover in a dark theme

I'll look into that, thanks!

the whole bar is of a bit different color

To confirm -- @terpimost do you want  the full header to be a different color? I believe the issue is that some of the header isn't the header color and not that some of the header is a different color than the body, but let me know if you want the header to actually be the same color. Someone noticed this on main and we're working on fixing it -- discussion here.

No search results could be improved

Great callout! I didn't notice that part of the design. I can work on that as another commit in this PR, or a separate PR.

We lost space between user pill and the text

I will look into that.

Close button takes full width but not height, which is wrong

I will look into that

The suggestion about bold was not only to change font-weight but also contrast of a color, right now it is jut font-weight

I talked about this a bit on CZO but I haven't changed anything about the bold or font weight stuff yet. Are you seeing different behaviour than on CZO? Or maybe you're talking about something different than that?

Screenshot of previous request about colors

Are you not seeing the color changes? I see them on my version locally. Or am I misinterpreting your comment?
Thank you very much for taking a look! I'm excited to be getting close  :)

I believe the issue is that some of the header isn't the header color

Correct, I was talking about the same issue.

haven't changed anything about the bold or font weight stuff yet

There are 2 issues here. One is what to bold... which is might be hard for the very first search result as I understand. Second is how to bold - I suggest to not only bold but change a color of that so bolded text would be darker in light mode and lighter in dark mode:
see here de is of a black color, while the text of suggestions is dark grey

@terpimost the close button looks to me like it takes full height, am I missing something?

Second is how to bold - I suggest to not only bold but change a color of that so bolded text would be darker in light mode and lighter in dark mode:

Ah I see! I haven't changed anything relating to the bolding, but it sounds like you want to change the existing bolding to be more contrasting as well as having the top result include the bold text? I can remember that when I get working on that.

fixed:

1 has been fixed in this PR
2 has been fixed in a separate PR and merged into main
4 has been fixed in this PR

3 is waiting on @terpimost's  design, 5 is waiting on Vlad's response to my question above
and 6/7 I'll work on in a separate PR for now, to set up the bolding.

want to change the existing bolding to be more contrasting as well as having the top result include the bold text?

Yes, top search result isn't that critical, while more contrasting current bolding is very helpful

3 is waiting on @terpimost's design

Discussing in Zulip chat

All right, Evy. I've reviewed the CSS here. There are a few small comments and things you might want to check for.
It's really tricky trying to poke at this in the browser, because (as I'm guessing you know) even manually adding classes like .expanded or inline display: block styles to hold things open quickly collapse thanks to our solid but in this case a bit annoying event-handling to close things up and off.
That said, when you next want me to take a look at this, please let me know.

@terpimost can you respond to this comment above? I think I've otherwise addressed your comments in this PR or by opening other PRs.

There should be no focus outline on click and it should be of the full height anyway :)

Please remove custom focus/active class and replace it with focus-visible - works only when focused via a keyboard.
Please make the height of the button to utilize the full height of the input field
In the dark theme I do see some strange visual bug:

Input text is black in the dark theme for some reason:

Sigh, that dark theme bug came from #26131 which was merged two weeks ago. This is an unfortunate effect of leaving a PR open this long while other work is being done. Thanks for catching that!
I updated the focus thing as well:

diff --git a/web/styles/dark_theme.css b/web/styles/dark_theme.css
index 4e0b708a62..6f307e7fb8 100644
--- a/web/styles/dark_theme.css
+++ b/web/styles/dark_theme.css
@@ -482,8 +482,7 @@
     select,
     .pill-container,
     .user-status-content-wrapper,
-    #custom-expiration-time-input,
-    #searchbox #search_query {
+    #custom-expiration-time-input {
         background-color: hsl(0deg 0% 0% / 20%);
         border-color: hsl(0deg 0% 0% / 60%);
         color: inherit;
diff --git a/web/styles/search.css b/web/styles/search.css
index 8ec121aa24..4a12744e0c 100644
--- a/web/styles/search.css
+++ b/web/styles/search.css
@@ -32,10 +32,14 @@

     .search_close_button {
         width: 28px;
+        height: 100%;
         background: none;
         border: none;
         opacity: 0.5;
         line-height: 0;
+        &:not(:focus-visible) {
+            outline: none;
+        }

         &:hover {
             opacity: 1;

If I'm focused in the field and hit Tab it just closes the input. Should it be so? Right now it acts like Enter key

Tab acting like enter key doesn't make that much sense to me, so I prefer the way it works in this PR. Thanks for noticing it changed though -- would you prefer tab acting like enter?

Confirmed on CZO that current behaviour is fine. Vlad would like to have Tab move the focus to the close button, but that doesn't seem blocking.

Okay Evy! I found a couple of things:

One big regression I note here is that the / key doesn't properly refocus the search input box from all search views or certain narrows. For example, searching for just a text string, or for posts from a sender renders the / key unresponsive. Something about those narrows is off, even if you go directly to the URL, e.g., http://localhost:9991/#narrow/sender/11-Iago That seems important to fix prior to CZO burn-in. Keyboard users, like me, instinctively whack that thing to refine the search terms when the results aren't satisfactory.
The Tab key does seem to focus the Close button on a second strike. I still don't think that's ideal, but it is frustration-discoverable :) ("[Tab] You should go to close! [Tab] Oh, okay. Cool.")

I wasn't able to replicate the / regression for sender views, but I have replicated it for text string searches so I'll start there :)

I think this should fix it, do you see the issue still after the most recent push?

diff --git a/web/src/search.js b/web/src/search.js
index 6adcc1301c..3f6f637694 100644
--- a/web/src/search.js
+++ b/web/src/search.js
@@ -153,10 +153,9 @@ export function initialize({on_narrow_search}) {

 export function initiate_search() {
     // Don't reset the search bar if it's already open.
-    if ($(".navbar-search.expanded").length) {
-        return;
+    if (!$(".navbar-search.expanded").length) {
+        message_view_header.open_search_bar_and_close_narrow_description();
     }
-    message_view_header.open_search_bar_and_close_narrow_description();
     open_typeahead();
 }

Added a commit to remove the custom handling for Tab in the typeahead, does that seem like the right solution?

@karlstolley ready for your review again :)

Hi @evykassirer! Okay, the / issues seem to be taken care of. The Tab-handling seems right functionally. Let me look at the code now and I'll comment if I have anything to suggest.

Hmmmm. I can't seem to replicate it now, but somehow I got into a state on Recent conversations where the usual Tab traps that keep a user tabbing endlessly through the filters or individual conversation rows stopped working, so that it was possible to tab from the filters box into the first message row, and on down through the entire message list. The only real problem with that (other than a behavioral change that should be discussed if it's intentional, but I can't seem to replicate now) is that the tooltips on the Time column didn't clear.

Changed some things from your comments (noted in relevant threads) and pushing that now.
A few things I asked to further clarification on.
Thanks so much for your review!

Addressed all your comments @karlstolley !

Whew! All right, @evykassirer -- I suggested a couple of nits in comment wording, but otherwise I think this is ready for some time on CZO, so I'm marking it as such.

Fixed those two things! And also fixed them in #26139 since that's where those commits are expected to be merged.

Alya and I played with this and found a couple bugs/quirks:

There's no border/difference between the text box section and the options to select section of the search here; somehow that feels a bit off to me but I'm not sure what to propose as a change.

If I got to a group DM thread, and click to open search, and then click on the "X" to close it, there's a weird flicker that appears like the animation/update got split into two steps.

Should there be a stronger hover behavior or tooltip when hovering over the search box? I feel like a tooltip might be overkill but somehow I feel like just the magnifying glass changing color feels a little weak? Unsure. Oh! In light theme, there's an on-hover shadow (but no on-hover change to the magnifying glass!) and in the dark theme it's the opposite; this is probably not intentional.

The light them contrast feels like it's in the uncanny valley where it almost looks like it's the same but it slightly different but it's too faint of a contrast to easily make out.

The bottom borders seem broken in some way in narrow windows:

If I got to a group DM thread, and click to open search, and then click on the "X" to close it, there's a weird flicker that appears like the animation/update got split into two steps.

Ah, this happens any time the X is clicked. There's some weird stuff around the typeahead closing before the search bar closes. I fixed this with:
diff --git a/web/src/message_view_header.js b/web/src/message_view_header.js
index 2b68bcc54e..e337672791 100644
--- a/web/src/message_view_header.js
+++ b/web/src/message_view_header.js
@@ -163,10 +163,14 @@ export function open_search_bar_and_close_narrow_description() {
 }

 export function close_search_bar_and_open_narrow_description() {
-    $("#search_query").val("");
-    $(".navbar-search").removeClass("expanded");
-    $("#message_view_header").removeClass("hidden");
     if ($("#search_query").is(":focus")) {
+        // Blur first so that the typeahead closes at the same time as
+        // the search bar. Blurring will trigger this function to be
+        // called again.
         $("#search_query").trigger("blur");
+        return;
     }
+    $("#search_query").val("");
+    $(".navbar-search").removeClass("expanded");
+    $("#message_view_header").removeClass("hidden");
 }

The light them contrast feels like it's in the uncanny valley where it almost looks like it's the same but it slightly different but it's too faint of a contrast to easily make out.

Darn, I've messed around with this before and thought I fixed it. I'll take a look again.

posted other followups on CZO here: https://chat.zulip.org/#narrow/stream/101-design/topic/search.20redesign

Doing a test-deploy of this on chat.zulip.org so we can get some feedback.

I see now.  As @evykassirer suggested we can try to solve that with minimum change:
dark mode:

    border-top-width: 1px;
    border-top-color: rgba(0, 0, 0, 0.35);
    border-radius: 0px 0px 4px 4px;

light mode: border-top-color: rgba(0, 0, 0, 0.1);

Ideally I would add backdrop to darken all content and indicate that active search input is a modal... but it might be hard at the current step. Do you think we should do that?
Other apps doing different things:
Google chrome does nothing in light mode:

Yandex does that beautifully (it has nothing in the background like zulip ... no borders under it):

Youtube doesn't look beautiful:

Duck Duck go:

Updates in the recent push:

Rounding the borders of the focus outline for the X button and updates on styling for the outline to not overlap nearby elements
Updated the tab keypress commit to be custom for search
Added a new commit typeahead: Don't act on blurs that change focus within the parentElement. that stops Tab from closing the searchbox, and some blur/keydown handlers elsewhere to ensure that Tab from the close button does still close the searchbox
Simplified close_search_bar_and_open_narrow_description and moved the logic to avoid the narrowing dropdown visual jump to its callsite -- this code is still in the temp commit at the end of this PR
Added the border top to the typeahead

It's great to see this moving along!
Playing with the PR, I noticed that the placeholder word "Search" is in a darker font (in light theme) than actual search terms, which seems weird to me. Is this intentional?

Something seems a bit off with the animation when I click x to close to search box. I think the typeahead is getting shifted to the right, and then immediately closed. It would probably look more smooth if we just closed the typeahead dropdown directly.

I don't know how critical this is, but if I click on the search box and start typing very quickly, the start of what I type disappears when the search box expands. I actually found this easier to replicate by tabbing to the search box, though it's kinda awkward to figure out how to get the keyboard nav to the right place for that.

Mm, I'm seeing problems with overlapping icons in narrow windows:

Something seems a bit off with the animation when I click x to close to search box. I think the typeahead is getting shifted to the right, and then immediately closed. It would probably look more smooth if we just closed the typeahead dropdown directly.

I see this one was noted on CZO a while back as well.

I noticed that the placeholder word "Search" is in a darker font (in light theme) than actual search terms, which seems weird to me. Is this intentional?

That doesn't seem intentional! I updated it to have a similar situation as the dark mode, with the placeholder text being a lighter color than the color for the input and also dropdown options.

Something seems a bit off with the animation when I click x to close to search box. I think the typeahead is getting shifted to the right, and then immediately closed. It would probably look more smooth if we just closed the typeahead dropdown directly.

I see this one was noted on CZO a while back as well.

Yeah this has been a frustrating issue to fix because of how the code is set up here as well as the functionality I want out of closing the typeahead in various circumstances. I feel a bit like I've been doing a bit of wackamole, but hopefully the thing I just changed (still in the temp commit at the end of the PR) works this time!

I don't know how critical this is, but if I click on the search box and start typing very quickly, the start of what I type disappears when the search box expands. I actually found this easier to replicate by tabbing to the search box, though it's kinda awkward to figure out how to get the keyboard nav to the right place for that.

Ah, great find! I was able to replicate it easily enough with a click. Fixed with this:

diff --git a/web/src/message_view_header.js b/web/src/message_view_header.js
index d482cadff1..cb4478a475 100644
--- a/web/src/message_view_header.js
+++ b/web/src/message_view_header.js

 export function open_search_bar_and_close_narrow_description() {
-    reset_searchbox_text();
+    // Preserve user input if they've already started typing, but
+    // otherwise fill the input field with the text operators for
+    // the current narrow.
+    if ($("#search_query").val() === "") {
+        reset_searchbox_text();
+    }
     $(".navbar-search").addClass("expanded");
     $("#message_view_header").addClass("hidden");
 }

I'm seeing problems with overlapping icons in narrow windows.

I just introduced that bug when trying to refactor something. Thanks! Fixed it.

Ready for re-review :)

The unread count looks odd on really narrow screens; I think we should just hide it in this situation:

Otherwise looks good to me in manual testing. Thanks for all the fixups!

Great catch -- just pushed a fix to that :)

Test-deploying on chat.zulip.org. (The test failure was a known flake in main).

Apparently it didn't actually deploy yesterday, fixing now.

@evykassirer can you clean up the last "temp" commit at this point? I think the UI is getting close to completion and I'm not sure how to review it.

squashed the temp commit into the main commit and pushed  :)

I think this lgtm aside from https://github.com/zulip/zulip/pull/24345#discussion_r1330838138

I found a bug where the typeahead isn't properly narrowed after opening the search bar (it shows the generic options until the user takes some action in the input field.)

Merged, thanks @evykassirer and @YashRE42 for all the work on this!


Negative value for used memory

Hello!
I'm receiving negative values for used memory item. It is related to '-w ' key for 'free' command in a script.
#cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)

But running 'free' with no -w gives:
#free
              total        used        free      shared  buff/cache   available
Mem:        3879576      345564     1706380      190400     1827632     3000856

And so, $2-$4-$6-$7 gives negative value.
Running 'free' with -w gives values, that are good after arithmetics:
              total        used        free      shared     buffers       cache   available
Mem:        3879576      345320     1706488      190400        2088     1825680     3001084

$2-$4-$6-$7 = 345320
I gonna remove this check in my setup and hardcode free -w, but it's kind a crutch.
May be it's better to check 'free' version instead of release?
# free --version
free from procps-ng 3.3.10

I find this problem too,Script memory_zabbix_master_item.sh must suit CentOS 6.X,Not CentOS 7.X.
MemUsage=`free | awk 'NR==2 {printf("%d %d %d %d",$2,$4,$6,$7)}'`
Cached=`echo $MemUsage | awk '{print $4}'`

On CentOS 7.x,Command free seventh column is available


Bug Report: full screen issues

While it seems fixed on macOS it seems to be broken on windows now. Need to test if it may need to run different code on  mac and windows due to some odd logic in electron

It's really annoying how fiddly this part is. Need to check if we are doing something wrong or if its just fiddly with electron.

The fullscreen issues are fixed now BUT to fix that I had to enable it always be resizeable.
Need to find a proper fix before the release of the next update or update the styling to be manually resizeable which should fix some of the other issues or make other ones possible.


Ft existing vpc

Description

Motivation and Context

Breaking Changes

How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[ ] I have tested and validated these changes using one or more of the provided examples/* projects

[ ] I have executed pre-commit run -a on my pull request

this is not a change we are looking to implement


Support fetching version from .tool-versions

In case the version of the tool is not defined and the .tool-versions file from asdf is present, we should use version defined there instead of "latest".

This is a useful feature! Scarb already implement this (see versions.js)

We want to do it eventually, but we're currently focused on topics in the Starknet Foundry itself. PRs are welcome though 😅

Done in #18


MD5 should be updated in flutter_service_worker.js

This is my working script with MD5 fixes:
#!/bin/bash

# Based on: https://github.com/doonfrs/flutter-build-web-cache-problem/blob/main/build-web.sh
# Run only ONCE after 'flutter build web' as: ./prepare.sh
# Expected folder structure:
#   build
#     web
#   prepare.sh
#   pubspec.yaml

echo "Reading version from pubspec.yaml without + sign"
version=$(grep version: pubspec.yaml | sed 's/version: //g' | sed 's/+//g')
echo "$version"

echo
echo "Calculating MD5"
md5_0=($(md5sum build/web/main.dart.js))
echo "main.dart.js   $md5_0"

md5_1=($(md5sum build/web/flutter.js))
echo "flutter.js   $md5_1"

md5_2=($(md5sum build/web/index.html))
echo "index.html   $md5_2"
echo

echo "Patching version in js partial urls in main.dart.js"
sed -i 's/\.createScriptURL([[:graph:]]\++[[:space:]]*\+[[:graph:]]/&+"?v='"$version"'"/g' build/web/main.dart.js

echo "Patching main.dart.js path in flutter.js"
sed -i 's|\(${baseUri}main\.dart\.js\)|\1?v='"$version"'|g' build/web/flutter.js

echo "Patching main.dart.js path in flutter.js (for obsolete Flutter 3.3)"
sed -i 's|\(= "main\.dart\.js\)|\1?v='"$version"'|g' build/web/flutter.js

echo "Patching index.html for flutter.js"
sed -i 's/"flutter\.js"/"flutter.js?v='"$version"'"/' build/web/index.html

echo
echo "Calculating new MD5"
md5_n0=($(md5sum build/web/main.dart.js))
echo "main.dart.js   $md5_n0"

md5_n1=($(md5sum build/web/flutter.js))
echo "flutter.js   $md5_n1"

md5_n2=($(md5sum build/web/index.html))
echo "index.html   $md5_n2"
echo

echo "Patching MD5 in flutter_service_worker.js"
sed -i 's/'"$md5_0"'/'"$md5_n0"'/' build/web/flutter_service_worker.js
sed -i 's/'"$md5_1"'/'"$md5_n1"'/' build/web/flutter_service_worker.js
sed -i 's/'"$md5_2"'/'"$md5_n2"'/' build/web/flutter_service_worker.js

Nice Idea to use md5

@doonfrs I've opened the Flutter issue https://github.com/flutter/flutter/issues/127459

I've updated the script to support latest flutter 3.22
I use --pwa-strategy=none currently to avoid service_worker problems, you can check the latest version of the script then you may create a pull request to support service_worker


Update matrix multiplication benchmark

Update the matrix multiplication benchmark to the form used in the final version of the paper, with more scalars + ops and 1 more matrix.  Also cleaned things up a bit to better control number of test runs for each matrix and manage those more automatically

Requesting PR description.

Closed by 982f6d4e482d1184a3ff6ed4a0d2f58430318a50


Excessive log messages; can I change log level somehow?

I'm getting log messages so often I can't troubleshoot other plugins with typescript open. I finally had to edit the plugin and disable the log messages.
Those are "debug" level; is there a config option somewhere to change the log level for the plugin?

The level should be set to WARN by default, per https://github.com/Microsoft/TypeScript-Sublime-Plugin/blob/master/typescript/libs/global_vars.py#L47 . You haven't changed any settings and you're seeing DEBUG level by default?

Indeed; I'm still seeing it, in fact, I just commented out the message that was causing me the most issues, but everything else I'm still seeing the debug messages.

I have seen some other plugins changed the message level for typescript plugin before. What other plugins do you have install? I can try to repro on my machine

Here is my package control list:
"""
{
"bootstrapped": true,
"in_process_packages":
[
],
"installed_packages":
[
"1337 Color Scheme",
"Angular Material Snippets",
"AngularJS",
"Block Cursor Everywhere",
"Color Highlighter",
"ColorPicker",
"Copy to HipChat",
"DocBlockr",
"Emmet",
"Gist",
"Git Config",
"GitGutter-Edge",
"Gitignore",
"Jasmine JS",
"Jira",
"JSHint Gutter",
"Less Tabs",
"MarkdownEditing",
"Material Theme",
"Origami",
"Package Control",
"Railscasts Extended",
"Sass",
"SideBarEnhancements",
"Theme - SoDaReloaded",
"ToggleMinimapOnScroll",
"TypeScript",
"Vintageous",
"Vintageous - Region To Selection",
"VintageousOrigami",
"VintageousPluginSurround"
]
}
"""
I have a system at home that I haven't set up sublime text on yet; I'll have to see if I can find some time to install from scratch and see if I can spot when the issue appears.

I have same issue. I found where the problem is.
https://github.com/Microsoft/TypeScript-Sublime-Plugin/blob/master/typescript/libs/logger.py
On line 20 you need to change
log.setLevel(logging.DEBUG) to log.setLevel(logging.WARN)

Same here. Any news on this?

+1 on console log spam. Will you accept a patch to make that change the @Chyzwar suggested?

+1. I too get the console log spam. Is the correct answer here to do what @Chyzwar suggested? Or is there a more preferable way to handle this? Perhaps a setting?

@pope there is no setting, which is a bug if you ask me, but one way you can do it from an external Python file without having to modify plugin settings is logging.getLogger('TS').setLevel(logging.WARNING) inside a custom plugin of yours or something similar.

I've submitted a PR to fix this issue - as @Ivanca mentioned, setting the level to WARN fixes this issue, although the root cause is due to logger.addHandler being effected by the level of the TS server.
This makes the editor usable again. If anyone sees a way to properly prevent the logging handlers from overlapping their levels(without lots of work) feel free to submit a different fix.


BT 1.9 compatibility

The mod stopped working with the new update,
here is the my log:
Levels :Spam True :Debug True :Info True :Warn True
[Info] Harmony? <IP_ADDRESS>
[Info] Unity? 2018.4.2f1
[Info] Product? BATTLETECH-1.9.0-680R
[Info] ModTek? <IP_ADDRESS>
[Info] Initialized com.github.m22spencer.BattletechPerformanceFix <IP_ADDRESS>434
[Info] Mod-Dir? C:\Program Files (x86)\Steam\steamapps\common\BATTLETECH\Mods\BattletechPerformanceFix
[Error] BattletechPerformanceFix expected BattleTech (1.8), but found 1.9.0

HTH

closed with 5bf736ec1
Check releases tab


HF_PRETRAINED_MODEL not working properly

Description
am not sure to perfectly understand the following
https://github.com/containers/ai-lab-recipes/blob/55610a8c90b6e72c6e9289513825112e6c5e99b1/model_servers/llamacpp_python/src/run.sh#L18-L20
But using the command
podman run -v /home/axel7083/Documents/models/:/models:Z -e MODEL_PATH=/models/functionary-small-v2.5.Q4_0.gguf -e HF_PRETRAINED_MODEL=meetkai/functionary-small-v2.5-GGUF -e CHAT_FORMAT=functionary-v2 -p 8000:8000 -e PORT=8000 ghcr.io/containers/llamacpp_python:latest

does not provide the proper value to --hf_pretrained_model_name_or_path.
Expected
The tokenizer_config.json should be downloaded at startup

Current
With the current, it does not download it

cc @Gregory-Pereira I think a \ is missing on the following line
https://github.com/containers/ai-lab-recipes/blob/55610a8c90b6e72c6e9289513825112e6c5e99b1/model_servers/llamacpp_python/src/run.sh#L19
but when adding it we got the following error
./run.sh: line 12: HF_PRETRAINED_MODEL: %=--hf_pretrained_model_name_or_path %: syntax error: operand expected (error token is "%=--hf_pretrained_model_name_or_path %")


Move /build files into /src

Cleans up the /build directory by moving it into /src.
How to verify

Checkout this branch.
Run the application with $ npm start.
Verify that it works the same as with the master branch.

Fixes #11

This works, but shouldn't we remove the build/ dir too?

I thought I had done that. Thanks for noticing!

Going to merge this in now! :)


Invalid configuration object in hot

Laravel Mix Version: "laravel-mix": "^6.0.27"
Node Version v14.15.1
NPM Version 6.14.8
OS: Win10

Description:
hot mode does not start
Laravel-Mix 6.0.27 + Vue 2.6.14
"scripts": {
    "dev": "npm run development",
    "development": "mix",
    "watch": "mix watch",
    "watch-poll": "mix watch -- --watch-options-poll=1000",
    "hot": "mix watch --hot",
    "prod": "npm run production",
    "production": "mix --production",
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build"
},
"devDependencies": {
    "@vue/cli-plugin-babel": "~4.5.0",
    "@vue/cli-plugin-router": "~4.5.0",
    "@vue/cli-plugin-vuex": "~4.5.0",
    "@vue/cli-service": "~4.5.0",
    "file-loader": "^6.2.0",
    "node-sass": "^4.12.0",
    "sass-loader": "^8.0.2",
    "vue-template-compiler": "^2.6.11"
},
"dependencies": {
    "axios": "^0.21.1",
    "bootstrap": "^4.6.0",
    "bootstrap-vue": "^2.21.2",
    "core-js": "^3.6.5",
    "laravel-mix": "^6.0.27",
    "v-calendar": "^2.3.2",
    "v-video-embed": "^1.0.8",
    "vue": "^2.6.14",
    "vue-plyr": "^7.0.0",
    "vue-router": "^3.2.0",
    "vue-template-loader": "^1.1.0",
    "vuex": "^3.4.0"
}

Steps To Reproduce:

npm run hot
Message in terminal

[webpack-cli] Invalid configuration object. Object has been initialized using a configuration object that does not match the API schema.
 - configuration has an unknown property 'webpackbar'. These properties are valid:
   object { bonjour?, client?, compress?, devMiddleware?, firewall?, headers?, historyApiFallback?, host?, hot?, http2?, https?, liveReload?, onAfterSetupMiddleware?, onBeforeSetupMiddleware?, onLi
stening?, open?, port?, proxy?, public?, setupExitSignals?, static?, transportMode?, watchFiles? }

I have the same issue. I have created several Laravel + Vue proof of concepts over the past weeks and they all worked flawlessly. I don't know what I did differently this time yet I am stuck with this error now. Have been for the past 2 days...

Duplicate of https://github.com/JeffreyWay/laravel-mix/pull/3066

Duplicate of #3065

It be closed

Duplicate of #3065

It be closed

Yes but it has been fixed, but it is not released yet. So, you either have to wait for it to be released.
Or if you don't want to wait you can add the package from GitHub by adding
"laravel-mix": "https://github.com/JeffreyWay/laravel-mix.git",
to devDependencies to your package.json
or running
# Yarn 1
yarn add https://github.com/JeffreyWay/laravel-mix.git --dev
# Yarn 3
yarn add laravel-mix@https://github.com/JeffreyWay/laravel-mix.git --dev
# Npm 6
npm install https://github.com/JeffreyWay/laravel-mix.git --save-dev

Even after executing this command and adding the hot dependency in this way, the module does not work correctly, there is no live-reload. laravel-mix 5v worked great with this, now project development is much more complicated. I will return temporarily to the previous version, it is practically impossible to work with this

Duplicate of #3065

It be closed

Yes but it has been fixed, but it is not released yet. So, you either have to wait for it to be released.
Or if you don't want to wait you can add the package from GitHub by adding
"laravel-mix": "https://github.com/JeffreyWay/laravel-mix.git",
to devDependencies to your package.json
or running
# Yarn 1
yarn add https://github.com/JeffreyWay/laravel-mix.git --dev
# Yarn 3
yarn add laravel-mix@https://github.com/JeffreyWay/laravel-mix.git --dev
# Npm 6
npm install https://github.com/JeffreyWay/laravel-mix.git --save-dev

Even after executing this command and adding the hot dependency in this way, the module does not work correctly, there is no live-reload. laravel-mix 5v worked great with this, now project development is much more complicated. I will return temporarily to the previous version, it is practically impossible to work with this

For me, npm run hot works now. I just ran npm update to update all dependencies and now it works.


Service account policy bindings for logging and monitoring

Create the service accounts policy bindings for allowing logging from docker containers and monitorins

Done


Update dependencies and minor package.json tweaks

I can split this up if needed, just let me know.

Can you elaborate more on the reason behind these changes? Also, can you squash this down to 1 commit?


Remove pending block forking

Closes #938
Checklist

[x] Linked relevant issue
[x] Updated relevant documentation
[x] Added relevant tests
[x] Performed self-review of the code
[x] Added changes to CHANGELOG.md

Missing changes in fn block_id_to_string

I know, couldn't it stay that way, so it encodes string for each BlockId?

I know, couldn't it stay that way, so it encodes string for each BlockId?

I think removing it can help us get rid of random bugs since it should never appear there. Just use unreachable! imo


IE11, data-sizes and vw based units

vw based units in the a data-sizes attribute are ignored in IE11.
To Reproduce:
Here is a demo: https://jsfiddle.net/25cjfgbL/2/
While this demo does not make a lot of sense, it is the best way to reproduce the Bug.
What is the expected behavior
In IE11 I would expect both images to load the 20x20 source.

This is documented in the respimg polyfill plugin:

If data-srcset with width descriptors (w descriptor) are used either the data-sizes="auto" feature has to be used or the sizes value has to consist of just one source size value with the CSS px unit.


Added try-except

Added try-except so that it shows "Nothing playing at the moment" instead of crashing

Since there are try-excepts in song, artist functions anyways so there won't be need of them in get_info error handling

yes but it's still better to do it in the get_info functions for completeness


feat: add webrtc-direct support

WebRTC Direct is enabled by default in go-libp2p so this will be replaced by #45


Fix typos in UG

Codecov Report
Base: 46.01% // Head: 44.92% // Decreases project coverage by -1.09% :warning:

Coverage data is based on head (08a0ac6) compared to base (858d05c).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #121      +/-   ##
============================================
- Coverage     46.01%   44.92%   -1.10%
  Complexity      429      429
============================================
  Files           107      109       +2
  Lines          2134     2186      +52
  Branches        237      241       +4
============================================
  Hits            982      982
- Misses         1102     1154      +52
  Partials         50       50

Impacted Files
Coverage Δ

src/main/java/seedu/waddle/logic/PdfFieldInfo.java
0.00% <0.00%> (ø)

src/main/java/seedu/waddle/logic/PdfFiller.java
0.00% <0.00%> (ø)

...ava/seedu/waddle/logic/commands/ExportCommand.java
0.00% <0.00%> (ø)

src/main/java/seedu/waddle/model/item/Day.java
9.30% <0.00%> (-2.13%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Remove unneeded closing check

Turns out the check has not been needed since 2016.

Fixed @mcooley

@AtariDreams can we register for the events in XAML instead of in the .cs file? I think it would be better to register for the Closing events in the same place we register for the Closed events: here and here.

@mcooley Done!


[Bug]: Manifest.json 403 Forbidden

What happened?
Tried adding the app to homescreen with chrome which even supports the option for apps without a manifest.json. So it was weird to me that this wasn't available at all for your app (great app btw). Looked into the network panel and saw the manifest.json file being requested but the server was returning a 403. When I open the URL in a separate tab however the manifest loads fine.  Judging by the fact your app is cloudflare protected I'm willing to bet this a cloudflare config issue. Not a cloudflare user so I won't be much help there. Anyways thanks.
What browsers are you seeing the problem on?
No response
Steps to reproduce?
Issue can be reproduced by either visiting the application or simply sending a request to https://pseudo-flix.pro/assets/manifest-CuRP_CD7.json via postman or other similar HTTP client.
Other relevant information

Uh has to be smth with cf and cache, we will later remove the manifest and then favicon from waf


[Enhancement] Add Configuration for TOC helper to control header levels

Is your feature request related to a problem? Please describe.
The TOC shortcode plugin assumes a default configuration of 4 header levels.
Describe the solution you'd like
I would like a basic configuration option to set which header levels to apply to the TOC
Describe alternatives you've considered
Rework documentation to limit what headers are used, however this is less than ideal when using sub headings for clarity but not navigation
Additional context
Screenshot showing content with only h2 in the TOC

Your change has been included in version 1.12.0 and got released.


Compiling from source does not work

Also the git clone command is in SSH, should be it HTTPS.
I have OpenJDK version 17, maven version 3.9.6. Running on local machine on wsl2.
local:~/nf-test$ ls
nf-test
local:~/nf-test$ MVN=~/apache-maven-3.9.6/bin/mvn
local:~/nf-test$ $MVN install
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.068 s
[INFO] Finished at: 2024-01-15T11:09:50+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] The goal you specified requires a project to execute but there is no POM in this directory (local/nf-test). Please verify you invoked Maven from the correct directory. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MissingProjectException

My bad.

make sure you have nextflow installed and in PATH or ~/bin