Sensor only install

Just read your IDS article on tripwire.com and decided to give it a shot since I had a spare raspberry pi 3 lying around.  It looks like from the code that if you choose option 2 (sensor only) that it tries to connect to elasticsearch during the logstash installation process but elasticsearch doesn't install for option 2.   It tries to connect 10 times and then exits.    I'm not a programmer so forgive me if this is way off.   Looks like you just updated the files so maybe you're still working out some bugs.

That's by design i believe. Option 2 assumes that you already have a server installed in another device (Pi or otherwise), which will have the elasticsearch running. The script is trying to connect to that server. Just be mindful to insert the same elasticsearch user and password on the client "setup", that you used on the server.
if you only the 1 Pi to use, you should choose option 1.

excellent that worked.  Thanks.


Missing command line argument

File: docsarchive.md
Im afraid there is no command line argument for the first example in this file.  The variable {{ archive.image }} specified in the document source is undefined (or blank?) because this source file was changed not to include _data/docsarchive/archive.yaml.

Thanks for sharing the issue. This appears to be fixed. If the issue still persists, please let us know.


I can't find the minimized version

I've been searching and cannot find the minimized version. Is there a good reason for not including it in the download? I want to combine normalize.css with my own styles, but there is too much whitespace and comments for comfortable production use. I'm not sure if this is a bug, a suggestion, or just a question, but the documentation doesn't  seem to address it.

Please search existing issues before reporting new ones.
This was decided against in https://github.com/necolas/normalize.css/issues/4#issuecomment-1783421


simplemde.min.js has 214 KB seems a litte  large ?

Hi,I noticed simplemde.min.js has 214 KB ,it seems a litte  large for  a simple, embeddable, and beautiful markdown editor ?

Since it is standalone, it is bundled with a number of libraries and plugins and cannot be reduced in size any further.


Images are not being uploaded when adding a pin

Steps to recreate -

Create a new board
Add a new pin to a board
Upload an image - the image fails to upload

This prevents from adding a pin as the image field is required
Browser version: Firefox 119.0
Operating System: MacOS

uploads are powered by https://nostr.build api and it's currently working fine.

@sepehr-safari just tested it out, working as expected. Thanks


[Backport] basic security extension ignore permissions that use unknown ResourceType or Action

Backport of #10896 to 0.21.0.

Oops, I need to fixup the test for this backport since it is using the 'VIEW' enum value, which doesn't exist in this branch 😜

backport + changes to tests LGTM


decide on workflow strategy

As there seem to be different opinions on workflow, especially merges, we need to discuss that in an own issue instead of the now closed pull request #58.

@Bachibouzouk I got explicitly asked by @MGlauer and @gnn to let my changes undergo a review process before I merge so I‘m in conflict right now.

@akleinau - No you're not in conflict :) : I am not giving you the order to merge without asking for a review, I am suggesting we do not let a PR open for too long. Therefore suggesting you should soon ask for someone to review your PR so we can merge it and you can keep working on the issue in a subsequent PR :)
My point is that we should keep each PR as small work packages (all the changes you commit should nevertheless not be dependent of changes to come). For example, it seems to me that the commit 693b4504ead2f312cb955e913a83fd5f35c8bcb5 could perfectly be merged into devregardless of the other commits of this PR.
To recap : @MGlauer and @gnn are right that changes need review before merging and one should merge as often as possible (because all developers will modify oeo.omn and it can create merge conflicts). "As often as possible" is to be evaluated by the developer and the exact time span can vary. For small things it can be hours, for larger ones days. If longer than a week, maybe the work can be spitted in smaller independent packages?
Originally posted by @Bachibouzouk in https://github.com/OpenEnergyPlatform/ontology/pull/58#issuecomment-550227742

I appreciate that your goal to avoid merge conflicts by committing often, but this sounds like a very dangerous strategy, because it would involve merging untested content into dev.
In the ontology world there is no such thing as "local variable" or "encapsulation". Thus, any change you make to an ontology may interact with anything else (via logical inferences). For this reason, if you make significant changes to the structure of an ontology, it is usually not possible  to break that down into smaller steps. In my experience you need to finish the task, ensure consistency, and check whether the ontology is able to prove its intended consequences (aka competency questions), and then you make the pull request.
Originally posted by @fabianneuhaus in https://github.com/OpenEnergyPlatform/ontology/pull/58#issuecomment-550307597

Very good initiative @akleinau :)

Just to make sure my intent is not misinterpreted : I am not giving orders, I am making suggestions so we can find the best workflow to have multiple person contributing to the ontology's repo.
@fabianneuhaus (from your comment within #58 discussion's thread)

I appreciate that your goal to avoid merge conflicts by committing often, but this sounds like a very dangerous strategy, because it would involve merging untested content into dev.

Merging often does not mean merging untested content into dev, merging a branch into dev must be done via a Pull Request and be reviewed (i.e. tested) by someone else (as described in the CONTRIBUTE.md file).

For this reason, if you make significant changes to the structure of an ontology, it is usually not possible to break that down into smaller steps. In my experience you need to finish the task, ensure consistency, and check whether the ontology is able to prove its intended consequences (aka competency questions), and then you make the pull request.

I have no experience with ontology, so I don't know what is the smallest task that can be made on the ontology, this is why I used the "As often as possible" expression. The definition of "possible" must come from someone (like you) who has experience with ontology.
My goal is to ensure that no one else needs to spend another 2 hours solving 54 merge conflicts on the oeo.omn file because the changes were sitting on several feature branches for months (which is also not good for the ontology because there could be many errors arising from the conflict solving). Therefore I am trying to setup a workflow in the CONTRIBUTE.md file. This is a first draft and it would be good if you can help improve it by adding from your ontology experience (typical number of lines changes for a task (order of magnitude, i.e. it is more 100 lines or 1000 lines change for one task), typical number of days for a task (1-2 days, week or months)
One thing is sure : with the current git workflow it is very likely to get conflicts when more that one people work on the same file. Maybe we could make sure the people do not edit the same lines of the file before starting to work on a task (i.e. a developer could say I will make changes on lines 100-1000, so that another developer could avoid making changes in this region of the file).

I understand your frustration having to spend 2 hours of dealing with merge conflicts. We all agree that speedy reviews are desirable and will help to avoid problems. Further, I agree with the goal  to break down tasks in the smallest portions possible. My point is just that if you make significant changes to the structure of the ontology, “smallest possible” is still very large. Because you cannot test your changes until you are done applying the changes systematically. And if several people work in parallel while structural changes to the ontology are made, merge conflicts are probably unavoidable.
This problem should occur less frequently as the ontology becomes more mature and stable. Because in the case of established ontologies most changes involve just adding new classes or axioms or maybe some definitions. All of  these changes are relatively localised and involve only few axioms. And, thus, the reviews of these changes should be quick and easy.
By the way, in my opinion the testing should be the done by the developer before the Pull Requests.

On 7. Nov 2019, at 12:03, Pierre Francois<EMAIL_ADDRESS>wrote:
Just to make sure my intent is not misinterpreted : I am not giving orders, I am making suggestions so we can find the best workflow to have multiple person contributing to the ontology's repo.
@fabianneuhaus https://github.com/fabianneuhaus (from your comment within #58 https://github.com/OpenEnergyPlatform/ontology/pull/58 discussion's thread)
I appreciate that your goal to avoid merge conflicts by committing often, but this sounds like a very dangerous strategy, because it would involve merging untested content into dev.
Merging often does not mean merging untested content into dev, merging a branch into dev must be done via a Pull Request and be reviewed (i.e. tested) by someone else (as described in the CONTRIBUTE.md https://github.com/OpenEnergyPlatform/ontology/blob/dev/CONTRIBUTE.md file).
For this reason, if you make significant changes to the structure of an ontology, it is usually not possible to break that down into smaller steps. In my experience you need to finish the task, ensure consistency, and check whether the ontology is able to prove its intended consequences (aka competency questions), and then you make the pull request.
I have no experience with ontology, so I don't know what is the smallest task that can be made on the ontology, this is why I used the "As often as possible" expression. The definition of "possible" must come from someone (like you) who has experience with ontology.
My goal is to ensure that no one else needs to spend another 2 hours solving 54 merge conflicts on the oeo.omn file because the changes were sitting on several feature branches for months (which is also not good for the ontology because there could be many errors arising from the conflict solving). Therefore I am trying to setup a workflow in the CONTRIBUTE.md https://github.com/OpenEnergyPlatform/ontology/blob/dev/CONTRIBUTE.md file. This is a first draft and it would be good if you can help improve it by adding from your ontology experience (typical number of lines changes for a task (order of magnitude, i.e. it is more 100 lines or 1000 lines change for one task), typical number of days for a task (1-2 days, week or months)
One thing is sure : with the current git workflow it is very likely to get conflicts when more that one people work on the same file. Maybe we could make sure the people do not edit the same lines of the file before starting to work on a task (i.e. a developer could say I will make changes on lines 100-1000, so that another developer could avoid making changes in this region of the file).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/OpenEnergyPlatform/ontology/issues/64?email_source=notifications&email_token=AAWE2W4KYF4KN6GNIOYPU53QSPYXBA5CNFSM4JJXGDCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMBJXA#issuecomment-551032028, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWE2W6WCPJMVIJCUQR62L3QSPYXBANCNFSM4JJXGDCA.

Maybe it can be helpful to distinguish workflows between a) including new terms and b) restructuring existing parts.
a) Small steps for PRs can be helpful when including new terms to the ontology. Anyway, I think it is necessary to increase the ontology slowly and sustainably. I make a first suggestion for a work flow:

1 PR for 1 new term, including adequate bfo classification, proper definition, proper relations, and maximum a few(!) subclasses, if at all.
Discussion on the topic and Review by at least 2 domain experts.

