Add comments to simulation templates

In the future, we may want to learn a mapping of the form:
text description ---> template script for simulator x
for that, we will need to have training data that contains both the text description and the script.
We need:

abstract.txt for EACH template file
comments on each template explaining what each line "does"

Closing this, since this are attached to the scenarios which are being moved from this repository.


Establish Logging and Progress Dashboard HL7 data feed from PHIN MS into DEX

With the aid of Databricks and access to the Parquet files, add logging and general status information.

The current databricks process that is used for bulk loading of the old data is currently logging its run. The logging process for this system will need to be improved some, but should be done today or early tomorrow.

Now that the methodology and permissions for the final 'daily step', to copy the files pulled from PHINMS DB into PHINMS, and now adding a last step to copy from the PHINMS directory where the records are created, backed up and logged.then copy these records will be copied daily to 'hl7ingress'.  The pieces for the dashboard are now in place and will be collected for a dashboard.

Established process to map information to temporary Dataframes then to Parquet files that will be informational pieces for the dashboard.

Also working on documenting the above processes.


Change data fields in view response

I get this response from a  "Select2QuerySetSequenceView":
{"pagination": {"more": false}, "results": [{"text": "Mymodel", "id": null, "children": [{"text": "  first_unicode   ", "id": "23-firstmodelfield"}, {"text": "  second_unicode", "id": "23-firstmodelfield"}]}
I've seen that select2 allow to change id by:

https://select2.github.io/options.html#my-objects-dont-use-id-for-their-unique-identifiers-what-can-i

I ask you if it is there a way to tell autocomplete to use another value for the id, to have it in the response ? i.e. "id": 23-thirdmodelfield
without acting on the frontend?
I use autocomplete to retrieve values, to be inserted in a field that is a simple text field, no link in any table.
So I'd like to put the id = textvalue so the field result is compiled with only that, no id, no pk.

Perhaps in (view.get_result_value)[
http://django-autocomplete-light.readthedocs.org/en/master/api.html#dal.views.BaseQuerySetView.get_result_value]
?

Thanks for fast reply, I was a little lost, now I get it!
Thanks again, the docs is good, but searching in it when you have no idea of where to look is a little complex.
Have a nice day!


REQ plz Add En Lange

Hi
plz add En Lange .
thanks a  lot.

We will consider adding this later. Thank you.

up++++


sunstone save as template dialog does not honour instantiate_persistent setting

Description
tabs/vms-tab/dialogs/saveas-template/html.hbs does not have any hiding the persistence option based on the setting of features.instantiate_persistent in the view config. If this value is false the checkbox should be hidden
Details

Affected Component: Sunstone
Version: 5.10.1

Progress Status

[ ] Branch created
[ ] Code committed to development branch
[ ] Testing - QA
[ ] Documentation
[ ] Release notes - resolved issues, compatibility, known issues
[ ] Code committed to upstream release/hotfix branches
[ ] Documentation committed to upstream release/hotfix branches

The Make the new images persistent checkbox at Save as Template dialog can be used even if the VM is not instantiated as persistent because both are different ways to obtain the same result.

Make the new images persistent generates a new VM Template with a copy of all the images located at the current VM, this can be done at any moment while your VM has the state POWEROFF.

Instantiate as persistent option creates a new VM with is persistent, but this is done when the user is creating a VM.

In this case the features.instantiate_persistent in the view config is about the Instantiate as persistent option and this checkbox at tabs/vms-tab/dialogs/saveas-template/html.hbs makes reference to Make the new images persistent option.
We will close this issue and wait for your feedback.

Thanks for the information. However the main issue is that I see no way currently in the template to change the config to disable this option from being shown to users - can this be patched?

Thanks for you feedback.
Sunstone does not provide customization at this level of detail. The "instantiate as persistent" option is a special case since it can over populate the VM Template catalog


Enhanced HollowHistoryTypeKeyIndex with Optimized Mappings and Memoization

This PR significantly optimizes HollowHistoryTypeKeyIndex by eliminating unnecessary round trips for state updates, leading to substantial improvements in performance and memory management.
In this newly proposed architecture, HollowHistoryTypeKeyIndex manages several associations:

Hashed ordinals mapped to assigned ordinals (open addressing/linear probing)
Hashed fields mapped to assigned ordinals (Java hashmap)
Assigned ordinals mappedto their respective object field arrays (Java hashmap)

The primary advantages of this approach include:

Efficient Updates: State updates no longer require round trips; instead, mappings are updated based on the latest typeState.
Instant Storing and Hashing: Keys are stored and hashed immediately upon an update, eliminating the previously required indirection.
Significant Memory Usage Reduction: Instead of storing every record as an individual POJO in each state, identical boxed primitives are memoized and stored as references to the same object.
Improved Query Performance: Direct lookups in a hashmap now facilitate faster querying, bypassing the need to traverse the readStateEngine.

To support this optimized implementation, I'm introducing two new helper classes, HollowOrdinalMapper and ObjectInternPool.
HollowOrdinalMapper is designed to manage the mapping of hashed ordinals to assigned ordinals. It leverages an open addressed linear probing hash table to store these mappings, preventing key overwriting, even in edge cases where different keys have the same hash. This was previously done within the HollowHistoryTypeKeyIndex class, but it makes sense to decouple.
ObjectInternPool, on the other hand, focuses on the memoization of objects. Given that many states store identical keys, it is efficient to maintain references to a single boxed primitive rather than multiple. This class stores these boxed primitives, and if an object with an exact copy is interned, a reference to the existing copy is returned and the duplicate object is deallocated by the GC. A future PR will extend this feature to the HollowHistory class, allowing for history-wide (version agnostic) memoization. would likely reduce performance due to synchronization requirement
Overall, these modifications render HollowHistoryTypeKeyIndex more concise, decreasing the class from ~550 lines to about 250, enhancing readability in the process.
The impact of these changes on performance is substantial. Preliminary profiling indicates a 3-4 times faster history processing speed. Moreover, as the older implementation stored a full read/write state, ordinal mapping, hash mapping, and lacked memoization, I'd expect a memory usage reduction by over 50% (will test later).
Todos

[x] Implement support for multi-field key delimiters during queries
[x] Store field values by object, rather than by string
[x] Fix potential hash collision edge case where records are not equal but hashes are
[x] Implement memoization for fields

[x] Strings: intern() builtin
[x] Other (long, float, etc): implement intern equivalent
[ ] Bytearray (will likely not intern these due to high overhead, will change intern class to reflect later today)

[x] Support rehashing open-addressed table

Unit/integration tests for potential sources of bugs (or make sure they already exist):

[x] Unit tests for ObjectInternPool
[x] Record hash collision test (distinct keys, equal hashes)
[x] Rehashing/hash table expansion tests

Profiler screenshots to illustrate the performance improvements
Note the stack percentages in the bottom left
Old implementation

New implementation

Hi Steve, thanks for putting this together. I'll review today.

Can you expand on why indexing into an array will be limiting? I’m not sure
I’m on the same page because the previous implementation also used integer
arrays for ordinal mappings.
On Sat, Jul 1, 2023 at 1:32 AM Sunjeet @.***> wrote:

@.**** commented on this pull request.
In
hollow/src/main/java/com/netflix/hollow/tools/history/keyindex/HollowOrdinalMapper.java
https://github.com/Netflix/hollow/pull/624#discussion_r1248515169:

+import com.netflix.hollow.core.index.key.PrimaryKey;
+import com.netflix.hollow.core.memory.encoding.HashCodes;
+import com.netflix.hollow.core.read.HollowReadFieldUtils;
+import com.netflix.hollow.core.read.engine.object.HollowObjectTypeReadState;
+import com.netflix.hollow.core.schema.HollowObjectSchema;
+import com.netflix.hollow.tools.util.ObjectInternPool;

+import static com.netflix.hollow.core.HollowConstants.ORDINAL_NONE;
+import java.util.Arrays;
+import java.util.HashMap;
+
+public class HollowOrdinalMapper {

private int size = 0;
private static final double LOAD_FACTOR = 0.7;

private Integer[] ordinalMappings;

Indexing into an array will be limiting. For e.g. some datasets churn ~5
million modification+removals a day. But maybe ok for the scope of this PR,
and something we can scale in future. Or we could consider reusing Hollow's
FixedLengthElementArray here- it's indexed into using long and it would
also be more compact.
—
Reply to this email directly, view it on GitHub
https://github.com/Netflix/hollow/pull/624#pullrequestreview-1508250885,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALJL7FY7ZTNECIG6HX55KR3XN6ZAFANCNFSM6AAAAAAZQVBWQE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Update for anyone tracking this - met with @Sunjeet, will have requested changes ready shortly

The latest changes look good. Test has been running for 5 days on our most complex dataset, the resulting history views look good and performance improvements are maintained. I'm now confident about merging this in.
The only remaining concern is with corruption happening when double snapshots are incurred. I dont see that as blocking this PR merge, since double snapshots are believed to be buggy in the original impl. But this will be followed by a change to fail hard when History sees an incoming double snapshot- to avoid silent corruption.
Double snapshots would be useful for handling schema changes dynamically. The path fwd for handling schema changes will be to be able to apply them as a part of delta updates (TODO for core hollow), and the interim workaround is to initialize a new instance of HollowHistory and discard the old one.
To summarize the improvements attained in this PR,

heap size is the same as before
cpu util is about 1/3rd as compared to before
consumer refreshes are about 2.5x faster (down from ~50s to ~20s)

Thank you for the contribution @stevenewald


Refactor docstring params

[x] Closes #1574 among other updates. See bottom of PR body.
[x] I am familiar with the contributing guidelines
~[ ] Tests added~
~[ ] Updates entries in docs/sphinx/source/reference for API changes.~
~[ ] Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).~
[x] Current code includes numpydoc compliant docstrings, examples, and comments everywhere.
[x] Pull request is nearly complete and ready for detailed review.
[ ] Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

I just want the docstrings to be homogeneus and compliant with numpydoc.
Changes in this PR

Adds a space before colon in parameters and returns
solar_azimuth: numeric -> solar_azimuth : numeric
Changes excessive use of parentheses in defaults
return_components : bool (optional, default=False) -> return_components : bool, default False
Removes colon when default is to be specified
logical_records : list or tuple, default: ('0100',) -> logical_records : list or tuple, default ('0100',)
default None -> optional (#1574)
See also -> See Also

Thanks for submitting this PR @echedey-ls!
I think the main priority for docstring formatting is that the sphinx HTML output is correctly rendered.  Since spaces before colons and See Also versus See also don't make any difference in the HTML, I don't think those are really needed.  The cost of changing them is that it clutters the git blame, which is only a minor problem, but still enough to want to avoid making these kinds of sweeping changes without a good reason for it IMHO.
For changing default None to optional, I think that is good.  But probably some of the parameter descriptions should be updated as well.  For example in pvlib.clearsky.detect_clearsky it now says:
    times : DatetimeIndex, optional
        Times of measured and clearsky values. If None the index of measured
        will be used.

Since None is no longer mentioned as the default value, I think the description needs to change to If not specified, ... instead.  There are other cases like this too (e.g. surface_type in pvlib.irradiance.get_ground_diffuse and many parameters in pvlib.modelchain.basic_chain).

Good points. I forgot to add an explanation to what I really want to address since I've been travelling a bit and didn't bother to check what I had written.
I intend to open a PR to hint contributors of docstring errors. I've come up to two options that may be useful. Both may be used at the same time:

suggest running the command python -m numpydoc --validate pvlib.module.func in the PR template and/or the contributing guidelines, so it can be tested quickly. From numpydoc validation, this section.
in the sphinx-build job (well, in the conf.py file). See this section of numpydoc.

Also, they recently added a pre-commit hook, although I feel that is a bit overwhelming to add to pvlib since it is currently not being used, I believe.
Anyway, for choice 1, it doesn't mind having these "issues" in the docstrings, since contributor would only apply the checker to their function/class/method... The problem with that is that I haven't found a way to include/exclude rules (it checks all of them) and that's definitely not desired. Some rules just don't apply to the pvlib style, like mandatory examples section, some punctuation or capitalisation, but users may not know of that. Adding a grep pipe to the output might be the hardcoded way to do so but it may be OS dependent.
Some work on this may be found at numpy/numpydoc#459
On the other hand, choice 2 allows to check for a custom subset of rules, so there is a cleaner output. However, it checks all sphinx docstrings. This PR would allow using the most of them that seem useful. For example, the "See Also" change allows using the rule that checks that all sections exists (it raises a warning for all of them). Adding a space before a colon and removing parentheses makes the default validator parse the argument name and the type correctly. To sum it up, most of the changes in this PR remove false positives and typos that mess with the validator, as a previous step. Personally, I like this option the most.
And these superfluous changes, well, since they almost don't have an impact on the docs, I thought of doing them via an independent PR. So checking another PR with the tool is not a pain (I'm aware this one is).
I will check the default None and clean those docstrings in the following days.

Thanks for this in-depth research @echedey-ls :)
One thing relevant especially for option 2 is that we don't actually use numpydoc, we use the napoleon sphinx extension (#691).  I'm guessing that enabling both of them in the build would cause problems, but I don't know that for sure.

I'm guessing that enabling both of them in the build would cause problems, but I don't know that for sure.

Good point, it does.
I will pursue choice 1, but I'd like to wait for the numpydoc issue to get resolved then.
Thanks for the review. Which changes should I keep? Changes 2 to 4 in the "changes" section from PR body?

Continued work over #1828


Implement the RangeCoder

[ ] Implement/use a bitstream reader
[ ] Implement/use a reverse bitstream reader
[ ] Implement the actual RangeCoder

@lu-zero This is fantastic! I am going to start here tonight.
Do you know of any tests/data I could run against the RangeDecoder? Just to make sure it works as expected.
If not I will just dump some input/output results from ffmpeg's implementation.

here there are two unit tests that I used, if you want to extend them it is relatively easy to produce them and possibly a good idea :)

@lu-zero I just pushed a basic range decoder! I mostly learned from reading yours and the ffmpeg implementation (and have some questions)
ffmpeg and your implementation mostly uses the cdf decode method for decode, and then logp. Is that the right way to go?

Yes, rawbits and the other methods are for celt.


Bug Fixes in ERMrestJS

Make sure we're hiding the foreignkey from related table to the main, in compact/breif/inline too (we're doing it only for compact/inline).
Add numeric column type to use facet range picker by default.
Add $fkeys support to page.content

