I added A Content Table

For Viewers to access names easily, I made a contents table with each letter.
Thanks.

@CodingSpecies That's a nice idea. But it looks a bit uneven can we have something like below (more symmetric boxes)?

@CodingSpecies That's a nice idea. But it looks a bit uneven can we have something like below (more symmetric boxes)?

Sure. thanks @kaiwalyakoparkar

@kaiwalyakoparkar Done!

@Panquesito7 thank you

Due GitHub provides a table of contents I would suggest leaving the readme as it is

Due GitHub provides a table of contents I would suggest leaving the readme as it is

Not many people know about that, so we can probably let our users know in the readme. 🙂

Due GitHub provides a table of contents I would suggest leaving the readme as it is

@schmelto how can I make it possible for viewers to easily navigate through the alphabetical list?

@schmelto how can I make it possible for viewers to easily navigate through the alphabetical list?

puhh tough question. Don't know if this really a necessary thing to add in this repo due I think not a lot of people will go through the list. Due its only Hacktoberfest practice I think most people only add there GitHub handle to get started with the PR process of git/GitHub and it would not be necessary to go though the list.
If you want to search for your own name I think most folks would use str + f 😄
But all of this is only my opinion

👍🏽 Yes I agree thank you

What are the updates with this PR?

This PR should be good to go after @Panquesito7's requested changes

I have completed @kaiwalyakoparkar Thanks.

Thanks for contributing to this project!

OH this is an awesome idea 🔥 great collaboration everyone 💥


Add basic filter to ImagesTable (next to create button)

The images table will be replaced with the blueprints table. Filtering for the blueprints table has been defined by UX and will be implemented properly.


leftJoin against KeyProducer should support window on both streams

Right now it supports window on only one stream.
e.g. if x.leftJoin(y, buffer) then only events of y are kept for a window of time.
This is a problem when processing is needed to be done on only a part of payload data. Let's say X is a big thrift event, which wants an upper limit applied on only one field on it.
class X {
val id: Long
val charge: Int
...
}
Let's say we want to keep track of sum of charges per id and reduce it if needed to keep the maximum charge limited. e.g. if limit is 100 and current sum is at 99 and we get an event with charge of 2 we reduce it to 1. If current sum is already 100 then we reduce charge to 0 for all subsequent events.
The efficient way to do it would be to send only charge and id to a summer to apply the limits and join back with the original stream. But since the current join is windowed on only one stream there will be a race condition and we can fail to join.
We should support joins that are windowed on both streams.