b) Changing the current structure of the onology might be more difficult and not so easy to break down to small steps, as @fabianneuhaus described. I have no good suggetion for this workflow right now.
We are also going to discuss this on next weeks SzenarienDB meeting.

@fabianneuhaus - Thank you for your reply. This triggers new questions form my side :

Could you provide order of magnitude estimates of the number of days, weeks, month it typically takes to restructure an ontology (I have no idea, so even a vague idea is better than no idea)?

Do you have a procedure to test an ontology after it was restructured ?

Maybe it can be helpful to distinguish workflows between a) including new terms and b) restructuring existing parts.

Thank you for this suggestion @stap-m :)
Would you like to include a draft of this in the CONTRIBUTE.md file? Otherwise I can do it and ask you to review it. I would suggest that we include in the PR and issue name a [A] or [B] to indicate if it concerns either a) or b) workflows.

I would also suggest that we keep the information about who knows what in an AUTHORS.rst file so that newcomers to the project (like me) get an idea of who's responsible for what.
##Ontology experts:

@fabianneuhaus
@MGlauer
@stap-m  ?

##Students currently working on the ontology:

@akleinau
@solar-c
@Izzet91

##Past contributors to the ontology:

The number of papers on ontology evaluation probably exceeds the number of ontologies. Here is my own contribution to the pile:
https://www.researchgate.net/publication/260834360_Toward_Ontology_Evaluation_across_the_lifecycle
One useful technique is called “Competency Questions”. Papers on this are by Michael Gruninger and Fox. Another involves looking for bad patterns. There used to be tool called Oops! for this purpose, I am not sure whether it is still around.
I don’t think it is possible to estimate duration. In my experience, the time consuming part of ontology development is never doing the changes, it is getting consensus among the people that it is the right thing to do.

On 7. Nov 2019, at 12:51, Pierre Francois<EMAIL_ADDRESS>wrote:
@fabianneuhaus https://github.com/fabianneuhaus - Thank you for your reply. This triggers new questions form my side :
Could you provide order of magnitude estimates of the number of days, weeks, month it typically takes to restructure an ontology (I have no idea, so even a vague idea is better than no idea)?
Do you have a procedure to test an ontology after it was restructured ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/OpenEnergyPlatform/ontology/issues/64?email_source=notifications&email_token=AAWE2W24OTXPPOVSPXHMHODQSP6KXA5CNFSM4JJXGDCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMFDLQ#issuecomment-551047598, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWE2W62XAURIGJLTZQ6HDTQSP6KXANCNFSM4JJXGDCA.

Here is my own contribution to the pile

Thank you for the references @fabianneuhaus !

I don’t think it is possible to estimate duration.
Not even a lower limit, i.e. "Based on experience, it usually takes more than X days/weeks/months"?

In my experience, the time consuming part of ontology development is never doing the changes, it is getting consensus among the people that it is the right thing to do.

This is a valuable information for ontology beginners, thank you :)

This issue arise from @han-f comment

This is why I am a "fan" to always explain the "why" right where I ask for something. I think this also helps to avoid confusion and saves time (no need to click somewhere else and get familiar with another issue and then click back).

I would suggest that one should at least copy-paste the issue description within the PR description.
Originally posted by @Bachibouzouk in https://github.com/OpenEnergyPlatform/ontology/pull/70#issuecomment-552426191


Enable zoom out same size

The input for the zoom operation is limited to min_factor>1.
I actually needed to use it for a "zoom out" functionality and simply disabled the input check - then everything worked as expected.
Should this input check even be there? I know for most users adding a black margin for the "zoom out" effect is unwanted, but they can simply only use min_factor>1 so no need to forbid it.
See the issue I opened here:
https://github.com/mdbloice/Augmentor/issues/53#issuecomment-340140842

Hi @eddiesmo looks good to me, thanks for the PR!


configurable inclusion of trash can / delete

... and configure this to be "off" for DCW.

@mcjustin @pbugni @ivan-c
With this PR, the appearance of trash can/delete icon is governed by the configuration variable, ENABLE_PATIENT_DELETE.  Setting the variable to true will make the icon appear.  The default value for the configuration variable is currentlyfalse - meaning that the trashcan icon won't be present by default.  It means that we will need to set the variable to true for COSRI..  Or should the configuration variable has a true value by default so the trashcan icon is present by default?

@mcjustin @pbugni @ivan-c With this PR, the appearance of trash can/delete icon is governed by the configuration variable, ENABLE_PATIENT_DELETE. Setting the variable to true will make the icon appear. The default value for the configuration variable is currentlyfalse - meaning that the trashcan icon won't be present by default. It means that we will need to set the variable to true for COSRI.. Or should the configuration variable has a true value by default so the trashcan icon is present by default?

I prefer a default of false for this, since the delete operation is rather undefined and dangerous (COSRI has a special carve-out since it can rely on the PDMP for re-population of most data).


Support for Javadoc Comments

Generated API has no line of text describing what each operation does. A good case for javadoc! However due to the fact that this analyzer gathers data from bytecode, it does not have the Javadoc available. A possibility might be for the analyzer to gather some data from the source, invoke a build process and gather the remaining information from bytecode. Another option albeit less attractive would be to have a special annotation carry the comment into bytecode.

any news on this ? thanks !

Yes, JavaDoc is actually supported in the current version. Thanks for reminding me to close it.


Enable CSS oklab() and oklch() format and ∆Eok

There are still some discussions regarding Oklab and Oklch. Will they scale some things differently? Will the ∆E method get shaken up? It is a bit early to include this until the dust settles.

If perchance, the CSS spec adds some additional ability to use percentage on chroma, we will adjust accordingly. This would most likely be optional.


VASSAL: Add VASSAL engine v3.7.14

Adding manifest for VASSAL. This relates to #960

[x] I have read the Contributing Guide.

/verify

Don't merge this yet, I need to add a pre_install

I added installer and uninstaller properties in the manifest. When I test this it does pop up the UAC prompt since even running silently and setting destination to scoop $dir doesn't cause the installer to not try and elevate to admin. Is that an issue, as I think the goal with scoop manifests is to avoid UAC, but I'm not sure of the best way to avoid that here.

Is that an issue, as I think the goal with scoop manifests is to avoid UAC, but I'm not sure of the best way to avoid that here.

This is a NSIS-based installer according to file:
$ file VASSAL-3.7.14-windows-x86_64.exe
VASSAL-3.7.14-windows-x86_64.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows, Nullsoft Installer self-extracting archive, 7 sections

You should be able to remove the (un)installer properties and add #/dl.7z at the end of the download URL, similar to sauerbraten.json.


Integrate with Performance Monitoring tools

Replace/repurpose Monitoring widget with Application Performance monitoring widget. First version will be integrating with AppDynamics

Also see https://github.com/capitalone/Hygieia/issues/463

@tabladrum please let me know if this is still a valid issue.


Use PubChem as the primary identifier for Compounds

