Access to fetch at 'http://localhost:7071/api/etc.' from origin 'vscode-webview://4idqakvcb etc.' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Describe the Bug with repro steps

Open a LogicApps Standard workspace that was previously working.
Run the debug session for LogicApps.
Attempt to "Run" the affected workflow straight from the "Overview" page.
The error occurs.

What type of Logic App Is this happening in?
Standard (VSCode)
Are you using new designer or old designer
New Designer
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
Yes
Workflow JSON
{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            "For_Each_Employee_Packet": {
                "type": "Foreach",
                "foreach": "@variables('Employees To Process')",
                "actions": {
                    "Process_Each_Employee_Packet": {
                        "type": "Workflow",
                        "inputs": {
                            "host": {
                                "workflow": {
                                    "id": "20-Process-Packet"
                                }
                            },
                            "body": {
                                "CredentialsList": "@variables('Credentials')",
                                "PacketData": "@item()"
                            },
                            "retryPolicy": {
                                "type": "none"
                            }
                        },
                        "runAfter": {
                            "Call_a_local_function_in_this_logic_app": [
                                "SUCCEEDED"
                            ]
                        }
                    },
                    "Call_a_local_function_in_this_logic_app": {
                        "type": "InvokeFunction",
                        "inputs": {
                            "functionName": "Log Message",
                            "parameters": {
                                "message": "Processing Packet @{variables('Loop Index')} of @{length(variables('Employees To Process'))} ...",
                                "messageType": "@{null}"
                            }
                        },
                        "runAfter": {
                            "Increment_Loop_Index": [
                                "SUCCEEDED"
                            ]
                        }
                    },
                    "Increment_Loop_Index": {
                        "type": "IncrementVariable",
                        "inputs": {
                            "name": "Loop Index",
                            "value": 1
                        }
                    }
                },
                "runAfter": {
                    "Initialize_Loop_Index": [
                        "SUCCEEDED"
                    ]
                },
                "runtimeConfiguration": {
                    "concurrency": {
                        "repetitions": 1
                    }
                }
            },
            "Retrieve_Credentials": {
                "type": "Scope",
                "actions": {
                    "List_Secrets": {
                        "type": "ServiceProvider",
                        "inputs": {
                            "serviceProviderConfiguration": {
                                "connectionName": "keyVault",
                                "operationId": "listSecretMetadata",
                                "serviceProviderId": "/serviceProviders/keyVault"
                            }
                        }
                    },
                    "Filter_Secrets_List_(Prefix)": {
                        "type": "Query",
                        "inputs": {
                            "from": "@body('List_Secrets')",
                            "where": "@startsWith(item()['name'],parameters('Credentials_Secret_Prefix'))"
                        },
                        "runAfter": {
                            "List_Secrets": [
                                "SUCCEEDED"
                            ]
                        }
                    },
                    "Filter_Secrets_List_(IsEnabled)": {
                        "type": "Query",
                        "inputs": {
                            "from": "@body('Filter_Secrets_List_(Prefix)')",
                            "where": "@equals(item()['isEnabled'],true)"
                        },
                        "runAfter": {
                            "Filter_Secrets_List_(Prefix)": [
                                "SUCCEEDED"
                            ]
                        }
                    },
                    "For_Each_Secret": {
                        "type": "Foreach",
                        "foreach": "@body('Filter_Secrets_List_(IsEnabled)')",
                        "actions": {
                            "Get_Secret": {
                                "type": "ServiceProvider",
                                "inputs": {
                                    "parameters": {
                                        "secretName": "@item()['name']"
                                    },
                                    "serviceProviderConfiguration": {
                                        "connectionName": "keyVault",
                                        "operationId": "getSecret",
                                        "serviceProviderId": "/serviceProviders/keyVault"
                                    }
                                }
                            },
                            "Compose_Credentials": {
                                "type": "Compose",
                                "inputs": "@addProperty(item(), 'value', body('Get_Secret')?['value'])",
                                "runAfter": {
                                    "Get_Secret": [
                                        "SUCCEEDED"
                                    ]
                                }
                            },
                            "Append_To_Credentials": {
                                "type": "AppendToArrayVariable",
                                "inputs": {
                                    "name": "Credentials",
                                    "value": "@outputs('Compose_Credentials')"
                                },
                                "runAfter": {
                                    "Compose_Credentials": [
                                        "SUCCEEDED"
                                    ]
                                }
                            }
                        },
                        "runAfter": {
                            "Filter_Secrets_List_(IsEnabled)": [
                                "SUCCEEDED"
                            ]
                        }
                    }
                },
                "runAfter": {
                    "Initialize_Employees_To_Process": [
                        "SUCCEEDED"
                    ]
                }
            },
            "Initialize_Credentials": {
                "type": "InitializeVariable",
                "inputs": {
                    "variables": [
                        {
                            "name": "Credentials",
                            "type": "array"
                        }
                    ]
                },
                "runAfter": {}
            },
            "Initialize_Employees_To_Process": {
                "type": "InitializeVariable",
                "inputs": {
                    "variables": [
                        {
                            "name": "Employees To Process",
                            "type": "array"
                        }
                    ]
                },
                "runAfter": {
                    "Initialize_Credentials": [
                        "SUCCEEDED"
                    ]
                }
            },
            "Initialize_Loop_Index": {
                "type": "InitializeVariable",
                "inputs": {
                    "variables": [
                        {
                            "name": "Loop Index",
                            "type": "integer",
                            "value": 0
                        }
                    ]
                },
                "runAfter": {
                    "Get_Employee_List": [
                        "SUCCEEDED"
                    ]
                }
            },
            "Get_Employee_List": {
                "type": "Scope",
                "actions": {
                    "Get_All_Active_Employees": {
                        "type": "ServiceProvider",
                        "inputs": {
                            "parameters": {
                                "query": "@decodeBase64(body('Get_Employee_Selection_SQL')?['$content'])"
                            },
                            "serviceProviderConfiguration": {
                                "connectionName": "sql",
                                "operationId": "executeQuery",
                                "serviceProviderId": "/serviceProviders/sql"
                            }
                        },
                        "runAfter": {
                            "Get_Employee_Selection_SQL": [
                                "SUCCEEDED"
                            ]
                        }
                    },
                    "Split_Employees_Into_Packets": {
                        "type": "InvokeFunction",
                        "inputs": {
                            "functionName": "Split Array Into Packets",
                            "parameters": {
                                "data": "@first(body('Get_All_Active_Employees'))",
                                "packetSize": 250
                            }
                        },
                        "runAfter": {
                            "Get_All_Active_Employees": [
                                "SUCCEEDED"
                            ]
                        }
                    },
                    "Set_Employees_To_Process": {
                        "type": "SetVariable",
                        "inputs": {
                            "name": "Employees To Process",
                            "value": "@body('Split_Employees_Into_Packets')"
                        },
                        "runAfter": {
                            "Split_Employees_Into_Packets": [
                                "SUCCEEDED"
                            ]
                        }
                    },
                    "Get_Employee_Selection_SQL": {
                        "type": "ApiConnection",
                        "inputs": {
                            "host": {
                                "connection": {
                                    "referenceName": "sharepointonline"
                                }
                            },
                            "method": "get",
                            "path": "/datasets/@{encodeURIComponent(encodeURIComponent(parameters('SharePoint_Site_Base_URL')))}/GetFileContentByPath",
                            "queries": {
                                "path": "/Shared Documents/02. Projects/025. Long Service Leave Model/SQL Scripts/10-Employee Selection.sql",
                                "inferContentType": false,
                                "queryParametersSingleEncoded": true
                            }
                        }
                    }
                },
                "runAfter": {
                    "Terminate": [
                        "SUCCEEDED"
                    ]
                }
            },
            "Get_SharePoint_Site_Base_URL": {
                "type": "Scope",
                "actions": {
                    "HTTP_(Get_Site)": {
                        "type": "Http",
                        "inputs": {
                            "uri": "@{parameters('MS_Graph_Base_URL')}/sites/@{parameters('SharePoint_Site_ID')}",
                            "method": "GET",
                            "authentication": {
                                "type": "ActiveDirectoryOAuth",
                                "tenant": "",
                                "audience": "",
                                "clientId": "",
                                "secret": ""
                            }
                        },
                        "runAfter": {
                            "Compose_Credentials_For_HTTP_Call": [
                                "SUCCEEDED"
                            ]
                        },
                        "runtimeConfiguration": {
                            "contentTransfer": {
                                "transferMode": "Chunked"
                            }
                        }
                    },
                    "Compose_Credentials_For_HTTP_Call": {
                        "type": "Compose",
                        "inputs": {
                            "audience": "https://graph.microsoft.com",
                            "clientId": "@first(variables('Credentials'))?['value']['applicationId']",
                            "secret": "@first(variables('Credentials'))?['value']['secret']",
                            "tenant": "@{parameters('Azure_Tenant_ID')}",
                            "type": "ActiveDirectoryOAuth"
                        }
                    }
                },
                "runAfter": {
                    "Retrieve_Credentials": [
                        "SUCCEEDED"
                    ]
                }
            },
            "Terminate": {
                "type": "Terminate",
                "inputs": {
                    "runStatus": "Cancelled"
                },
                "runAfter": {
                    "Get_SharePoint_Site_Base_URL": [
                        "SUCCEEDED"
                    ]
                }
            }
        },
        "triggers": {
            "When_a_HTTP_request_is_received": {
                "type": "Request",
                "kind": "Http",
                "inputs": {
                    "method": "POST"
                }
            }
        },
        "contentVersion": "<IP_ADDRESS>",
        "outputs": {}
    },
    "kind": "Stateful"
}

Screenshots or Videos

Browser
Chrome
Additional context
vscode-app.zip

This wasn't happening last week so not sure what's changed.  This work went on hiatus briefly while I attended to other activities.

@ccastrotrejo  to take a look. I don't think this is a UX change issue, the local server shouldn't be requiring CORS at all.

@ccastrotrejo I thought changing over from my work assigned laptop to my own personal one would get me by for now but it looks like that didn't help.  I get the same error on that laptop, mind you, I took over the exact set of project files that I was working on when on the work laptop.  So it's either 1) tooling, or 2) the project itself.  Keen to hear your thoughts because now I'm really stuck.