I'm not super crazy about windows, but mostly because merging offline and online results seems like a challenge. If you have a clear implementation idea, I'm happy to hear it.
One problem with summingbird is that you have to pass the storage for such things (Buffer), because storm has no storage, nor do some other streaming systems.
That said, windows can be done by a special data type and using sumByKey with the correct Semigroup[V]. So, if we have a Window[V] that manages this, I think we can leverage the existing merging of offline and online.
I do think the race conditions in complex topologies is an issue. I think this could be solved with new APIs for sumByKey and write  For instance:
// write out, and get a way to read the store (service) and an event stream of changes
def sumByKeyEff(s: Store[K, V])(implicit s: Semigroup[V]): Effect[(Service[K, V], Producer[(K, (Option[V], V)))]

def writeEff[T](s: Sink[T]): Effect[Producer[T]]

Where Effect[T] is a monad like Execution[T] or Future[T]. This will allow us to make sure that effects (writing external to the system) in a way that we can be sure that one write happens before another read.
Planning this offline seems doable pretty easily. Online there can be real challenges since ordering the reads and writes is not trivial (also at Twitter data-rates, it might not always scale easily).


Add recommandations to README.md

These are just a couple - this PR is just the beginning, to have a place to add more as we think of them.

LGTM


[Feature Request]: Encrypt Passwords Before Storing Them

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
Hey @Trisha-tech In your website you are directly storing users password without encrypting it first.
This would an serious issue because users data is not secure.
anyone can see their passwords.
Solution
I can fix this issue by encrypting the password before storing it in database.
using Bcrypt, it will make your platform more secure.
Use Case
Encrypting Passwords
Benefits
It Will make the platform more secure
Add ScreenShots

Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

Hey @Trisha-tech i can help you to fix this issue and make your platform more secure, could you please assign this task to me

@iamsohelx bcrypt is already been used to hash the password. Check models/customerSchema.js pre method.


cleanup package

using MANIFEST.in to include less in the package.
excluding docs for now.

git history got messed up... squashing.


Reuse app fixture in tests

Hello!
This PR replaces the manual creation of Sanic app with a pytest fixture (similar to the one in the docs), which reduces the code duplication and makes the test suite more in line with the examples in the documentation.
Cheers

I think this is a positive change and would like to see it in 18.12 LTS. @ashleysommer and @yunstanford could you eyeball this and verify that I wouldn't be crazy for merging. I'm comfortable with the pass that @r0fls gave it, but I want to just be triple-sure before we do anything that is a hefty change.

@sjsadowski Yep, as long as all tests are still passing then I see this as a good change to have in the test suite.


Add scaling operations for batch matrices

This PR adds a batch::Diagonal matrix format, core and device kernels for the apply(MultiVector*, MultiVector*). This is useful when scaling matrices and vectors that are necessary in some applications.
This PR now only adds the kernels and free standing functions for two-sided scaling.
TODO

[x] Add scaling kernels for batched matrices
[x] Check docs
[x] Add in_place apply core function
[x] Add row, col scaling and update batch solvers to enable scaling.

format!

In the PR description you said that this PR only adds kernels and free-standing functions, but the scale_add and add_scaled_identity are member functions. Why are those members, but two_sided_scale not?

TBH, it seems like the scale_add and add_scaled_identity are not meant to be part of this PR, since the device kernels for those are not implemented.

Stale PR, superseded by #1527, but will leave the branch un-deleted to allow for testing.


Dynarray tests

(This PR is based on top of #462, which it depends on.)
The new module Dynarray has a rather tricky implementation as it is not designed for parallel use, but still strives to guarantee memory safety even in the event of such incorrect use. This implies a lot of subtle invariants to maintain. My local runs of this branch have exposed a bug in the initial implementation (https://github.com/ocaml/ocaml/pull/12885#discussion_r1568976695).

I just pushed a few changes, partly to address some of the red lights.
I still expect a 32-bit 0xdeadbeef out-of-range though.

Thanks for taking care of that!

I still expect a 32-bit 0xdeadbeef out-of-range though.

We should probably replace it with 0xcafe, or something.
Also, the Lin test was triggering segfaults, presumably due to a leftover “operation” fake which was doing some extremely unsafe things, probably to trigger exactly that, and should be removed. Sorry for leaving it in the PR, I just pushed a commit to remove it.

Remaining problems:

The STM tests fail as they are supposed to. Instead of agree_test_par and stress_test, we should have neg_agree_test_par and stress_test.
There seems to be some exceptions raised by computations in the model, which should not happen.

I don’t have the bandwidth to look at it today, but hopefully shortly.

When devising a system to maintain a pool of Dynarrays as my SUT, I have neglected an issue with shrinking.
Some commands cause a new Dynarray to be added to the pool and others take one or more Dynarrays as input. These Dynarray arguments are represented as list indices; when generating commands, care is taken to generate indices that are valid indices in the current list of arrays, given the previous commands.
But when shrinking, some of the commands are arbitrarily removed, which leads to some of these indices to become invalid at the moment of the command’s execution and causes unexpected exceptions.

I was a bit blocked by the shrinking issue and hadn’t thought of Util.protect as a solution.
Thanks for doing what I neglected to do! This looks great to me.

CI summary: all 33 workflows green.

CI summary for merge to main:

Bytecode 5.3 timed out due to excessive shrinking in STM Weak test parallel #498

Out of 34 workflows, 1 failed with a false alarm (timeout)


Clarify documentation on "engines" field in package.json

The docs say for engines:

An object containing at least the vscode key matching the versions of VS Code that the extension is compatible with. Cannot be *. For example: ^0.10.5 indicates compatibility with a minimum VS Code version of 0.10.5.

It's not clear to me what happens when you publish an update with an engines constraint that targets the next Code version (currently Insiders). That is, will this update be invisible for regular non-insider users and only the insider users will see it? The other scenario would be that non-insider users would see an update that they can't install.
Also, is it possible to release updates on two different streams, e.g. let's say 1.2.3 is the current non-insiders release to which I can publish updates like 1.2.4 while at the same time releasing a 1.3.0 version targeting insiders, again with updates for it, like 1.3.1.
I assume it all just works out but documenting that somewhere would help.

.... just found it: https://code.visualstudio.com/docs/extensions/publish-extension#_visual-studio-code-compatibility
So maybe add a link to that page from the engines docs.

This issue was moved to Microsoft/vscode-docs#1165


remove specific IDE m2e files

those files are specific to m2e they shouldn;t be stored in the Apache Maven sources
Following this checklist to help us incorporate your
contribution quickly and easily:

[ ] Make sure there is a JIRA issue filed
for the change (usually before you start working on it).  Trivial changes like typos do not
require a JIRA issue.  Your pull request should address just this issue, without
pulling in other changes.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Format the pull request title like [MRESOURCES-XXX] - Fixes bug in ApproximateQuantiles,
where you replace MRESOURCES-XXX with the appropriate JIRA issue. Best practice
is to use the JIRA issue title in the pull request title and in the first line of the
commit message.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Run mvn clean verify to make sure basic checks pass. A more thorough check will
be performed on your pull request automatically.
[ ] You have run the integration tests successfully (mvn -Prun-its clean verify).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

[ ] I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

[ ] In any other case, please file an Apache Individual Contributor License Agreement.

@alexsuter sorry for that but according to this comment https://github.com/apache/maven-resources-plugin/pull/40#pullrequestreview-1189572912 it shouldn’t have.


Send HarnessId in DataClient

The data client needs to contain HarnessId to register itself
Please add a meaningful description for your change here

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.

Run Java Precommit

Run Java Precommit


-[NSURL initFileURLWithPath:]: nil string parameter'

2015-03-31 15:49:47.786 HackerNews[95696:1478127] CLTilesManagerClient: initialize, sSharedTilesManagerClient
2015-03-31 15:49:47.786 HackerNews[95696:1478127] CLTilesManagerClient: init
2015-03-31 15:49:47.786 HackerNews[95696:1478127] CLTilesManagerClient: reconnecting, 0x7fd23152dbe0
RCTJSLog> "Running application "HackerNews" with appParams: {"rootTag":1,"initialProps":{}}. __DEV__ === true, development-level warning are ON, performance optimizations are OFF"
RCTJSLog> "Warning: Failed propType: Invalid prop `selected` of type `string` supplied to `TabBarItemIOS`, expected `boolean`. Check the render method of `HackerNews`."
2015-03-31 15:49:48.072 HackerNews[95696:1478127] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSURL initFileURLWithPath:]: nil string parameter'
*** First throw call stack:
(
    0   CoreFoundation                      0x00000001067c0a75 __exceptionPreprocess + 165
    1   libobjc.A.dylib                     0x0000000105880bb7 objc_exception_throw + 45
    2   CoreFoundation                      0x00000001067c09ad +[NSException raise:format:] + 205
    3   Foundation                          0x00000001053f584f -[NSURL(NSURL) initFileURLWithPath:] + 131
    4   HackerNews                          0x0000000104ece700 -[RCTVideo setSrc:] + 192
    5   CoreFoundation                      0x00000001066b85ec __invoking___ + 140
    6   CoreFoundation                      0x00000001066b8442 -[NSInvocation invoke] + 290
    7   CoreFoundation                      0x0000000106747636 -[NSInvocation invokeWithTarget:] + 54
    8   HackerNews                          0x0000000104eee3dd RCTSetProperty + 1277
    9   HackerNews                          0x0000000104eceea8 -[RCTVideoManager set_src:forView:withDefaultView:] + 136
    10  HackerNews                          0x0000000104f67d1a RCTCallPropertySetter + 266
    11  HackerNews                          0x0000000104f67bd6 __RCTSetViewProps_block_invoke + 198
    12  CoreFoundation                      0x00000001067bfdcc ____NSDictionaryEnumerate_block_invoke421 + 28
    13  CoreFoundation                      0x00000001066c0bf0 CFBasicHashApply + 128
    14  CoreFoundation                      0x00000001066fa0bb __NSDictionaryEnumerate + 619
    15  HackerNews                          0x0000000104f5d603 RCTSetViewProps + 339
    16  HackerNews                          0x0000000104f5d3f5 __65-[RCTUIManager createAndRegisterViewWithReactTag:viewName:props:]_block_invoke + 1109
    17  HackerNews                          0x0000000104f55f7c __27-[RCTUIManager addUIBlock:]_block_invoke + 124
    18  HackerNews                          0x0000000104f5f046 __29-[RCTUIManager flushUIBlocks]_block_invoke + 342
    19  libdispatch.dylib                   0x00000001096ab186 _dispatch_call_block_and_release + 12
    20  libdispatch.dylib                   0x00000001096ca614 _dispatch_client_callout + 8
    21  libdispatch.dylib                   0x00000001096b2a1c _dispatch_main_queue_callback_4CF + 1664
    22  CoreFoundation                      0x0000000106728749 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
    23  CoreFoundation                      0x00000001066eb62b __CFRunLoopRun + 2043
    24  CoreFoundation                      0x00000001066eabc6 CFRunLoopRunSpecific + 470
    25  GraphicsServices                    0x000000010a1aba58 GSEventRunModal + 161
    26  UIKit                               0x00000001081ea580 UIApplicationMain + 1282
    27  HackerNews                          0x0000000104ece4d3 main + 115
    28  libdyld.dylib                       0x00000001096ff145 start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)

And, my background.mp4 was placed in root directory of my project.

@developerworks - make sure that it's in XCode and in the Build Phases > Copy Bundle Resources list.

Fixed, thank you.

I was also facing the same issue but in my case I was passing the uri from url.. and the issue was in one of the video link had a space in the beginning of the video url " https://vimeo.com/546795671" & it was causing it to crash.

I was also facing the same issue but in my case I was passing the source={{uri: "url"}} from database which had video links.. and the issue was in one of the video link which had a space in the beginning of the video url, something like this " https://vimeo.com/546795671" & it was causing it to crash.

Similar problem, my url started with Http. Changed to http and it works. Thanks.


Make logo

Looking for logo designs for energized-id-django
Dimensions 800x800
Ideas I have had:
minimalist
using bootstrap primary blue color
somehow related to cardholders or identity (no fingerprints though)

Done


Form tag inside a modal breaks css

I try to implement a form inside a modal
http://jsfiddle.net/nynevi/efp8z6Ln/227/
but putting a form tag inside a modal breaks header content and action classes
http://jsfiddle.net/nynevi/efp8z6Ln/228/

Just add form class to your form and some CSS on form header http://jsfiddle.net/Greggg/efp8z6Ln/232/

I am embarresed :< Thanks @ZeGregg

Hi all,
I think that form tag inside a modal really breaks css.
Please see my example here:
http://jsfiddle.net/boblin/kshybf3L/7/
If you remove ** ** and  tags, modal looks OK.
Is it bug?


Convert bulk images to a single pdf

Is your feature request related to a problem? Please describe.
I want to share multiple images from my file browser app to this app and convert all images in sequence to a single pdf.

It's possible

Use Images to Pdf tool inside PDF tools


Beast CMakeLists.txt MSVC link fail

@ 6fab138150e6f61736a158c34c043a13d18e2f2a
I'm not 100% sure link_directories should go away.  I had a link fail on MSVC 15.2 because system  has several other libraries it tries to link in. Normally this isn't a problem if you download and install the boost libraries but since I built the boost libraries on a separate drive the link step didn't know where to find things like libboost_date_time.lib. The quick solution:
link_directories(${Boost_LIBRARY_DIR_RELEASE})
link_directories(${Boost_LIBRARY_DIR_DEBUG})

Why both? They might be disjoint directories.
Additionally this could potentially be fixed within find_package but that might be outside the scope of Beast :wink:

By the way the code I removed was wrong:
link_directories(${Boost_LIBRARY_DIR})

It should be Boost_LIBRARY_DIRS

I'm adding

This results in the following Additional Library Directories:
$(BOOST_ROOT)/stage/lib
$(BOOST_ROOT)/stage/lib/$(Configuration)

That should cover the case you mentioned

This was merged to version 64
https://github.com/vinniefalco/Beast/commit/8449697a2c225688a9cf8e4fcf01206d56903b85
If its still a problem feel free to re-open the issue or to create a new one, thanks!


Add examples directory

I've created an examples directory, and provided a few league examples.

My sincere apologies, I have continuously forgotten your PR, or purposely delayed due to uncertain decisions about whether adding an examples directory is beneficial. Today I have thoroughly revised the content of the PR, the decision is as follows: While it does allow developers to have a quick start, it will likely push them to use this package in one or a few specific ways. The documentation currently provides enough guidelines while not encouraging specific project structure or code style.


Lit and inventory refactor

this PR adds Lit to SkyCrypt and uses it to rework the inventory.
adds a map from itemId to item is stored to make accessing items by Id easy
the grid of inventory items is now not processed on the server at all
the main inventory grid and the backpack preview in the lore now share code
more code is loaded asynchronously
code is easier to read

it's bean a while sense I worked on this so it might not be entirely done.
I think this is ready to merge but please test this toughly before merging

Tested with multiple profiles and everything looks good.
I noticed you didn't use scoped styles, any reason for that? Should we not use that in the future?

I noticed you didn't use scoped styles (inside the component .ts), any reason for that? Should we not use that in the future?

In the future scoped styles and shadow root would be great but converting an existing element to shatterroot can be difficult.
The main reason I didn't use shadow root Is because the items in the inventory share a lot of CSS with the items in the weapons/armor/pets sections. I had originally wanted to also convert the items in those other sections to use the rich-item element but I have decided That is outside the scope of this PR.

tested, looks good :thumbsup:


Scope and time scheduling of the meeting for presentation of DynPy environment to scholars of InterCars foundation (issue #975 related)

The goal is to schedule the meeting in Teams calendar on 2024.10.13 at 12:00.

Meeting has been scheduled.

Meeting has been scheduled.


Enable Hardware Acceleration of Chroot?

name: xenial
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/xenial...
crouton: version 1-20180718130616~master:5d4c3014
release: xenial
architecture: amd64
xmethod: xorg
targets: xfce,xorg,keyboard,touch
host: version 10718.88.2 (Official Build) stable-channel cyan
kernel: Linux localhost 3.18.0-17866-g4dfef3905aba #1 SMP PREEMPT Wed Aug 22 02:27:12 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
freon: yes
Not unmounting /mnt/stateful_partition/crouton/chroots/xenial as another instance is using it.

Please describe your issue:
I need to enable hardware acceleration to load an android emulator on my chroot. How do I do this?

Your Acer Chromebook R11 (cyan) uses a Braswell X86_64 SoC so when using the 'xorg' xmethod that you have already installed per above hardware acceleration will be implemented without user intervention.


Admission web hook will check if the pod is already processed

Description
This patch adds additional checks if the webhook should be applied. Specifically, it evaluates if there is already an "NSC" initCOntainer injected.
Motivation and Context

How Has This Been Tested?

[X] Covered by existing integration testing
[ ] Added integration testing to cover
[ ] Tested locally
[ ] Have not tested

Types of changes

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

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

@platoff what do you think here?


[Feature] Program behaviour for system tray icon and task bar

I suggested in another thread the concept of having options to configure how the program behaves when minimized and with the system tray icon.
Options to configure this would be like this:

Minimize to task bar (this should be normal/default window behaviour)
Minimize to task bar and show system tray icon at all times
Minimize to system tray and show system tray icon at all times

I'm pretty sure these three cover all situations.
Thread where this originated: https://github.com/stax76/staxrip/issues/179#issuecomment-303756889

Thinking about it, I try to avoid adding features that are not very useful, which behavior would you like to use and why?

I like to have it simple and not confusing.
If the program minimizes, I usually expect it to minimize to the taskbar like every program usually does.
When the program goes elsewhere it's because there's some added feature that makes it more complex and less simple.
Suggesting these features is only about giving more control to the user on how StaxRip operates; configuring it to work how the user wants it to work. Leaving the settings on a specified default should make it less confusing and less noticeable of the change to those that don't want it changed.

I've added a setting to minimize to tray instead of the task bar, it's not enabled by default and will be available in the next build.

Cool. I'll test it when I dl it.

It's online now, I hope it works.


Release Image

This is the next issue after #107 (or #108 if we want to go that route). The idea is that when a PR gets merged to master it should trigger building a release quality image. The image needs to:

Be as minimal/optimized as possible.
Install ParallelZone in a way that can be used downstream.
Publish the image (probably however we end up publishing the base image in NWChemEx-Project/.github#81)

The image which results from this build will become the "base image" for downstream repositories, such as PluginPlay. From PluginPlay's perspective this new base image will serve the same role as the .github base image did for ParallelZone.

I am thinking about how to keep the balance of image consistency (one image update triggers all image updates) and CI efficiency (keep images fixed). Now I think maybe a good way is to build every repo only with the STABLE release images of other repos, and only update all stable images when necessary (e. g., in the case of a major release). With this design, the daily CI is very simple and fast (load the building image containing everything needed including the compiled libraries of other repos, and then compile and test the repo). We need only one workflow to update all images, and this workflow can even be manually triggered since it will not be run very frequently. A failed workflow run to update all images will release some code integration issue (some repo breaks other repos), but will NOT affect the daily CI.
Any comments?

I feel like we need to break this problem down and try to build up to a solution. So at this point I am going to suggest:

Add two workflows to .github which build the base images for ParallelZone.

One workflow should be GCC based, the other clang based.
The images should only contain the dependencies for ParallelZone, don't worry about other repos.

Add two workflows (one for GCC the other for clang) to ParallelZone which use the base images from the previous step to build ParallelZone and run the tests.
Add two different workflows to ParallelZone which build release images (one GCC-based, one clang-based) which trigger when master is updated.
Repeat step 2, but for PluginPlay and using ParallelZone's release images as the base images
Repeat step 3, but for PluginPlay

Each of the above steps can be a separate PR and it should be possible to accomplish those PRs without breaking the current CI pipeline. That's because repos which depend on PZ or PluginPlay should still be able to build since their CI includes steps for building PZ/PluginPlay (implicitly via the CMakeLists.txt). I would recommend copy/pasting the workflows into the various repos and then modifying them as needed; don't try to have a master workflow at this stage.

I feel like we need to break this problem down and try to build up to a solution. So at this point I am going to suggest:
1. Add two workflows to .github which build the base images for ParallelZone.

* One workflow should be GCC based, the other clang based.

* The images should only contain the dependencies for ParallelZone, don't worry about other repos.

2. Add two workflows (one for GCC the other for clang) to ParallelZone which use the base images from the previous step to build ParallelZone and run the tests.

3. Add two different workflows to ParallelZone which build release images (one GCC-based, one clang-based) which trigger when master is updated.

4. Repeat step 2, but for PluginPlay and using ParallelZone's release images as the base images

5. Repeat step 3, but for PluginPlay

Each of the above steps can be a separate PR and it should be possible to accomplish those PRs without breaking the current CI pipeline. That's because repos which depend on PZ or PluginPlay should still be able to build since their CI includes steps for building PZ/PluginPlay (implicitly via the CMakeLists.txt). I would recommend copy/pasting the workflows into the various repos and then modifying them as needed; don't try to have a master workflow at this stage.

Sever questions:

For the base images with GCC and clang, do you mean the dependencies are compiled using GCC and clang, respectively?
I think the release images do not contain the dependencies that necessary to build the repo, so they are different from the base (building) images, right?.

I'm also planning to update the CI repo by repo with a leap-frog strategy.

If you build the dependency then yes it should be built with the respective compiler. If you can just pull the dependency from a package manager it doesn't matter. The GCC vs. clang distinction applies more to what compiler will be used to build our repos.
ParallelZone's release image needs to include the shared libraries it linked to, otherwise when PluginPlay tries to link to Parallelzone you're going to get linker errors. I don't fully follow your second point. The base image for ParallelZone will not be the same as the base image for PluginPlay. ParallelZone's base image will have spdlog, MPI, and MADNESS. Keeping things simple for now, PluginPlay's release image will just be ParallelZone's release image (let PluginPlay build utilities and libfort).

I don't understand what updating by a leap-frog means in this case. The update process should be a breadth-first traversal of a tree.

If you build the dependency then yes it should be built with the respective compiler. If you can just pull the dependency from a package manager it doesn't matter. The GCC vs. clang distinction applies more to what compiler will be used to build our repos.

ParallelZone's release image needs to include the shared libraries it linked to, otherwise when PluginPlay tries to link to Parallelzone you're going to get linker errors. I don't fully follow your second point. The base image for ParallelZone will not be the same as the base image for PluginPlay. ParallelZone's base image will have spdlog, MPI, and MADNESS. Keeping things simple for now, PluginPlay's release image will just be ParallelZone's release image (let PluginPlay build utilities and libfort).

I don't understand what updating by a leap-frog means in this case. The update process should be a breadth-first traversal of a tree.

Yes, the release image of ParallelZone would have the shared libraries it linked to, such as MADNESS, spdlog, cereral, etc, but it won't have the building tools such as gcc and cmake. In this sense I can use the image to build ParallelZone as a base to build other repos (with other tools/packages added when necessary), not the release image of ParallelZone.  The release image of ParallelZone, which contains the shared libraries (ParallelZone, MADNESS, spdlog, cereral, etc), can be added as a layer into the building image of PluginPlay, since PluginPlay depends on ParallelZone.
It looks that we have different definitions for the building and release images, which is fine in my eyes. I just want to get a clear picture.
When I said "leap-frog" I just meant I will try to update the CI workflows repo by repo, not to update them in one run.

Now that Docker allows image composition here's how I would do this.

Here each box is an independent image we need to maintain. Diamonds are literal libraries which are included in the image (libraries are not shown in all cases). The nesting shows the images they derive from. So:

MADNESS image derives from the MPI image,
ParallelZone base image derives from the MADNESS and spdlog images,
ParallelZone release derives from ParallelZone base
PluginPlay base image derives from ParallelZone base, utilities, and libfort images
PluginPlay release derives from PluginPlay base

The innermost images are parameterized on the compiler type (GCC or clang), the compiler version, the CMake version, and the version of the namesake library. Derived images inherit the parameters of their inner images. When building say PluginPlay base, you must then specify:

compiler type
compiler version
cmake version
utilities version
libfort version
parallelzone version
spdlog version
MADNESS version
MPI version

Then:

the compiler type, compiler verions, cmake version, parallelzone version, MADNESS version, MPI version, and spdlog version will be used to select the ParallelZone Release image
the compiler type, compiler version, cmake version, and utilities version parameters will then be used to select the appropriate utilities image, and
the compiler type, compiler versions, cmake version, and libfort version will then be used to select the appropriate libfort image

In practice, we have pinned the version of all the dependencies (and the versions live in the NWXCMake repo) so we do not have a combinatorial explosion. So the only parameters we'll change with any frequency are the compiler type, compiler version, and cmake version.

Now that Docker allows image composition here's how I would do this.

Here each box is an independent image we need to maintain. Diamonds are literal libraries which are included in the image (libraries are not shown in all cases). The nesting shows the images they derive from. So:
* MADNESS image derives from the MPI image,

* ParallelZone base image derives from the MADNESS and spdlog images,

* ParallelZone release derives from ParallelZone base

* PluginPlay base image derives from ParallelZone base, utilities, and libfort images

* PluginPlay release derives from PluginPlay base

The innermost images are parameterized on the compiler type (GCC or clang), the compiler version, the CMake version, and the version of the namesake library. Derived images inherit the parameters of their inner images. When building say PluginPlay base, you must then specify:
* compiler type

* compiler version

* cmake version

* utilities version

* libfort version

* parallelzone version

* spdlog version

* MADNESS version

* MPI version

Then:
* the compiler type, compiler verions, cmake version, parallelzone version, MADNESS version, MPI version, and spdlog version will be used to select the ParallelZone Release image

* the compiler type, compiler version, cmake version, and utilities version parameters will then be used to select the appropriate utilities image, and

* the compiler type, compiler versions, cmake version, and libfort version will then be used to select the appropriate libfort image

In practice, we have pinned the version of all the dependencies (and the versions live in the NWXCMake repo) so we do not have a combinatorial explosion. So the only parameters we'll change with any frequency are the compiler type, compiler version, and cmake version.

Ok, now I understand. In your design, base image = dependencies, and release image = base + compiled repo.

@ryanmrichard What gcc/g++ and clang versions should we cover in the building images? Now the building images are based on Ubuntu 20.04, so the gcc/g++ version no. ranges from 8 to 11 (correct?).

@yzhang-23 just worry about a single version for now, but parameterize the CI on the version so we can change it later.

I have redesigned the docker image building strategy:  the building image of a repo used to have everything including the released dependent repos. However, as we want to build and test the repo both with gcc and clang, with the original building image setting, we have to store two different building images for each repo: one for gcc, and the other for clang. This could result in storage space issue. I think Ryan's suggestion of constructing a base image containing only the building tools but not the dependent repos is good. With such a base image, I can load the release images compiled with gcc or clang during the process of building the repo. In this way we don't need two different building images for gcc and clang. I'm trying to applying this new design into the workflows. Hope the testing won't take too much time. I will give updates.

I have a workflow in hand to parse the file in NWXCMake to obtain the package version info, but I would postpone its check-in until I find a good way to conveniently handle all versioned packages. Now I still have some minor issues, such as cannot separate the installation of gcc and clang, the exact version no. of some packages are missing, etc.

I wanted to run jobs within containers from images built on-the-fly (not pushed into some registries), but it turned out to be impossible. Please see the discussions at the GitHub Actions forum.
I think what I need here is a docker container action in order to build/test our repos with temporary docker images not being pushed into some registry. I have written a toy container action to test this idea and it worked. I will convert our existing action for building/testing into a container action and see how it works.


php artisan ide-helper:all command for all helpers

Summary
Let's create a new command that calls all four commands in one run this can be
php artisan ide-helper:all

This would be really, really helpful.

This would be really, really helpful.


Add a weighted pmf udf

--- work in progress ---

Thank you for submitting this pull request, however I do not see a valid CLA on file for you. Before we can merge this request please visit https://yahoocla.herokuapp.com/ and agree to the terms. Thanks! :smile:


the paths and maps generatedt are different from paper

Thank you for your excellent work on LIO-SAM!
I run the sample datasets following the tips, and  I have change nothing except that parameters in config/params.yaml are adapted to the dataset. But the results including maps and paths are different from the paper. what's the reason? @TixiaoShan

There are many reasons that may cause this, for example, using different computing hardware, optimization returns different results.


[Ask] Migration Database

Dear Parse.com
We are on progress for migrating parse server to our local server backend(ruby) and we recode again to make the new API service.
i have a question for this statement
" If you do not migrate your database by April 28, we will assume you do not consider the app's migration to be a high priority. Traffic to your app may be de-prioritized as we shift our focus to serving production apps that are being migrated according to our recommended schedule. "
in this statement have no detailing about the cons about migrating database. can you explain about pro and const if we don't migrate our database in our own server ? after April 28, 2016 what happen with our database in your server ? slowly performance ? or what ?
Thank you

Please see #1145 for the official answer

From my experience:
Pro migrating:

Improved database latency if using dedicated cluster
Can use database metrics, logs, tools
Can use mongo shell for administrative purposes, e.g. populate a missing default value to documents
Not going to suffer additional Parse platform performance issues after April 28th
Required step for migrating from Parse.com

Cons:

Additional cost
Have to manage own indexes
Have to manage database servers or use managed solution such as mLab
Dashboard import and export may not work (although seem temperamental on non-migrated apps)

Hope this helps. I'm really happy we migrated but if you're unsure then you can set up a test Parse app to check it out.

Thanks @steven-supersolid this is indeed a duplicate of #1145. You can also see the migration guide.


Add Ultragreen to celo cli

Description
Adding ultragreen to the celo cli
Tested
Todo unit tests
Related issues

Fixes https://github.com/celo-org/celo-monorepo/issues/10326

@0xarthurxyz: Todo

[ ] Find out what this PR aims to achieve (ask @montera82)


Doc cleanup

Review it

Review required

@mraunak I see this was opened, but closed soon after. Is the branch ready to be reveiwed?

@pgleeson I got an error while running it on my system, error: no module named h5py, . Once it is fixed, I will bring the changes to doc_cleanup branch it would be ready for review.


Allow users to indent bullet lists within a numbered list

Issue:
Users should be able to indent a bulleted list (unordered list) within a numbered (ordered) list.  Markdown specifies that 2 spaces beyond the previous level will indent the list https://spec.commonmark.org/0.28/#list-items. Note that  typing more than 4 spaces beyond the initial mark of the previous level will create a code block.
The proposed solution is to disable preview mode editing.
DoD:
typing 2 spaces beyond the initiating marker of the previous level will indent the unordered list.
Details:

v 1.2.0 allows for indented bulleted lists within a numbered list using 4 spaces before the *
v 1.2.1 ignores the 4 spaces, creates a separate bulleted list, and restarts the numbering.
This appears to be a regression due to the changes in #613
NOTE: 5 spaces will indent the nested list in v1.2.1

v1.2.0

v 1.2.1

@cckozie can you confirm that you're seeing this?

test

So does this fail #613?

one suggestion:
Currently: We DIVIDE BLOCKS based on the markdown content

this behavior ends up breaking the MD rendering rules (e.g., nested lists, sequential ordered lists, etc)
since each block is rendered as a separate document, without the context of the larger file

Suggested: DIVIDE BLOCKS after rendering.  That is, divide based on HTML:

possibly divide on the  paragraph tag? other tags?
this means the whole markdown document is rendered as a whole

@birchamp  provided some videos comparing ZULIP markdown preview
Birch — 10/29/2021
We we need to meet with the  Content team to confirm before we do that.
I can't get it to behave is that because the source side is restricting it?
Birch — 10/29/2021
check this video of what I'm seeing. https://drive.google.com/file/d/19FQa6JCGkoHJ1zovA7nbRXcxq4LRpsKA/view?usp=sharing
Birch — 10/29/2021
I'm wondering what would happen if we ignored the whitespace like zulip does - https://drive.google.com/file/d/1iG9P55GQWI8AdFur5RvNEkblTcQ8Hlad/view?usp=sharing

@jincypjose
the problem here is:

yes, zulip "IGNORES" MD paragraphs in PREVIEW mode
but notice that zulip "PRESERVES" the users original markdown (SINCE THEY CAN'T EDIT IN PREVIEW MODE 🤯🤯)
BUT our current implementations of "EDIT MODE" (tC Create) have TWO WAY conversion ( HTML <--> MD)
THEN in our apps, we would be altering the user data (SAVED back to DCS)

that's OK we just want to discuss first

the way we choose to render the HTML
--> will change the content of the MARKDOWN

@birchamp just confirming we are moving forward testing this approach:

remove the extra invalid linebreaks (INVALID markdown)
NOTE: this edit will be reflected in the users' data file

thanks

@birchamp discuss with stakeholders disabling preview editing. Discuss normalizing all line breaks in MD.

@jincypjose The stakeholders have said that we can turn off editing in Preview mode.

@elsylambert can you retest this now that Preview mode editing has been turned off?


Rename mr -> merge-request

lab mr was originally added because cobra does not implicitly
support commands with -'s in them and it was believed that hub pr
and hub pull-request were aliases. It is now understood that these
are seperate commands. This change corrects the mistake by renaming the
mr command.

Hub's pull-request is being deprecated. https://github.com/github/hub/issues/1536
Definitely want to support mr as described for pr in the linked issue. For completeness it's probably best to also support merge-request since hub intends to keep their equivalent around.

I would say creating an issue for creating the pr/mr sub commands would be good. Linking that issue.
I vote for quickly adding the mr create subcommand asap so typing merge-request does not become too much of a habit.


Investigate Arxiv API for potential Plugin

Output: identification of Arxiv API and signals we can supply to GPT

Once Pranav has accepted GH invite, can add him here


Add a easy way to create simple topologySpreadConstraints and PodDisruptionBudget

implements #191
Signed-off-by: UMEZAWA Takeshi<EMAIL_ADDRESS>

Thanks for contribution!

By the way, there is much duplicate code not only in this PR but also in the originally existing code. I think it is bug-prone and should be solved. However, I'm not sure that it should be done now because it could lead to a breaking change in Golang-level API, depending on how to solve it.

By the way, there is much duplicate code not only in this PR but also in the originally existing code. I think it is bug-prone and should be solved. However, I'm not sure that it should be done now because it could lead to a breaking change in Golang-level API, depending on how to solve it.

Yep, i've refactored it a bit.  For now, i prefer to make small patches with improvements - remove duplicate code and unify some parts.
All breaking changes can be done before v1.0 release, if its needed.


Upgrade calico-vxlan to v3.26.1

Which issue(s) this PR fixes:
Fixes #2192
Xref #2782
What type of PR is this?
/kind bug
Does this PR introduce a user-facing change? Then add your Release Note here:

Upgrade calico-vxlan to v3.26.1

Documentation:

NONE

/test pull-kubeone-e2e-aws-default-install-containerd-v1.26.6

damnit terraform, can't properly delete nested objects
/retest


added support for ui-router-1.0.0.rc API changes

I added support to use the new $transitions service mechanism for angular ui-router 1.0.  A little refactoring for DRY as well.  Please let me know if there is anything required to accept the PR.

Also, I get the following error when it tries to redirect using $location.path:
TransitionRejection(type: 3, message: The transition has been aborted, detail: Hook aborted transition)
I don't think the redirect can use $location.path from a transition hook

I put these suggestions into a pull request on @justinwatkins branch

when it will be updated because it does not work with ui-router 1.x?
thanks!

@justinwatkins thanks for your PR :)
I can merge this in as soon as we resolve the items that @kylemantesso commented on.
Thanks!

Rebased the fine work done by @kylemantesso and @justinwatkins into https://github.com/auth0/angular-jwt/pull/152


cloudatcost is not a recognized provider

require 'fog'
compute = Fog::Compute.new(
  provider: 'CloudAtCost',
  api_key: 'coolapikey',
  email<EMAIL_ADDRESS>)

produces:
ArgumentError: cloudatcost is not a recognized provider
from /path_to_rvm_ruby/gems/fog-core-1.35.0/lib/fog/core/services_mixin.rb:12:in `new'

ruby 2.1.8p440 (2015-12-16 revision 53160) [x86_64-linux]
installed fog, fog-cloudatcost fresh from gems

@geemus Could you please release a new version of fog-core to fix the issue.Thanks

Yeah, I can try to get to that soon, sorry for the delay. Could you add me to the gem owners on rubygems.org? That way I can do updates just-in-case? Thanks!

@geemus Done I have added you. :+1:

Thanks!

Should be good to go now, just released fog-core 1.36.0. Thanks!

@geemus Thanks a lot :+1:

@voobscout Please update your gemfile to use the latest version of the gem, its should work now

@h0lyalg0rithm @geemus Thanks! It works now.


Change default connection.pool.local.size

Hi Team,
Astra is using DSE which is based on TPC, a lower value of the local connection pool will cause more issues that benefit, can we bump this value to a higher say 8, and add it clearly in documentation to configure it correctly?
    { "name": "astra.cql.driver-config.advanced.connection.pool.local.size",
      "type": "java.lang.Integer",
      "description":"The number of connections in the pool.",
      "defaultValue": "1" },

The default pool.local.size = 1 works in almost all cases. Can you provide a bit more context, like what problem are you trying to solve? It help us understand if we have a bit more background. Cheers!

Any update @bhisey  ? Thank you

After tests with internal team 1 is the recommended value, you can still update it in your own application.conf


1st performance pass

Identify suboptimal resource usage and try to improve it

Vectorizing what can be vectorized ist the first bullet point on the agenda.

It seems like closing the issue by post-commit comment did not work, so here it is.
While optimization is still not stellar and better ways of doing calculations can certainly be found, the runtime of the test example (generating a single image generated by standard microscopy and comparing it with a STED-enabled one) has for the combination of parameters used been reduced from 48 seconds to 65 milliseconds, an improvement by a factor of some 700. Good enough for now.


Document TDD+IOSP for contributors

In our contributor's guide, we should really mention that we want them to work on issues (if none exist for the feature you want to contribute, create one), use test drive development where possible, and use integration operation separation principle (among others) to decide whether TDD is possible.

I've integrated this into the contributor's guide. Is this enough or do we want to add another document?


boost on xenial is too old

We currently need a more recent version of boost in the SuperBuild than what is provided on Ubuntu xenial (although this isn't required for STIR).
I tried
sudo add-apt-repository ppa:boost-latest/ppa
sudo apt-get update

However, that gives me an error that an URL isn't available. The ppa seems to say it's no longer maintained.
Looks like I can use
sudo add-apt-repository ppa:mhier/libboost-latest

but that's untrusted.

I guess I'll just use USE_SYSTEM_BOOST=OFF for now


Added covid19za_provincial_cumulative_timeline_recoveries.csv & fixed incorrect data in covid19za_timeline_testing.csv

Added covid19za_provincial_cumulative_timeline_recoveries.csv
covid19za_provincial_cumulative_timeline_recoveries.csv contains the recoveries per province per day. However note there are gaps in this data either because they have not been released by government or I have not been able to find the data. All this data was taken from NICD infographics via their their twitter.
Fixed incorrect data in covid19za_timeline_testing.csv
In covid19za_timeline_testing.csv incorrect recoveries data was fixed for 23, 24 ,25 and 28 April.
23, 24 & 25 April had recoveries recorded as 1437 rather than 1473. The sources for this are here: 23, 24 & 25.
28 April had recoveries recorded as 2073 rather than 1473 with it being authenticated by this source.
Additional
Note: The two 'Update covid19za_timeline_testing.csv' commits should be ignored as these were just me fixing an issue from my side where my repo didn't merge correctly and thus deleted some data which I then added back.

The commits pertaining to covid19za_timeline_summary_data.csv should be ignored as they do not pertain to this pull request as this file was deleted.


Add tests

Should have
lines = cd_stats[:total_lines_of_code].to_f
expectations = cd_stats[:total_test_expectations].to_f
 0.045 < (expectations / lines)

Add VERY simple tests just to confirm that the model API is working. Simply set the variable and then check that it has been set.

Fixed by 791d74bb9b1a53ef501b38257f270b469bd1c9fd


The builder depends on internal use of handlebars that will be removed in Storybook 8.4

For Storybook 8.4 we're doing a lot of internal cleanup and optimisation (see https://github.com/storybookjs/storybook/issues/29038).
As part of my work to replace the express dev-server with polka, I wanted to try out if that worked with RSBuild, because the server is exposed to the builders via the start() function. However I never got that far, because RSBuild fails with the following error in the latest alpha releases of Storybook 8.4.0:
=> Failed to build the preview
TypeError: (0 , import_common.handlebars) is not a function
    at getVirtualModules (./node_modules/storybook-builder-rsbuild/dist/index.js:195:66)
    at async iframe_rsbuild_config_default (./node_modules/storybook-builder-rsbuild/dist/index.js:371:72)
    at async rsbuild (./node_modules/storybook-builder-rsbuild/dist/index.js:656:23)
    at async Module.start (./node_modules/storybook-builder-rsbuild/dist/index.js:691:18)
    at async storybookDevServer (./node_modules/@storybook/core/dist/core-server/index.cjs:37195:11)
    at async buildOrThrow (./node_modules/@storybook/core/dist/core-server/index.cjs:36205:12)
    at async buildDevStandalone (./node_modules/@storybook/core/dist/core-server/index.cjs:38385:78)
    at async withTelemetry (./node_modules/@storybook/core/dist/core-server/index.cjs:36950:12)
    at async dev (./node_modules/@storybook/core/dist/cli/bin/index.cjs:2877:3)
    at async r.<anonymous> (./node_modules/@storybook/core/dist/cli/bin/index.cjs:2929:74)

This is because we've removed handlebars from the Storybook core/common exports, as it was unnecessary. It was never intended to be used as a public API, but it's fair that you perhaps just copied the logic from the Webpack builder.
You should be able to to the same migration that @ndelangen we did for the Webpack builder in https://github.com/storybookjs/storybook/pull/29208. High-level, that PR:

converts the handlebar template to a regular JS file
uses '{{someVariable}}' for stuff that needs replacement
Uses regular replaceAll() calls to do the variable replacements.

Thanks @JReinhold for the kind remind. I'll do the same migration quickly.


Fix #33 Add Excel export.

Export all Excel-Sheet into a separate directory as csv-files.

wow. that was quick. Thanx!
btw: if you would like to write a blog post about how you wrote this task - a PR to https://github.com/rdmueller/rdmueller.github.io/tree/master/_posts would be the right place :-)

...and btw: if you would like to document your task:
https://github.com/rdmueller/docToolchain/tree/master/src/docs/manual :-)


Figure out optimal limits

There are a lot of limits, and some overlap. Figure out what the best options are. Maybe create a set of rules like the join_overlap_limit must be <= the join_ttl.

These limits may change based on the number of streams being monitored. The only way to calibrate seems to be manually. Possibly have limits based on another limit that is proportional to number of streams being monitored.

Should definitely have a separate config file with all these limits defined in one place


GHCJS doesn't like GHC.Event

When trying to compile base-noprelude with GHCJS, it fails on the GHC.Event reexport. Is it possible to disable it for ghcjs?

I just came across this as well.

I also noticed the same behaviour. Can @ondrap 's PR be merged or anything else is required for pushing this forward?


Make i18next a dependency

Is there any reason why i18next is not a dependency in package.json?

As we do not use i18next directly in this module - it does not depend on i18next - it's more a plugin to i18next and a middleware to express (express is no dependency neither)

Got it, Thank you.


Added Timothy Clark to Contributors list

I have added my name to the list of contributors, and have corrected a couple of minor mistakes in title case for some of the other names in the list.

I'm quite elated about your pull request. I wanna evolve this project to addresses various problems faced by first-time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a pull request and learned that I merged it?
We’ve recently added Facebook share and tweet feature to our web app. Could you please go to https://roshanjossey.github.io/first-contributions/#social-share and share your first contribution to open source?
Also, check out projects with easy issues while you’re there.


Custom domain changes

Update the top level categories to match the sections on the left.
Correct the domain to hugo.azurecitadel.com.

Fixed by commit e96b54c552219094b8005407e6c309e97c5a4582


Update for Stylelint 7.6.0?

My stylelint-config-standard v15 depends on stylelint 7.6.0.
Any chance of getting gulp-styelint updated to use this new version (7.6.0)?
Thanks.

It looks like @greenkeeperio-bot missed the stylelint v7.6.0 release

That said, gulp-stylelint should support stylelint v7.6.0 perfectly as is, it has a semantic version dependency of "stylelint": "^7.4.2",, 7.6.0 is covered by ^7.4.2.
You check semver coverage here as an FYI https://semver.npmjs.com
@danimalweb Running npm update should get things sorted for you 😄

Thanks. I thought that would be the case, but removing node_modules, cleaning npm cache and re-installing / updating the issue continues.
It's must be a conflict with stylelint-config-standard then. For now, I've added  "stylelint": "^7.6.0" directly into my package.json.to reslove the issue.
Cheers.

Updated and published as v3.5.0 to npm. Sorry for delays... life's busy.


Invalid prop: tooltipOfferLabel

What happened?
Added in bf523e0e1522615dc211343801678025e597b2ff and 99672bcd1c8cc2d32b3995b0cd0863fcf71ed8e6

Please reproduce in steps

[ ] As logged user open some NFT detail on Basilisk
[ ] e.g (http://localhost:9090/bsx/gallery/3195582573-1)

Expected Behavior
Console should be without warnings :)
What browsers are you seeing the problem on?
Chrome
Are you logged in?
Yes
At which address did you encounter bug?
No response
Screenshots
~
Relevant log output
[Vue warn]: Invalid prop: type check failed for prop "tooltipOfferLabel". Expected String, got Object

found in

---> <ActionList> at components/rmrk/Gallery/Item/ActionList.vue
       <AvailableActions> at components/bsx/Gallery/Item/AvailableActions.vue
         <BaseGalleryItem> at components/shared/gallery/BaseGalleryItem.vue
           <GalleryItem> at components/bsx/Gallery/Item/GalleryItem.vue
             <GalleryItemPage> at pages/bsx/gallery/_id.vue
               <Nuxt>
                 <Layouts/default.vue> at layouts/default.vue
                   <Root>

Payment link for reward
https://kodadot.xyz/transfer/?target=<My_Kusama_Address_check_https://github.com/kodadot/nft-gallery/blob/main/CONTRIBUTING.md#creating-your-ksm-address>
Code of Conduct

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

Possible fix in #3324


How to use it with GitHub actions?

I checked https://gha-cache-server.falcondev.io, which only describes how to deploy, but does not mention any usage with GitHub actions. I have a macOS locally as a self-hosted runner. I wonder if this library can solve the problem of pointing the cache server to the self-built gha-cache-server.

Since we are patching the runner binary directly, there is no need to use a custom action. Just use the default actions/cache.

Thx.


Change the links in WP posts from GitLab to GitHub

There are several posts in WP that have GitLab code links, we have to change them all.

Also related to #9


Promote to 1.17.1-sr-beta1-snapshot

What does this PR do?
A brief description of the change being made with this pull request.
Motivation
What inspired you to submit this pull request?
Additional Notes
Anything else we should know when reviewing?
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Make sure you discussed the feature or bugfix with the maintaining team in an Issue
[ ] Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

Codecov Report

Merging #1238 (c969062) into session-replay-snapshots-release-branch (a97ee9c) will increase coverage by 0.01%.
The diff coverage is n/a.

@@                             Coverage Diff                             @@
##           session-replay-snapshots-release-branch    #1238      +/-   ##
===========================================================================
+ Coverage                                    82.80%   82.81%   +0.01%
===========================================================================
  Files                                          358      358
  Lines                                        12629    12629
  Branches                                      2101     2101
===========================================================================
+ Hits                                         10457    10458       +1
- Misses                                        1524     1525       +1
+ Partials                                       648      646       -2

Impacted Files
Coverage Δ

...g/internal/domain/event/DdSpanToSpanEventMapper.kt
95.83% <0.00%> (-4.17%)
:arrow_down:

...in/com/datadog/android/log/internal/LogsFeature.kt
84.62% <0.00%> (-1.54%)
:arrow_down:

...ain/java/com/datadog/opentracing/PendingTrace.java
59.48% <0.00%> (-0.86%)
:arrow_down:

.../kotlin/com/datadog/android/v2/core/DatadogCore.kt
85.08% <0.00%> (-0.81%)
:arrow_down:

...rc/main/java/com/datadog/opentracing/DDTracer.java
55.65% <0.00%> (-0.42%)
:arrow_down:

...src/main/kotlin/com/datadog/android/DatadogSite.kt
86.67% <0.00%> (ø)

...ndroid/telemetry/internal/TelemetryEventHandler.kt
74.22% <0.00%> (ø)

.../datadog/android/sessionreplay/utils/ThemeUtils.kt
83.33% <0.00%> (ø)

.../android/rum/internal/domain/scope/RumViewScope.kt
95.39% <0.00%> (+0.35%)
:arrow_up:

.../android/rum/internal/monitor/DatadogRumMonitor.kt
91.35% <0.00%> (+0.54%)
:arrow_up:

... and 4 more


[Potential Bug]: sanity check addState in handling modulos

Triton python code
No response
Triton IR
No response
Crash log
No response
Additional information
My understanding of the modulo definition is that mod happens last in the address generation. E.g., for a 1D tensor of pointers, the addresses it generates are: (offsets[0] + i * strides[0]) % parent_sizes[0] for each i. Does that sound right to you?
If so, my question is regarding the handling of modulo in addState. Should we check that only one of the operands has modulo to be set? It looks like we perform related check in visitOperandAdd here, but the check is limited to rank-1 tensors only. Can you please explain the reasoning?
If my understanding is correct, I believe the pattern in this LIT test  should fail because we are adding a scalar (which is represented by an offset in dimension 0) to %arg9 / %15, which has modulo in dimension 0.

Happy new year Haishan! It's good you're lending another pair of eyes at this code again as I'm still not happy with the amount of complexity that the feature has :)

If so, my question is regarding the handling of modulo in addState.
Should we check that only one of the operands has modulo to be set?

I agree. We have an assert here in addState:
https://github.com/microsoft/triton-shared/blob/3230526f95f7e73f1885b9c9d008b1aec535f2d2/lib/Analysis/PtrAnalysis.cpp#L102C1-L105C1
My intention is this should assert that for every dimension, only one of the operands has a modulo expression. This should match your expectation I think.

It looks like we perform related check in visitOperandAdd here, but the check is limited to rank-1 tensors only.
Can you please explain the reasoning?

I think the assert here might look a little misleading on first glance:
if ((lhsState.getRank() == 1 && lhsState.hasModulo()) ||
      (rhsState.getRank() == 1 && rhsState.hasModulo())) {
    assert(0 && "Current do not support this pattern: a + arange(0, K) % M");
}

This reads as, if we're of rank 1, and if we already have an existing modulo expression in either lhs or rhs, then it means we must be dealing with something resembling the pattern a + (arange(0, K) % M) (here lhs is a and rhs is arange(0, K) % M which has a modulo).
The pattern we're looking for like you said is (offsets[0] + i * strides[0]) % parent_sizes[0] for each i -- the add is between offsets[0] and i * strides[0] which does not any modulo expression.
Any other cases, including when we're of rank 2, we just skip over the assert and let addState handle verifying that there are only at most one modulo expression in each dimension.

Happy New Year to you too Nhat! Thank you for your detailed answer!

Any other cases, including when we're of rank 2, we just skip over the assert and let addState handle verifying that there are only at most one modulo expression in each dimension.

Ah thanks. That makes sense to me. I missed that we also have a check in addState.

So the addptr we're interested in is...

Sorry I should have been more clear. The addptr I am referring to is:
%33 = tt.addptr %arg9, %30 : tensor<4x4x!tt.ptr<f32>>, tensor<4x4xi32>

Where %30 is a scalar, which I believe is represented as an offset on dim0. Should the analysis fail on this pattern?

Sorry I should have been more clear. The addptr I am referring to is:
%33 = tt.addptr %arg9, %30 : tensor<4x4x!tt.ptr<f32>>, tensor<4x4xi32>
Where %30 is a scalar, which I believe is represented as an offset on dim0. Should the analysis fail on this pattern?

Ah no, the analysis should not fail on this pattern. %30 is a scalar and does not have any modulo expression involved, so as per the current code, we can take the modulo state directly from %arg9 during addState.
Reading the IR is hard, here's the rough triton code that I used to generate this lit test, hopefully it will make more sense:
@triton.jit
def wrap_stacked_masked_loop(
    a_ptr, c_ptr, M, N, stride_am, stride_an, stride_cm, stride_cn
):
    BLOCK_SIZE_K = 4
    offs_am = (2 + tl.arange(0, 4)) % M
    offs_an = 3 + tl.arange(0, 4)
    a_ptrs = a_ptr + (offs_am[:, None] * stride_am + offs_an[None, :] * stride_an)

    offs_cm = tl.arange(0, 4)
    offs_cn = tl.arange(0, 4)
    c_ptrs = c_ptr + stride_cm * offs_cm[:, None] + stride_cn * offs_cn[None, :]

    for k in range(0, 2):
        a = tl.load(a_ptrs)
        tl.store(c_ptrs, a)
        a_ptrs += BLOCK_SIZE_K * stride_an
        c_ptrs += BLOCK_SIZE_K * stride_an

Since this is a "stacked wraparound" case, here's the visualization for the above code:
                     cols
             wrappedAroundOff
    --------------*------------*-------------------------------------------
    |        d2   |            |                         |            |   |
    |             |------------|                         |------------|   |
rows|                                                                     |
    |                                                                     |
    |           targetOffset                                              |
    |             *------------|                         *------------|   |
    |             |            |                         |            |   |
    |         d1  |            |   we move alomg this    |            |   |
    |             |            |          dim            |            |   |
    |             | clampedOff |  -------------------->  |            |   |
    --------------*--------------------------------------------------------
                  |  overflow  |
                  *-------------
               nextOff

The triton modulo patterns that we have seen always take the modulo on one dimension and move along the other dimension.
So in %33 = tt.addptr %arg9, %30 : tensor<4x4x!tt.ptr<f32>>, tensor<4x4xi32>, because %30 is just a scalar with no modulo information (but %arg9 does have it), we can reuse %arg9's info and be able to generate the same "stacked wraparound" offsets for the next blocks.
I hope this makes more sense, otherwise we can discuss this offline too.

Thank you Nhat. Your explanation makes sense to me.
The only thing I want to make sure is that in your diagram, you are showing that the addptr performed in creating %33 moves the tensor horizontally, but in the IR %30 is a scalar and afaik the offset is recorded in dim0 (since at compiler level we can't tell which dimension the scalar value is incrementing, I believe the current code defaults to using dim0). Would that mean we are shifting vertically?

I think there are a few key points that contribute to how this works, we are actually shifting horizontally as illustrated in the diagram even though the offset is recorded in dim0. "Stacked wraparound" always shifts horizontally, and "side-by-side wraparound" always shifts vertically.

when we rewrite the addptr, we determine which scenario (stacked or side-by-side) we are dealing with:

https://github.com/microsoft/triton-shared/blob/3230526f95f7e73f1885b9c9d008b1aec535f2d2/lib/Analysis/PtrAnalysis.cpp#L784C1-L793C1

then in both

createStackedCastOps
https://github.com/microsoft/triton-shared/blob/3230526f95f7e73f1885b9c9d008b1aec535f2d2/lib/Analysis/PtrAnalysis.cpp#L148
and createSideBySideCastOps
https://github.com/microsoft/triton-shared/blob/3230526f95f7e73f1885b9c9d008b1aec535f2d2/lib/Analysis/PtrAnalysis.cpp#L241
the formulas that we use to derive the wraparound point only depend on a single pointer offset (i.e.: all dimensional offsets are already collapsed, so it does not matter if we default to dim0 for scalars:
  Value targetOffset =
      ofrToIndexValue(accumulateTargetOffset(loc, rewriter), loc, rewriter);

This is also the reason why we have the following limitation:
  //////////////////////////////////////////////////////////////////////////////
  //
  // Handling side-by-side wraparound
  //
  // Note: We do not support cases where the target has already overflown the
  // number of columns! This is because in PtrAnalysis, the offset has already
  // been collapsed into a single dimension, so it is ambiguous to determine
  // whether the offset actually overflows or just refers to an element on the
  // subsequent rows.
  //
  // Same limitations apply to the stacked wraparound case.
  //
  //////////////////////////////////////////////////////////////////////////////

So as long as the triton user writes the correct code to move the blocks horizontally, our modulo code will also move horizontally.
This whole wraparound shenanigans all boil down to:

process the pointer offsets as we normally would
while visiting the expression tree, we keep track of the modulo amount in each dimension

Then, assuming the triton user writes the expected pattern that we support, in createStackedCastOps or createSideBySideCastOps, we generate the wraparound using the final pointer offset and the recorded modulo amount.

Thank you so much Nhat! This really clarifies!

We expect "stacked wraparound" to always shift horizontally and "side-by-side wraparound" to always shift vertically.

That's what I am missing! The code that you pointed at is doing exactly what you are saying.
Tbh I think this is also making me feel a little uneasy, because there is not going to be an easy way for us to detect if our assumption is true, even if we keep offset for each dimension (because of these spatting of constant into scalars) . E.g., in the LIT test we are discussing, if the user for some reason wanted shift vertically, our address calculation will produce wrong results. This is not a sane code though as you mentioned but nonetheless.
I just posted the proposal (#81) about teasing apart the current triton-to-linalg btw. Please feel free to take a look. I will probably take the same approach as you in dealing with this pattern there (and maybe add some warning). Any feedback from you is of course greatly appreciated!
Let me close this issue. Thank you again for explaining this to me!

I'm glad the explanations help :) I agree the handling for modulo isn't great. We have a lot of assumptions baked in, and the code itself isn't simple to understand nor works for all cases either. Hopefully with the community we can improve this more.


[TimexExpression] Option to start week on sunday

Hi,
We are using LUIS for one of our customers in UAE where the week starts on Sunday.
Currently when we say "for the last 2 weeks" the phrase is resolved for 2 weeks back, but started on Monday.
We would like to be able to configure the starting day of the week (set to Sunday)
Thanks!

Hi @kirsanau,
in the current design, the process for such cases would be to get the response from LUIS and re-resolve it using the TimexExpression lib and pass the week definition as context to get a new resolution according to it.
The lib exists in the lab and also as packages, but this specific feature is not yet implemented in it.
We can prioritize it and include it in release vNext+1. Would that address your need?

Hi @tellarin,
Thanks for response. Not sure if I got your idea right - do you propose

send the expression to Luis
get the resolved value
manually check if it corresponds to this case (because other luis responses are fine we rely on them)
if not week related - proceed normal
if week related - re-resolve week issues with lib and new week definition

is kind of work around, but not really what we are looking for. the response of lib and luis differs, and we already have done some extra after-processing to unify it in bot framework.
Ideally it should be param of luis.

The recognizers project is separate from LUIS and we can't commit to changes on their side. In this case you'd need to reach out to their team and perhaps they can expose customization of the resolution, which would basically be the same process, but on their service.
If you can share the differences you mentioned in a separate Issue or maybe in a GitHub Discussion that would be very helpful.
There should be no difference between a LUIS-based resolution and a non-customized result from the timexresolver lib.

+1 for the feature request.

@tellarin , the current Recognizer follows ISO8601 standard that starts a week from Monday. However, in some countries (including US, Canada), a week starts from Sunday. It would be great if the Recognizer can be configurable about this.


Adding limit for amount of pending activties in mutable state.

What changed?
Added limit to how many pending activties mutable state can have.

Why?
We need to limit mutable state size because otherwise we encounter timeouts when fetching mutable state from database.

How did you test it?
Tested locally + unit test.

Potential risks
If we have some clients that are above the threshold (default value of pending activities is 1024) their workflows would get stuck. In order to avoid this I added warn and error level logging and added feature flag for throwing the error so first we can see how many users will be affected.

Release notes

Documentation Changes

Pull Request Test Coverage Report for Build 0182ca84-ffb8-469c-9d2b-7ef6fc61bee6

22 of 32 (68.75%)  changed or added relevant lines in 2 files are covered.
92 unchanged lines in 12 files lost coverage.
Overall coverage increased (+0.1%) to 57.792%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

service/history/config/config.go
9
11
81.82%

service/history/execution/mutable_state_builder.go
13
21
61.9%

Files with Coverage Reduction
New Missed Lines
%

service/history/config/config.go
1
88.19%

common/persistence/historyManager.go
2
66.67%

common/persistence/nosql/nosqlplugin/cassandra/workflow.go
3
57.89%

common/task/fifoTaskScheduler.go
3
84.54%

service/matching/taskListManager.go
3
75.87%

common/persistence/serialization/parser.go
4
65.41%

common/persistence/serialization/thrift_decoder.go
4
61.22%

service/history/task/transfer_standby_task_executor.go
4
86.26%

common/persistence/sql/workflowStateMaps.go
12
85.34%

common/persistence/serialization/getters.go
16
61.37%

Totals

Change from base Build 0182aec6-8c47-4120-bfac-66e4850118c5:
0.1%

Covered Lines:
84213

Relevant Lines:
145718

💛  - Coveralls


Dw/serializer page additional test

The encoder parameters should be different. It seems that the go library doesn't use the same default than the rust. However, the decoding is correct, which is what we expect.

@dannywillems this PR is 2 months old, is it still WIP?

Let's close it. I couldn't find the right parameters in the libflate library. Not critical to have.


NANs in lf_matrix

Hey guys,
lf_matrix=CM.lf_matrix.todense()
I printed out some rows of the labeling function matrix and some of the entries are NANs instead of 1,0,-1..; not sure why this is happening?
for example:
lf_matrix[1005]:
matrix([[  0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,
0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,
0.,   0.,   0.,   0.,   0.,   1.,   0.,   0.,   0.,   0.,   0.,
1.,   1.,   0.,   0.,   0.,   1.,   0.,   0.,   0.,   0.,   1.,
0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,   0.,  nan,
nan,  nan,  nan,  nan]])

Was this in one of the example notebooks or using a custom LF?

Hey Henry,
I just fixed this. I realized my labeling functions were only returning -1 if I met the check conditions and were not returning 0 otherwise.

Great!


Make a release v0.2.0

Following migration from your account to fogfactory, go fails to update import when working with release v0.1.0 since the go.mod import doesn't point to the right github URL.
For now, I'm using a workaround by importing a specific commit hash from the default branch.
By making a release v0.2.0, I'll be able to use a more "stable" version, get automatic updates from renovate / dependabot and have go get -u ./... finding updates correctly.
I would also recommend, since the repository only changes with dependencies updates to have an auto releasing (to avoid the latest tag to potentially use vulnerable versions).
Impacted project: https://github.com/kilianpaquier/gitlab-storage-cleaner

I will make a 0.1.1 and see if I can automate patch release whenever a dependency PR lands.

Hi, thanks !


Bug patches and log tweaks

This PR:

Fixes the allapers setting in Stages 4+ which was broken by my previous fix for datetime.
Fixes Stage 6 for lsq runs from Stage 5 (lack of error bars previously broke this)
Fixes broken allanplot in Stage 5 if sigma clipping was done in Stage 4
Does instart-1 once per file, rather than everywhere instart is used
Slightly tweaks S3+ log formatting to look a bit nicer

Codecov Report

Merging #370 (2cf1204) into main (303f4bf) will increase coverage by 0.04%.
The diff coverage is 75.94%.

@@            Coverage Diff             @@
##             main     #370      +/-   ##
==========================================
+ Coverage   56.98%   57.03%   +0.04%
==========================================
  Files          67       67
  Lines        6710     6717       +7
==========================================
+ Hits         3824     3831       +7
  Misses       2886     2886

Impacted Files
Coverage Δ

src/eureka/S3_data_reduction/bright2flux.py
72.44% <0.00%> (ø)

src/eureka/lib/clipping.py
49.01% <0.00%> (ø)

src/eureka/S3_data_reduction/nirspec.py
50.53% <36.36%> (ø)

src/eureka/lib/util.py
82.24% <50.00%> (ø)

src/eureka/S5_lightcurve_fitting/fitters.py
63.89% <60.00%> (ø)

src/eureka/S5_lightcurve_fitting/lightcurve.py
86.90% <66.66%> (-0.16%)
:arrow_down:

src/eureka/S3_data_reduction/nircam.py
97.61% <80.00%> (ø)

src/eureka/S3_data_reduction/s3_reduce.py
91.23% <83.33%> (+0.04%)
:arrow_up:

src/eureka/S3_data_reduction/miri.py
64.77% <85.71%> (ø)

src/eureka/S6_planet_spectra/s6_spectra.py
81.99% <90.90%> (-0.09%)
:arrow_down:

... and 6 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 303f4bf...2cf1204. Read the comment docs.


RR7 -useQueryState() yields  Error: useNavigate() may be used only in the context of a  component.

Context
What's your version of nuqs?
"nuqs": "2.3.0-beta.2",

What framework are you using?

✅ React Router

Which version of your framework are you using?
    "@react-router/node": "^7.1.1",
    "@react-router/serve": "^7.1.1",
    "react-router": "^7.1.1"
    "@react-router/dev": "^7.1.1",

Description
Error: useNavigate() may be used only in the context of a  component. This comes from use of useQueryState.
Reproduction
https://github.com/ZipBrandon/rr7-nuqs
Example: Steps to reproduce the behavior:

npm i && npm run dev
Open the browser and get met with the error (which comes from use of useQueryState in welcome.tsx.

Thanks for the repro! It's weird because it's the exact same setup that I have in the e2e tests for RRv7, and I don't see this message there.
I'll take a closer look tonight.

I followed your instructions, and I cannot reproduce the error:

@franky47 Ahh, I'm using Node v22.12.0.  I installed Node 20 and it works.  Node 22+ is broken.  It seems this is upstream https://github.com/remix-run/react-router/issues/12475 .  I installed Node v22.9.0 as in the reporter and it works as expected.

Confirmed, I was running Node.js 22.11.0, which works. Switching to 22.12.0 shows the error message.
Going to close this since this is an upstream issue in React Router, thanks for figuring it out!


PromiseKit + Swift 3 + Xcode 8

Xcode 8 now requires Swift 2.3/3.0
@mxcl can't contribute to the project as far as I understand. Is anyone out there actively working on the minor transition to 2.3 or the somewhat more major transition to 3.0? I would offer to help myself if I felt more confident about PromiseKit and Swift's internals. 😰
I've been trying to build with @TheArtOfEngineering's 3.0 branch but think it may be out of date syntactically at this point?

There will be a branch provided asap.

@warpling That is certainly possible. I was working off of a Swift 3.0 development branch prior to the Preview 1 release. I would be willing to work on a Swift 3.0 transition if I can steal away some time.

@TheArtOfEngineering That'd be great! If the only thing in that branch needing a refresh is the syntax I can try to take a stab at it, but as mentioned I unfortunately haven't kept up with Swift much at all.

I have a minimal changes branch for Swift 3.0 incoming. Better updates to follow.

@nathanhosselton eagerly looking forward to it :)

Up at https://github.com/mxcl/PromiseKit/tree/4.0.0-beta1

Fantastic! Installing…

Hitting some build issues in NSURLConnection+Promise.swift
Did you use any special config in your podfile?
I'm currently using:
post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|

      # Turn off code signing (is this a bad thing?)
      config.build_settings['EXPANDED_CODE_SIGN_IDENTITY'] = ""
      config.build_settings['CODE_SIGNING_REQUIRED'] = "NO"
      config.build_settings['CODE_SIGNING_ALLOWED'] = "NO"

      # (May be able to remove eventually: https://github.com/CocoaPods/CocoaPods/issues/5521)
      config.build_settings['SWIFT_VERSION'] = "3.0"

      config.build_settings['CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES'] = 'YES'
    end
  end
end

What are the build errors?

Guessing it's the symptom of something else?

Yes unfortunately our dependencies need updated as well. So those categories/extensions which depend on third party libraries (such as NSURLConnection/Session) will not compile for now. OMG is ours and so that will be updated next, but the other two are beyond our control. Such is the nature of these things.

Got it. What do you think would be the easiest way to get PromiseKit compiling in Xcode 8 so I can work on a project? Should I try to make a 2.3 branch from the 2.2 minimal changes branch?

You can remove those categories. They are unnecessary for core PK.

Cool, that's what I was just looking into :)
What would be the best way to do that? Fork and remove them entirely?

Actually I was wrong. This is something I overlooked. Apologies. I will get it updates ASAP.

Updated and pushed. Try it now @warpling.

It compiles!! Thank you so much @nathanhosselton 😊
Just to confirm for future readers, there currently is no Swift 2.3 branch right?

Not yet. Hopefully soon. Not really sure what Apple is planning with 2.3 vs 3.0 in terms of Xcode 8 GM. If both are available and non "beta" at that point in time then 2.3 support will probably be merged in for the final PMK 3.x release, with Swift 3.0 support rolled into the PMK 4.0 official release at the same time.

Sounds like a plan!
For what it's worth, when I tried doing a conversion to 2.3 I'm pretty sure Xcode 8 told me that swift 2.3 was supported but would be deprecated in the future (insinuating Xcode 9?).

Ya, at WWDC they informed us Xcode 8 will support both Swift 2 and 3.

There is now a swift-2.3 branch which should compile.

Ideally PMK4 would support both with #if. Pragmatically, I think it would make the code unmaintainable.

Sorry for the dumb question, I haven't used PromiseKit in Swift yet, but is there any particular reason why the CorePromise module is not written in Objective-C for maximum compatibility, except strongly typed promises?

Many Swift types cannot be represented by id so it would be impossible to use those types in Swift if the core was ObjC. If you need a pure ObjC version of PromiseKit we still maintain version 1.

New branch up with changes for Xcode 8 beta 2: https://github.com/mxcl/PromiseKit/tree/4.0.0-beta2

@nathanhosselton you're awesome. Downloading the new beta now; just came here to check ;)


Update python doc

Update doc on flake8 to add pep8-naming and flake8-docstrings
Addresses #451.

@TessFerrandez Please merge it once you think it's ready. I don't have "write access" to merge pull request.

@TessFerrandez Please merge it once you think it's ready. I don't have "write access" to merge pull request.


added experimental backtrace API

Scope & Purpose
Experimental backtrace API for the threads in an arangod process.
By sending the arangod process a SIGUSR1 signal, it will make all its threads log a backtrace. It does so by enumerating the list of current threads via reading the fds in /proc/<pid>/task and using the tgkill syscall to deliver a SIGUSR2 signal to each thread. When a thread receives a SIGUSR2 signal, it will log its own backtrace to the log.
This functionality is currently only available on Linux. it is highly experimental and may not work in some environments (e.g. libmusl builds).

[ ] :hankey: Bugfix
[x] :pizza: New feature
[ ] :fire: Performance improvement
[ ] :hammer: Refactoring/simplification

Checklist

[ ] Tests

[ ] Regression tests
[ ] C++ Unit tests
[ ] integration tests
[ ] resilience tests

[ ] :book: CHANGELOG entry made
[ ] :books: documentation written (release notes, API changes, ...)
[ ] Backports

[ ] Backport for 3.11: -
[ ] Backport for 3.10: -
[ ] Backport for 3.9: -

Related Information

[ ] Docs PR:
[ ] Enterprise PR:
[ ] GitHub issue / Jira ticket:
[ ] Design document:

Closing this PR in favor of proper safer tools such as eu-stack.


Negative token-aware values

We need to support negative token aware values for numerical scales, such as space and size.
Repro: https://codesandbox.io/s/stitches-negative-token-aware-values-ifun5?file=/src/App.tsx

Aha! This is actually impossible with Typescript. You can not dynamically add keys to an object and expect them to be typed. They have to be explicitly set. But would argue that it does not take much time adding the negatives by hand? Like its config, not something you would do often? 😄
Or could expose a function for non Typescript users:
{
  tokens: {
    space: withNegatives({
      "1": "1rem"
    }) // { "-1": "-1rem", "1": "1rem" }
  }
}

Good point @christianalfoni
I don't mind both tbh. I think the only place where this would bug me is if I was modifying my scales.
maybe we could implement withNegativeValues internally so that js users who don't care about this could work on it without importing any functions

😓 😂
Typescript users:
They'll understand why its not possible to dynamically add keys to the scale. If they want the autocomplete experience, they'll be happy to simply add a negative scale. Easy enough. Requires good documentation.
Non-typescript users:
They'll probably expect negative values to just work. They wouldn't get autocomplete anyway, right? (maybe with intelisense?) But If we can make them work, I think that's what matters - even if there's no typing.
Negative Function:
I think we can offer this as a helper. No harm doing so, and seems like a simple enough thing to implement. @christianalfoni and @hadihallak keep me same here in regards to effort please
CSS Calc:
This was a super common technique used back in SASS days. Every one seemed pretty happy with it... haha
margin: 'calc(2 * -1)'

☝ where 2 is space.2. That would mean parsing the string, looking for tokens. I think some of this is already happening in #81 Again, @christianalfoni and @hadihallak please keep me sane.

yeah the lookup isn't an issue, I think the issue is that we can't do this while also offering typescript-based autocomplete

Understood.
So to offer better TS lookups, there are 2 options:

manually add negative scale
use a negative function

Everything else still works, but without the lookups

While working on moving this issue forward with Colm we uncovered two major issues:

Numeric values already mean something in cssinjs libraries and react (5 === '5px'). So we have to respect that convention.
Line-height supports unitless values, so we can't mess with that.

we're gonna rework how tokens get applied to CSS values so that tokens are required to have a prefix (TBD later during implementation) which in turn should simplify some of the parsing required for things like box-shadow but we'd lose some native typescript autocomplete so we'd need to handle that via plugins later.

Numeric values already mean something in cssinjs libraries and react (5 === '5px').

I don't see what's the major issue with this. Is it that we don't convert unitless numbers to px? Can you explain?

Hello! I'm not sure in which version happened, but I was able to do:
space: {
  '-md': '-16px',
  '-sm': '-8px',
  '-xs': '-4px',
  xs: '4px',
  sm: '8px',
  md: '16px',
}

and now it doesn't work, it looks like extra - are removed from the keys when converted to CSS variables, it also happened with the colors, they used to be blue-400 and now they appear as blue500.
Is this a bug? Or is intentional?
Right now I'm using _ as a workaround but it looks pretty weird 😂

@rubenmoya Thanks for reporting this.
Yeah this is related to a change we did before to remove non-allowed characters from tokens names. look like the - is being removed there by a mistake.
negative breakpoints the way you defined them should work and will be handled as part of this issue.


PSI-PROF weekly forecast

This is an updated version of this week's forecast with the correct origin_date and filename date.

thanks, the data was looked okay after the validation was successful, then is gonna be merged


Add ReaderUnarchiver interface and provide implementations

This commit adds a new ReaderUnarchive interface, which supports
performing an Unarchive operation from an io.Reader with a provided
size.
Fixes #150
Addresses #131

Will call out the following:

Not sure if ReaderUnarchiver and ReaderUnarchive are the best interface/function names here -- tried to match the existing style
If ImplicitTopLevelFolder is set to true, these implementations will fully read the reader bytes into memory first, which is not very memory-efficient. However, this is explicitly called out in the documentation, and not sure that this workflow is very common
If ImplicitTopLevelFolder is set to true, the implicit top-level folder is hard-coded to be named "archive" -- the file logic bases the name on the input filename, but there's no such analog when using an input reader

This is somewhat related to #131 -- as a follow-on, I'd like to add a parallel interface/functions for writing an archive to an io.Writer, so the eventual naming there should likely be consistent (for example, WriterArchiver and WriterArchive?).

@mholt Is this something you would consider merging?

Thank you for this! Sorry I never got back to this, it's been a crazy year.
This PR will be superseded by #302, which is a complete rewrite of archiver that has stream-oriented APIs. I think you'll like it. Let me know if you have any feedback! Really appreciate your contribution.


versions for deps

with poetry, for example:
typer = {extras = ["all"], version = "^0.7.0"}
it forces the version range of typer from 0.7.0 to 0.8.0, which is very limited, it would be nice to change it to <=1.0.0, same thing for other deps in the pyproject.toml file

It is recommended to use >=0.12.3 for the typer version because the latest version of fastapi depends on fastapi-cli


[Feature Request] hide app in recent app

Thanks for the great app again~
I used this app daily almost from day one~
May need a feature to hide this app in recent app list.
A new switch could be added to toggle this feature.
Because sometimes when I on default sms app and use full screen gesture by swipe right in the bottom, since this app is most recent one, it will automatically switch to default sms app again.
Thanks

I also have this problem occasionally, it is related to switching to SMS app by clicking the history record or notification.
But now I can't reproduce it, can you show me the steps to reproduce it?

Yes, I also saw this issue when I was on a third app.
When click login with sms, then new sms comes in. I click the notification
after that it will open default sms app.
then if you want switch back to third app with gesture, it will always switch back to default sms app since our app is on the most recent.
I see  some othet apps have feature to hide themself in the recent app list.

Fixed in the action build: https://github.com/aj3423/SpamBlocker/actions/runs/10306155341
There won't be ghost process when launched from clicking the notification anymore, and it doesn't affect the normal usage, no need for a new option.

Fixed in the action build: https://github.com/aj3423/SpamBlocker/actions/runs/10306155341
There won't be ghost process anymore when launched from clicking the notification, and it doesn't affect the normal usage, no need for a new option.

Perfect! I had this problem a few months but I wonder if most people use it


feat(sp): StepCircuitExt -> StepFoldingCircuit

Motivation
We want the ability to use StepCircuitExt as StepCircuit, to do this we need to move from the trait model to the wrapper-struct model. Motivated by comments in #145 from @chaosma
Overview

Big diff because moving StepCircuitExt into new module, but important to overview new design
StepCircuitExt -> StepFoldingCircuit struct
impl StepCircuit for StepFoldingCircuit
rm X0 & X1 from output, because of that (now we'll calc them off-circuit, WIP)
within the public parameters now plonk structure from step circuit counts only inside digest using the anchored generic

This modification among other things prevents me from finishing IVC (using the version from drafts) until it is closed #154, because I remove instance out from result

Let me know if you plan to delay it in future PRs.

https://github.com/snarkify/sirius/issues/153


Add start countroller unit test for launching on Linux

Codecov Report

Merging #617 into master will increase coverage by 0.27%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #617      +/-   ##
==========================================
+ Coverage   88.28%   88.56%   +0.27%
==========================================
  Files          27       27
  Lines        2459     2588     +129
  Branches      217      217
==========================================
+ Hits         2171     2292     +121
- Misses        288      296       +8

Impacted Files
Coverage Δ

browser/model/hyperv.js
92.68% <0%> (-2.19%)
:x:

browser/directives/breadcrumb.js
10% <0%> (-1.12%)
:x:

browser/services/request.js
20% <0%> (-0.84%)
:x:

browser/services/platform.js
86.39% <0%> (-0.38%)
:x:

browser/model/virtualbox.js
71.75% <0%> (-0.03%)
:x:

browser/model/cdk.js
100% <0%> (ø)
:white_check_mark:

browser/pages/location/controller.js
100% <0%> (ø)
:white_check_mark:

browser/model/cygwin.js
100% <0%> (ø)
:white_check_mark:

browser/model/helpers/installer.js
100% <0%> (ø)
:white_check_mark:

browser/services/data.js
100% <0%> (ø)
:white_check_mark:

... and 15 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 a71e334...891f3a5. Read the comment docs.


Sample video

Hi author,
Please tell me how to download the sample video, thanks.
BR.
star

The video link is updated in the Readme.