FEATURE DESCRIPTION
Feature Inspiration
HMDB is a very useful database of human metabolites, however, researchers sometimes measure or infuse compounds that are not considered naturally occurring human metabolites (e.g. ???). Using PubChem as the required, primary identification for a Compound record would allow TraceBase to handle a larger variety of compounds. Links to other databases such as HMDB can be added if available for convenience.
Feature Description
Make PubChem ID a required field for Compound. Change HMDB id to be an optional value.
Alternatives Considered
An alternative would be to use the SMILES key as the primary identifier (mostly hidden from user). Pubchem lists the SMILES id for compounds (for example: https://pubchem.ncbi.nlm.nih.gov/compound/6287#section=Canonical-SMILES).
The advantage would be that a compound not in pubchem could be integrated into the database. I doubt there are many of these. The only possibility might be pharmacologic compounds that researchers administer to animals.
Comment
Add any other context or screenshots about the feature request here.

ISSUE OWNER SECTION
Assumptions

List of assumptions made WRT the code
E.g. We will assume input is correct (explaining why there is no validation)

Requirements

List of conditions to be met for the feature
E.g. Every column/row must display a value, i.e. cannot be empty

Limitations

A list of things this work will specifically not do
E.g. This feature will only handle the most frequent use case X

Affected/Changed Components

Files
Environment variables
External executables
Database tables
Cron job settings
Etc.

DESIGN
GUI Change description
Describe changes the user will see.
Code Change Description (Pseudocode optional)
Describe code changes planned for the feature.
Tests
A test should be planned for each requirement (above), where possible.

An alternative could be to use the SMILES key as the primary identifier (mostly hidden from user). https://en.wikipedia.org/wiki/Simplified_molecular-input_line-entry_system.  Pubchem lists the SMILES id for compounds (for example: https://pubchem.ncbi.nlm.nih.gov/compound/6287#section=Canonical-SMILES).
The advantage would be that a compound not in pubchem could be integrated into the database.  I doubt there are many of these.  The only possibility might be pharmacologic compounds that researchers administer to animals.
I think Pubchem could be fine, but I wanted to share this idea for an alternative.

From @hepcat72: Towards a Universal SMILES representation - A standard method to generate canonical SMILES based on the InChI


dropping node-gyp as direct dependency

referencing
https://github.com/nodejs/node-gyp/issues/1439#issuecomment-397255452
and
https://github.com/sass/node-sass/issues/2355#issuecomment-397395712
node-gyp should be used as provided with the node installations.

referencing this https://github.com/sass/node-sass/issues/2355#issuecomment-397395712 probably there needs a discussion on how node-gyp should be used. @bnoordhuis maybe you can shed some light on using the implicit node-gyp.

If there's a binding.gyp in the top-level directory, then npm should automatically start node-gyp.

@bnoordhuis there is a binding.gyp, but I am still unable to access node-gyp in the scripts/build.js I am now planning to find the npm installation and locate the node-gyp.js manually.
but i am still wondering why am i not able to access node-gyp.

Ah, I understand now.  What I said about npm starting node-gyp is only true when there is no postinstall task in package.json but node-sass has one.
I think you should still be able to exec node-gyp rebuild though.  It's supposed to be on the PATH that the build script is spawned with.

Does this work with yarn as well? Why dropping node-gyp dependency improves things?

@bnoordhuis not really, i tried running node-gyp rebuild through the scripts it failed
@saper not sure yet, node-gyp is not a direct dependency for yarn, it was attempted because there are vulnerability issues in node-gyp and according to @bnoordhuis who is a node-gyp maintainer, it is recommended to use the node-gyp that was installed by npm.
the problem is that node-sass@5 is the only way to use the next node-gyp version as both of them will drop support for node<4.
but i was thinking if there was a way to use the latest possible version of node-gyp that can be allowed before the release of node-sass@v5

@Rohithzr yes but a project using yarn exclusively will not have node-gyp available. I think that explicit dependency is better.

@saper i know, i am just trying to find a way for it to work with yarn as well, if it doesn't then obviously it cannot be merged.

difficult to support it for yarn and some versions of npm. closing


S-Meter above S9

A minor observation on the S-meter display.
When a receive signal is greater than S9, the “overS9dBm” value is only shown if it is >= 10 dBm over S9.
I sort of expected any level above S9 to be shown, but the behaviour is as per the code and perhaps as intended.
Many thanks for this excellent firmware upgrade for the UV-K5 series.
73, Dave

Initially the + values were shown in multiples of 10, like an analog smeter, there usually are 10dB ticks, later I decided that this limitatiin doesn't make sense. This is why it is like it is. I'm not sure this can be considered a bug, it just works how it works. Maybe switching to + values after 6dB would be better, but does it really matter?

Hi,
Thanks for the response. All understood and accepted.
I will close the item.
73, Dave


Specifying component B to A in ligand mapping

Currently the LigandAtomMapping class has a componentA_to_componentB parameter that we can use to define the mapping. Some packages or tools might expect a different "directionality" in the mapping, for example in perses is inverted compared to the convention chosen by gufe (hopefully for convenience, but maybe it was just arbitrary).
Do we want to have a componentB_to_componentA option for the constructor of a LigandAtomMapping object? That said, I'd think that we want at least to have it unambiguously defined in the docstring, even for the current parameter.

@ijpulidos you mean this? https://github.com/OpenFreeEnergy/gufe/blob/main/gufe/mapping/ligandatommapping.py#L59

Oh, that helps, but I meant this https://github.com/OpenFreeEnergy/gufe/blob/main/gufe/mapping/ligandatommapping.py#L25

Conclusion: a clarifying docstring specifying what the keys, values are in the componentA_to_componentB and componentB_to_componentA property dicts.


CIP: EventStream

cip: 117
title: EventStream
author: Joel Thorstensson (@oed)
discussions-to: https://github.com/ceramicnetwork/CIP/issues/117
status: Draft
category: Standards
type: RFC
created: 2022-04-22
requires: Streamtypes (CIP-5)

Simple Summary
This CIP describes the Tile document which is a very general stream type that represents and event stream, where events are emitted by a  DID.
Abstract
The EventStream allows DIDs to create a stream of events that are ordered. This stream type doesn't have the notion of a state object in the same way that a TileDocument does. Instead it keeps track of events that have been emitted and it's up to the application how to interpret these events. For example, an indexing service could be built on top of one or multiple EventStreams to create a collection of items created by one or multiple users.
Motivation
While the TileDocument stream type is useful to represent a JSON object, many applications require collections of objects from one or multiple users. Certain applications might also want to interpret events in different ways and provide various different way to query the data. The EventStream is agnostic as to how events that are emitted should be interpreted and instead an application developer can choose to implement a CRDT, a database, or a searchable index on top of one or multiple event streams. This will enable much greater data composability and scalability of the Ceramic network because processing is unbundled from the event stream itself.
Specification
Below the commit formats and state transitions of the EventStream are specified. Together they should inform an implementer with the general idea needed to implement this stream type in Ceramic.
StreamID code: 0xXX
Commit formats
The Genesis commit has the following required properties:

owners - the owners array in the header needs to contain only DID strings

In addition to the required properties above the genesis commit may inlcude schema, tags, and unique. The unique property should include randomness as a string to ensure that there is no other document that is exactly the same.
The genesis commit must be stored using dag-cbor.
Signed commits of a Tile document are encoded using dag-jose. Other than that they conform to the standard commit format. The content of the data property should contain the event data. If the schema is defined in the genesis commit, the contents of the data property must conform to this json-schema.
State transitions
Below the state transition logic for the three different supported commits is described.
Applying the Genesis event
When the genesis event is applied a StreamState object is created that looks like this:
{
  doctype: 'event-stream',
  metadata: {
    owners: genesisCommit.owners,
    schema: genesisCommit.schema,
    family: genesisCommit.family,
    tags: genesisCommit.tags,
    unique: genesisCommit.unique
  },
  content: null,
  signature: SignatureStatus.GENESIS,
  anchorStatus: AnchorStatus.NOT_REQUESTED,
  log: [new CID(genesisCommit)]
}

In addition to this, the following should be verified:

genesisCommit.data MUST equal null
owners is an array containing only one DID
If schema is defined it should be Ceramic CommitId string
If tags is defined it should be an array of strings

Applying a Signed Commit
When a signed commit is applied the StreamState object should be modified in the following way:
state.next.content = signedCommit.data,
state.signature = SignatureStatus.SIGNED
state.anchorStatus = AnchorStatus.NOT_REQUESTED
state.log.push(new CID(signedCommit))

If schema is defined the data in the singedCommit.data should be valid according to the schema
The dag-jose signature should be valid and signed by the DID in the controllers array in the metadata property
The dag-jose signature should include a kid property in it's header which specifies the keyFragment as well as the version-id of the public key that was used to sign the commit

Applying an Anchor Commit
When an anchor commit is applied the StreamState object should be modified in the following way:
state.content = state.next.content
delete state.next
state.anchorStatus = AnchorStatus.ANCHORED
state.anchorProof = anchorCommit.proof
state.log.push(new CID(anchorCommit))

No additional validation needs to happen at this point in the state transition function.
Rationale
The EventStream specification provides a slight modification to the TileDocument stream type to create an event stream in Ceramic. By allowing a schema to be defined, the events of the document can be constrained. This gives developers both flexibility and control. The content just represents the latest the EventStream. Implementers should also provide an api to fetch previous event data based on the event log in the StreamState.
Implementation
No implementation exists currently
Security Considerations
See TileDocument (CIP-8).
Copyright
Copyright and related rights waived via CC0.

Will this become the core abstraction underneath all streams type or just one of the stream type?

Closing this CIP as there is no longer any plan to implement this as described here.

For context @qbig there is a plan to create an abstracted event stream in the Rust implementation of Ceramic. More info to come about this in the future.

Is this currently being inherited by #124 as the concept of an "Event" is not mentioned in other CIPs ? https://github.com/ceramicnetwork/CIP/pull/124

CIP #124 is a protocol for exchanging events. The idea is that the core protocol stops caring about stream types and only validates the integrity of the event log itself.
Currently the full core protocol is specified here:
https://developers.ceramic.network/protocol/


When composing, first lines of body could get interpreted as headers if there is an attachment

Hello.  I would like to a report a bug in version 2.6.1 of the mail gem.
To reproduce this bug, I ran the following code under ruby 2.1.3p242 (2014-09-19 revision 47630) [x86_64-linux]:
require 'mail'
msg = Mail::Message.new
msg.charset = 'UTF-8'
msg.to =<EMAIL_ADDRESS>msg.attachments['b.txt'] = ''
msg.body = "a:\n"
puts msg.to_s

The output I get from this is:
Date: Mon, 13 Oct 2014 14:58:35 -0700
To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--==_mimepart_543c4b0b50fd7_1ab33f8bb7ca7308887ee";
 charset=UTF-8
Content-Transfer-Encoding: 7bit

----==_mimepart_543c4b0b50fd7_1ab33f8bb7ca7308887ee
Content-Type: text/plain;
 filename=b.txt
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=b.txt
Content-ID<EMAIL_ADDRESS>

----==_mimepart_543c4b0b50fd7_1ab33f8bb7ca7308887ee
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
a:

----==_mimepart_543c4b0b50fd7_1ab33f8bb7ca7308887ee--

Note how there is no blank line before the "a:", so it is actually a header.  I would have expected there to be a blank line before the "a:" line, so that it would be part of the body of that MIME part.
I believe this is a bug because I would expect that a string passed into the #body= method would be treated as part of the body, not as a combined thing that contains headers and body.
This bad behavior goes away if I comment out the line that adds the attachments, or if I delete the colon or newline from the body.

Me and @xjeline5 have looked into this issue as part of our school project and we can confirm that this bug is still unfixed (under both Ruby 1.9.3 and 2.1.2).

msg.attachments['b.txt'] = ''
msg.body = "a:\n"

The problem is combination of creating multipart email and the way of setting the attachment and the body. Once the email is multipart, the simple assignment to body is treated as creating new part of email. This calls Mail::Part.new(value) in message's body_lazy function and then the value is checked for headers, which are in format "foo: bar". When creating new Part, :body parameter can be supplied instead and this leads to correct setting of the body (the same way convert_to_multipart does it). But because of the project structure design (there is a Message class, but also a Part class, that extends Message as well), there is not an easy way of recognizing that body_lazy function is called on an actual body of the whole email and it cannot be fixed there.

msg.attachments['b.txt'] = ''

This way of setting the attachment does not call the function convert_to_multipart, unlike when calling add_file, but the message is considered multipart internally. convert_to_multipart takes the old body and saves it as a new part correctly. If the text body is set before setting the attachment your way, it is overwritten.
The workaround to avoid this problem is to first set the body, then use add_file to insert attachment or call convert_to_multipart and then set the attachment the way mentioned in your example:
msg.body = "a:\n"
msg.add_file "b.txt"

or:
msg.body = "a:\n"
msg.convert_to_multipart
msg.attachments['b.txt'] = ''

Another way of achieving this that does not depend on the order of setting the body and attachment:
msg.add_file "b.txt"	# or msg.attachments['b.txt'] = ''
msg.text_part = Mail::Part.new(:content_type => 'text/plain', :body => 'a:\n')

If anyone has a hint how to solve the root cause, let us know and we can arrange the fix.

Fixed by #1114 😊


Fix memory leaks by using more specialized xml*Free functions.

Fixes https://bugs.swift.org/browse/SR-5256.

Does our current test case hit these lines?

TestXMLDocument.test_xpath() covers them.

I can confirm this fixes the leak. Thanks @mattrajca !

@swift-ci please test and merge

FYI @svanimpe this fixes the XML memory leak you reported on the Kitura slack 🙂


//replace does not work when damage values are supplied

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Select an area
Run //replace with a damage value specified in the block to replace (eg. //replace planks:1 air)

Expected behavior
The blocks should be replaced.
Screenshots
https://streamable.com/mrjqsm
System information (please complete the following information):

OS: Linux
PHP Version: 8.0
BuilderTools Version: Release 1.3.1

1s video so helpfull xd

sorry uploaded the wrong video

I also dont think that they work when you use block ids

What version are you using?


Security architecture

@rootzoll The RaspiBlitz is a hot wallet, therefore a potential target of physical or remote attacks. With this issue I'd like to a) get a clear overview of the existing security architecture and b) identify improvements.
Existing security architecture:

where and how are passwords A-C stored (file locations, clear text or some type of encryption)?
which "random" inputs are used to generate the Lighting wallet seed?
where and how is the Lightning wallet seed stored (file locations, clear text or some type of encryption)?

Potential improvements:

currently, during the update process of a new RaspiBlitz version, the master password (A) is automatically invalidated and a new master password has to be defined. Could this be a security risk? How can it be improved?
encryption of passwords on the disk, if not encrypted already
remove (potential Raspberry Pi-specific) deterministic components from the Lightning wallet seed generation
what would it take to move the Lightning wallet private keys into a Secure Element (e.g. Ledger Nano S) as an option? Maybe some of the other passwords as well? Could you raise your voice in the LND community and ask for a potential improvement to "externalize" the key storage? Is there someone who could write the Ledger App for LND?

where and how are passwords A-C stored (file locations, clear text or some type of encryption)?

password A is stored by the linux os as password for the users - thats standard linux security
password B is stored in the lnd/bitcoin conf in clear text - but thats OK and not possible another way. password B is also used by RTL app to secure the login within local network.
password C is only stored when user activates the auto-unlock feature. Otherwise LND can just say that password C is correct if its able to decrypt the wallet - so its not stored otherwise.
password D is also not stored on the device (if used to encrypt seed)
In generel during setup passwords could be stored in temp files, but those are deleted with unix shred command afterwards.
From my perspective this looks good. Any concerns here?

which "random" inputs are used to generate the Lighting wallet seed?

RaspiBlitz calls LND for that - so that question needs to be directed to the LND Dev Slack.

where and how is the Lightning wallet seed stored (file locations, clear text or some type of encryption)?

Thas also standard LND - as fas as I get it: the seed itself  is not stored. The seed is used to generate different private keys from and those are stored in the wallet.db - which is encrypted by Password C, wich is by default is not stored in the device. But while wallet is unlocked - its a hot wallet and is at risk when someone gains access to the device.

currently, during the update process of a new RaspiBlitz version, the master password (A) is automatically invalidated and a new master password has to be defined. Could this be a security risk? How can it be improved?

On update the sd card is fresh - it can just contain a standard password. To keep the password A it would be needed to be stored on the HDD in clear text what is not a good idea. So I think as long as the SSH is not exposed to the public and the local network is not compromised - this is OK for now.
But an idea could be that a fresh sd card image on first start would generate a temp password based on time and some other random data (temp, etc) and would set this for first login and just diplay on LCD. That way only the user physically seeing the LCD could login to a fresh RaspiBlitz or during a update. BUT -> that would make the LCD a must have and some users run their RaspiBlitz without an LCD - those user would not be able to make use RaspiBlitz anymore.

encryption of passwords on the disk, if not encrypted already

In generell a RaspiBlitz is not optimized to provide physical security. If you have physical access you can gain control. As much scary as that sounds - dont forget - even Trezor is not 100% secure against attacks if you have physical access (#walletfail). Thats why RaspiBlitz depends on the security of your home and location where you run it. This could be improved in the future but should not ease of use and ease of recovery of data. Because at the moment the risk of data loss/corruption is much higher as the physical security at your home. And encryption of HDD will make recovery of data much more harder in case of hardware fail.

remove (potential Raspberry Pi-specific) deterministic components from the Lightning wallet seed generation

We use ARMv7 build of LND - so I cannot see that there are any RaspiPi specific components on wallet seed generation. So that would also be a question to the LND team. BTW if you dont trust the seed gen on RaspiBlitz - you could generate seed on your own/other hardware with LND and use that seed during  RaspiBlitz setup.

what would it take to move the Lightning wallet private keys into a Secure Element

There is research to build hardware wallets for lightning - but thats early stage and we will have to see if there will be a LND integration - see: https://www.youtube.com/watch?v=Ipv-P1-pIv4

@geco91 Thank you so much for your detailed answer and for the reference of the presentation of Crypto Advance GmbH regarding Lightning HW-wallet aspects.
Regarding the passwords:
Password A: I didn't find it, neither in /etc/passwd nor in /etc/shadow.
Password B: I didn't find the lnd/bitcoin conf in /usr/local/bin/lnd.
Password C: If auto-unlock is enabled, where and how will it be stored?
My concern in general is that e.g. a coffee shop is proud to accept payments with his new Lightning node and posts his node in the web. Then a hacker might quickly get access to funds, maybe first trough a quick physical access reading out or changing the master password and then later quietly accessing the node remotely and executing transactions.
It seems quite safe if the node is completely stolen because, due to the power loss, the LND wallet would be locked again.
But for the worst case I'd consider that the hacker keeps the (unlocked) LND node running, has quick physical access to the node and is familiar with the system.
How to make sure that funds are still safe in this case?
As I understand, the trick with updating a new RaspiBlitz version could actually work well (during the short period of physical access) to set a new master password, however, at this point the LND wallet will probably be locked again due to restarts.
I think it is worth to specify different attack scenarios in detail, maybe open separate issues for each of them, and discuss how they could be prevented.
I can imagine a new monitoring / watchdog service which e.g. immediately shuts down the RaspiBlitz if "irregular activities" are identified (e.g. plugging not registered USB devices). After the shutdown it would be great if all passwords / wallets were locked and passwords are stored encrypted so that the attack was useless. On the other hand I'm aware that an immediate shutdown would not be the best approach for a running LND.
Regarding the HW-wallet for LND, the diagrams of Crypto Advance GmbH (screenshots from https://youtu.be/Ipv-P1-pIv4) indeed show the complexity, thank you for this link.

For now I'll keep an eye on https://cryptoadvance.io and hope they will keep pursuing their plan.

My concern in general is that e.g. a coffee shop is proud to accept payments with his new Lightning node and posts his node in the web. Then a hacker might quickly get access to funds, maybe first trough a quick physical access reading out or changing the master password and then later quietly accessing the node remotely and executing transactions.

You would not run the RaspiBlitz "in the coffee shop". The solution is to run the physical RaspiBlitz in a more private place (at home or in the locked managers office) and to give the staff a device (dedicated POS or a smartphone) that is online and has just the read-only/invoice macaroons from the LND. So it can create invoices and monitor payment - but it cannot send/steal money.
I havent found an easy simply Smartphone-App that allows that - @CandleHater wanted maybe look into this at the next Lightning Hackday in Munich/Germany. But the DIY PoS device "Flux Capacitor" is already aiming in that direction: https://github.com/arcbtc/flux-capacitor
Keeping your RaspiBlitz safe at home and putting a receive-only device connected to it at the store is the best way at the moment.
And future development of lightning-hardware-wallets or scripts RaspiBlitz-Scripts that automatically loop-out/splice-out channel funds to classic BTC-hardware-wallets will improve the security of your Home-RaspiBlitz further.

Very informative.
pls close this, not to be rude, but issues solved need to be closed to focus on important ones.


Updates the location of protobuf downloads

The protobuf repo has moved from github.com/google/protobuf -> github.com/protocolbuffers/protobuf. This updates the scripts/docs to reference this new repo.

Closing in favor of #5803.I didn't see it before I opened this one.


NumPy -> Torch

Really great work Hang! A couple high-level comments:

You mentioned a performence regression due to synchronization. Is that resolved?
For each of the issues I mentioned above, you should consider doing a global search, because I am not being exhaustive for every occurrence of these issues.
Can we make sure all the tests / examples as tests pass before merging this PR? What's the current status?
Currently I rubberstamped the transform_utils.py because I am not sure whether the math is completely correct. Any suggestoin for how I should actually review this?


fix: concurrency tests

Patch the COLUMNS_EQUAL_SQL template -- used in the adapter method get_rows_different_sql -- to not use the same identifiers as the tested relations in the TestConcurrency test cases. This avoids a duckdb binding issue and allows the original test cases to be evaluated.

LGTM @AlexanderVR -- thank you!


Don't show project settings starting with underscore

If you add a project setting that begins with underscore (e.g. _some_setting, without slashes), it will display under Global category. It's inconsistent with editor settings, which don't show underscored settings. This PR fixes the inconsistency.

Out of curiosity, does this also apply to editor settings?
It might be worth documenting this fact in the ProjectSettings (anf if relevant, EditorSettings) class reference, as editor plugins may want to rely on this in specific scenarios.

ProjectSettings have set_as_internal() for hiding properties. This is more relevant when editing project settings without a plugin (which is how I discovered this bug).


Android notification service  (IDFGH-9752)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
How can i program esp32 s3 to notify android sms/call alerts like ancs apple example.
Is there any guidance is there any android app required for that .
Kindly provide me the information.

ANCS is an Apple feature, it doesn't adapt to android.


[MM-467] Notification sounds

Summary
This PR is the continuation of another PR in the webapp to support custom notification sounds and adds the necessary functionality to play correctly the sounds.
Ticket
MM-467
Related webapp PR: https://github.com/mattermost/mattermost-webapp/pull/5721

@esethna I need a definition here before implementing this, so let me explain the current behaviour

Windows

lower or equal to 8.1 plays a custom sound
greater than 8.1 plays the native notification sound

Linux is working the same as webapp in browser
Mac: I have not done tests because I don't have one but my suspect is there is no custom sound for mac, meaning that it is always playing a native sound

Now we are adding 6custom sounds for the webapp, that means that for desktop app in Windows and Mac It would have 7 sound (6 custom + native). So the idea is the webapp can offer the selection the custom sounds only when the desktop app version is greater than x.y.z (up to you) as an older version of the app won't have the custom sounds bundled in the desktop app so it should not be able to play them.
If the desktop app is newer then the webapp will show the option to select custom sounds so until here there is no problem. My concern is as we are giving the option to choose custom sounds, when an user selects one, then the native sounds (for windows > 8.1 and mac) will be lost because it was overwritten by the custom selection. So I would like to know if this is ok or we should do another thing to handle this. Keep in mind the selection is only for the 6 custom sounds and the native one is not present in the list.
Maybe we should add the native option when the desktop app is detected, of course it complicates a bit more the things but I'm here to solve this :wink:
@Willyfrog I you see I said something wrong please let me know

@rvillablanca i haven't tested it, but there is the silent option in the options object passed to the constructor, so if the notification is going to be custom, we might want to use that to prevent having both sounds. See specs.

Hi @Willyfrog this is ready to be reviewed, I left some comments here that are related with this PR :wink:

This issue has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!
/cc @jasonblais @hanzei

@esethna @jgilliam17 Gentle reminder to review this PR when you have time :)

Thanks @rvillablanca, nice work!

Verified on Windows 7 - working as expected

Blocking until https://github.com/mattermost/mattermost-webapp/pull/5721 is merged.

This can be merged now @hanzei


Upgrade react-native-vision-camera

Explanation of Change

The PR upgrades react-native-vision-camera along with patch updates.
Fixed Issues

$ https://github.com/Expensify/App/issues/51761
PROPOSAL: https://github.com/Expensify/App/issues/51761#issuecomment-2473954373
Tests

There are no UI/UX changes, so the camera should work the same way it does now.

[x] Verify that no errors appear in the JS console

Offline tests

Same as "Tests".
QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."
Same as "Tests".

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/user-attachments/assets/7932695e-fe2f-4719-952d-f8c43db5f021

Android: mWeb Chrome

https://github.com/user-attachments/assets/1d088ec3-13f7-4d8d-b0f3-b48810787649

iOS: Native

https://github.com/user-attachments/assets/c605788e-045a-4411-b0e5-afecee1f44aa

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@rezkiy37 we have a failing test, can you please have a look ?

Yes, I am investigating it right now.

It works properly on Android, Android Chrome, and IOS Safari 😎
Videos

https://github.com/user-attachments/assets/4087c19e-cf0e-4823-b4f3-62aaa4651988
https://github.com/user-attachments/assets/13eee732-2152-4e75-835f-aff13613314f
https://github.com/user-attachments/assets/babf9f51-ddbb-4229-adf1-8ee231d96394

Unfortunately, I could not run the app on my iPhone because "its integrity could not be verified". However, I have the dev. mode enabled. @mountiny, do you know how I can fix it?
Screenshot

cc @allgandalf

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.


use es6 for awesome book

In this pull request I have used ES6 version of JS to build this awesomeBook project which me and my coding partner have already built using ES5 , following is the thing I did in this PR :

Project Setup:

Created a new directory for the project.
Created an index.js file as the entry point for JavaScript code , Created an index.css file for styling.
Created an index.html file and linked index.js and index.css to it.
Created a modules directory to organize your code.

App Development:

Developed the Awesome books app following ES6 syntax.
Divided mucode into modules by creating separate files in the modules directory.
Refactored functions to use arrow functions.
Utilized let and const appropriately for variable declarations.

Current Date Display:

Installed the Luxon library using npm to handle date and time.
Imported Luxon as a module in your code.
Utilized Luxon's capabilities to display the current date and time accurately.
Thank You ,
Bhushan .

Hello sir , thank you reviewing my code , I have made changes suggestedby previous reviewer :

Made all functions as arrow function .
Also I think the previous reviewer checked the wrong commit because i don't have any background image in my directory and time and date was showing .

Thank you ,
Bhushan .


📚 Fix typo in README.

Just updating the link to the tests.

@TheDubliner, thanks for the fix. :)


⚠ ClamAV has degraded performance

In 9479342, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 66 ms

Resolved: ClamAV performance has improved in 2609501.


Now, Contact Us form details easily get saved  into JSON file

🛠 Fixes Issue #637

👨💻 Changes proposed

✔ Check List (Check all the applicable boxes)

[ ] My code follows the code style of this project.
[ ] This PR does not contain plagiarized content.
[ ] The title of my pull request is a short description of the requested changes.

📄 Note to reviewers

📷 Screenshots

i am almost done my job. But it shows me some CORS policy error.
Can u plz suggest me how can i fix this error..

Which url should i include in "Access-Control-Allow-Origin"?


[Feature Request] Enable NativeAOT support for validating Json Web Tokens in ASP.NET

Is your feature request related to a problem? Please describe.
In .NET 8 our goal is to enable a subset of ASP.NET functionality to support publishing with NativeAOT. For more information on this goal, see Support publishing ASP.NET Core API apps with Native AOT.
One of the scenarios we are targeting is for an application to expose an HTTP API endpoint that is secured with JWT auth.
For example, an app like the following:
using System.Security.Claims;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication("Bearer").AddJwtBearer();
builder.Services.AddAuthorization();

var app = builder.Build();

app.MapGet("/", () => "Hello, World!");
app.MapGet("/secret", (ClaimsPrincipal user) => $"Hello {user.Identity?.Name}. My secret")
    .RequireAuthorization();

app.Run();

In order to make NativeAOT work in this application, we will need to make the JWT token validation library work with NativeAOT. See https://learn.microsoft.com/dotnet/core/deploying/native-aot/ for information on NativeAOT.
In short, we will need to address any NativeAOT and trimming warnings coming from the Microsoft.IdentityModel.* libraries when publishing an ASP.NET app for NativeAOT.  Current known warnings are stemming from:

[ ] LogHelper.LogExceptionImpl (should be an easy fix)
[ ] Microsoft.IdentityModel.Json, the internal fork of Newtonsoft (which is not AOT compatible). We will need to update all places that ASP.NET token validation code calls to use System.Text.Json instead, which can be AOT compatible.

Describe the solution you'd like
I am able to publish the above ASP.NET application for NativeAOT with no warnings. The app works successfully. The app's RPS is within 5% of the same application published normally. And then app size on disk isn't bloated due to unnecessary/unused code being generated.
Describe alternatives you've considered
N/A
Additional context
N/A

@eerhardt we should also https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/2032 and have asp.net use JsonWebTokenHandler then we do not have to include JwtSecurityTokenHandler (another assembly).

7.x is compatible with AOT


More high level documentation

I want to expose sort of a plugin system for my bevy app.
and i don't want different plugins to be using the same lua vm for four reasons:

mix up of different variable names and their data (atleast in global scope) leading to different weird (or even malicious) errors.
security. one plugin might require some kind of api key and this should not be accessed by other plugins.
one plugin might accidentally mess up the whole global table and cause others to go down with it.
run different plugins in different lua instances concurrently when they are not interacting with any global bevy data.

so, when i create a LuaScriptCollection, i want it to have its own lua vm.
is this possible right now?
also, I am wondering there could be a small Architecture.md  explaining at a high level how this works. I am not familiar with what the terms ScriptHost or ScriptCollection really mean in the abstract concept sense.

Hi! Sorry if this is not made clear in the docs, I will keep this issue around as a tracking issue for doc improvement. but in the meantime:
ScriptHost
The best way to understand the project structure is to look at the interface for a ScriptHost (line 64 in hosts/mod.rs):
/// A script host is the interface between your rust application
/// and the scripts in some interpreted language.
pub trait ScriptHost: Send + Sync + 'static + Default {
    /// the type of the persistent script context, representing the execution context of the script
    type ScriptContext: Send + Sync + 'static;
    /// the type of events picked up by lua callbacks
    type ScriptEvent: ScriptEvent;
    /// the type of asset representing the script files for this host
    type ScriptAsset: CodeAsset;
    /// the type representing the target of api providers, i.e. the
    /// script engine or the thing which stores the API
    type APITarget;
    /// the type of each doc fragment
    type DocTarget: DocFragment;

    /// Loads a script in byte array format, the script name can be used
    /// to send useful errors.
    fn load_script(
        &mut self,
        script: &[u8],
        script_name: &str,
        providers: &mut APIProviders<Self::APITarget, Self::DocTarget>,
    ) -> Result<Self::ScriptContext, ScriptError>;

    /// the main point of contact with the bevy world.
    /// Scripts are called with appropriate events in the event order
    fn handle_events<'a>(
        &self,
        world: &mut World,
        events: &[Self::ScriptEvent],
        ctxs: impl Iterator<Item = (FlatScriptData<'a>, &'a mut Self::ScriptContext)>,
    );

    /// Loads and runs script instantaneously without storing any script data into the world.
    /// The script receives the `world` global as normal, but `entity` is set to `u64::MAX`.
    /// The script id is set to `u32::MAX`.
    fn run_one_shot(
        &mut self,
        script: &[u8],
        script_name: &str,
        world: &mut World,
        event: Self::ScriptEvent,
    ) {
        let providers: &mut APIProviders<Self::APITarget, Self::DocTarget> =
            &mut world.resource_mut();
        let mut ctx = self.load_script(script, script_name, providers).unwrap();

        let entity = Entity::from_bits(u64::MAX);

        let events = [event; 1];
        let ctx_iter = [(
            FlatScriptData {
                name: script_name,
                sid: u32::MAX,
                entity,
            },
            &mut ctx,
        ); 1]
            .into_iter();

        self.handle_events(world, &events, ctx_iter)
    }

    /// Registers the script host with the given app, and attaches handlers to deal with spawning/removing scripts at the given stage.
    ///
    /// Ideally place after any game logic which can spawn/remove/modify scripts to avoid frame lag. (typically `CoreStage::Post_Update`)
    fn register_with_app(app: &mut App, stage: impl StageLabel);
}