@ccastrotrejo  has an internal thread working with our backend engineers going right now. We’ll update this issue when we know more.

@brad302 As an update we have raised an internal incident, this will help to prioritize it, get an engineer to start looking for the code bug and fix.


[entropy_src/rtl] Refine Observe FIFO interface

The Observe FIFO threshold register has been restricted to not
allow zero as a valid setting.
The depth of the Observe FIFO can now be read through a register.
Fixes #11134.
Signed-off-by: Mark Branstad<EMAIL_ADDRESS>

yeah it's not a huge deal.
so when it's not inconvenient, i usually do it.
On Wed, Mar 2, 2022 at 1:07 PM mwbranstad @.***> wrote:

@.**** commented on this pull request.
In hw/ip/entropy_src/data/entropy_src.hjson
https://github.com/lowRISC/opentitan/pull/11189#discussion_r818102428:

             '''

       resval: "0x20"
     }
   ]
 },

{ name: "OBSERVE_FIFO_DEPTH",

 desc: "Observe FIFO depth register",

 swaccess: "ro",

interesting...I rarely think about saving 6 flops in my high-speed ASIC
designs, but this seems easy enough. Will do!
—
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/pull/11189#discussion_r818102428,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSSKMEEMDQCM76BOSKLU57KB5ANCNFSM5PX4RBNQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID:
@.***>


Implement Safe EIP1271 message signing

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

15 of 15 (100.0%)  changed or added relevant lines in 1 file are covered.
16 unchanged lines in 7 files lost coverage.
Overall coverage decreased (-0.2%) to 83.617%

Files with Coverage Reduction
New Missed Lines
%

gnosis/eth/ethereum_client.py
1
81.38%

gnosis/safe/safe.py
1
88.22%

gnosis/eth/typing.py
2
83.33%

gnosis/protocol/gnosis_protocol_api.py
2
87.63%

gnosis/safe/api/relay_service_api.py
2
52.27%

gnosis/safe/proxy_factory.py
3
95.24%

gnosis/util/util.py
5
61.54%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
3297

Relevant Lines:
3943

💛  - Coveralls


Add runs_to_keep parameter

Closes #64
✅ Checks

[x] My pull request adheres to the code style of this project
[x] My code requires changes to the documentation
[x] I have updated the documentation as required
[x] All the tests have passed

oh yeah baby !!! Thank you Igor :)

Sorry it took this long to get it done @lgmorand. Busy days!
Please let me know if you have any further issues.


Convenience method to get the latest model for a given model type

Is your feature request related to a problem?
As a user, it would be great if there was a method I could use to grab the latest released model (eventually with the option to choose a "production" model once one is released) for a given model type.
Note: I say model type here because I assume by the "am1bcc" tag in the model that other charge models might come along some point.
Describe the solution you'd like
Maybe some kind of method with a signature like this:
def get_latest_model(model_type: str = 'am1bcc', production_only: bool = True) -> str

Describe alternatives you've considered
Relying on the list_available_models sort - assuming there are no other model types and it's guaranteed to be release ordered.

As a user, it would be great if there was a method I could use to grab the latest released model (eventually with the option to choose a "production" model once one is released) for a given model type.

I'm happy to do this but it does runs a bit counter to the philosophy we have in openff-forcefields, where we require users to specify which force field they're after every time. The main worry I would have here is that users would suddenly start getting different charges with the same script if a new model is released and picked up instead. Is needing to specify the model problematic in your workflow?

Yes, it would be useful for us to be able to identify the latest release of a model. If anything, for validation purposes being able to programmatically tell that a model is out of date helps.
We can deal with this on our end by parsing the strings but we would need to know that the model names have an agreed upon format that will not be changing going forward.

I don't think I actually answered the question re users & being problematic for our workflow: it's hard to tell right now, part of the issue is that we don't have a good idea of how quickly these models will be released.
That being said the main uses of all this, for now, isn't so much user facing but developer facing. There are lots of cases where an ordered list would help (documentation comes to mind as another use case).

Thanks for the info about what you need this for. I went back and forth on this and did eventually open PR #13, but I wonder if most of these problems could just be solved with better documentation (e.g. an ongoing table of models like https://github.com/openforcefield/openff-forcefields#how-to-cite)? I don't anticipate that these models will be released too often, although we do anticipate new models coming along with different charge methods / property predictions.

I've added my thoughts in the PR on maybe a better way to avoid some of the concerns.
However I do agree that better documentation here would go a long way, we definitely would prefer to avoid having our own documentation of available charge methods. Additionally, if the model names have documented guaranteed patterns then we can always just have our own filters downstream.


Update card rendering

do not merge. Depends on https://github.com/bustlelabs/mobiledoc-kit/issues/236
Fixes #33

the tests will fail until the dependent PR is merged


example

implement the base class which should have the functionality of a regular turn. special turns should inherit from this class.
I implemented and tested the score function.


Attributes with (*) text failing

Describe the bug
Any variation of open and close parenthesis with an asterisk character somewhere in between those parentheses in an attribute's text is evaluating on code execute for the node.
To Reproduce
Steps to reproduce the behavior:
-Create node
-Add attribute with (*) text
-Execute the node

Moved to: https://github.com/nxt-dev/nxt/issues/76


inference appear Invalid Node name conv2d_1_convolution specified for DPU kernel tf_yolov3_vehicle.

Hi @zhaozhengjuan ,
Can you share more detailed about test environment and error information? Thanks!

please reopen this issue if still have question. Thanks!


Registration of Data Use Agreements as licenses?

https://data.donders.ru.nl/doc/dua/RU-DI-HD-1.0.html?1
@apdavison and @UlrikeS91 specifically for externally published data, should we register DUAs as licenses (similar to the HDG EBRAINS DUAs we registered)?

for clarity, I suggest adding a new schema for DUAs

A separate schema for DUAs is probably smarter. They do not have the same field as licenses and we already agreed when we added the EBRAINS DUAs that this is not a pretty fix but a good enough workaround for now. If we want to expand on this list, we should maybe fix it properly now.

@apdavison and @UlrikeS91 I agree with the both of you but we didn't do this for EBRAINS at the moment either because it entails a longer discussion (politically).
If you have a concrete suggestion that we could quickly implement (openMINDS is less of an issue here) and properly define a way of handling this in EBRAINS (display wise in the KG and politically wise because of missing licenses) please tell :)
Otherwise I suggest we continue the workaround for now and get back to it later.
What do you think?

I assume that there won't be a quick solution, but we should raise this issue anyway. Until then, if you need the other DUAs urgently, I would agree that we stick to the workaround for now.

we can come back to finding a better solution later on in a separate issue. thanks for your quick feedback and support with this one.


Add category label

Hi @cw-sakamoto !
First of all, thanks for your hard work on this repo.
It helps us tremendously!
Quick question, any reason to have removed the category 2 years ago with this commit https://github.com/chatwork/sendgrid-stats-exporter/commit/38788efc9b9d60e54c1b5719d99475a1a1f22258 ?
I do not see any documentation about it(not even in the commit body).
Could you consider adding it again?
Thanks for your help.

Hi @cw-sakamoto !
Any news about this ? :)
Thanks a lot


"Already have an instance running" error

Hello!
I have only one VM.Standard.A1.Flex 1 core OCPU, 2 GB already running on Oracle Cloud.
When I run php ./index.php, I am getting the following message:
Already have an instance(s) [MY_INSTANCE_NAME] in state(s) (respectively) [RUNNING]. User: ocid1.user.oc1.xxxxxxxxxxxxxxxxxxxxxx
I am far from reaching my Free Tier capacity. Is it possible they are limiting "Always Free Tier" to only 1 ARM instance?

I’ll just leave a part from the README
… check whether there're already existing instances with the same OCI_SHAPE, as well as number of them OCI_MAX_INSTANCES (you can safely adjust the last one if you wanna e.g. two VM.Standard.A1.Flex with 2/12 - 2 OCPUs and 12GB RAM - each).


Main Production Code

Code is updated with:

dockerfiles
README instructions
docs created
test code
general documentation

Was able to install docker, however the nvidia command didn't work for me. Since I'm a novice, I didn't know what to do - can you add something in the readme for how to use docker without visualizations?
Once I got past that, everything ran smoothly, all the tests passed and I was able to generate an example hand. Its just that the visualizations didn't work, because I had bypassed that

Updated the readme to include an alternative docker command for non-gui use and sudo in front of the docker commands.

Looks good! Will merge pull request now


"error" please help! 😭

Keep getting this error after hours of waiting for it to make a font! 💀😭😭
I'm using Linux Ubuntu if that helps!

Anyone else get this error? 😭😭😭

The check-virtual-env string is not part of the Noto Emoji codebase. Any way your Makefile got messed up? Can you compare its contents to https://github.com/googlefonts/noto-emoji/blob/master/Makefile ?

Looks the same 😭

@rsheeter Perhaps related to recent changes?

well, that "check-virtual-env" string is not coming from us.
here's a github-wide search for the string
https://github.com/search?q=check-virtual-env&type=Code
@RickyBush try to start afresh with a clean git clone of noto-emoji repository and see if that helps.

@anthrotype that done the trick thank you for your time! 💚


perf: compress site

I think it will be a good idea to compress the site and also serve images in webp format, as per my understanding if nextjs converts them to webp, we won't face the api errors

Also unsure why tests ran before build...

Thanks Krish! But not sure if webp is supported on Mac yet though

You would be surprised to know, yes, they decided to support webp but not svg: https://caniuse.com/webp

Thanks Krish 👍 It would be great to know the size comparison before and after?
Btw I am curious why these are not on by default? There must be a reason?

NextJS wouldn't fiddle with the quality of the images - but because the avatars/images we don't use aren't so detailed already - we don't need that...
Plus, most websites use it including Discord as well :D
I am not sure about comparison - I'll have to install a bunch more code so that it checks the bundle size each time - but that sounds like not having a place in this PR,
but:

WebP lossless images are 26% smaller in size compared to PNGs.
-- developers.google.com


fix overline and italic styles

Original message: This is a drive-by-commit fixing an obvious error. Please don't force me to go through paperwork.
Maintainer added description: Overline and italic styles were looking at the underline argument by mistake.
Checklist:

[x] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[ ] Add or update relevant docs, in the docs folder and in code.
[ ] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[ ] Add .. versionchanged:: entries in any relevant code docs.
[ ] Run pre-commit hooks and fix any issues.
[x] Run pytest and tox, no tests failed.

Thanks for fixing this. However, in the future, please do "go through the paperwork", such as describing what you're fixing. The way you've worded this PR is really dismissive of maintainers time, which is not appreciated. Keep this in mind for any PRs you make, not only on Pallets projects.

Rebased to 8.0.x since this is a bug fix. Added a changelog entry so users are aware that an issue with styles was addressed.


Add suppressX suppressZ to grabbable?

Hi,
We're trying to adapt http://apps.tlt.stonybrook.edu/tarski/ to your excellent super-hands component.
We need a lever which only has freedom in the Y direction.
We modified https://github.com/wmurphyrd/aframe-super-hands-component/blob/master/reaction_components/grabbable.js to have functionality similar to suppressY but now we would need to keep a local version of this component and maintain it in case of further updates.
Is there a preferred way to extend grabbable without modifying the existing code?
I am unsure why suppresssY exists without the other axes, could we ask for a feature request to include  suppresssX and suppresssZ ?
BTW we've already used super-hands on the following (only tested in Vive)
http://apps.tlt.stonybrook.edu/hanoi/

Thanks for using super-hands. The reason I only added the suppressY option was it was all I needed at the time for a-locomotor. I'd be open to a pull request that added the other axes. (although, rather than added two more schema properties, I'd probably favor changing to a single suppress string property that could have any combination of x, y, and/or z, i.e. for your case it would be suppress: xz).
super-hands is also designed to be extensible with custom reaction components, so you could just copy the code for grabbable and register a new component under a different name that did exactly what you wanted.
Have you considered using physics simulation to power your lever interaction? I think you'd find a much more satisfying experience using aframe-physics-system and some constraints to get a nice lever action going. In my experience, however, the lock constraint that my grabbable component uses doesn't play too well with constrained objects; it works much better if alter it to use a point-to-point constraint with a small maximum force. Here's an example of a spinnable wheel made using that technique with a hinge constraint.

Would love for this to happen!


For DocumentSymbol, allow passing also Location optionally, not only Range

Currently, DocumentSymbol, used in the result of Document Symbol request only contains Range, so it is only able to reference the file for which the request was sent.
I propose, that we would be able to reference other files as well, so the definition of properties range and selectionRange could change from:
range: Range;
selectionRange: Range;

to the following:
range: Range | Location;
selectionRange: Range | Location;

We are developing a language server for High Level Assembler, where we would quite benefit from such feature. There is a construct, which makes symbols that may be defined in different files related (imagine something like partial class in C#). It would be nice if the user could see all the related symbols listed in one place (the outline in VS Code), even when they are defined in different files.
What are your thoughts on this? Is there a reason why such feature was not allowed until now? Would it be worthwhile to create a pull request implementing these changes?

+1 - we'll eventually be moving from SymbolInformation (which does have a Location) to DocumentSymbol for some C# scenarios.  As mentioned in the original post, having the Location is important for partial types and methods which are defined across documents.  In VS, documentSymbol is used for some navbar scenarios where, for example, we would want to show methods in a partial type from all documents.

+1


Jit produces wrong code with version 0.49.0

Our library's tests fail on all platforms when upgrading from numba version 0.48.0 to 0.49.0.
The smallest test case that I could come up with that still reproduces the issue is the following:
import numpy as np
from numba import jit

def foo():
    values = np.zeros(1)
    tmp = 666
    if tmp:
        values[0] = tmp
        print(values)

print("Without jit")
foo()
print("With jit")
jit(foo)()

It prints 666.0 with Python and 1.0 when jitted.

[ x ] I am using the latest released version of Numba (most recent is visible in
the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
[ x ] I have included below a minimal working reproducer (if you are unsure how
to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

I can add the following observations (with slightly more simplified code (no numpy))
from numba import njit

@njit
def foo1():
    res = 0
    tmp = 10
    if tmp:
        res = tmp
    return res

print(foo1())
#Returns 1

@njit
def foo2():
    res = 0
    tmp = 10
    if tmp != 0:
        res = tmp
    return res

print(foo2())
#Returns 10

@njit
def foo3(tmp):
    res = 0
    if tmp:
        res = tmp
    return res

print(foo3(10))
#Returns 10

So there is definitely an issue that only arises when using a constant value and skipping the explicit comparison in the if statement. I do not know whether that is the root cause of the original problem in @99991 's project though.

Thanks for the report. This is a bug.

Will patch it for 0.49.1.

This is the first time I look into the numba src, but it looks like the conditions are added to the list of nullified conditions after pruning
https://github.com/numba/numba/blob/334e65cef19257faf1c6452bc0750df7d1ce76d8/numba/core/analysis.py#L443-L447
and subsequently replaced by 0 or 1?
https://github.com/numba/numba/blob/334e65cef19257faf1c6452bc0750df7d1ce76d8/numba/core/analysis.py#L464-L475

@HPLegion correct, this is trying to reuse the rewrite that was written for the case of conditionals. I've got a patch to fix it.

Further... if I do this:
import numpy as np
import llvmlite
import numba
import platform
from numba import njit, gdb

print("System:", platform.uname())
print("llvmlite version:", llvmlite.__version__)
print("numba version:", numba.__version__)
print("numpy version:", np.__version__)

# If this should crash, try without this line
@njit("i8(i8[:], i8[:], i8[:], i8[:], i8[:], f4[:, :, :], f4[:], f4[:, :], i8[:], i8)",
       boundscheck=True, debug=True)
def _make_tree(
    i0_inds,
    i1_inds,
    less_inds,
    more_inds,
    split_dims,
    bounds,
    split_values,
    points,
    indices,
    min_leaf_size,
):
    dimension = points.shape[1]
    # Expect log2(len(points) / min_leaf_size) depth, 1000 should be plenty
    stack = np.empty(1000, np.int64)
    stack_size = 0
    n_nodes = 0
    # min_leaf_size <= leaf_node_size < max_leaf_size
    max_leaf_size = 2 * min_leaf_size

    # Push i0, i1, i_node
    stack[stack_size] = 0
    stack_size += 1
    stack[stack_size] = points.shape[0]
    stack_size += 1
    stack[stack_size] = n_nodes
    n_nodes += 1
    stack_size += 1

    # While there are more tree nodes to process recursively
    while stack_size > 0:
        stack_size -= 1
        i_node = stack[stack_size]
        stack_size -= 1
        i1 = stack[stack_size]
        stack_size -= 1
        i0 = stack[stack_size]

        lo = bounds[i_node, 0]
        hi = bounds[i_node, 1]

        for d in range(dimension):
            lo[d] = points[i0, d]
            hi[d] = points[i0, d]

        # Find lower and upper bounds of points for each dimension
        for i in range(i0 + 1, i1):
            for d in range(dimension):
                lo[d] = min(lo[d], points[i, d])
                hi[d] = max(hi[d], points[i, d])

        # Done if node is small
        if i1 - i0 <= max_leaf_size:
            i0_inds[i_node] = i0
            i1_inds[i_node] = i1
            less_inds[i_node] = -1
            more_inds[i_node] = -1
            split_dims[i_node] = -1
            split_values[i_node] = 0.0
        else:
            # Split on largest dimension
            lengths = hi - lo
            split_dim = np.argmax(lengths)
            split_value = lo[split_dim] + 0.5 * lengths[split_dim]

            # Partition i0:i1 range into points where points[i, split_dim] < split_value
            i = i0
            j = i1 - 1

            while i < j:
                while i < j and points[i, split_dim] < split_value:
                    i += 1
                while i < j and points[j, split_dim] >= split_value:
                    j -= 1

                # Swap points
                if i < j:
                    for d in range(dimension):
                        temp = points[i, d]
                        points[i, d] = points[j, d]
                        points[j, d] = temp

                    temp_i_node = indices[i]
                    indices[i] = indices[j]
                    indices[j] = temp_i_node

            if points[i, split_dim] < split_value:
                i += 1

            i_split = i

            # Now it holds that:
            # for i in range(i0, i_split): assert(points[i, split_dim] < split_value)
            # for i in range(i_split, i1): assert(points[i, split_dim] >= split_value)

            # Ensure that each node has at least min_leaf_size children
            i_split = max(i0 + min_leaf_size, min(i1 - min_leaf_size, i_split))

            less = n_nodes
            n_nodes += 1
            more = n_nodes
            n_nodes += 1

            # push i0, i_split, less
            stack[stack_size] = i0
            stack_size += 1
            stack[stack_size] = i_split
            stack_size += 1
            stack[stack_size] = less
            stack_size += 1

            # push i_split, i1, more
            stack[stack_size] = i_split
            stack_size += 1
            stack[stack_size] = i1
            stack_size += 1
            stack[stack_size] = more
            stack_size += 1

            i0_inds[i_node] = i0
            i1_inds[i_node] = i1
            less_inds[i_node] = less
            more_inds[i_node] = more
            split_dims[i_node] = split_dim
            split_values[i_node] = split_value

    return n_nodes

def main():
    k = 20
    n_data = 100_000
    n_query = n_data
    dimension = 5

    data_points = np.random.rand(n_data, dimension).astype(np.float32)
    min_leaf_size = 8

    n_data, dimension = data_points.shape

    max_nodes = 2 * ((n_data + min_leaf_size - 1) // min_leaf_size)

    i0_inds = np.empty(max_nodes, np.int64)
    i1_inds = np.empty(max_nodes, np.int64)
    less_inds = np.empty(max_nodes, np.int64)
    more_inds = np.empty(max_nodes, np.int64)
    split_dims = np.empty(max_nodes, np.int64)
    bounds = np.empty((max_nodes, 2, dimension), np.float32)
    split_values = np.empty(max_nodes, np.float32)
    shuffled_data_points = data_points.copy()
    shuffled_indices = np.arange(n_data).astype(np.int64)

    _make_tree(
        i0_inds,
        i1_inds,
        less_inds,
        more_inds,
        split_dims,
        bounds,
        split_values,
        shuffled_data_points,
        shuffled_indices,
        min_leaf_size,
    )

main()

I get this:
$ NUMBA_FULL_TRACEBACKS=1 python pymatting1.py
<snip>
llvmlite version: 0.33.0dev0
numba version: 0.50.0dev0+129.g2f6309d6c
numpy version: 1.18.1
debug: IndexError: index -875736469 is out of bounds for axis 0 with size 100000
Traceback (most recent call last):
  File "pymatting1.py", line 178, in <module>
    main()
  File "pymatting1.py", line 165, in main
    _make_tree(
IndexError: index is out of bounds

which suggests an out of bounds access is probably involved.

Master branch passes this test now.

@99991 many thanks for confirming, will close this now.


Clearing color controls to default doesn't trigger change event

Issue description:
Clearing the color controls does not enable the save button in customizer.
Version used:
(Did you try using the develop branch from github? There's a chance your issue has already been adressed there)
Yes
Using theme_mods or options?
theme_mods
Code to reproduce the issue (config + field(s))
Kirki::add_field( [
        'settings' => 'primary-button-color',
        'type' => 'color',
        'section' => 'buttons',
        'title' => esc_html__( 'Primary button color' , 'theme' ),
        'default' => '',
        'transport' => 'auto',
    ]);

Looks fine to me...
It doesn't trigger the change event when the default is empty, and the color is already empty. Which makes perfect sense. Other than that it seems to be working fine on my end.

If the control has a color selected, doesn't the clear button trigger change?

Closing due to inactivity.
If this is still an issue for you then please feel free to reopen this ticket and post an update with some more details.


V3 / ethers preview

Changes

Added ethers-5 package
Added support for WalletConnectProvider
Added support for InjectedProvider
Added support for CoinbaseProvider
Added support for EIP6963Provider
Created utils package to store shared constants, presets and helpers
Created scaffold-react package to store shared react hooks
Created scaffold-vue package to store shared vue compositions

Hi

And this is feedback from testing the app

I am unable to switch chain if it is not configured in my metamask wallet (injected) i.e. no proposal to add new chain
ens details dissapear if I switch away from ethereum
When I switch chain from within metamask wallet, change is not reflected in modal
If I switch account from metamask wallet, chain is not reflected in the modal

Few notes on initial full testing

In laboratory when you click on wagmi or ethers example and go to their respective pages, refreshing the page results in 404. Same when you go straight to the page i.e. via /library/wagmi. Unable to check account state persistence due to this atm.
I have phantom wallet installed, when I go to ethers example, I am always instantly prompted to connect without performing any action (even with clean localstorage).

High level thought: There's very little ethers5-specific code here. Have you considered defining a minimal web3 provider interface that someone can implement to create wrappers for any provider?
For example, what about supporting ethers6?

Hi @shazow we are planning to add support for v6 as well, were currently figuring out the best approach


Yatin: Watch 8[^\d]+8[^\d]+8[^\d]+9[^\d]+5[^\d]+9[^\d]+2(?:[^\d]|0)+1[^\d]+1

Yatin requests the watch of the watch_keyword 8[^\d]*+8[^\d]*+8[^\d]*+9[^\d]*+5[^\d]*+9[^\d]*+2(?:[^\d]|0)*+1[^\d]*+1. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Rejected by Makyen in Charcoal HQ. Reason: 'Replacing a blacklist with a watch isn't what we'd normally want to do when the blacklist is detecting TP and not detecting FP. Generally \D is better to use than [^\d]. Using \D*+ for the inter-digit separation feels like we're making the regex too broad, even if it is still quite unlikely to produce FP. OTOH, it's clear the spammer has cases of using a low number of \w characters as separators. Overall, I'd prefer to use something a bit more restricted.'


Add some information in the data to the prompt

Before this change, when asking to create code for analyzing column values e.g., in an .xlsx-File, GPT often just guessed the relevant column names and thus most of the time, the generated code did not run with the actual data.
With this change, we try to open the uploaded file with pandas, read the column names and also inject them into the prompt. This considerably reduces failure rate of the generated code.

This is great! Merging. Will run a release tomorrow

Works like a charm!


Custom github app

Lately more and more workflows are being created to automate certain processes, one ambitious project that would help encompass all these things avoiding (in theory) security vulnerabilities is a bot (Github Apps) created for free-programming-books, like microsoft's but simpler.
At this time I don't have so much time to devote to this project but as soon as I can I start trying to do something, it would be nice to be able to develop it in more people.
Related:

#7024
#6914
#6942

Could you explain for those of us who haven't played much with Actions, what the difference would be?

Mainly to have everything in a more organized and professional way, secondly it should be safer

Could you please assign this task to me? Thank you!

Can we develop any kind of app according to our specific requirements and preferences?


API GW CLI Tests

Positive wsk api-experimental tests that require a deployed backend with API GW support.

@rabbah - Here's the addition to the Wsk.scala common test tooling for your feedback.  In the meantime, I'll be creating additional tests based on this structure.

@mdeuser is this superseded by #1626?

@rabbah - yep


Easy activation PowerToys Run-plugins

Description of the new feature / enhancement
Buttons under the run dialog box for an easier way to use the plugins shortening the learning curve that comes with remembering all the activation commands.

sorry for the slopy concept i had only 10 mins
Scenario when this would be used?
Makes using Powertoys-run plugins much easier by shortening the learning curve that comes with remembering all the activation commands.
Supporting information
No response

/dup #12182


Support template arguments for Markdown.

1. What does this change do, exactly?
Adds the second args ...interface{} parameter to the version of Include used with the Markdown plugin. This allows arguments to included templates when using that plugin.
2. Please link to the relevant issues.
3. Which documentation changes (if any) need to be made because of this PR?
I don't think this will require any changes. The documentation already implies that passing arguments to included templates should be possible.
4. Checklist

[ ] I have written tests and verified that they fail without my change - the file is untested at the moment and the change is pretty trivial, I can write tests if necessary, though.
[x] I have squashed any insignificant commits
[x] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I am willing to help maintain this change if there are issues with it later

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@mholt not sure what the review process is, but this is a pretty small change... :-)

Thanks for contributing, @glesica! Welcome to the project. Thanks for making the code consistent with the documentation. ;)


Augment the event Buffer size

Hello,
I'm using telegraf to monitor snmp routers/switches/optical equipments. Currently it is more than 700 equipments. We use kapacitor in stream node to check pings with sensu as alerting system.
To make it works, i had pushed the limit of eventBufferSize from 100 to 5000. Not sure, i need so many events but the limit to 100 seems a little conservative.
The constant value is defined in alert/topics.go line 16.
Best regards

@ellis2323 Thanks for letting us know.  The event buffer/topic features a brand new. Can you share more details about what behavior you were seeing before and after increasing the eventBufferSize? How many events per second are you generating?  etc...

I had many error messages from the file services/alert/handlers.go
return fmt.Errorf("failed to deliver event %q to handler", event.State.ID)

I have actually 700 equipments i monitored with telegraf. In this case, i check ping response. Telegraf seems to check all equipments in the same second.

Hi,
We've been having this issue as well and waited for v1.4.0 to fix this in our setup. Yesterday we rolled out this version, but unfortunately we still get an insane amount of these errors:
ts=2017-12-14T12:49:15.145Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=critical_logs node=alert3 err="failed to deliver event \"mendix_runtime.critical_logs_count:app_name=03f98f2a-603c-41ce-bc43-16d73db53787\" to handler"
ts=2017-12-14T12:49:15.145Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=critical_logs node=alert3 err="failed to deliver event \"mendix_runtime.critical_logs_count:app_name=0ee02ca5-193c-43d9-af46-8a7d48a41b04\" to handler"
ts=2017-12-14T12:49:15.941Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=critical_logs node=alert3 err="failed to deliver event \"mendix_runtime.critical_logs_count:app_name=5691b627-b0e1-46e0-932e-c2781b44d6c4\" to handler"
ts=2017-12-14T12:49:15.955Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=critical_logs node=alert3 err="failed to deliver event \"mendix_runtime.critical_logs_count:app_name=e879adc2-8ab2-4a97-8699-230f0213900b\" to handler"
ts=2017-12-14T12:49:15.956Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=critical_logs node=alert3 err="failed to deliver event \"mendix_runtime.critical_logs_count:app_name=754f322d-a328-4d1a-8174-a4dcaff890b8\" to handler"
ts=2017-12-14T12:49:28.957Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=runtime_heartbeat node=alert3 err="failed to deliver event \":nil\" to handler"
ts=2017-12-14T12:49:28.957Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=runtime_heartbeat node=alert3 err="failed to deliver event \":nil\" to handler"
ts=2017-12-14T12:49:28.957Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=runtime_heartbeat node=alert3 err="failed to deliver event \":nil\" to handler"
ts=2017-12-14T12:49:28.957Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=runtime_heartbeat node=alert3 err="failed to deliver event \":nil\" to handler"
ts=2017-12-14T12:49:28.957Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=runtime_heartbeat node=alert3 err="failed to deliver event \":nil\" to handler"
ts=2017-12-14T12:49:28.957Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=runtime_heartbeat node=alert3 err="failed to deliver event \":nil\" to handler"
ts=2017-12-14T12:49:28.957Z lvl=error msg="encountered error collecting event" service=kapacitor task_master=main task=runtime_heartbeat node=alert3 err="failed to deliver event \":nil\" to handler"

Some info about our setup:

Kapacitor is subscribed to an InfluxDB instance at InfluxCloud
We are running kapacitor with 9 tasks (7x stream, 2x batch)
The tasks are processing metrics for currently ~600 applications

1 stream task receives 1 metric per 10 seconds per application (task=critical_logs from the errors above)
3 stream tasks receive 1 metric per 15 seconds per application
2 stream tasks receive 1 metric per 5 minutes per application
1 stream task == influxDBOut() (stats about kapacitor)
1 batch task queries 1 measurement for all applications every minute (task=runtime_heartbeat from the errors above)
1 batch task queries 1 measurement for 1 application every minute

The tasks alert to Alerta when a threshold is crossed

The errors above only appear for task=runtime_heartbeat and task=critical_logs
runtime_heartbeat tick script:
batch
    |query('''
        SELECT last("value")
        FROM "appmetrics"."autogen"."mendix_runtime.critical_logs_count"
        GROUP BY "app_name"
    ''')
        .groupBy('app_name')
        .period(15m)
        .every(1m)
    @since()
    |alert()
        .info(lambda: "since" <=<PHONE_NUMBER>00)
        .crit(lambda: "since" ><PHONE_NUMBER>00)
        .alerta()
            .message('Runtime Heartbeat received {{ index .Fields "since_string" }} ago')
            .resource('{{ index .Tags "app_name" }}')
            .services('mendix_runtime.heartbeat')
            .event('heartbeat')
            .value('{{ index .Fields "since" }}')

@since is a UDF that basically calculates time.Now().UnixNano() - p.Time
critical_logs tick script:
stream
    |from()
        .measurement('mendix_runtime.critical_logs_count')
        .groupBy('app_name')
    |window()
        .period(1m)
        .every(1m)
    |alert()
        .info(lambda: "value" == 0)
        .crit(lambda: "value" > 0)
        .message('Critical errors count is {{ index .Fields "value" }}.')
        .alerta()
        .resource('{{ index .Tags "app_name" }}')
        .event('critical_logs')
        .value('{{ index .Fields "value" }}')

Some graphs to give you an idea how kapacitor is performing:

1h
12h

Is the (magic) number 5000 not high enough for our situation?

How can we debug this issue?
What would be the impact of increasing eventBufferSize to 100,000?
Is it possible to see how much of the eventBufferSize is used (when there are no errors like these)?


Bug: CustomSelection Initialize with Subset, func Attribute Update Needed

https://github.com/jmschrei/apricot/blob/8b9026508ea788916ae7394aa8ab7b6cd330e594/apricot/functions/custom.py#L176

This should be self.function

Thanks for the amazing package!

I've just temporarily patched on my end using class inheritance and seems to work just fine:
class CustomSelection2(CustomSelection):
    def _initialize(self, X):
        super(CustomSelection, self)._initialize(X)

        if self.initial_subset is None:
            pass
        elif self.initial_subset.ndim == 2:
            if self.initial_subset.shape[1] != X.shape[1]:
                raise ValueError("The number of columns in the initial subset must " \
                    "match the number of columns in X.")
        elif self.initial_subset.ndim == 1:
            self.initial_subset = X[self.initial_subset]
        else:
            raise ValueError("The initial subset must be either a two dimensional" \
                " matrix of examples or a one dimensional mask.")

        if self.initial_subset is None:
            self.total_gain = 0
        else:
            self.total_gain = self.function(self.initial_subset)

Happy to PR, I just figured it's a quick fix and is probably best done on your end. Thanks!

Thanks for the report. This should be updated in 0.6.1, which I just uploaded.


Performance improvements

Use google benchmark or other performance/profiling tools to make better choices about inlining, branch ordering, [[likely]]/[[unlikely]] or other code gen in critical paths to improve performance.

Use clang's optimization reports to find opportunities: https://johnnysswlab.com/loop-optimizations-interpreting-the-compiler-optimization-report/

In chrome every time we un-inline something performance goes up? Or a lot? So probably a lot of attribute((noinline)) is in order, driven by some kinda measurements.

Benchmarking framework added in https://github.com/chromium/subspace/pull/305.
Benchmarks go in the bench/ directory and use GoogleTest for now to register each function to run. Kinda weird cuz then they run when running unittests unless you -E ^Bench.* which the bots now do.


If typescript is present - plugin readme links to .ts files

Expected Behaviour
Links in readme.md should be correct.
Actual Behaviour
Reproduce Scenario (including but not limited to)

add typescript to package.json
run npm i
run npm run prepack

observe links to src files in readme are all .ts
ex.
_See code: [src/commands/app/index.ts](https://github.com/adobe/aio-cli-plugin-app/blob/9.1.0/src/commands/app/index.ts)_

remove typescript from package.json
run npm i
run npm prepack

observe links to src files are .js
ex.
_See code: [src/commands/app/index.js](https://github.com/adobe/aio-cli-plugin-app/blob/9.1.0/src/commands/app/index.js)_
Environment Info
  System:
    OS: macOS 12.5
    CPU: (10) arm64 Apple M1 Max
    Memory: 280.22 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.16.0 - ~/Library/pnpm/node
    Yarn: Not Found
    npm: 8.11.0 - ~/Library/pnpm/npm
  Virtualization:
    Docker: 20.10.17 - /usr/local/bin/docker
  npmGlobalPackages:
    @adobe/aio-cli: 8.3.1-next

oclif PR https://github.com/oclif/oclif/pull/955

fixed by removing typescript from all our repos 🤷


AccessLog update causes deadlock

In user_logged_out function of handler/database.py there is an update() call:
AccessLog.objects.filter(
  username=username, logout_time__isnull=True
).update(logout_time=request.axes_attempt_time)

There are two problems with this update:

If the same user logs into the system from multiple places then at logout the AXES Django module tries to update ALL rows that has logout time NULL for the user. That means that the first logout will trigger all records belonging to the user to be updated, which is not correct. The system must update only the record that was created for the current session (and do not touch the other records).

The second problem is because the first problem exists. During update the database puts locks on the rows and when the logout takes place simultaneously from two places and the update is run simultaneously and there are multiple logins, then it is not guaranteed that the order of the rows will be tha same during update and that might result in a deadlock.
See this StachExchange article:
https://dba.stackexchange.com/questions/257217/why-am-i-getting-a-deadlock-for-a-single-update-query

The quick and dirty fix for the deadlock would be to sort the rows by ID. If the new rows are guaranteed to have higher ID than the old ones, then the UPDATE will never deadlock, because at every run the system will lock in the same order.
The real fix would be to save the ACCESSLOG row ID in the session and update the corresponding row when logout takes place.

Quick and dirty fix can not be guaranteed to work with all the database backends as row IDs are not always-incrementing. Would somebody be interested in exploring linking sessions to the AccessLog records or fixing the deadlock by other means?


[STORM-1961] Stream api for storm core use cases

The initial version of unified stream api for expressing streaming computation pipelines over the storm core spouts and bolts. Right now this provides at-least once guarantees and addresses only the storm core use cases.
For high level design see - https://issues.apache.org/jira/secure/attachment/12827547/UnifiedStreamapiforStorm.pdf
A few examples have been added which should give a basic idea on how to use the apis. More examples and detailed documentation will be added as followup tasks.

Updated doc -
https://docs.google.com/document/d/1Ew7uFF1UJ6e_zq0t4bM6A9auuEaArviAjjWYSpVFqPY/edit?usp=sharing
Pinging for reviews and feedback. Its a big patch mostly due the number of different apis, however the doc and the examples should be a good starting point.
@HeartSaVioR would like inputs from you esp. since it could be potentially used in storm-sql in future.
@ptgoetz would be great if you could take a look as well, since you were working on a prototype beam runner for storm. To validate the apis and identify gaps, I will try to do a prototype runner using the proposed apis.
@revans2 please take a look if you get a chance.

@arunmahadevan I will review. Before you start working on a prototype beam runner, let me push what I have to a feature branch. I have a fair amount of the basic scaffolding you would need.

@arunmahadevan
I'm in the middle of reviewing updated design doc again. Since I've read it once so there will be no outstanding comments, but just would like to check again.
Btw, I merged this PR to my local and convert one of example on storm-starter (windowing example), and it seems to run fine. After reviewing design doc, I'll play with API sets and leave some feedbacks.

It is better to discuss these APIs before working on Beam runner prototypes. Lets not jump on using these APIs to work on runner. Beam API is currently changing and we should discuss those API contracts and we should evaluate what kind of enhancements we need to do. We can create subtasks for the requirements and work on those later.

@satishd right now its more of a prototype proof of concept for the proposed apis, not the final version. Once the beam api solidifies we can have a separate discussion to identify the gaps, but doesn't make sense to hold off the prototype implementation which is more for validating the proposed apis.

For me this stream API is not only for supporting Beam. This is what Storm needed to have even before Beam is open-sourced. We may want to label this API to experiment or unstable or something, but anyway I'd like to see it released not too late.

@arunmahadevan I was saying we should not hold on this PR till Beam runner API is tried with these APIs. We should review these APIs soon and these may remain experimental for couple of minor releases.
I was going through Beam features earlier and I plan to have a doc about Beam features and how we can start implementing some of those APIs. I will add details once Taylor's branch is open and the doc can be updated with that. I will share the doc once it is ready(in 2-3 weeks). We can create subtasks based on that doc and work on them later.

@satishd proper beam support cannot happen until underlying storm primitives are enhanced and the windowing enhancements which has been pending is completed. This a big task which we can discuss separately. The prototype I was mentioning is just a proof of concept with the proposed api to see how it goes, when I get some cycles. This PR definitely need not wait on this and we can mark the apis "unstable" and release it sooner once the review is done.

@arunmahadevan Ofcourse, BEAM support is not expected to be done in a large PR with all the functionality. The approach I mentioned is to do in stages starting with a doc to discuss BEAM features and involve community in all those stages. This is more about discussing/figuring out the requirements for state checkpointing, windowing and operators semantics.

I have looked through the proposal, and I have a number of concerns about the API.  I mostly want to be sure that we can consistent terminology about what different operations are intended to do.  groupby is the big one for me, because it seems to be a routing function and not an actual groupby, but join also seemed a little off.
Why do we need so many lines of code to do a repartition/groupby in the word count example?
builder.newStream(new RandomSentenceSpout(), new ValueMapper<String>(0), 2)
      /*
       * split the sentences to words
       */
      .flatMap(s -> Arrays.asList(s.split(" ")))
      /*
       * create a stream of (word, 1) pairs
       */
      .mapToPair(w -> new Pair<>(w, 1))
      /*
       * group by word so that the same words end up in the same partition
       */
      .groupByKey()
      /*
       * streams parallelism changed to 3 and applies to downstream operations
       */
      .repartition(3)
      /*
       * a ten seconds tumbling window
       */
      .window(TumblingWindows.of(Duration.seconds(10)))
      /*
       * compute the word counts in the last two second window
       */
      .aggregateByKey(new Count<>())
      /*
       * the words that occurred at-least five times in the last two seconds
       */
      .filter(x -> x.getSecond() >= 5)
      /*
       * print the results (word, count) to stdout
       */
      .print();

it feels like we could accomplish the entire thing much simpler (look at flink or spark streaming, even BEAM (although it is rather complex ultimetly the final code does the aggregation more cleanly).
builder.newStream(new RandomSentenceSpout(), new ValueMapper<String>(0), 2)
      .flatMap(s -> Arrays.asList(s.split(" ")))
      .window(TumblingWindows.of(Duration.seconds(10)))
      // short hand for .aggregateBy(1 /*index to use in grouping*/, new Count<>(), 3 /*new number of partitions although we probably want to internally actually have many more partitions but only 3 executors to start out with*/)
      .countBy(1, 3)
      .filter(x -> x.getSecond() >= 5)
      .print();

But I am most concerned about expanding this API in the future.  The stated plan is to start out with defining the API and implementing a back end that supports at most one and at least once processing and then move on to exactly once processing.  I really would like to have a plan in place on how we expect to do exactly once processing before we go too deeply into the API.  Even if we do mark the API as unstable.  I am really concerned about how state plays into this (inputs, outputs, windowing, and actual state).  We currently have two different types of spouts.  We have one type for at least once/at most once and another for exactly once.  The exactly once use case scares me a bit because if we want to support BEAM they have a very specific model on exactly once.  All operations are idempotent and replay includes a complete rollback to a known consistent checkpoint.  The trident spout does not do this (no ordering guarantees).  The other spouts also do not do this.  My concern is that the APIs for a lot of different user facing things may need to change for exactly once, and I would like to have a plan in place on how we want to support it and have thought out how that might impact the APIs before we release this to the public.
This also goes for the windows.  Having more robust windowing may impact some of these APIs.  Have we thought that through?

@revans2  thanks for taking time to do detailed and thoughtful review.

I have looked through the proposal, and I have a number of concerns about the API. I mostly want to be sure that we can consistent terminology about what different operations are intended to do. groupby is the big one for me, because it seems to be a routing function and not an actual groupby, but join also seemed a little off.

groupby is doing the fields grouping on key. I will rename it. May be it need NOT be exposed at all since reduce/aggregate etc can do implicit partitioning on the key. I didn't do implicit partitioning in aggregate since trident had a concept of partitionAggregate (keyed aggregate per partition) and thought it may be useful. May be its not needed.
Will add a groupByKey() api which returns an Iterable<V> similar to beam/spark.

Why do we need so many lines of code to do a repartition/groupby in the word count example?

repartition is not really required, but was there to show the usage. I will remove it from the example. Groupby (partitionbykey) can also be removed and aggregate can do an implicit fields grouping.

builder.newStream(new RandomSentenceSpout(), new ValueMapper(0), 2)
.flatMap(s -> Arrays.asList(s.split(" ")))
.window(TumblingWindows.of(Duration.seconds(10)))
// short hand for .aggregateBy(1 /index to use in grouping/, new Count<>(), 3 /new number of partitions although we probably want to internally actually have many more partitions but only 3 executors to start out with/)
.countBy(1, 3)
.filter(x -> x.getSecond() >= 5)
.print();

Since count seems to be a common operation it can be added as an additional api. But aggregate is more general and users can provide different Aggregators.

But I am most concerned about expanding this API in the future. The stated plan is to start out with defining the API and implementing a back end that supports at most one and at least once processing and then move on to exactly once processing. I really would like to have a plan in place on how we expect to do exactly once processing before we go too deeply into the API.

The state checkpointing mechanism we have can be extended to provide exactly once. (e.g with transactional updates and message de-duplication similar to the millwheel model), or saving source level spout offsets.
The initial ideas for phase 2 are listed here - https://docs.google.com/document/d/1Ew7uFF1UJ6e_zq0t4bM6A9auuEaArviAjjWYSpVFqPY/edit#heading=h.nmf14n

My concern is that the APIs for a lot of different user facing things may need to change for exactly once,

The changes would mostly be in the underlying framework and we may add some additional constraints like the emitted tuple should have a unique message Id field and re-emits with the same message id for exactly once. It can be non-intrusive without changes at the api level.

This also goes for the windows. Having more robust windowing may impact some of these APIs. Have we thought that through?

The underlying windowing framework has to be enhanced before this can be supported. From the api point of view, the window() function right now takes a window config builder where we can add additional apis to support triggers and so on. Something like,
stream.window(TumblingWindows.of(...).triggering(...).withAllowedLateness(Duration.standardDays(2)) and so on, and the window will trigger based on the window config.

Ok I feel a lot better seeing how you have thought through most of these things.  I would like to see us write out some more examples, not just word count in what this new API would look like.  The we could have a better feel of what this might look like.

@revans2
A few basic examples are here.
Will add more examples, a Readme and api documentation, but I have very less free cycles to work on it right now, so will take some more time.
I also pushed a commit to change the groupBy semantics so that it returns a pair of key, Iterable<V>. The aggregation operations on key now does an automatic partitioning on the key (unless the stream is already partitioned by key). Examples are updated to reflect the same.
I will raise follow up tasks to add additional examples and apis like cogroup, transform and so on which I think would be useful. I plan to work on it incrementally when I get time, but if someone in the community wants to contribute, I will be happy to help.
@HeartSaVioR thanks for your inputs I also added Typed tuples (upto Tuple10 for now), see TypedTupleExample for usage.

Have fixed a few issues, updated the examples and raised follow up JIRAs for tasks that can be taken up after the initial work.
I think the PR is in a better shape now to do the code review. @revans2 @HeartSaVioR would appreciate if you could also take a look as time permits.

Have fixed a few issues, updated the examples and raised follow up JIRAs for tasks that can be taken up after the initial work.
I think the PR is in a better shape now to do the code review. @revans2 @HeartSaVioR would appreciate if you could also take a look as time permits.

This Streams API is built on top of the core APIs. The idea of building Beam APIs on top of this looks like the API stack is getting too tall... 3 levels!!   Like a tower of cards.
In practice, not a great idea from the debugging/monitoring/other perspectives ... IMO.

This Streams API is built on top of the core APIs. The idea of building Beam APIs on top of this looks like the API stack is getting too tall... 3 levels!!   Like a tower of cards.
In practice, not a great idea from the debugging/monitoring/other perspectives ... IMO.

Let's not worry about Beam API. Stream API is needed for Storm itself, not only for supporting Beam. Once we make shape a stream public API set, we could change internal state if we really need.

@arunmahadevan
Btw, I'm seeing some failures with Redis state backend: StatefulWordCount and StateQueryExample. They're running fine with removing Redis state backend setting.
Could you take a look if you have time?

I just have a look at other streaming frameworks API, and feel that this is a good start. We can still add features after this patch.
I'm OK to add this for 2.0.0, but am also OK to add this for 1.x for experimental purpose. (No strong opinion since it involves additional works.)
Since this is a huge change and introduce a brand new API set, I'd like to wait for more people to gather more reviews and also opinions.

@HeartSaVioR thanks for taking time to review and provide feedback. The Redis state was working for me earlier however after rebasing with master I am seeing exceptions (triggered from kryo) and I think it may be due to multiple threads using the same kryo instance. I will look into this and other comments.

One  important thing to include in this API will be to allow users to be explicit about how to handle  errors.  I don't know if any API out there does it... so this would be unique to Storm.
In short:
Broadly speaking there are two kinds of tuple process errors that the users need to be concerned about:
1- Retry worthy Errors - For instance, failure to deliver to destination service due to connection issues.
2- Not worth retrying - For instance, Parsing errors due to bad data in the tuple. These problems can jam up the pipeline if they are retried repeatedly. Such tuples can be sent to a configurable Dead-Letter-Queue.

@roshannaik

1- Retry worthy Errors

Right now theres no explicit fail api. When a stage in the stream completes processing (and possibly emits results), the underlying tuples are acked automatically. The only way spout will re-emit is after the message timeout. It may be good to have a fail fast api, but I am not sure how it would help since the replayed tuple could fail again in processing. Instead the processing logic itself can have some retry logic (say retry 3 times) and forward to an error stream  and ack the tuple.

2- Not worth retrying

This can be handled via branch logic. E.g. send valid values to stream1 and bad values to stream2.
I have opened https://issues.apache.org/jira/browse/STORM-2282 to discuss ideas around this and see what apis can be added.

@HeartSaVioR have addressed the comments and fixed the issue with state handling. StatefulWordCount and StateQueryExample works fine for me locally.

@arunmahadevan Could we have separate patch for state handling? We should push the fix for 1.x and 1.0.x branches.

@HeartSaVioR sure will raise as separate PR with the specific fix for state handling.
If we plan to consider this PR for 1.x branch need to do some refactoring to make it work with Java 7 unless we plan to move 1.x to Java 1.8 soon.

@arunmahadevan
Its ok to keep retry-ing errors that are considered retry-worthy. The non-retry worthy are the ones we must fail fast and move them out as they will cause a jam and prevent good tuples from flowing. Also no good way to recover from that.
One approach to do this...
For non-retry worthy error conditions (like bad data), any processing element in the pipeline can throw a specific exception. This can then be handled by the runtime to send to a configurable dead letter queue. Ideally this needs a new kind of Fail() notification in the spout to avoid re-emit. Alternatively, we can send the spout an ACK instead of FAIL to avoid retry. The DeadLetterQ bolt's metrics will capture these failure metrics. Best to no have each spout/bolt explicitly deal with dead letter queue ... that will complicate the topology definition...as every spout bolt will need to be configured and wired up to do this.
For retry-worthy errors (timeouts, destination unavailable, etc)... perhaps no special treatment is required as the existing retry mechanism will kick in.
However in today's core API, there is one pain point for spout writers. Each spout needs to implement the logic to track inflight tuples and attempt retry on fail(). The implementation is moderately complicated as ACKs/Fails can come in any order. All the spouts have to do the same thing but end up doing slightly differently. Some how retry limits, some dont. This retry logic should ideally be lifted out of the Spout and handled in the API. This new API is a good opportunity to fix this issue.

@roshannaik yes, it can be useful if we can come up with the right way to expose it. We can discuss this further in https://issues.apache.org/jira/browse/STORM-2282

@revans2 @ptgoetz pinging again for review.

@arunmahadevan I will try to find time to take a look at it soon.  Sorry for the delay.

@revans2 thanks for taking the time to review.

I really would like to see how triggers and exactly once processing might fit into this. Not that we need it right now, but just that I would like to see how you would fit it in, because I can see how I might do it, but I would like to hear from others about it.

Right now the stateful operations (aggregations, join etc) uses an in-memory map to maintain state and relies on storm's acking mechanism to replay and rebuild the state. For exactly once we can build support at the storm framework level (e.g. enhance the stateful bolts) so that operations like aggregations and join can use the underlying framework state to maintain its state. Initial ideas are here - https://docs.google.com/document/d/1Ew7uFF1UJ6e_zq0t4bM6A9auuEaArviAjjWYSpVFqPY/edit#heading=h.nmf14n.
Anyways this needs longer discussion. Would be great if you can share your ideas in the doc or in the JIRA https://issues.apache.org/jira/browse/STORM-2155

@revans2 @HeartSaVioR any further comments on the patch? I think it would be nice to get it merged soon and get feedback from potential users. The apis are marked unstable right now. Will follow up this patch with a how to/primer for users to get started.

@arunmahadevan I'm just waiting for other committers' review, and IMO once @revans2 is OK to merge we can merge this.

@HeartSaVioR and @arunmahadevan sorry I have been busy with other things.  I have not seen anything that I would consider to be blocking and since the API is marked as changing I am +1 to merge it in.

+1


[Release and Roadmap] update outdated OpenSDS data and add SODA Roadmap

Issue/Feature Description:
update outdated OpenSDS data and add SODA Roadmap - https://docs.sodafoundation.io/releases/
Why this issue to fixed / feature is needed(give scenarios or use cases):
Outdated document content on the roadmap and releases
How to reproduce, in case of a bug:
NA
Other Notes /  Environment Information: (Please give the env information, log link or any useful information for this issue)
NA

Updated SODA Roadmap and Elba Release info. (Fixed)


License information at print time

The license information of the dataset is associated with every subject of the dataset. Hence, the text information is printed each time the subject or the dataset is printed. It would be great if a minor cosmetic change is made such that the data is only printed once. This will make the print data very readable and eliminate the need to scroll endless pages if the license file is large.

Fixed in #124.


Dont exclude benchmarks from MANIFEST.in, need them for sample Balls

References and relevant issues
Closes: https://github.com/napari/napari/issues/7185
Description
Balls were added to sample images in https://github.com/napari/napari/pull/6527 but the manifest wasn't updated to not exclude napari/benchmarks. This PR updates the manifest so benchmarks is in the wheel.
Hopefully in https://github.com/napari/napari/pull/7186 we can make CI fail with current main and then this PR will fix it.

Or maybe it's better to just add this change to the other PR once we have tests failing? Your call!

The #7186 reach state of properly failing tests.
It is good brick, but I think it may require add proper explanation. I try to add some basics here https://napari.zulipchat.com/#narrow/stream/212875-general/topic/Problem.20with.20installing.20from.20source.2Fbuild.20--wheel/near/462302314
But I will be happy if you get my commit into this PR and add explanation for future us to avoid problems in future.

Maybe it's better the other way? put the fix in your PR to confirm CI will pass?

Closed in favor of https://github.com/napari/napari/pull/7186


cl.user_followers(user_id, amount=10) dont return story timestamp,

I al trying to check the followers of a profile, and I want to also retrieve data:
from instagrapi import Client

ACCOUNT_USERNAME = 'xxx'
ACCOUNT_PASSWORD = 'xxx'
cl = Client()
cl.login(ACCOUNT_USERNAME, ACCOUNT_PASSWORD)

user_id = '12345436465'
followers = cl.user_followers(user_id, amount=10)

The data I am getting is :

although it say include reels, I dont see any story data (I checked story exists on some users)

here is the issue

class UserShort(TypesBaseModel):
def hash(self):
return hash(self.pk)
def __eq__(self, other):
    if isinstance(other, UserShort):
        return self.pk == other.pk
    return NotImplemented

pk: str
username: Optional[str] = None
username: Optional[str]
full_name: Optional[str] = ""
profile_pic_url: Optional[HttpUrl] = None
profile_pic_url_hd: Optional[HttpUrl] = None
is_private: Optional[bool] = None
is_verified: Optional[bool]  # not found in hashtag_medias_v1
latest_reel_media: Optional[int]
has_anonymous_profile_picture: Optional[bool]
# stories: List = [] # not found in fbsearch_suggested_profiles


[DOC] Fix markdown syntax in natural gradient example

Pull Request Test Coverage Report for Build<PHONE_NUMBER>7
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
56 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-3.7%) to 88.786%

Files with Coverage Reduction
New Missed Lines
%

curvlinops/examples/utils.py
10
31.25%

curvlinops/fisher.py
46
26.47%

Totals

Change from base Build<PHONE_NUMBER>3:
-3.7%

Covered Lines:
1346

Relevant Lines:
1516

💛  - Coveralls


tsconfig paths not works

Describe the bug
Hi. I just tried to upgrade @ladle/react from v2.4.5 to v2.11.1, and met this problem:

My project is a nx monorepo, and ladle is an app. @/... is actually a lib consumed by other apps. With the tsconfig:
"compilerOptions": {
    "paths": {
      // align with apps tsconfig
      "@/*": ["../app-shared/*"],
    },
	"include": [
      "**/*",
      "./.ladle/**/*",
      "../app-shared/**/*",
    ]
  },

it worked quite well originally.
Looking up release logs, I wonder the problem has something to do with this patch?
Environment

OS: WSL2
Version 2.11.1

Are you using yarn pnp? If so, 2.11.1 disables vite-tsconfig-paths in pnp environment. We had some issues with it in our internal monorepo but it might be specific to our (pretty complicated) setup. You can add it back by creating your own vite.config.js.

Nope, I don't. But I do have customized vite.config.ts for configuring pubicDir. Might it be the cause?
// vite.config.js
/**
 * @type  {import("vite").UserConfig}
 */
export default {
  publicDir: "public",
};

Hi, my case is less simpler, so I made some extractions to demo the issue: https://github.com/donrsh/issue-ladle-tsconfig-path-not-work

it got broken by updating<EMAIL_ADDRESS>to<EMAIL_ADDRESS>going to pin it down in Ladle to 3.6.0
in meantime, you can fix your setup by adding this into package.json
"resolutions": {
  "vite-tsconfig-paths": "3.6.0"
},


Enable  ESLint: `jsdoc/require-returns-description'

Currently .eslintrc.js has this line:
'jsdoc/require-returns-description': 'off',
Need to change this to:
'jsdoc/require-returns-description': 'on',
Then deal with the lint complaints

More to do


TypeError: (0 , _createTheme.default) is not a function

Steps to reproduce
Upgrade as follows leaves a working application unable to load.
                 "@ckeditor/ckeditor5-theme-lark": "^41.2.0",
                 "@ckeditor/ckeditor5-typing": "^41.2.0",
-                "@emotion/react": "^11.11.3",
+                "@emotion/react": "^11.11.4",
                 "@emotion/styled": "^11.11.0",
-                "@mui/icons-material": "^5.15.7",
-                "@mui/material": "^5.15.7",
-                "@mui/utils": "^5.15.7",
+                "@mui/icons-material": "^5.15.12",
+                "@mui/material": "^5.15.12",
+                "@mui/utils": "^5.15.12",
                 "@mui/x-date-pickers": "^6.19.2",
                 "@mui/x-tree-view": "^6.17.0",

The following code in the generated bundle fails
// Update /system/styled/#api in case if this changes
function shouldForwardProp(prop) {
  return prop !== 'ownerState' && prop !== 'theme' && prop !== 'sx' && prop !== 'as';
}
const systemDefaultTheme = exports.systemDefaultTheme = (0, _createTheme.default)();
const lowercaseFirstLetter = string => {
  if (!string) {
    return string;
  }
  return string.charAt(0).toLowerCase() + string.slice(1);
};

with the error createStyled.js:41 Uncaught (in promise) TypeError: (0 , _createTheme.default) is not a function
Current behavior
The application fails with a script error on startup.
Expected behavior
The generated bundle should allow the application to startup.
Context
No response
Your environment

npx @mui/envinfo
  System:
    OS: Linux 6.5 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
  Binaries:
    Node: 18.18.2 - ~/.nvm/versions/node/v18.18.2/bin/node
    npm: 10.5.0 - ~/.nvm/versions/node/v18.18.2/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: 122.0.6261.111
  npmPackages:
    @emotion/react:  11.11.4
    @emotion/styled:  11.11.0
    @mui/base:  5.0.0-beta.38
    @mui/core-downloads-tracker:  5.15.12
    @mui/icons-material:  5.15.12
    @mui/material:  5.15.12
    @mui/private-theming:  5.15.12
    @mui/styled-engine:  5.15.11
    @mui/system:  5.15.12
    @mui/types:  7.2.13
    @mui/utils:  5.15.12
    @mui/x-date-pickers:  6.19.2
    @mui/x-tree-view:  6.17.0
    @types/react:  18.2.65
    react:  18.2.0
    react-dom:  18.2.0
    typescript:  5.3.3

Search keywords: createTheme

Hello.
I've recently upgrated to 5.15.12 myself and also got my app broken. The error is similar:
_styledEngine$1.internal_processStyles) is not a function. Hope, this can help. Will try to override some of subdeps to bypass this.
While tracking this I've noted that doc says:

By default, @mui/material has @mui/styled-engine as a dependency.

But I can't see that to be the case. If someone could assist me with this issue and my findings that would be very nice.

Please provide a minimal reproduction.

Have you found a way to solve this issue? I am currently facing this problem too.

@juanpamm I've managed to fix my issue with this https://github.com/mui/material-ui/issues/33875#issuecomment-2063585831

@StreetStrider thanks for answering. I actually found a way to fix it (or so it seems). I had to downgrade:

@mui/material from version 5.15.17 to 5.15.7
@emotion/styled from version 11.11.5 to 11.11.0
@emotion/react from version 11.11.4 to 11.11.3

I also removed ^ from the versions of those packages in the package.json.

I think I have got to the bottom of this now:
In my rollup config I had the @rollup/plugin-commonjs plugin with the configuration as follows:
commonjs({
    ignoreGlobal: true,
    requireReturnsDefault: 'auto'
})

it is specifically the requireReturnsDefault which is causing the issue. Setting this property to false resolves this bundling issue. I'm not sure of the implications of that setting at the moment, but a quick check through my app seems to have everything working now.
You can read more about the config options for that plugin here. git link
I hope this helps others who were experiencing this issue.


Start on multiple hosts

Description
It seems as if it is not possible to start using multiple IPs/hosts. I've tried separating by comma, but thats throwing an error. As of now it seems that it's only possible to use one host or all ...
Suggested solution
add support for multiple hosts (perferrably as array: host: string | boolean | array).
Alternative
No response
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Can you explain why you want to start on multiple host? Node.js createServer only supports starting on one host (unless DNS could resolve multiple different hosts to this one).

Can you explain why you want to start on multiple host? Node.js createServer only supports starting on one host (unless DNS could resolve multiple different hosts to this one).

multiple sub-domain, eg laravel route support multiple domain and php artisan serve not support ssl, so just can use vite/apache to run ssl to dev

I suppose we can call .listen() multiple times to support multiple hosts, but it doesn't seem like a common usecase. There's the same discussion in webpack: https://github.com/webpack/webpack-dev-server/issues/400

I am currently facing the same issue. The app will run on multiple subdomains in production and I need to replicate this for development.

facing the same issue. I would like to run an instance for each of the environments: mock data environment, dev environment and production environment simultaneously

I have a use case for this as well (originally reported in https://github.com/vitejs/vite/issues/18469)
TLDR: I want vite to run on IPv4 (<IP_ADDRESS>) and IPv6 (::1) simultaneously to make it easier for us to use a custom domain for local development (e.g. local.example.com points to either <IP_ADDRESS> or ::1, but we don't know if the developer uses IPv4 or IPv6 on their machine, local.example.com can use IPv4 while localhost uses IPv6, leading to a mismatch)
My workaround ended up being this, so it's still just listening on a single host, but we're smarter about how to pick it:
const { family } = await dns.promises.lookup("local.example.com");

export default defineConfig({
	plugins: [tsconfigPaths(), react()],
	server: {
		port: 3000,
		host: family === 6 ? "::1" : "<IP_ADDRESS>",
	},
});


Empty pages built when paginating collection on homepage

Description
Following the docs, I'm paginating a blog posts collection, which I then show on my site's homepage.
The actual file generated at dist/2/index.html (and so on), is empty: it contains the 404 page contents, instead of the HTML with blog posts, like dist/index.html does.
Steps to reproduce
For a quick test, see this demo page - you should see a 404. Of course, when going to the homepage and then navigating (with JS enabled) to it from the bottom nav, it works, because Vue takes care of that...
Oddly, paginated taxonomy pages, i.e. category-name/2/ are built perfectly fine.
I have the following config:
// gridsome.config.js
module.exports = {
  siteName: 'Gridsome Starter Blog',
  titleTemplate: `%s | Gridsome`,
  plugins: [
    {
      use: '@gridsome/source-filesystem',
      options: {
        path: 'content/posts/**/*.md',
        typeName: 'Post',
        route: '/:category/:title-:year:month:day',
        refs: {
          category: {
            typeName: 'Category',
            route: '/:title',
            create: true
          },
        }
      }
    },
  ],
}

In src/pages/Index.vue, I have the following <page-query>:
<page-query>
  query Home ($page: Int) {
    allPost (page: $page, perPage: 2) @paginate {
      totalCount
      pageInfo {
        totalPages
        currentPage
      }
      edges {
        node {
          _id
          title
          date (format: "D MMMM, YYYY")
          datetime: date (format: "YYYY-MM-DD HH:mm:ss")
          content
          excerpt
          path
          image
          category {
            title
          }
        }
      }
    }
  }
</page-query>

Finally, I have 3 markdown posts in content/posts, to make sure a second index page is generated.
Expected result
dist/2/index.html should contain the posts from page 2 of the site, as displayed when loaded by Vue.
Actual result
dist/2/index.html has the 404 content. File is indeed output, but the content is not there. This happens to all following pages, so /3/, /4/ and so on are also 'empty'.
This is what it contains:
<!DOCTYPE html>

    <title data-vue-tag="true">Gridsome Starter Blog | Gridsome</title><meta data-vue-tag="true" charset="utf-8"/><meta data-vue-tag="true" name="generator" content="Gridsome v0.5.0"/><meta data-vue-tag="true" data-key="viewport" name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover"/><meta data-vue-tag="true" data-key="description" name="description" content=""/><meta data-vue-tag="true" data-key="format-detection" name="format-detection" content="telephone=no"/><link data-vue-tag="true" rel="icon" type="image/png" sizes="16x16" href="/assets/static/favicon.ce0531f.efcb514.png"/><link data-vue-tag="true" rel="icon" type="image/png" sizes="32x32" href="/assets/static/favicon.ac8d93a.efcb514.png"/><link data-vue-tag="true" rel="icon" type="image/png" sizes="96x96" href="/assets/static/favicon.b9532cc.efcb514.png"/><link data-vue-tag="true" rel="apple-touch-icon" type="image/png" sizes="76x76" href="/assets/static/favicon.f22e9f3.efcb514.png"/><link data-vue-tag="true" rel="apple-touch-icon" type="image/png" sizes="152x152" href="/assets/static/favicon.62d22cb.efcb514.png"/><link data-vue-tag="true" rel="apple-touch-icon" type="image/png" sizes="120x120" href="/assets/static/favicon.1539b60.efcb514.png"/><link data-vue-tag="true" rel="apple-touch-icon" type="image/png" sizes="167x167" href="/assets/static/favicon.dc0cdc5.efcb514.png"/><link data-vue-tag="true" rel="apple-touch-icon" type="image/png" sizes="180x180" href="/assets/static/favicon.7b22250.efcb514.png"/><link data-vue-tag="true" rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,400,700%7CHind+Madurai:400,500&amp;subset=latin-ext"/><link rel="preload" href="/assets/css/styles.76a9a8cc.css" as="style"><link rel="preload" href="/assets/js/app.e7cec1f7.js" as="script"><link rel="preload" href="/assets/js/component--404.87245fb2.js" as="script"><link rel="prefetch" href="/assets/js/component--category.59116350.js"><link rel="prefetch" href="/assets/js/component--home.006d5547.js"><link rel="prefetch" href="/assets/js/component--post.91f8a3a2.js"><link rel="prefetch" href="/assets/js/page-query.584d3c2f.js"><link rel="stylesheet" href="/assets/css/styles.76a9a8cc.css">

404 - not found

I should also add that I've tried other routes for the collections. For example, this yields the same results:
plugins: [
    {
      use: '@gridsome/source-filesystem',
      options: {
        path: 'content/posts/**/*.md',
        typeName: 'Post',
        route: '/:title',
        refs: {
          category: {
            typeName: 'Category',
            route: '/categories/:slug',
            create: true
          },
        }
      }
    },
  ],

Looks like there is a bug with root level pagination. I'll fix it in the next update.

Got excited when I saw 0.5.2, so I went ahead and updated it and @gridsome/transformer-remark to 0.2.1. Ran gridsome build and it now seems files are output properly - the page at /2/ has the right content.
However there's now something else wrong, this time when Vue takes over:
Error: Cannot find module './/index.json'
    at page-query.51f1a430.js:1

You can check it at the same link. Apologies if you're already aware of it - no pressure :)

Oh, I'll try to publish a fix asap :)

Published 0.5.3 now. Should fix this issue :)

Yes, 0.5.3 has fixed it 🎉
Thank you!


Update the project links on the community page

What kind of change does this PR introduce?
Updated the dead links on the community page and added one more project with physical computing + ml5 — I thought it'd be useful to show ml5 applied outside the browser window, but let me know if it's not the right project for this!

Hi @yonaymoris. Thanks for the update here. It looks like about 33 or so additional files were updated in your last PR due to what looks like linting changes. Was this intentional?

No, I think I ran yarn format before pushing the changes, and that's what happened.
Apologizing for a dumb question, would you mind guiding me on how to add in those configs?

Hi Yona. Apologies for the very delayed response here. I got caught up trying to find a new job and I forgot to follow up on this PR! Your contribution is very appreciated!
My suggestion is to focus this PR on the helpful updates to the Community page. To get this PR ready, let's start by removing the large number of lint-related changes here and focusing only on the additions that you included by hand. Then, if you're interested, we can talk about how you could create a separate PR that adds a great linting approach to this entire codebase for all contributors. How does that sound?
In case it's useful, I'll share how I'd approach removing the lint-related changes from the PR. You may already be familiar with these steps; adding the details here just in case it could be useful (to you or to someone who looks at this commit in the future). One approach you could take to fixing this is the following:

Change to the branch yonaymoris:yona-communityp-fixes with git checkout yona-communityp-fixes.
Run git log. Assuming you haven't made other changes to this branch, the latest commit (at the top) should be called "Remove the extra project".
Run git reset HEAD~1. This will tell Git to undo the last commit, but leave all of the file changes intact. This is similar to what the state of the repo would look like right before you ran git commit -am .... to make the commit we just reset. The HEAD~1 is essentially like saying "go back to one commit behind most recent commit`.
Run git status. You should now see all of the files that were changed in the commit we just undid. They should be unstaged (showing up as red in many terminals).
Run git add <file path> for the specific files you intended to change (e.g the files you updated in the docs/ directory, etc).
 Note that we want to avoid running git commit -am because the -am flag will automatically stage all of the other files we don't want to add.
Lastly, update this branch with git push --force. This force push is necessary because we change the commit history on this branch by resetting a commit and replacing it with a new one.

That's it! Let me know how it goes or if I can be helpful! I'll prioritize quick follow-ups here to reconcile for my delay in responding.

Apologies! This got cloned temporarily while I was updating the default branch from master to main. Looking forward to your updates here if you'd still like to edit this PR!

Thanks, Bomani!
Working on another PR now!

Hi Bomani. Sorry, I got caught up in the finals and internship hunting. I just pushed a new commit which should be fine with the updated links in the markdown. There is still the change in the hello.js file left from seems like even older commits, I checked it, and seems like it wrapped the last function into brackets for some reason (?) which is interesting.

This should now be live!


Readme file need to be  changed, Missing mode = "wb"

Missing mode = "wb"
https://github.com/mhpob/otndo/blob/main/R/make_tag_push_summary.R#L24 use the function's example for now

Closed by 72feefa707e2e3c7d5aec36f34856e15a3125be4