This commit fixes all these three bugs and adds test cases for them.
@hongsudt can you please verify these?

It is now working here:
https://dev.rebuildingakidney.org/chaise/record/#2/Cell_Line:Mouse_Strain/RID=Q-2CP0


[5.3] IRGen: Store scalars as bytes to avoid undefined bits

Don't tempt llvm to misbehave on partially initialized bytes -- it will.
Explanation: Before this patch we would store integer types of non
integral byte widths (e.g i1) with llvm store instructions of the same type. The
semantics of a load of a differently sized store for such non-integral
sized byte widths is undefined in LLVM. And indeed LLVM ends up misoptimizing
code involving a combination of a full byte store and a partial bit store,
such as the attached test case.
Scope: This changes how we store non integral byte sized integer values.
Risk: Low, instead of storing an i1 we store a i8 which in hardware is
the same byte store.
Testing: Regression test added
Reviewed by: Joe Groff
rdar://67408302
Original PR: #33485

@swift-ci please test windows

The windows failure is unrelated. Also fails in an empty commit e.g. here https://github.com/apple/swift/pull/33612


Update yanked version of minimum requests requirement

Update yanked version of minimum requests requirement.
Version 2.32.1 was yanked: https://pypi.org/project/requests/2.32.1/

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@albertvillanova could I ask why we should use latest requests here? we are using docker and datasets in the same time. However, docker requires requests<=2.32.0.

Hi @albertvillanova,
We updated the minimum required requests version for security reasons: https://www.cve.org/CVERecord?id=CVE-2024-35195

affected versions < 2.32.0

Latest version of docker should normally support requests > 2.32.0: https://github.com/docker/docker-py/releases/tag/7.1.0

Fixed an issue due to an update in the requests package breaking docker-py by applying the https://github.com/psf/requests/pull/6710

https://github.com/docker/docker-py/pull/3257

I guess you need to update your docker library as well:
pip install -U docker

Thank you! it works for me 👍


hasOwnProperty is not a function

The task was "get search params from URL and add it as event properties to amplitude". To get search params I use popular 3rd-partly lib query-string.
const params = queryString.parse(document.location.search)
project.logEvent('EventName', params)

And I have a runtime error 'hasOwnProperty is not a function' here :(
The reason is queryString.parse() returns the object created with Object.create(null), so it doesn't have hasOwnProperty method in prototype.
Expected Behavior
No runtime errors when types of all arguments are correct
Current Behavior
Runtime error, when the second argument of logEvent() is object created via Object.create(null)
Possible Solution
Use Object.prototype.hasOwnProperty.call(foo, 'bar') instead of foo.hasOwnProperty('bar')
Steps to Reproduce
const obj = Object.create(null)
project.logEvent('eventName', obj)

Thanks for the report, we'll work on a fix.
We're thinking of doing foo in bar instead of Object.prototype.hasOwnProperty.call(foo, 'bar') for easier readability and think that it should work. Do you have any opinions on this?


bud imports - question.

Hi @matthewmueller, First of all, Thanks for building this bud !!
I thought of learning this by giving a try, so here is an understanding question:
So, I was able to install the bud, create the app, was able to see bud home page with the nice splash. Now I tried this command bud new controller photos show index and then was able to see the index page in the browser with the nice title. All good until here.
Now, I wanted to rename the photos to photo, so I thought of deleting the folders/files and retype bud new... and deleted the photos directory present in both the controllers & views directory & did go mod tidy and it ended up showing this error:
❯ go mod tidy
go: finding module for package github.com/kishorevaishnav/shinyroll/controller/photos
github.com/kishorevaishnav/shinyroll/bud imports
        github.com/kishorevaishnav/shinyroll/bud/.app/program imports
        github.com/kishorevaishnav/shinyroll/bud/.app/web imports
        github.com/kishorevaishnav/shinyroll/bud/.app/controller imports
        github.com/kishorevaishnav/shinyroll/controller/photos: no matching versions for query "latest"

I tried to find the word photos in the entire directory and couldn't find any word of it, rather than fixing this or reverting the code, would like to understand where is this cached? & what is the logic behind it. If you can give me some insight and direct me some files to understand will be of great help.
P.S. Apologize if this shouldn't be posted here - not sure where to ask these kind of questions.

Never mind - I was able to find the bud directory. Ignore this issue.

Hey thanks, for the issue, I'd like to re-open this because I also noticed this bug recently. The watcher should be able to notice file removals / renames and re-compile
The workaround right now is to remove the bud directory and restart bud.

I'm hoping this is fixed by #123. I'll close and we can re-open if we encounter this again.


Consume strict dependencies from module in external repository

Strict dependencies can be defined in a single or multi-project build. However, those constraints are not published. The POM file, or Ivy files, do not allow strict dependencies either. This story is not about publishing the strictness of such dependencies, but rather about making sure that we can consume metadata defining strict dependencies for external modules.
This implies updating the Gradle metadata file format to support the declaration of strict dependencies, and consuming them from an external repository.
Implementation should make sure that:

the Gradle metadata file format can parse strict dependencies, in whatever form
resolving a module from an external repository can read this metadata file
works properly wrt to caching
make sure that if module is resolved from a repository that doesn't use Gradle metadata first, then from a module which does, then strict dependencies are honored

@melix I believe that this issue should be linked to #3418

I added a dependency. Thought I could live without :)