A ScriptHost essentially orchestrates how ScriptEvent's get acted on/distributed to your scripts while also providing utilities for loading them from byte sequences.
Script
Script related components like ScriptCollection  and Script are essentially just markers describing which script assets are attached to which entities, they do not hold any script runtime data or contexts. The need for ScriptCollection arises since one can only have one instance of a component per entity as of bevy 0.7.
ScriptContexts
The actual script contexts, or script VM's are stored  inside the ScriptContexts resource, which is generic over the type of context it stores. As you can see from this structure:
pub struct ScriptContexts<C> {
    /// holds script contexts for all scripts given their instance ids.
    /// This also stores contexts which are not fully loaded hence the Option
    pub context_entities: HashMap<u32, (Entity, Option<C>, String)>,
}

impl<C> Default for ScriptContexts<C> {
    fn default() -> Self {
        Self {
            context_entities: Default::default(),
        }
    }
}

impl<C> ScriptContexts<C> {
    pub fn script_owner(&self, script_id: u32) -> Option<Entity> {
        self.context_entities.get(&script_id).map(|(e, _c, _n)| *e)
    }

    pub fn insert_context(&mut self, fd: FlatScriptData, ctx: Option<C>) {
        self.context_entities
            .insert(fd.sid, (fd.entity, ctx, fd.name.to_owned()));
    }

    pub fn remove_context(&mut self, script_id: u32) {
        self.context_entities.remove(&script_id);
    }

    pub fn has_context(&self, script_id: u32) -> bool {
        self.context_entities
            .get(&script_id)
            .map_or(false, |(_, c, _)| c.is_some())
    }
}

There is a unique one-to-one mapping between script components (which all have unique ID's) and their contexts/vm's.
Now the actual meaning of what a ScriptContext is depends on the ScriptHost itself, but for Lua this is represented as a Mutex<mlua::Lua> as seen here
Answer
What does this imply for Lua scripts? It means that every instance of a Script corresponds to a unique Lua VM, so all of your points 1 through 3 are indeed upheld with this crate.
When it comes to your point 4 however, while it may be possible to run multiple Lua VM's concurrently in general, in the current implementation of RluaScriptHost, script events are handled sequentially as seen here:
fn handle_events<'a>(
        &self,
        world: &mut World,
        events: &[Self::ScriptEvent],
        ctxs: impl Iterator<Item = (FlatScriptData<'a>, &'a mut Self::ScriptContext)>,
    ) {
        let world_ptr = world as *mut World as usize;

        world.resource_scope(
            |world, mut cached_state: Mut<CachedScriptEventState<Self>>| {
                let (_, mut error_wrt) = cached_state.event_state.get_mut(world);

                ctxs.for_each(|(fd, ctx)| {
                    let success = ctx
                        .get_mut()
                        .map_err(|e| ScriptError::Other(e.to_string()))
                        .and_then(|ctx| {
                            let globals = ctx.globals();
                            globals.set("world", world_ptr)?;
                            globals.set("entity", fd.entity.to_bits())?;
                            globals.set("script", fd.sid)?;

                            // event order is preserved, but scripts can't rely on any temporal
                            // guarantees when it comes to other scripts callbacks,
                            // at least for now.
                            // we stop on the first error encountered
                            for event in events {
                                // check if this script should handle this event
                                if !event.recipients().is_recipient(&fd) {
                                    continue;
                                }

                                let mut f: Function = match globals.get(event.hook_name.clone()) {
                                    Ok(f) => f,
                                    Err(_) => continue, // not subscribed to this event
                                };

                                let ags = event.args.clone();
                                // bind arguments and catch any errors
                                for a in ags {
                                    f = f.bind(a.to_lua(ctx)).map_err(|e| {
                                        ScriptError::InvalidCallback {
                                            script: fd.name.to_owned(),
                                            callback: event.hook_name.to_owned(),
                                            msg: e.to_string(),
                                        }
                                    })?
                                }

                                f.call::<(), ()>(())
                                    .map_err(|e| ScriptError::RuntimeError {
                                        script: fd.name.to_owned(),
                                        msg: e.to_string(),
                                    })?
                            }

                            Ok(())
                        });

                    success
                        .map_err(|e| {
                            error!("{}", e);
                            error_wrt.send(ScriptErrorEvent { err: e })
                        })
                        .ok();
                });
            },
        );
    }