This is better, but not exactly what I meant. I use the ZenHub board filtered by in:dependency-management to keep a view of what's going on.
The best way I've found to link a PR to an issue is with the "Connect this pull request with an existing issue" button on the PR. That way it shows up like this on the board:

It also doesn't add the "blocked" notice which just adds noise IMO.

But this is separate work: consuming depends on the new metadata file format, but they are implemented separately.

OK That wasn't clear to me. I would probably do it as 2 PRs attached to the
same issue, since adding support to the metadata format in isolation
doesn't really add any value. (It's pretty easy to connect multiple PRs to
the same issue).
On Thu, 9 Nov 2017 at 06:45 Cédric Champeau<EMAIL_ADDRESS>wrote:

But this is separate work: consuming depends on the new metadata file
format, but they are implemented separately.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/gradle/gradle/issues/3308#issuecomment-343158520, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAK-FvzZsBHAFgIGNo6N7U9S-86QLOIsks5s0wIJgaJpZM4QLWHC
.

--
[image<EMAIL_ADDRESS>Daz DeBoer
Lead Software Engineer
www.gradle.com
Gradle Summit is now open
Click HERE to register https://summit.gradle.com/


Task was replaced with Var ?

No explanation given for this switch. And wanted to know the meaning of this.

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

ID: 17d27a0d-c072-8c9f-7e31-3de60bee9ae8
Version Independent ID: e0c09794-e712-19ff-cb9f-12648d60d4f6
Content: Asynchronous programming in C#
Content Source: docs/csharp/programming-guide/concepts/async/index.md
Product: dotnet-csharp
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

We try to program with var as much as possible to implicitly type the variable. For more information, see Implicitly typed local variables.

I hope this answers your question. If not, please let me know. Thanks.


TypeError: _chalk.default.whiteBright is not a function

When I run Webdriver.io project on Jenkins Server, I encounter following error,
/home/workspace/TestBootWizard/node_modules/@wdio/logger/build/node.js:120
nameFormatter: name => _chalk.default.whiteBright(name)
^
TypeError: _chalk.default.whiteBright is not a function
at Object.nameFormatter (/home/jenkins/workspace/TestBootWizard/node_modules/@wdio/logger/build/node.js:120:41)
at Logger. (/home/jenkins/workspace/TestBootWizard/node_modules/loglevel-plugin-prefix/lib/loglevel-plugin-prefix.js:77:62)
at launch (/home/workspace/TestBootWizard/node_modules/@wdio/cli/build/run.js:91:7)
at run (/home/workspace/TestBootWizard/node_modules/@wdio/cli/build/run.js:68:12)
at Object.run (/home/workspace/TestBootWizard/node_modules/@wdio/cli/build/index.js:45:20)
at Object. (/home/workspace/TestBootWizard/node_modules/@wdio/cli/bin/wdio.js:11:21)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Module.load (internal/modules/cjs/loader.js:599:32)
at tryModuleLoad (internal/modules/cjs/loader.js:538:12)

 "@wdio/cli": "^5.7.14"
"chalk": "2.4.2"

I just tested that Chalk version with the following and it works fine:
const chalk = require('chalk');

chalk.whiteBright('foo');

Happy to look into it furtger if you submit a pull request with a failing test.

I have created on function in typescript file and use chalk as a warning and error log as below
import chalk from "chalk";
console.warn(chalk.bgRed.underline("[WARN] Error while "))
In my windows system cmd it is showing color code but in jenkins it is not showing the color.
In Jenkins I have use ansiColor('xterm') but still I can't see the color code output in my jenkins console log


Default source file encoding in Python 2 is ASCII

We're experiencing the following error with Python 2.7:
SyntaxError: Non-ASCII character '\xc2' in file <...>/rapidfuzz/process.py on line 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
In Python 3 it's UTF-8 by default so this probably doesn't cause problems: https://www.python.org/dev/peps/pep-3120/
If you want to keep the symbol, an alternative is to set an encoding on the file as per PEP-0263. But just making the file ASCII was easier for our testing.
Note we didn't experience this on most environments, i.e. our Mac and Linux development environments didn't error, probably due to the system default encoding there vs our CI/prod environments.
(Apologies for slightly messing around with your copyright header.)

Thank you for the Pull Request. I think following https://en.wikipedia.org/wiki/Copyright_symbol
it would be best to replace the © with (C).

it would be best to replace the © with (C).

Sure, I made the change.

Thanks I will publish this as a last release before I finally get v1.0.0 (https://github.com/maxbachmann/RapidFuzz/pull/68) out.


path coordinates

Hi,
How could I provide path coordinates for panacus from pggb graph? Since it didn't have an interval in the GFA, this function only works for Minigraph-Cactus graph?

panacus does not make use of node annotations, if that is what you mean. It uses the sequence underlying the nodes as reference for the coordinates. In other words, path coordinates should work in pggb as well as Minigraph-Cactus, and I have tested it on both. Does it not work for you?

No. It did work with my pggb graph. Here is the command I use:
panacus hist -c bp -e Col-0.CEN.bed -H -t 12 ../At_Chr1_p90_s10000/panCEN.Chr1.fa.gz.f6e6337.f85392c.20baff7.smooth.final.gfa > Chr1.hist

And here is the bed info
Col-0#Chr1      14842915        17129565
Col-0#Chr2      5281568 5281745
Col-0#Chr3      13596521        15747999
Col-0#Chr4      5256168 5256346
Col-0#Chr5      12395998        14812445

Can you send me the graph, too?

The graph is quite large, could I send you a link by email?

Yes--Just sent you an email, so you have mine.

Thanks! Sent it. By the way, what's the exact meaning of quorum?

Quorum sets the number of paths/groups that must share the counted graph feature when going from n to n+1. The simplest way to understand quorum when it is set to 100%, i.e, -q 1. In that case, panacus would count only those graph features that are shared by all paths/groups. This is commonly known as core genome. Setting -q 0.5 is also known as shell pangenome and -q 0.1 cloud pangenome. Here are some more explanations: https://hackmd.io/asojhSf-T8GOJOr9HQj_IA#Panacus

Actually, panacus run successfully with BED. The error is because I use whole genome bed for chr1 graph.


Cannot pull in Drone 0.7

When drone tries to pull the image it gets
panic: EOF
goroutine 1 [running]:
github.com/NYTimes/drone-gke/vendor/github.com/drone/drone-plugin-go/plugin.MustParse()

        /go/src/github.com/NYTimes/drone-gke/vendor/github.com/drone/drone-plugin-go/plugin/param.go:129 +0x4e
main.wrapMain(0x0, 0x0)
       /go/src/github.com/NYTimes/drone-gke/main.go:76 +0x5a3
main.main()
	/go/src/github.com/NYTimes/drone-gke/main.go:50 +0x22```

that looks like bad parameters passed in through the drone config: https://github.com/drone/drone-plugin-go/blob/master/plugin/param.go#L124-L130
unrelated to pulling image.

@jrynyt  ok, makes sense. I removed to the secrets just to test if that would run. But when have the secrets i get this error
ERROR: yaml: unmarshal errors: line 23: cannot unmarshal !!map into []*yaml.Secret

Looks like I had the secrets collum when i didn't need it.


Fail to pass a class object into a cell generation function.

I tried to define a function to generate a component, and use gf.cell() function to translate this component to be a cell. To generate my component, I need to pass a class object into my function. However, I found that once I call this function, my python kernel will be shut down. Either use gf.cell(myfunction) or decorator @gf.cell to translate this function, same thing will happen. Only when I try not to pass any class object into my function it will run.
Is this a bug of gf.cell? Or it's my fault to use it wrongly? I really hope I can pass a class object into my function. I use gdsfactory in an anaconda env on Windows System with python 3.11.5. I have uploaded my code with problems in my repository mlc_dev/Cellbug.

Your class needs to be json serializable as far as I can tell.
I am getting this with your code:
Traceback (most recent call last):
  File "/home/sgoeldi/repos/mlc_dev/src/First Board.py", line 88, in <module>
    LCCircuit = LCGenerator(L,C,LC,LAYER,via_pad_width)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/sgoeldi/miniforge3/envs/mlc/lib/python3.12/site-packages/gdsfactory/cell.py", line 201, in wrapper
    f"{key}={clean_value_name(changed2[key])}" for key in sorted(changed.keys())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/sgoeldi/miniforge3/envs/mlc/lib/python3.12/site-packages/gdsfactory/serialization.py", line 180, in clean_value_name
    return str(clean_value_json(value, fast_serialization=True))
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/sgoeldi/miniforge3/envs/mlc/lib/python3.12/site-packages/gdsfactory/serialization.py", line 126, in clean_value_json
    raise e
  File "/home/sgoeldi/miniforge3/envs/mlc/lib/python3.12/site-packages/gdsfactory/serialization.py", line 120, in clean_value_json
    value_json = orjson.dumps(
                 ^^^^^^^^^^^^^
TypeError: Type is not JSON serializable: CapacitorClass

Is there a reason to use classes? Generally it's not the best idea to have stuff live in cells, unless you really have to. As far as I can tell from your code, you are merely using the classes to store parameters?
I would suggest to either use config files or tech files which just define constants and use those instead.
If you really want to use classes, pydantic classes are json serializable afaik.

gf.cell is intended as a decorator of functions
See tutorial
can you share the link of your repo


⚠ Spryr has degraded performance

In 77ed1e4, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 6384 ms

Resolved: Spryr performance has improved in 96d38ec after 7 minutes.


Adding omitempty tag to DnsSearchList

cc @jhowardmsft Can you please merge and tag.
Signed-off-by: msabansal<EMAIL_ADDRESS>

LGTM.


One Publisher -> Many Subscribers

Is it possible to have multiple subscribers all receive the same message from a publisher?

Yes, that's exactly how it works.

I currently have a message being published based upon device coordinates.  When those coordinates change, a single message is sent.  That message has multiple subscribers with the same key value in this case "geoUpdate".
For testing purposes when those subscribers receive the message they log "geo1" or "geo2".
The behavior i'm seeing is that only the first subscriber receives the message.  So we end up with two nearly identical subscribers, but only the second one receives the message.  Any ideas?
       var sub = new cote.Subscriber({              name: queueName,             key: JSON.stringify(bindArgs)         });         sub.on('message', (msg) => {             func(msg,func_args);         });

are you sure JSON.stringify(bindArgs) gives the same result for both subscribers? if you can share a more complete example, I can take a look at what's wrong.

Here is an output of each (the two relevant) subscriber objects.  Does this help?
I can write a quick sample project that I can share to recreate the issue.

Sorry for the delay --- here is a full example of what i'm seeing.  My feeling is i'm doing something wrong, but i would appreciate any help! =)

`const cote = require('cote');
var buildListener = function(queueName,bindArgs,func){
var sub = new cote.Subscriber({
name: queueName,
key: JSON.stringify(bindArgs)
});
sub.on('message', (msg) => {
func(msg);
});
}
var publish = function(){
let pub = new cote.Publisher({ name: 'message', key: JSON.stringify({'test':'test','woo':'woo'})});
pub.publish('message','testing');
}
var t1 = function(){buildListener('test1',{'test':'test','woo':'woo'},function(){console.log('test1')});};
var t2 = function(){buildListener('test2',{'test':'test','woo':'woo'},function(){console.log('test2')});};
publish(t1(),t2());
`

Good afternoon!  Just wondering if I can provide any more information?

Apparently the publisher was creating and sending the message faster than all the listeners could attach.


Use vendored-in primitives from OpenTitan

Instead of using copies of primitives from OpenTitan, vendor the files
in directly from OpenTitan, and use them.
Benefits:

Less potential for diverging code between OpenTitan and Ibex, causing
problems when importing Ibex into OT.

Use of the abstract primitives instead of the generic ones. The
abstract primitives are replaced during synthesis time with
target-dependent implementations. For simulation, nothing changes. For
synthesis for a given target technology (e.g. a specific ASIC or FPGA
technology), the primitives system can be instructed to choose
optimized versions (if available).
This is most relevant for the icache, which hard-coded the generic
SRAM primitive before. This primitive is always implemented as
registers. By using the abstract primitive (prim_ram_1p) instead, the
RAMs can be replaced with memory-compiler-generated ones if necessary.

There are no real draw-backs, but a couple points to be aware of:

Our ram_1p and ram_2p implementations are kept as wrapper around the
primitives, since their interface deviates slightly from the one in
prim_ram*. This also includes a rather unfortunate naming confusion
around rvalid, which means "read data valid" in the OpenTitan advanced
RAM primitives (prim_ram_1p_adv for example), but means "ack" in
PULP-derived IP and in our bus implementation.

The core_ibex UVM DV doesn't use FuseSoC to generate its file list,
but uses a hard-coded list in ibex_files.f instead. Since the
dynamic primitives system requires the use of FuseSoC we need to
provide a stop-gap until this file is removed. Issue #893 tracks
progress on that.

Dynamic primitives depend no a not-yet-merged feature of FuseSoC
(https://github.com/olofk/fusesoc/pull/391). We depend on the same
functionality in OpenTitan and have instructed users to use a patched
branch of FuseSoC for a long time through python-requirements.txt,
so no action is needed for users which are either successfully
interacting with the OpenTitan source code, or have followed our
instructions. All other users will see a reasonably descriptive error
message during a FuseSoC run.

This commit is massive, but there are no good ways to split it into
bisectable, yet small, chunks. I'm sorry. Reviewers can safely ignore
all code in vendor/lowrisc_ip, it's an import from OpenTitan.

The check_tool_requirements tooling isn't easily vendor-able from
OpenTitan at the moment. I've filed
https://github.com/lowRISC/opentitan/issues/2309 to get that sorted.

The LFSR primitive doesn't have a own core file, forcing us to include
the catch-all lowrisc:prim:all core. I've filed
https://github.com/lowRISC/opentitan/issues/2310 to get that sorted.

Here we go, the final battle to bring (more) order into mess of copied files between OT and Ibex. Please have a look at the individual commits for slightly more details.
There should be no functional change after this PR is applied.

In terms of testing we should be good as well.

CI tests are green, which includes

Ibex compliance
Lint & Co.

ibex_core UVM tests pass
The simple system example can execute code.
The Arty A7-35 example synthesizes (I don't have a board to test)
icache UVM tests pass

I've updated this PR to use the new vendor.py script, took the updated check_requirements.py, and found a small change which wasn't related to this PR (#901).

Good catch @rswarbrick, fixed.


Conway's Game Of Life.

Thank you for you contribution to the repo and the community

On 5 Oct 2017, at 18:44, Anurag Kumar<EMAIL_ADDRESS>wrote:
You can view, comment on, or merge this pull request online at:
https://github.com/geekcomputers/Python/pull/246 https://github.com/geekcomputers/Python/pull/246
Commit Summary
Merge pull request #1 from geekcomputers/master
added Game of Life module
added plotting of the canvas
moved GOL to new dir, added sample.gif output of the code.
File Changes
A game_of_life/game_o_life.py https://github.com/geekcomputers/Python/pull/246/files#diff-0 (118)
A game_of_life/sample.gif https://github.com/geekcomputers/Python/pull/246/files#diff-1 (0)
Patch Links:
https://github.com/geekcomputers/Python/pull/246.patch https://github.com/geekcomputers/Python/pull/246.patch
https://github.com/geekcomputers/Python/pull/246.diff https://github.com/geekcomputers/Python/pull/246.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/geekcomputers/Python/pull/246, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHa0qf2M3ULG8swZUQudFhxTChKWcEBks5spRVygaJpZM4Pvczy.


chore(create-app): remove tsconfig.types

Description
Definition of tsconfig.types on the TS documentation writes

If types is specified, only packages listed will be included in the global scope. For instance:

So if use Vite to create a *-ts project and TS will not recognize global definition such as Jest unless add Jest to tsconfig.types.
Additional context

What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[ ] Documentation update
[x] Other

Before submitting the PR, please make sure you do the following

[ ] Read the Contributing Guidelines.
[ ] Read the Pull Request Guidelines and follow the Commit Convention.
[ ] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[ ] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

Anyone would like to review this? cc @Shinigami92 😉

@Shinigami92 I'd say setting types is a less sensible default than providing a globals file. As a user you'd expect Jest and other global types to just work, but if we pre-set types then users will have to find out why their project is broken (when they add a new package and the types don't work).
Next.js also uses this approach, creating a next-env.d.ts file with the client types referenced.
Cypress is an exception since the Cypress & Jest globals interfere with each other, and like you said, that is normally a separate tsconfig in any case.
In general you shouldn't have to make a config file for each package you add [that affects the global types].

Yes, remove compilerOptions.types and  adding a global declaration file won't block other new added global types. create-react-app also init a react-app-env.d.ts for TypeScript template. And maybe we can tweak and unify the d.ts naming.

Okay, so what about naming the file vite-env.d.ts
Also we could add a documentation section for explaining this file, like in the Next.js docs.
Please also check if there isn't already "old" documentation that needs to be updated.

Have tested it and yes it's working, please rename the file and then we can merge it

Alos updated the doc of Client Types 🤠


Testing suite

Purpose
Add a testing suite to h5-audio
Approach

Create base testing suite
Install chai-as-promised
???
Profit

Learning
Chai-as-promised to make testing easier: https://github.com/domenic/chai-as-promised
Chai expect/should syntax: http://chaijs.com/api/bdd/
Open Questions and Pre-Merge TODOs

PR should be ready to merge

@stevekinney Now that we've got this bad boy tested, what else would you suggest?

@stevekinney If you pull down now, I've added an audio file to the data structure and fixed it to work universally

This is all lookin good!


Improving Sharding Downtime

Right now, sharding the log requires about 10-20 minutes of downtime.
Sharding process currently looks like this:

Create a new trillian tree
Mark the current tree as frozen (at this point, the log is readable but not writable)
Update rekor config with the following:

Change the active tree to the tree created in (1)
Update the sharding config with the now-inactive tree ID and length

The log is ready to go again!

Downtime occurs between freezing the log & updating the sharding config. We require the length of the inactive shard in the config to properly compute virtual indexes across shards.
FAQ

Why can't we migrate traffic from one shard to the next and then update the sharding config?

In this case, the inactive shard wouldn't be correctly queryable for some portion of time. That's because rekor relies on the sharding config to determine which shards to search and how to determine the "virtual index" across shards. In the period between switching over traffic and updating the sharding config, we could append entries to the log but we wouldn't be able to access entries in the frozen log -- almost all verifications would fail & get by log index would be incorrect.

What do we use the sharding config for?

The sharding config keeps track of inactive shards and for each tracks:

ID
Length
Associated public key (needed if we rotate keys for new shards)

Instead of manually creating the sharding config, why don't we automatically search for shards and compute the config in code?

We'd have to guess at how to order the shards (this determines virtual log index computation). We could assume shards should be ordered chronologically, if we're comfortable with that it could reduce downtime.

Thanks for this recap, @priyawadhwa ! I would be a fan of trying to automate as much of this as possible instead of doing manual shard config / restart. The manual portions introduce the most downtime and also I think there is some possibility for user error down the line if the project continues to grow and scale. Could the issue with trillian trees not necessarily being chronologically ordered be fixed by Rekor code ordering them and keeping track?

Other ideas floated in the meeting:

Instead of using the size of the logs to calculate the virt index, have a pointer to the next log
Create a mapping of log index <--> UUID only during migration-to-new-shard periods

Could the issue with trillian trees not necessarily being chronologically ordered be fixed by Rekor code ordering them and keeping track?

We can order trees chronologically during runtime, there's a CreateTime field on the Tree struct.
I think we can achieve way less downtime by keeping the config, but removing the requirement for knowing the size of the inactive shard ahead of time. We can figure out the size during runtime. Sharding would look something like this:

Create a new tree
Add the old tree ID to the sharding config (w/ public key if we are rotating signers)
Update the Rekor configmap to point to the new tree ID
Redeploy Rekor to pick up these new changes
During runtime, Rekor will get the sizes of the inactive shards (maintaining the order in the config) to determine the virtual log index for entries

WDYT @lkatalin ?

@priyawadhwa I read this a couple of times, at first thinking you meant these steps would be implemented in the code (except redeployment) but now realizing that steps 1-4 are manual and 5 is implemented in code - is this right? So the change would be that instead of passing in tree sizes in the config, Rekor can calculate them at runtime, but the config is still used to specify and order the shards. I think that in itself would be a good change.
My first (I think mistaken) read of your idea was that these steps would be automated and that led me to thinking about the utility of eventually having an API endpoint for sharding commands that could perform some of these functions. Then we could avoid having to do a redeployment to update the config, and instead the new config could be picked up during runtime. This would be in addition to having Rekor compute the inactive shard sizes separately from the config. Something like:
rekor-server shard --create-config mynewconfig.yaml #generates updated config with specified name (other parameters tbd)
# next, someone can manually edit the config if desired or even skip the previous step
rekor-server shard --use-config mynewconfig.yaml

In addition to not needing to do a redeployment, the benefits would be less work for whoever is creating the config or updating the server to use it, and less room for human error while still giving the option to do overrides.
I think the step you described of having Rekor get the sizes of inactive shards during runtime is more important and then this could be additional if we want to do it. There may be some problems as I'm still thinking through it but it seem beneficial to skip mandatory redeployment if possible. What do others think?

Regarding the proposal around seamless updates, is it rollback safe? i.e. if something goes wrong with the new Rekor deployment during the roll out or for some window after the roll out has completed, can the system quickly and easily be restored to the previous state?
With the current approach, there is a small window of downtime but it does seem to have rollback safety at the cost of a small window of data loss.

Regarding the proposal around seamless updates, is it rollback safe?

That's a good point. If we're automatically marking logs as FROZEN when they're in the sharding config, we would need to automatically make them as ACTIVE again if we rolled back.

Re: my initial idea around marking pods as FROZEN; I think an easier way of achieving the same thing would be to mark the Rekor deployment strategy as [Recreate](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment -- all old pods would be terminated before new ones come up. The current strategy is the default Rolling Update. the nice thing about this is that if something goes wrong, we can easily run kubectl rollout undo to get back to the old state.

@priyawadhwa This is complete, correct?

Yep!


Role handingling service and cog need to be redone

It was one of the first things i wrote before i had a good idea of how the bot should be architected and some of the design decisions arent great, update and delete roles needs to be handled better then it is right now. When a server has a mass edit of roles it overloads the sqlite database and locks due to how we are currently hitting the database

Started in commit 02bab3229605317fda0e498d8810cb7620f8833d


Add easy way to fill gaps in time series data

Use case:
As a user with time series data I want an easy way to fill gaps in my data with interpolated values so that I can execute my queries.
Feature description:
It's possible to do this with CrateDB already but usage is not very intuitive or user friendly (compare [1], [2]).
Other time series databases / data analysis tools include similar functionality like e.g. timescaledb time_bucket_gapfill, influx fill, panda fillna / interpolate
Adding comparable functionality increases usability for time series use cases for CrateDB users.
[1] Example with NULL interpolation from CrateDB Docs https://crate.io/docs/crate/tutorials/en/latest/normalize-intervals.html#interpolate-missing-records
[2] Community Tutorial with some examples https://community.crate.io/t/interpolation-of-missing-time-series-values/659

Relates partially to https://github.com/crate/crate/issues/11322


make sure $nuxt is set if possible

Types of changes
return window.$nuxt if $root is not set

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

Description
$nuxt was not always accessible (if $root was not set), so return the property from window object
Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly. (PR: #)
[ ] I have added tests to cover my changes (if not applicable, please state why)
[ ] All new and existing tests are passing.

fixes #8995

I recently tried upgrading to 2.15.4, but I am still facing $root not available issue.
Cannot read property '$options' of undefined


Fix javadoc:aggregate-jar target

This change makes the javadoc:aggregate-jar target work at the
top-level.
Doing this correclty is complicated because javadoc:aggregate is
confused by the repackaged/shadedPattern renaming of the bigtable client
in the dataflow submodules.
After a lot of experimentation, banging my head against the wall, and
discussions with Jeff I decided the best way to handle javadoc at
the top-level was simply to exclude the dataflow projects; we already
have a way to handle and publish those docs that we aren't going to
change, so we simply skip the com.google.cloud.bigtable.dataflow*
packages when doing a top-level javadoc:aggregate[-jar] for the main
project.
I also made a change to ensure that you can turn back on the doclint
behavior by passing -Ddoclint on the commandline if you want to inspect
it for any javadoc target, though it's still not particularly useful
given all the noise from grpc-java (and note that they have it disabled
in their build).
I also made some tweaks to the way we express configuration so the
javadoc stuff will apply for all profiles, and the aggregate-jar target
will be used during the package phase.
Finally I threw in a couple of fixes for new warnings that I noticed.

LGTM.
I have a follow up request for another PR.  Let's please get rid of the v1 proto files and the excludePackageNames.


chore: arm64

:tada: This PR is included in version 1.5.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Seperate database connection for the data_rows and data_tables to store in SQLight

I think being able to store the 2 tables in a SQLight file would make it easier to keep all the bread settings in sync between dev and production.
If it is possible having a config file(s) instead of a SQLight database might be better so that changes can be tracked

You can use SQLite as your main database.
However, I'm open for other ideas for handling this.

What if we want to use them on other operations. Combining them or something like that. I can't think one reason for this but maybe some people do that already and if these tables will be transfer to separate database could lead to a mess or to more code for the same goal.

I don't really like the SQLite solution for the reasons @vaggelis2018 mentioned.  I wouldn't mind doing a table prefix or something, but we haven't come up with an easy way to do that yet


Add command iostats in istgtcontrol to fetch the volume metrics

Is this a BUG REPORT or FEATURE REQUEST?
FEATURE REQUEST

What happened:
istgtcontrol does not have any commands to display performance and capacity stats and other details.
What you expected to happen:
istgtcontrol should display the volume metrics
How to reproduce it (as minimally and precisely as possible):
you can run the istgtcontrol --help
Anything else we need to know?:
Link for istgt repo : https://github.com/openebs/istgt

Closing this via openebs/istgt#36


Fix #415:  Fixing link to the award page

Adding https:// to the link seems to fix the problem.

Indeed, this seems to be the case. Merging.
Thank you.


Includes and Extends in a begin/end block are not reflected to the surrounding scope

Input
→ View on sorbet.run
# typed: true

module Bar
  def bar
    42
  end
end

module Foo
  begin
    extend Bar
    a = 1 # arbitrary statement needed to keep begin/end block
  end

  bar
end

Observed output
editor.rb:15: Method bar does not exist on T.class_of(Foo) https://srb.help/7003
    15 |  bar
          ^^^
Errors: 1

Expected behavior
No errors since Foo will extend Bar
irb(main):001:1* module Bar
irb(main):002:2*   def bar
irb(main):003:2*     42
irb(main):004:1*   end
irb(main):005:0> end
=> :bar
irb(main):006:0>
irb(main):007:1* module Foo
irb(main):008:2*   begin
irb(main):009:2*     extend Bar
irb(main):010:2*     a = 1 # arbitrary statement needed to keep begin/end block
irb(main):011:1*   end
irb(main):012:1*
irb(main):013:1*   bar
irb(main):014:0> end
=> 42

I noticed that in the Flatten rewriter we move the method definitions out of the begin/end block and they work fine. I'm curious if something similar can be done for include and extend.

Closing this issue after slack discussion outlining this as a feature and not a bug.


weird use of module.exports = packages/chevrotain/src/api.ts

I am trying to make an esm build in my chevrotain fork, for better treeshaking, just like #976 .
But I find there is a weird use of module.exports = in src/api.ts.
https://github.com/SAP/chevrotain/blob/87ed262c36b6f5cb4073e14f4f59901146c6c7a5/packages/chevrotain/src/api.ts#L280
I think this should be changed to esm export for the following reasons:

I don't think using module.exports =  is a good practice in a typescript project because typescript uses esm as its module system instead of commonjs.

With the module.exports =  which remains in my esm build, esm bundlers such as rollup didn't recognize the generated api.js as an es module, thus it fails to bundle.

So I think, instead of
import { VERSION } from './version'
API.VERSION = VERSION
module.exports = API

we can:
import { VERSION } from './version'
export { VERSION }

They produces same results when targeting commonjs So I am wondering why to use module.exports = in the source code, and can we change it to esm export?

The reason for that pattern is that this API variable has a type signatures that links (and validates) between the external public apis and the internal implementation.

https://github.com/SAP/chevrotain/blob/87ed262c36b6f5cb4073e14f4f59901146c6c7a5/packages/chevrotain/src/api.ts#L155-L207

Regarding ESM builds:

I am interested in integrating such a build output but I am not yet familiar with the topic.
My understanding so far is that I would need to switch from webpack to something like rollup to implement this.
Why does the TypeScript sources implementation need to change in order to implement an ESM build?

Could an ESM build be implemented regardless of the module system used in the source code or does an ESM build output requires pure usage of ES modules in every source file?

It is fine to implement the external vs internal APIs validation in a different manner if it is a mandatory requirement to implement ESM builds.

My understanding now is that:

All the TypeScript sources must use only pure ES modules import/export syntax.
Then we can use --module ES2015 option on the TypeScript compiler to transpile the TypeScript sources to (almost) ES5 sources which also use ES modules import/export syntax.
Then we can use rollup --format esm to provide a singular entry point to be exported as package.module which other bundling tools can use to perform ESM bundling (With tree shaking).

Is this correct?

Yes! Thanks for response 😆 . esm is the only module system in typescript, so we should use pure es import/export syntax.
So as you said, api.ts has two goals in the package?

decide what to export as public api from internal implementations.
type check the internal implementation is compatible with declared types in api.d.ts.

(Am I misunderstanding? 😳  )

So as you said, api.ts has two goals in the package?

Yes. Could we split up the 2nd goal to a separate file?
Maybe one that is part of the tests rather than the production code, e.g:
import * as actualApi from "api.ts"
import * as expectedApi from "api.d.ts"

let expectedApi: {
VERSION : typeof expectedApi .VERSION,
/* ... */
} = null;

// TypeScript compiler goes boom here if we make a mistake (?)
expectedApi = actualApi

I think this will work! ( and without runtime assignment ! )
Here is a simple example: https://github.com/EqualMa/ts-api-type-check
In case you don't have computer at hand, try this: https://gitpod.io/#https://github.com/EqualMa/ts-api-type-check

In conclusion:

To decide what to export as public api from internal implementations, use export-statements and re-exports

They are preffered in typescript, so now we don't need module.exports =

To ensure internal implementations correctly implement the types defined in api.d.ts, we can type checking in this way:

./api.ts
// re-exports from internal implementations
export { VERSION } from './version'

./api-check.ts
// from ../api.d.ts
import * as defs from "../api"
// from ./api.ts
import * as apiImpl from "./api"

type AssertExtends<T extends R, R> = [T, R]

export type TypeCheckForApi = AssertExtends<typeof apiImpl, typeof defs>;

If you think this is 🆗 , I can re-write 'api.ts' and make a pull request

https://github.com/SAP/chevrotain/issues/982#issuecomment-507859667
My understanding so far is that I would need to switch from webpack to something like rollup to implement this.

This project (chevrotain) may not need to switch from webpack to rollup.
As I understand, chevrotain uses webpack only to get a umd bundle (bundle all src and dependencies). This bundle is for importing in html.
And this projects uses tsc to produce js files (in commonjs, only src, no dependencies). These files are for npm and node. And the entrypoint is specified in the field "main" of package.json (pkg.main)
Thus, to produce js files in esm, we just need a tsconfig.esm.json which extends "tsconfig.json" and sets "module": "esnext" (or "es2015"? this needs discussion)  and outDir to "esm" or "lib/esm" or somewhere else. Then just run tsc -p tsconfig.esm.json. Also the module entry should be specified in the field "module" of package.json (pkg.module)

"module" field is not standard in package.json, but is respected by rollup and webpack so that when others use this package as a dependency, and use webpack or rollup as a bundler, the bundler will find where the module file is.

However, maybe someday chevrotain can change to rollup for better treeshaking, which means removing unused codes more precisely and producing a smaller bundle. (But this project already has coverage checking so I think some research is needed to see how well rollup works)

Here are some refrences about webpack vs rollup
"Use webpack for apps, and Rollup for libraries" from this article in 2017
a detailed comparation between webpack and rollup in this article

(The above articles may be outdated because webpack changed a lot since 2017.)

API assertions

If you think this is 🆗 , I can re-write 'api.ts' and make a pull request.

Yes I think this is ok, pull  requests welcome 😄
package.module
In #976 a single esm bundle was requested (single file), so what is the "best" way to provide the "package.module" entry point? bundled or as separate files?
I also agree that we should probably support this flow without modifying existing dev flows in Chevrotain (if possible), e.g we could use rollup just to create chevrotain.esm.js while still using webpack for the UMD bundle.
Last but not least, any new output format we create must be tested, for example the UMD output is tested in Karma browser tests so that is one more requirement...

fixed in #984


Remove deprecated System.runFinalizer call

Changes

Remove deprecated System.runFinalizer call

Codecov Report

Merging #764 (443d113) into main (aa72ec8) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##              main      #764    +/-   ##
==========================================
  Coverage   100.00%   100.00%
==========================================
  Files           66        56    -10
  Lines         2864      1972   -892
  Branches       506       336   -170
==========================================
- Hits          2864      1972   -892

Impacted Files
Coverage Δ

...la/codes/quine/labs/recheck/cli/AgentCommand.scala
100.00% <ø> (ø)

...ges/eslint-plugin-redos/src/rules/no-vulnerable.ts

packages/recheck/src/main.ts

packages/recheck/src/lib/agent.ts

packages/recheck/src/lib/java.ts

packages/recheck/src/lib/pure.ts

packages/recheck/src/lib/native.ts

packages/recheck/src/browser.ts

packages/recheck/src/lib/env.ts

packages/recheck/src/lib/worker-pool.ts

... and 1 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


LinkedList: use === and !== and fixing JSDoc

one missing type declaration

Thanks @vladad , I added this to the release


Provide helm charts for Kubernetes deployment

Provide helm charts for Kubernetes deployment
Summary
Provide a Helm chart to deploy keycloak-gatekeeper on Kubernetes.
Why?
A lot of people, like me, are/were using keycloak-gatekeeper (or maybe louketo) on Kubernetes and used Helm to simplify deployment. Supplying a Helm chart simplifies this deployment and makes it attractive to migrate from the abandoned incarnations to Gatekeeper.
Gabibbo97 has an excellent chart for keycloak-gatekeeper, but K-G has been killed. Also, since the deprecation of helm/stable, there is a strong trend towards helm charts being maintained/hosted from the project itself.
How
I would suggest to copy Gabibbo97's chart and use the  chart-releaser-action in the workflow to CD the charts. Finally, register the resulting chart museum at artifacthub.io so everybody can find Gatekeeper.

this would be nice but there are quite many fixes needed+tests so i think it is low priority for now, but thanks for suggestion :+1:

I have also written a chart and I'd love to contribute it to you :-)

@mkilchhofer ok, great, just make pull request :)

@mkilchhofer hmm, thinking, probably it would be better to have separte repo for helm-chart

Yes, both makes sense. I'd use the Github Releases for the helm chart as well, so maybe it makes sense to decouple it and use a separate repo for the .tar.gz files and the software itself.

Here it is: https://artifacthub.io/packages/helm/gogatekeeper/gatekeeper
I think we can close this issue now 😃


Gittip Fraud HOWTO

Gittip involves moving money between people, and as such it's also a potential vehicle for fraud and money laundering. A typical workflow may be as follows:

EvilPerson steals credit card details and attaches them to a gittip account.
EvilPerson pays money to other Gittip accounts under their control.
EvilPerson withdraws money from those other accounts, possibly via BitCoin, which—like its legally dubious cousin "cash"—is used by drug-lords, arms-dealers, and Portland street-food vendors.

It would be useful to have a discussion as to how to combat this. New accounts giving lots of money to other new accounts are a potential sign of fraud, but an attacker may choose a less obvious (and less efficient) route to try and avoid detection.
One possible solution would be to have the concept of "cleared funds" and "uncleared funds". Pay-ins that can't be reverted (eg: Bitcoin) are automatically cleared. Those which can be reverted as 'uncleared' for a period of time, to at least increase the likelihood of us receiving fraud alerts before we pay-out of those funds.  Another solution would be some sort of fraud insurance.
Other suggestions and discussions very welcome here. Understanding potential attack patterns can help us defend against them when they arrive.
~ pjf

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1436972-gittip-fraud-howto?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github).

Finally circling back around to this one after an eventful couple of years. Gittip is now Gratipay, and Gratipay now has a well-established policy for managing the private/public boundary in user support:

Protecting User Privacy

Before answering questions or performing actions related to an account, verify the user's identity by asking for, "the first eight digits of the API key on your Gratipay settings page." We generally don't trust even verified email addresses as identity confirmation (because of the risk of spoofing).
Never share personally identifying information about a user on GitHub or anywhere else without their explicit consent.
Copying anonymized, generic comments into a public GitHub ticket is okay, and so is a simple "+1" with a link to Freshdesk.

That was actually a sidebar in this ticket. The main point here was how to combat fraud, for which we've also adopted policies by now.


error updating from webui and console

From web UI:
`USER: homebridge
DIR: /usr/local/lib
CMD: npm --no-update-notifier install --unsafe-perm homebridge-config-ui-x@latest
Unhandled rejection Error: EACCES: permission denied, mkdir '/home/homebridge'6
npm ERR! cb() never called!
npm ERR! This is an error with npm itself. Please report this error at:
npm ERR!     https://npm.community
Command failed. Please review log for details.`
From cosole:
`pi@pihole:~ $ sudo npm --no-update-notifier install --unsafe-perm homebridge-config-ui-x@latest
npm WARN saveError ENOENT: no such file or directory, open '/home/pi/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/home/pi/package.json'
npm WARN pi No description
npm WARN pi No repository field.
npm WARN pi No README data
npm WARN pi No license field.

<EMAIL_ADDRESS>updated 1 package and audited 818 packages in 25.608s
found 0 vulnerabilities`

You need to enable sudo mode: https://github.com/oznu/homebridge-config-ui-x#sudo-mode

Sudo is set to true in my config. Issue persists.
I’ll try adding -g now.

CMD: npm --no-update-notifier install --unsafe-perm homebridge-config-ui-x@latest

This line shows sudo not being used.

Yes, I used sudo in both console and had sudo enabled in my config.json, still had those errors. But it seems -g in console got it to work, so might need to update homebridge-config-ui-x to do the same?

Yes, I was using sudo in the console and had sudo enabled in config.json, and that's how I got those errors. Using -g in console got it to update, but the plugins version reports the current version installed but the main page at the bottom reports 4.3.0 is installed.

If sudo mode is active and you're still getting errors make sure you have these lines in your systemd service file:
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_CHOWN CAP_FOWNER CAP_DAC_OVERRIDE CAP_AUDIT_WRITE CAP_SYS_ADMIN
AmbientCapabilities=CAP_NET_RAW

this is the same issue I'm having.
{
    "bridge": {
        "name": "#####",
        "username": "#####",
        "port": #####,
        "pin": "#####"
    },
    "platforms": [
        {
            "platform": "config",
            "name": "Config",
            "port": 8087,
            "sudo": true,
            "service": "homebridge",
            "restart": "sudo pm2 restart homebridge"
        },
        {

ERROR
The user "pi" does not have write access to the target directory:

/usr/local/lib

This may cause the operation to fail.
See the docs for details on how to enable sudo mode:
https://github.com/oznu/homebridge-config-ui-x#sudo-mode

USER: pi
DIR: /usr/local/lib
CMD: npm --no-update-notifier install --unsafe-perm homebridge@latest

#330

Try this:
echo 'pi    ALL=(ALL) NOPASSWD: ALL' | sudo
And this:
chown -R pi: /usr/local/lib/

made the changes on visudo and it took it. I'm able to update the UI. Thank you @mafyata


fixed issue with natural_foreign_keys and key_is_id

Problem
Closes #1816
key_is_id which fixes #974 clashes with use_natural_foreign_keys.
Solution
Only apply the key_is_id widget kwarg is use_natural_foreign_keys is False.
Acceptance Criteria
Added tests (thanks to @mishka251)

coverage: 99.855%. remained the same
when pulling 736bb27f39c206242128d16b6edde74f88c98ebf on matthewhegarty:issue-1816-use-natural-fk
into 6eb2d21fbefe97e8e85e94bc22d655a8172f15d4 on django-import-export:main.


Added docstring to and fixed type hint of :func:.get_winding_number

Overview: What does this pull request change?
See title.
Changed documentation page: https://manimce--2886.org.readthedocs.build/en/2886/reference/manim.utils.space_ops.html#manim.utils.space_ops.get_winding_number

Just make those examples a test as well :)

They already are -- the magic of doctests. :-) (They run when pytest --doctest-modules manim is called.)


[Bug]: Duplicate product generations trigger InvalidChecksum from ASF DAAC

Checked for duplicates
Yes - I've already checked
Describe the bug
Duplicate product generations:
Traceback (most recent call last):
File "/home/ops/verdi/ops/CNM_product_delivery/product_delivery/commons/exec_util.py", line 15, in wrapper
status = func(*args, **kwargs)
File "/home/ops/verdi/ops/CNM_product_delivery/product_delivery/scripts/../utils/update_es.py", line 463, in main
raise ValueError(error_message)
ValueError: CNM-R message reported an error:
dataset=OPERA_L2_CSLC-S1_T108-230160-IW3_20231119T022138Z_20231120T074019Z_S1A_VV_v1.0, error_code=PROCESSING_ERROR, error_message={"errorType":"InvalidChecksum","errorMessage":"Invalid checksum for S3 object s3://asf-cumulus-test-opera-staging/OPERA_L2_CSLC-S1_T108-230160-IW3_20231119T022138Z_20231120T074019Z_S1A_VV_v1.0/asf-cumulus-test/OPERA_L2_CSLC-S1_V1___1.0/OPERA_L2_CSLC-S1_T108-230160-IW3_20231119T022138Z_20231120T074019Z_S1A_VV_v1.0.iso.xml.md5 with type md5 and expected sum 9469a908e9731d499bfb5b04480db200","trace":["InvalidChecksum: Invalid checksum for S3 object s3://asf-cumulus-test-opera-staging/OPERA_L2_CSLC-S1_T108-230160-IW3_20231119T022138Z_20231120T074019Z_S1A_VV_v1.0/asf-cumulus-test/OPERA_L2_CSLC-S1_V1___1.0/OPERA_L2_CSLC-S1_T108-230160-IW3_20231119T022138Z_20231120T074019Z_S1A_VV_v1.0.iso.xml.md5 with type md5 and expected sum 9469a908e9731d499bfb5b04480db200","    at Object.validateS3ObjectChecksum (/var/task/webpack:/src/S3.ts:876:9)","    at runMicrotasks ()","    at processTicksAndRejections (node:internal/process/task_queues:96:5)","    at GranuleFetcher.verifyFile (/var/task/webpack:/GranuleFetcher.js:288:7)","    at handleDuplicateFile (/var/task/webpack:/src/granule.ts:284:27)","    at GranuleFetcher.ingestFile (/var/task/webpack:/GranuleFetcher.js:392:26)","    at async Promise.all (index 4)","    at GranuleFetcher.ingest (/var/task/webpack:/GranuleFetcher.js:135:29)","    at ingestGranule (/var/task/webpack:/index.js:57:58)"]}
_stderr_triaged_job-job_process_cnm_response-OPERA_L2_CSLC-S1_T108-230160-IW3_20231119T022138Z_20231120T074019Z_S1A_VV_v1.0-20231120T081549.388235Z_task-0d01698f-96b2-4df4-8ec2-923ef0f3381b.txt
What did you expect?
I expected [...]

Per @philipjyoon, Invalid checksum due to reprocessing of both static and non static products due to overlapping Standard and STATIC trigger rules.

Closing as it is more related duplication of trigger rules.


compilation speedup and ref-counting removal

This improves "compileBinary" by ~25%, and overall compilation by ~15%.
TS compiler is now about half of compilation time (on jumpy platformer). I think further gains will have to come from some sort of incremental compilation.
This also removes support for non-GC build (which I'm 100% sure were broken before, but now it's really gone).

Also, using node.js, first overall compilation time is 3.4s on my box, then 2.0s, 1.7s, and after a few more down to 0.8s. This doesn't seem as terrible as advertised.
If you're getting much worse times in the browser, then it's probably worth investigating.
(BTW, all of these times are for JS compilation; native is much slower)

re: build failure, looks like this just needs to be dropped?
https://github.com/microsoft/pxt/blob/12539bb7fdd3bf4c4f89338f75fdb73917927e1e/pxtcompiler/emitter/backjs.ts#L68-L69

build fixed, @pelikhan @riknoll


chore(travis) make sure run_tests.sh exits the correct code

@hutchic Looks like it's still giving a false positive? https://travis-ci.org/Kong/kong/jobs/455102458

closing this to just revert the commit that added | less. Will debug separately


Global imports with browserify ES6 syntax

I'm using Gulp with Browserify as my build tools.
Angular2 needs zone as a global variable, normally I would do this like that:
window.zone = require('zone.js');

but I have a problem when it comes to ES6 syntax and TypeScript.
Tried doing it like this:
import 'zone.js';
(<any>window).Zone = zone;

but this of course shows an error "Cannot find name zone' because variable zone is not defined anywhere.
Then I tried defining it like this:
import * as zone from 'zone.js';
(<any>window).Zone = zone;

and now I get "Cannot find module zone.js" but the weird thing is that it works and browserify compiles it correctly.
Also tried:
import {zone} from 'zone.js';

but this causes the same error "Cannot find module zone.js.
Could anyone help me how should I import it correctly?

Could anyone help me how should I import it correctly?

Currently your best option is to include zone.js via good old script tag. zone.js isn't really meant to be imported as it does non-trivial amount of monkey-patching and you don't want to have module loader interfering with this monkey-patching.

Thanks for the answer!
What about other libs that Angular2 requires? es6 promise, shims and reflect metadata?
Is it ok to import them with a module loader or is it better to use the script tag?
I separeted vendor libs from my actual app scripts. In the vendor file I import:
import 'angular2/platform/browser';
import 'angular2/platform/common_dom';
import 'angular2/core';
import 'angular2/router';
import 'angular2/http';

But then again in my app I import functions from those libs:
import {bootstrap} from 'angular2/platform/browser';
import {ELEMENT_PROBE_PROVIDERS} from 'angular2/platform/common_dom';
import {ROUTER_PROVIDERS} from 'angular2/router';
import {HTTP_PROVIDERS} from 'angular2/http';

Is this ok or will it duplicate some code while importing?

Personally I would include all shims  via a script tag since all of them are doing monkey-patching and I see no particular reason for risking loader interference with shims.

I just wanted to limit the number of requests a browser has to do to acquire all the scripts. Well, now I know why most of the boilerplates and starter packs for angular2 have those script in the script tag and not just importing them. SystemJS seems fine but I'm not sure if I want to make a separate request for every script file that I create.

make it async then ;)


"isPinned" appears to be missing from the returned dictionary.

I've just tried parsing a few accounts with pinned tweets and here's how the returned dictionary structure looks like for me:
{'tweetId': 'tweet_id_here', 'tweetUrl': 'tweet_url_here', 'username': 'username_here', 'isRetweet': False, 'time': datetime.datetime(2020, 1, 8, 5, 52, 25), 'text': 'text_here.', 'replies': 53, 'retweets': 57, 'likes': 218, 'entries': {'hashtags': [], 'urls': [], 'photos': [], 'videos': []}}
As I understand from the source code, "isPinned" should be right after the "isRetweet" but for some reason it's not there.
Added a snippet for quick reproduction:
for tweet in get_tweets("IntelCrab", pages=1):
    print(tweet)

I guess you guys installed library via PyPI, can you guys update the package?
,

Yes, now "isPinned" is returned. Thank you.

Good to hear that ^^ Have a good experience with library.


Detect module dependencies

Order the plan to build the dependencies before
the children
Closes #2

Thanks for the patch! A few things that come to mind:

we'll need to make sure dockerfile-parse supports multistage builds like we use in kibana (unfortunately I suspect it does not...) or at least behaves reasonably rather than crashing
dbuild may try to build images in parallel so just ordering them in the input list may not be enough, I think child images will need to be explicitly be built as child plans of their parent (in build_plan_tree of build.py)
like you mentioned in #2, we will need to replace the FROM ... in child images with the newly-built parent

Actually, that last point might be more complex... just switching around FROMs could be invalid sometimes. To really do this "right" we'd need to somehow make sure we only swap in e.g. monasca/python:2 for some images and not :3. Not totally sure how we'd go about that short of trying to pull metadata from tags like I'd like to do in monasca/pr-bot#17...

Are you referring to this part of the code or maybe that.
Hard to get a grip there :D

If I can be serious, after digging deeper inside dbuild I started to feel like this too much for me. Don't get me wrong but I thought it will be a bit simpler. I am leaving my project and I am suppose to work on either simple stuff and complete my open changes.
Sorry, but I guess I have to call it a day and leave that bit for you to handle ;-(
@matrixik you think you could work on this or is it out of your scope as well ?

Heh, yeah, that's totally fair. The complexity is a big part of why I haven't touched on it myself (yet, at least).
I've been thinking more and more that dealing with this build dependencies problem is not really worthwhile on a per-repository basis, to the point that we're just making PRs that change any parent/child modules an error in monasca/monasca-helm#186. From there we can have the pr-bot propose changes automatically, since it has all of the logic for figuring out dependency trees in one place.


Cannot access 'browser' before initialization

Hello!
I'm following the guide on how to use the mockzilla, but in fact if I do exactly the same as given in the Solution artice, I get the following error:
 FAIL  __tests__/subcomponents.test.tsx
  ● Test suite failed to run

    ReferenceError: Cannot access 'mockbrowser' before initialization

       6 |
       7 | const [mockbrowser, mockBrowser, mockBrowserNode] = deepMock<Browser>("browser", false);
    >  8 | jest.mock("webextension-polyfill", () => ({ browser: mockbrowser }));
         |                                                      ^
       9 |
      10 | function render(): ReactTestRenderer {
      11 |     const shrinkedView = TestRenderer.create(<ShrinkedView />);

      at __tests__/subcomponents.test.tsx:8:54
      at Object.<anonymous> (app/src/popup/subcomponents/ShrinkedView.tsx:3:1)
      at Object.<anonymous> (__tests__/subcomponents.test.tsx:3:1)

My environment is:
  "devDependencies": {
    ...and others,
    "@types/jest": "^28.1.7",
    "@types/react": "^18.0.17",
    "@types/react-dom": "^18.0.6",
    "@types/react-test-renderer": "^18.0.0",
    "@types/webextension-polyfill": "^0.9.0",
    ...and others,
    "jest": "^27.0.5",
    "mockzilla": "^0.14.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-test-renderer": "^18.2.0",
    "typescript": "^4.7.4",
    "webextension-polyfill": "^0.10.0",
    ...and others
  },
  "jest": {
    "verbose": true,
    "testEnvironment": "jsdom",
    "setupFilesAfterEnv": ["<rootDir>/__tests__/setupTests.ts"]
  },

Is there any more info on how to avoid that?
What am I missing?

Hi @BartoszKlonowski , sorry for the late reply.
The link you posted is mockzilla.  Mockzilla by itself does nothing with webextensions. mockzilla-webextension already does the jest.mock call for you. Please take a look at https://lusito.github.io/mockzilla-webextension/ instead.
That being said, the link you posted is a bit out of date and I will revisit it and try to find out your issue.
I'm guessing this has to do with jest hoisting the mocks to the top of the file. I'm pretty sure though that this worked at some point. Maybe not with recent jest versions.

I just tried reproducing the issue, but using just mockzilla (not mockzilla-webextensions), I can't reproduce the issue.
One error I see on your code (that is probably not related):
// This:
jest.mock("webextension-polyfill", () => ({ browser: mockbrowser }));
// should be:
jest.mock("webextension-polyfill", () => browser);

I know the wording is a bit confusing, but mockBrowser is not the mocked object, but a builder to define your expectations. In this case, browser is the mock. If you have suggestions for better names, feel free to tell me :)
The documentation has been updated to use webextension-polyfill (instead of webextension-polyfill-ts) as an example and it now contains a hint to use mockzilla-webextension instead.

I'm seeing this same issue, as the original poster, the distinction between mockzilla and mockzilla-webextension is unclear the mockzilla-webextension   doesn't distinguish between the modules and the setup of the actual functions to test in the mockzilla documentation doesn't show how the browser is being called, could you clarify the installation instructions? Thank you!

Hello @Lusito!
If the issue of mine is about mockzilla itself, then let me close this one as I also think this should be OK when using mockzilla-webextensions.
Thank you for the reply!


[BUG] Inaccurate results using remote model

What is the bug?
I followed this tutorial: "https://opensearch.org/docs/2.15/ml-commons-plugin/remote-models/index/" to integrate OpenSearch with an external model via REST calls. I used model https://huggingface.co/nomic-ai/nomic-embed-text-v1.5. Model is deployed successfully and the embeddings created as expected.
Also, I have tested the model locally with some data to be ensure about the quality of the results.
The problem occurs when I try to query the data using neural search. The score is almost zero (e.g., 0.0033772818, 0.0032656149) but it should have been greater than 60 based on my local testing.
What is the expected behavior?
Neural search score is inaccurate when using external models.
What is your host/environment?

OS: Ubuntu 22.04
Version: 2.15
Plugins: "connectors"

It was models problem. The model https://huggingface.co/nomic-ai/nomic-embed-text-v1 works as expected


Player UUID cached even if unauthenticated

Description
Player information is written to plugins/LuckPerms/yaml-storage/uuidcache.txt even if player fails to authenticate
Reproduction Steps

Non-whitelisted player tries to connect, fails to authenticate
Player information written to plugins/LuckPerms/yaml-storage/uuidcache.txt

Expected Behaviour
No logging of players who fails to authenticate
Server Details
git-Paper-342 (MC: 1.20.4)
LuckPerms Version
5.4.113
Extra information
May be similar to https://github.com/Multiverse/Multiverse-Inventories/pull/495

Only log information
[21:03:45] [User Authenticator #0/INFO]: UUID of player ChegBurp is e97019e5-216d-4037-a0df-1caaff480b23
[21:03:45] [Server thread/INFO]: Disconnecting ChegBurp (/<IP_ADDRESS>:61679): You are not whitelisted on this server!
[21:03:45] [Server thread/INFO]: ChegBurp (/<IP_ADDRESS>:61679) lost connection: You are not whitelisted on this server!

I have enabled
debug-logins: true

to get more information on the next one.

go into your server console and do /whitelist off also next time remove your IP from your issues

I don't want non-whitelisted players to connect. The point is they should not be logged by LuckPerms.
As to the second point: it's not my IP, it's the miscreant's IP. I don't mind publishing it.

Vanilla whitelist check happens after the login/authentication process when the player is ready to enter the world basically, LP will grab and cache the UUID during user login which happens before the whitelist/banlist is checked. I guess storing the ID could be delayed until after that but that could have some other implications e.g. around plugins using the API.

After some internal dialogue conclusion is that this is working as intended and it is not in our best interest to change how names/IDs are cached. Thanks for the issue report.


Include aerobase java git hash in build info

Current build include artifactory hash code.
Alternative impl, add git hash code to war files.

VERSION.md added to unifiedpush-package module.


Intellisense not showing constructor arguments

Here is the source with the constructor it should be showing https://github.com/aspnet/Logging/blob/dev/src/Microsoft.Extensions.Logging.Console/ConsoleLogger.cs

Hi! Thanks for reporting this problem. This is a duplicate of #36.


Feature request binary inputs

Hi,
I am realy happy with the current integration you have created👏
I appreciate the work you put into it.
I use 2 binary sensors for the water level of my pool. I saw this feature is on your todo list and hope you can find time implement this. Having this functionality I can automate some events based on high or low water level.
Thanks in advance,
Rien

@RienduPre sure, if you know a little bit of python (I know very little myself) you totally can help, adding a new sensor shouldn't be too hard. Besides, I don't have use the binary entries so it would be harder for me to test if it actually works.

If am I am correct, you are using pypoolstation. Looking into that code, I don't see references to sensor input. So that would make things harder to develop. Correct?

@straybiker I created pypoolstation, so we can make any change we need. The problem is that the API is not documented and I don't use the binary inputs or ORP sensor, so I don't know what field in the hundreds (literally, hundreds) of fields in the API's response to look for.
Then names are not very helpful either, these are for instance the ones I figured out that contain temperature, salt concentration, target ph and current ph:

It's mainly a matter of know where to look.

How do you get this list?
you can simply shortcut an binary input on the printboard and see if the value changes from 0 to 1

This is just the requests made to the api every few seconds when you check your pool in https://poolstation.net

This is just one of the requests made to the api every few seconds when you check your pool in https://poolstation.net

Ok but how do I execute such a request?

What I found sofar is:
THe status of the four relais:

mc = relais1
mj = relais2
mb = relais3
mf = relais4
0=off 1=on

I assume you mean the binary inputs, right? Because the relays have worked for a while now.

No I'm searching for the binary inputs right now

The inputs are just potential free inputs. I wired them so I can easily make the contact to test and check the api response. But it has to wait till next week.

I'm having trouble to setup a HA development environment on my M1 mac, so I'm able to do some programming myself and my python knowledge is also very limited

Let me handle the pypoolstation update first to expose the binary sensors and that waterflow one too. Hopefully tonight.
For setting up HA in an M1 mac, I'd suggest to use VSCode with the docker extension installed. As soon as you open the project it should detect that it has a dockerfile and ask if you want to reopen it in a container.

I've published a new version of the pypoolstation that also parses the state of the binary inputs and also their names, because they are configurable. Initially they are "D1", "D2", etc..., but in your very screenshot you've renamed one of them to "Test1". This can be useful to create the entities in home assistant with a more helpful name.
I also parsed the waterflow, which can useful to create a binary sensor with device type "problem", which is a special type of sensor that when its state is ON home assistant will report it in the UI.
I've created one for when my heat recuperator tells me that the filters need cleaning and I found it handy.
It's a bit late to make the changes to the integration, I'll try to find time tomorrow.

Update: It turns out this integration was quite outdated with modern idioms for home assistant, particularly on how number entities worked. tl;dr; Some behavior was deprecated and it would have stopped working in 2023.10. I first took care of updating and cleaning everything.
Now I think I can start adding more features. In the next few days....

I added the waterflow binary sensor. It can be either OK or Problem.
Binary sensors will come next.

Works great sofar👍
Thanks for your effort.