The reason for this is that there is no guarantee that two scripts won't modify the same parts of the bevy World. Script concurrency is something I am considering, but it would require a lot of copying of what's already present in bevy and some sort of query syntax script-side to ensure safety.
However if concurrency is something you desperately need and you're sure your scripts won't violate rust safety rules, then you could most certainly implement your own ScriptHost which does in fact run your scripts in parallel. If this is something that people might want from this crate I am also happy to introduce cargo features to enable such behaviour in the feature!
I will note however that Unity for example does not run C# in parallel at all, and so this isn't the end of the world.
Let me know if this helps!

thank you. the README did not mention the scrip contexts, which finally made everything fall into place for me.
the main intended usage for scripts is to just provide egui to lua, so i won't lose much if the scripts run sequentially.
hope this crate gets published to crates.io soon :)

Yeah I need to improve some things in the presentation, hopefully once I publish to crates.io the presence of online documentation will help a bit.
The only reason I haven't published yet is that I am working on the bevy API which I believe to be an essential feature, and also because I want to be able to break public API's to develop quickly for now :P
Oh! That sounds great! do link me your crate if you end up using this one, I'd love showcase it in the readme when it's done!

I was able to successfully use bevy + bevy_mod_scripting + luaegui. although, now i just need to start adding bindings to functions as i use them in my projects to eventually cover the majority of the egui api.
The LuaArg type was simply the luaegui::Context which i get from Res<bevy_egui::EguiContextMut> in a normal system and send it via the priority event writer.
the main problem was the stale branch reference in the tealr dependency entry of bevy_mod_scripting crate. had to fork / patch it to tealr master for it to work. I also just used Cargo doc to look at the docs, and it was super easy to understand how bevy_mod_scripting worked and how to use it :) .
one thing that is also missing at the moment for a simple plugin system is being able to set package.cpath and package.path to the directory of the plugin. the main init script of a plugin would probably do a bunch of require("mylib.lua") or load native modules, but there is no way to set them afaik except implementing  my own custom RluaHost. default paths have current directory and std userlib directories like /usr/lib/lua.
maybe ApiProvider could provide the path of the script too? that would allow me to easily get the parent folder of the script and set it as the package.{path, cpath} before the script is loaded.

Fantastic news! thanks a lot for the constructive feedback, much appreciated!
This is exactly why I love scripting, hot reloading still blows my mind!
I will fix the tealr dependency issue tonight, I forgot to switch it back after the PR got merged (i needed it initially for full lua doc features).
Now I am gonna ask a bunch of possibly irrelevant or already answered questions just to make sure I understand what you're saying ;)
I will investigate your use case/package.cpath problem, could you elaborate on what the problem is exactly, I am gonna ? If memory serves me right scripts are able to require() paths relative to their own location, is this different for C dll's? Or is the problem wanting to load libraries from a location other than the scripts folder?
Also lastly, does modifying the LUA_CPATH env variable at runtime help at all in this case ?
When it comes to script paths, i think the bevy loader does not actually give you those back, so I'd have to store them on the script assets themselves, but providing those paths is certainly possible.
Could you provide me with a concrete use case so I can experiment with it and try to come up with a solution?

require starts searching from current directory. current directly is usually the project root where we run Cargo run
so, if there's two scripts in assets/scripts named sample.lua and hello.lua. then, if you want to require hello.lua inside sample.lua, then you write require("assets/scripts/hello") rather than require("hello").
usually, you would want plugins to be self contained and portable. so, i would just set package.path and package.cpath to the specific plugin root directory rather than just put all scripts inside the assets/scripts directory.
for example. assets/plugins be where the directory for my bevy game exists. a new plugin named "fps_counter" would be installed in such a way.
assets/
	plugins/
		fps_counter
			main.lua // the main script. this will have require("modules/counter") and require("native_modules/mmap")
			plugin.json // some details about version, download link, permissions required etc..
			modules/
				counter.lua // some library functionality in lua
			native_modules/
				whatever.so // on linux. probably made with mlua::module feature in rust for more performance like using machine learning to predict where the cake item is hidden :D

I would set the package.path and package.cpath to assets/plugins/fps_counter which would make sense. ofcourse, i might also want to set them to modules and native_modules directories directly too to restrict them even further.
LUA_CPATH would just set the env globally, while i want this to be specific to a particular script (plugin).
this will allow me to install, remove plugins cleanly and each plugin will exist in isolation. if something goes wrong, i can just tell users to go into this folder and manually delete the plugin that's causing issues.

@coderedart  please have a look at https://github.com/makspll/bevy_mod_scripting/pull/17

aye that should work. once i have the path, i can get the rest of the settings from the directory of the script.

Fantastic! let me know if anything else pops up :)

Should be addressed in https://github.com/makspll/bevy_mod_scripting/pull/67


Unable to connect to use the extension

Hi there, I can’t resolve the message…
Please log in to VSCode with a Microsoft Account first!
See blue badge at the bottom of the activity bar on the left
Shows as...

I’m logged in with a Microsoft account under Accounts
I have a dark blue “shield” badge at the bottom left of the status bar, below the activity bar, this takes me to “Workspace Trust” and I have “In a Trusted Workspace” selected
Settings are as follows..

What do I need to do?

looks like you have an outdated version - the UI should look like this and you should get prompted automatically for login the first time (or if you have not yet logged in successfully)

can you please check and make sure you are using the latest version v1.6.3

any feedback on this @atonkyn?
otherwise I would close this issue


Store something better than null in competition signup data

What's this PR do?
Moved the competition signup thing to outside of the response block.
That is only triggered if the user says yes, which was not saving any 0 values if a person opted out of a competition.
This allows for either a 0/1 to be stored here if the user interacts with the modal at all.
How should this be reviewed?
👀
Relevant tickets
Fixes #6617

👍


Can't change theme

Hi.
I installed vim-airline/vim-airline and vim-airline/vim-airline-themes with Plug and added let g:airline_theme='gruvbox' to ~/.vimrc file, but nothing changed. But if I enter :AirlineTheme gruvbox it applies. How to apply theme permanently?
This is my airline now.

I can confirm. I am using gruvbox theme too and on after opening any file with vim, airline just uses background colour with let g:airline_theme='gruvbox' in ~/.vimrc. Entering insert mode fixes that.
Before entering insert mode:

After:

Perhaps when trying to load the theme, the gruvbox colorscheme (and airline theme) is not loaded yet? Please provide a minimal reproducible example. Perhaps using the vimenter autocommand works for setting the airline-theme as well.

That's right. usig vimenter to set up theme allows to do it properly, also colours are  correct this way. This was, as you pointed it, caused by theme being unavailable. I have messed up plugin loading order so that is my fault.

Can you guys add some kind of warning about missing theme so newbies wouldn't open new issues next time? ;)

how about a doc PR?

Yes, vimenter solved the problem. Thank you.


Add Decimal128 support

Hello!
I wanted to pull in the work @zonyitoo has done in the past to allow support for Decimal128.
This PR:

[x] rebases that work over to master,
[x] includes a few more tests
[x] a serialization + deserialization for BSON Decimal128 type
[x] a few docs
[x] and two more methods for decimal128 -> i32 and u32 conversions.

@saghm and @kyeah if either of you have time for a review, I would really appreciate it.
Thank you for your time!

LGTM. Merge now.


refactor of indexing collection

See #78
This commit mainly:

Splits the IndexWebCollection (renamed to IndexCollection for generality) into pieces: IndexThreads, DiscoverFiles, etc. For now the IndexCollection does everything which is hard to maintain. After the refactor IndexCollection only maintains the main function (the entrance); IndexThreads deals with the threads; DiscoverFiles collects the to-be-indexed files based the collection.
Puts more work to each abcRecord: they go through the documents of each individual file, read documents and index them.

For a new record in the future add an entry to the IndexThreads and put the logic of reading/indexing documents into a new file in document package.

Hi @Peilin-Yang thanks for your contribution.
I took a look at your code... here's some discussion:
There's still a lot of logic centralized in IndexThreads, where you have "if type foo do this, type bar do that, etc." As we add more collections to index, this would become more complex...
How's this for an alternative proposal:

Rename ISimpleRecord something like Indexable - anything that can be indexed.
Create an interfaceCollection<D extends Indexable> - an abstract collection of anything that can be indexed. Maybe it even implements Iterator.
The indexer takes a Collection as input - that's the abstraction.
We have concrete implementations - Gov2Collection, ClueWeb09bCollection, etc. Each of these implementations has the parsing of the records, walking of the files, etc. hidden inside it. But this is hidden from the actual indexer, which basically just needs to know how to call "next document".
You can use inheritance to group together "similar collections. E.g., WarcCollection implements Collection, ClueWeb09bCollection extends WarcCollection, etc.

Thoughts about this design?

@lintool
Yes, this design makes the Collection more abstract.
I will try to make the changes soon.

Hi @Peilin-Yang can you go through all the files and make sure we have two space indentation to be consistent? Also, have you verified that everything still works after refactoring - i.e., effectiveness results still check out?

@lintool

will do the indent.
I've tested the indexes using DumpIndex and the numbers are correct -- disk12345, AQUAINT, Gov2, CW09B. Did not test on CW09A and CW12A but it should work.
will verify the effectiveness numbers soon.

Yes, we have a separate indexing path for tweets: let's leave that alone for now... we'll circle back and get that indexed in a separate issue.
Are we good to go for merging?

@lintool let me finish the refactor and the test first?

sg

@lintool Successfully verified the effectiveness numbers on Gov2.
I do not discard CollectionClass since SearchWebCollection uses that and I do not want touch it for now.

@Peilin-Yang Are we ready for merging?

@lintool Yes, if you do not have further questions.
We need a README for IndexCollection and another one for DumpIndex
I am going to file these issues


IEnumerable

Arrays do not implement IEnumerable<T> as can be seen via https://docs.microsoft.com/en-us/dotnet/api/system.array?view=netcore-3.0 which is a real pain. They do implement IEnumerable via Array -> IList -> ICollection

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

ID: a02d7544-6f92-5582-9d28-7160a5bc916a
Version Independent ID: 7e3f884a-94b6-ea27-70ea-060fe51f51c2
Content: Arrays - C# Programming Guide
Content Source: docs/csharp/programming-guide/arrays/index.md
Product: dotnet-csharp
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Hello!
Array is an abstract base class, and as the base class for other arrays, it doesn't know the type being used. Hence, IEnumerable<T> doesn't need to be implemented on Array directly. When you create a typed array, such as int[], they have the appropriate IEnumerable<T> interface implemented.
I'm going to close this issue. If your question is not answered, to leave a comment or reopen the issue. Thanks!

The documentation for array states "Array types are reference types derived from the abstract base type Array. Since this type implements IEnumerable and IEnumerable, you can use foreach iteration on all arrays in C#". The "Since this type" clearly refers to Array and states it implements IEnumerable which is incorrect. You can use foreach on any derived type of Array because it does implement IEnumerable.
All derived class may or may not implement IEnumerable but that is a bit irrelevant. You can write code that takes an Array as an argument and based on the documentation expect it to implement IEnumerable somehow.

Actually I just had a thought about 2D arrays. I tried
            var a = new int[,] { };
            IEnumerable<int> x = a;

Which fails to compile. So your comment about derived classes implementing IEnumerable<T> seems to only apply to 1D array not multi dimensional arrays.
In general that brings up another issue with this page that it is not clear about what in Array works for 1D arrays versus multi dimensional arays.

I can let @BillWagner decide what to do with this issue, but I don't think it's that important to document here. It is covered on the remarks section of the Array API type. You can see an answer on stackoverflow about this specific question: https://stackoverflow.com/questions/2773740/why-do-arrays-in-net-only-implement-ienumerable-and-not-ienumerablet
It's something that happens at runtime automatically for you.
However, if you really do want this info explained or linked to, you can always work with @BillWagner
to submit an edit to the original article. Click on the Content Source link at the bottom of your original comment. To learn how to edit, see the Editing files in a repository article from GitHub.
We can reopen the bug.

Just a note that this popped up on SO, with someone questioning the guide's accuracy, as it claimed that all arrays (even multi-dimensional ones) implement IEnumerable<T>.


fix curl get calico status error ( error in tls version, centos 7.3 1611)

curl use nss package to auto negotiate the tls version, but early nss package have issue with tls1.2 protocol.
this can cause curl report following error in kargo install process.
curl: (35) Peer reports incompatible or unsupported protocol version.
how to fix? ensure nss is the latest package.  after install latest nss package, above error disappear.
https://bugzilla.redhat.com/show_bug.cgi?id=1272504

Already got CLA

ci check this

ci check this

@xuhuilong The CI key word needs to be submitted by someone who has review rights for the repository. I apologize for the delays.

@mattymo got you, looks like it is not trigger the ci check. Could you please check it again? thanks in advance.

@mattymo  would you please review this by manual? cause the ci check cannot start.

@yamashi yes, could you provide a patch ?


HapiJS Integration

I've created a plugin for HapiJS (v17) based on the work you've done for Express. Would you be interested in adding it to your monorepo?
https://github.com/moonthug/hapi-xray

@moonthug
Thank you for writing this plugin for Hapi! I'll bring this up with the team internally to discuss.

Resolving as official support for HapiJS was released in 3.2.0 in the aws-xray-sdk-hapi package: https://www.npmjs.com/package/aws-xray-sdk-hapi


Release 0.5.1 with pre-built binaries

Would be great to have prebuilt binaries with https://github.com/google/ko/commit/ab4ca8ec17fc10541f2ddb1ef3b4118524a39079 included!

There was already a v0.5.1 tag for some reason, so I pushed v0.5.2 with that fix included 👍

Thank you @jonjohnsonjr :raised_hands:


Adding a note about support for pod labels.

@ahardin-rh PTAL, a companion PR to https://github.com/openshift/cluster-node-tuning-operator/pull/24


Processing file output option separate first level in yaml

Hi,
I see your json2yaml and is a great tool.
When use a big json file, and covert into a yaml file, write all in each line, the is difficult read without a separator.
An example is:
test1:
......
......
test2:
......
......
.....
Exist a option or workaround to generate the first level with a empty line?
Example:
test1:
......
......
test2:
......
......
.....
Regards

This should be possible. It'll be a couple of days before I have a chance to work on it though.

A provisional workaround, test if work:
cat myfile.json | json2yaml | perl -0 -pe 's/(\n\s+.+\n)([^\s]+|$)/\1\n\2/gim'


[Bug] Icons not showing in search

From version 0.5 to 1.1.0 icons don't show

Version 0.4.2 and prior show icons fine.

Thanks for the report. Fixed in b49d7f01f5d8f5bc754a5697dc9a71a6ccd0ecca

released a hotfix with version 1.1.1

Thanks. By the way, I see you are combining the paths as long as the Icon property is not null. It can be an issue with games that have the asset set via Url. What I've done to detect if they are an url is use regex to see if they match ^http
I also recommend using this method to get the file path instead of combining https://playnite.link/docs/api/Playnite.SDK.IGameDatabaseAPI.html#Playnite_SDK_IGameDatabaseAPI_GetFullFilePath_System_String_
Example: PlayniteApi.Database.GetFullFilePath(game.Icon)


Memory consumption increasing

Firstly, thank you for such a great library!
My issue is, the memory consumption is constantly increasing between batches in the adjoint method. Something to consider, one of the arguments I pass in as the solver's args field requires gradient. Could this be the culprit?

No, that wasn't it. It is not BacksolveAdjoint either. It is most likely a memory leak within the pytorch autograd Function's context ctx, see https://stackoverflow.com/questions/67471019/memory-leak-in-pytorch-autograd-function-when-assigning-and-returning-context-da

The snippet in the linked question runs with constant memory for me on pytorch 2.2.2. Do you have a minimal example that showcases the increasing memory requirements?

After some more snooping around, found pytorch/pytorch#25340, this might be the issue. Sorry, still can't make a proper minimal example

Torchmetrics was the culprit, sorry to disturb you


other style lora inference questions

I try to use other lora models (such as bellows) in civitai to generate results

I find that there are several black images in the 10 images after sd (I only merge the style lora, and I tried different lora models , and also many different multiplier_style numbers). How to fix this problem? THANKs VERY MUCH!

if you are interested in more other style lora, welcome to join our interest group for more information. https://www.yuque.com/forms/share/5892d145-99c3-406c-8785-13dcb50353b8 .


Output length not accounting for interleaved samples

I'm pretty confused about the following behavior:
#[test]
fn test_roundtrip() {
    let mut encoder =
        opus::Encoder::new(48000, opus::Channels::Stereo, opus::Application::LowDelay).unwrap();

    let mut decoder = opus::Decoder::new(48000, opus::Channels::Stereo).unwrap();

    let mut packet = vec![0; 200];
    let packet_len = encoder.encode_float(&[0.0; 960], &mut packet).unwrap();

    let mut output = [1.0; 960];
    let len = decoder
        .decode_float(&packet[..packet_len], &mut output, false)
        .unwrap();

    assert_eq!(960, len); // <- this assertion fails
}

The output buffer is filled to 960 samples, as expected (that's 10ms of stereo samples), but the returned size is 480. get_nb_samples returns 480, but passing a length 480 output buffer results in BufferTooSmall.
Is this just the expected behavior for libopus? I can't find it documented everywhere, but I also don't see anywhere this would be a bug in opus-rs. I haven't managed to test this using the C library yet.

Ok, the answer was in fact staring me in the face in the libopus docs (emphasis mine):

opus_decode() and opus_decode_float() return the number of samples (per channel) decoded from the packet.

Hopefully this helps someone else not get stuck on that.


Move doc/development/deployment into doc/deployment

This was a mistake in https://github.com/pachyderm/pachyderm/pull/1039. I should have moved doc/development to doc/deployment, but because I didn't give the -T flag to mv, the docs ended up in the wrong place.
This should hopefully (finally) fix CI

Since CI is broken without both this change (and is regularly failing without https://github.com/pachyderm/pachyderm/pull/1034), and it's a docs-only change (it breaks CI by breaking AssetsTest) I'm just going to submit it. I asked @JoeyZwicker to take a look at his convenience, and if this chance isn't what we want I'll revert and fix it


GH Actions

[x] lint

[x] ngx-slice-kit
[x] website

[x] test
[x] release flow

[x] publish ngx-slice-kit
[ ] deploy slice.rovergulf.net

https://github.com/rovergulf/ngx-slice-kit/blob/main/.github/workflows/build_publish_gcr.yml#L15
1
    name: Setup, Build, and Publish
# to
    name: Setup, Build and Publish

2
https://github.com/rovergulf/ngx-slice-kit/blob/main/.github/workflows/build_publish_gcr.yml#L32-L43
change to
      # Build and Publish Docker image
      - run: docker build --no-cache -t $IMAGE:$VERSION -t $IMAGE:latest .
      - run: docker push ${{ secrets.OCI_REGISTRY_IMAGE }}:$VERSION
      - run: docker push ${{ secrets.OCI_REGISTRY_IMAGE }}:latest


CC machine type, storage, and IOPS info

Specified machine types, storage types, and AWS IOPS per node in Step 5 of Create Your Cluster page.
Closes: https://cockroachlabs.atlassian.net/browse/CC-3698?atlOrigin=eyJpIjoiNjAwMWVlYWI3Y2U4NDlkMzg2ODUxOTkyY2FjN2U4Y2YiLCJwIjoiaiJ9
Question: Do we want to include IOPS for GCP cluster?

This change is

@lnhsingh Do you think it would be better to combine this info with this table: http://localhost:4000/docs/cockroachcloud/create-your-cluster.html#step-2-select-the-cloud-provider ?

Oh yeah, that's a good idea since Step 2 talks about vCPU
On Tue, May 4, 2021 at 4:14 PM Gemma Shay @.***> wrote:

@lnhsingh https://github.com/lnhsingh Do you think it would be better
to combine this info with this table:
http://localhost:4000/docs/cockroachcloud/create-your-cluster.html#step-2-select-the-cloud-provider
?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cockroachdb/docs/pull/10483#issuecomment-832213301,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADVMQGAHFDWZVYPHXKVCENLTMBIQ5ANCNFSM44BG2KEA
.

@kannanlakshmi friendly reminder to review when you can :)

And apologies for the 1 week delay here, this slipped my inbox last week!


issue334 - Added support for JSON logging via --json-logging command line option

Initial PR to allow JSON logging as per https://github.com/missionpinball/mpf-mc/issues/334

Thanks!


add css classes y-axis-[left/right] based on orientation

@drakonen this facilitates coloring the y-axes to match their chart lines

I am just wondering what you are going to do with this.

Closing this one. This is not needed anymore.


Ignore parsing logs of scan jobs has have been deleted

In the configauditreports controller we should ignore scan jobs that are cached but had been deleted from etcd so we cannot parse their logs. Currently we return an error, which is causing retry, but retrying does not make much sense in this case.
https://github.com/aquasecurity/starboard/blob/v0.13.0/pkg/operator/controller/configauditreport.go#L406

@danielpacak - Can we try to handle this with the check of IsNotFound like this:
logsStream, err := r.LogsReader.GetLogsByJobAndContainerName(ctx, job, r.Plugin.GetContainerName())
if err != nil {
    // Check if the error is related to not found
    if errors.IsNotFound(err){
        log.V(1).Info("Deleting complete scan job", "owner", owner)
        return r.deleteJob(ctx, job)
    }
    return fmt.Errorf("getting logs: %w", err)
}

func (r *logsReader) GetLogsByJobAndContainerName(ctx context.Context, job *batchv1.Job, containerName string) (io.ReadCloser, error) {
	pod, err := r.getPodByJob(ctx, job)
       // Return actual error
	if err != nil {
		return nil, err
	}
	...
}


Add References to MergeRequest.

Adds references as defined in the API:
    "references": {
      "short": "!1",
      "relative": "my-group/my-project!1",
      "full": "my-group/my-project!1"
    },

https://docs.gitlab.com/ee/api/merge_requests.html#get-single-mr

@finn-ball guess you need to fixup the tests first...

@svanharmelen Updated the tests. Should be ready to go now :)

Thanks 👍🏻


Getting "SECURITY ERROR" when running "make clean"

Over the last few releases (v0.9.1-alpha, v0.9.2-alpha, v0.10.0-alpha) I've seen the following error message when performing a "make clean" inside the repo directory:

SECURITY ERROR
This download does NOT match an earlier download recorded in go.sum.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

The full list of operations are:
git checkout master && git pull && git checkout tags/v0.10.0-alpha && make clean
I don't see this error when I pull, clean and build v0.9.0. I've been running v.0.9.0 since I don't feel comfortable building and running the other releases. Am I missing something?
The offending file seems to be go.mod

verifying<EMAIL_ADDRESS>checksum mismatch
downloaded: h1:G7mAYYxgmS0lVkHyy2hEOLQCFB0DlQFTMLWggykrydY=
go.sum:     h1:kA6FLH/JfUx++j9pYU0pyu+Z8XGBQuuTmuKYUf6q7/U=

I just checked the latest version again and things work for me. This usually happens if developers replace a tag with a new one. But that didn't happen in this case. Are you behind a corporate proxy or have any other unusual network setup?
Could also just be your local Go modules cache. Can you try go clean -modcache && go mod tidy?
Can you check what response you get if you open the following URL in a browser?
<EMAIL_ADDRESS>