Default values are ignored in FILESTORAGE and LOCALSTORAGE

I have the following tables:
CREATE TABLE IF NOT EXISTS banks (
       name STRING PRIMARY KEY,
       is_open BOOLEAN DEFAULT true,
       [key] STRING
);

CREATE TABLE IF NOT EXISTS pigs (
       id STRING PRIMARY KEY,
       bank STRING DEFAULT null,
       ready BOOLEAN DEFAULT false,
       dream STRING,
       notes STRING,
       kind STRING,
       timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
       FOREIGN KEY (bank) REFERENCES bank(name)
);

I have noticed that when I do an INSERT, all unspecified values are left as undefined instead of using any of the DEFAULT specifications.
This has been tested for both FILESTORAGE and LOCALSTORAGE.

Hii @mathiasrw
Noticing default values set during INSERT operations in tables (banks, pigs) are correctly applied. However, columns without explicitly provided values during retrieval display as 'undefined' instead of their defaults. Verified default value application in the database directly.
Additionally, updated the FOREIGN KEY reference from bank(name) to banks(name) for accuracy.

@arximboldi Can you confirm what @jigarBorde  said?


[Enhancement] Print pulsar log to a separated file

Pulsar related log is printing to be.out, use a separated file instead.
Also added a mutable config to change the log level:
// DEBUG: 0, INFO: 1, WARN: 2, ERROR: 3, WARN by default
CONF_mInt16(pulsar_client_log_level, "2");

What type of PR is this:

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)
[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.2
[x] 3.1
[x] 3.0
[x] 2.5

run all

@Mergify rebase


Wallet crashes without sudo rights on Ubuntu 17

Running nano_wallet without sudo results in an Aborted (core dumped) crash on Ubuntu 17.

Duplicate of #124
There's another solution there.

Thanks. It seems like the crash occurred because I was connected to the machine via xrdp, which is using xorg for display.
It doesn't occur when logging in normally on the machine. Setting GDK_BACKEND=x11 also solves the problem. I can update the wiki in case someone encounters a similar issue.


Allow nans to print in solution

To allow printing of nans in solution.

Related to issue 269

+1 for merging as a hotfix for #269.
Longer term, @bqpd, should we discuss whether nans should ever be in a GPSolutionArray? I'd be in favor of raising exceptions long before table printing if there are any nans, and therefore removing this fix. If you agree, let's still merge this but open a new issue for eliminating nans for a later milestone.

PS note inline commit comment to address before merging.

Made the or change as request.
And yeah, you're right there really shouldn't be nans there in the first place- I guess I just carried away with actually doing something.

Actually doing something is great!! Continuous improvement...

might want to close this and make the or change on #300 ?

@whoburg good point. I haven't reached that point in the refactor. We could potentially use a sparse vector instead? I put nan there here just so it'd be obvious if something weird happened (even several steps of algebra later), which seems to have worked...


Support Standard Name Modifers (not units!)

CF conventions support a set of standard_name modifiers.  See 3.3. Standard Name for more details, specifically:

A standard name is associated with a variable via the attribute standard_name which takes a string value comprised of a standard name optionally followed by one or more blanks and a standard name modifier (a string value from Appendix C, Standard Name Modifiers).

This PR modifies the CFVariableMixin standard_name setter (and the pyke rules) to support standard name modifiers.
I found there wasn't much testing of cube/coord names so I have split this PR into two commits:

The first commit has no functional changes. It just adds testing of the pyke rules to show that they don't break later when I add the functional changes
The second commit adds the changes to include the standard_name modifiers

Note that standard name modifiers have associated units (See CF Appendix C) however I have not included that in this PR as I am only modifying the standard_name setter which at the moment doesn't have any requirement on the unit

Ping @bjlittle !

@lbdreyer Okay, I think that I'm pretty much there...
As it happens, there wasn't any unit test coverage of CellMethods (there is for parsing, but not construction and usage), but I've added the minimal test coverage for the changes in this PR.
Being a good citizen, I'll add test coverage in a separate PR.
I've also not updated the docs either, just so that this PR can get banked sooner rather than later, but happy to make a follow-up PR, if you think that's appropriate... :smile:

@lbdreyer What's the strategy for checking the units of a standard_name with a standard name modifier?
Separate PR?

@lbdreyer What's the strategy for checking the units of a standard_name with a standard name modifier?
Separate PR?

I have raised this in a separate issue: https://github.com/SciTools/iris/issues/3408

@bjlittle I believe I have addressed your review comments in the third commit "review actions"
Note: I had to rebase the first two commits due a conflict that was caused when #3399 was merged, but those commits should be the same as they were before.

@lbdreyer Awesome, thanks! :tada:


feat: Expose atlas limits for TiledComponent

Description
This PR add the ability for users to override the max size of TiledAtlas used by TiledComponent for packing all the images of all the tilesets used by a tilemap. The overrides can be used if one is sure that their target platform can handle huge textures.
It also adds an assert for cases when the RectangleBinPacker runs out of space. This is done to help users find the problem quickly.
Checklist

[x] I have followed the [Contributor Guide] when preparing my PR.
[x] I have updated/added tests for ALL new/updated/fixed functionality.
[-] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[-] I have updated/added relevant examples in examples or docs.

Breaking Change?

[ ] Yes, this PR is a breaking change.
[x] No, this PR is not a breaking change.

Related Issues
Closes #2619

Lgtm! Maybe a short note about it in the docs? :)

Sure, but I am a bit divided on where to put it. There are 2 places in the docs that talk about TiledComponent

Flame->Components->TiledComponent
Bridge Packages->flame_tiled

Lgtm! Maybe a short note about it in the docs? :)

Sure, but I am a bit divided on where to put it. There are 2 places in the docs that talk about TiledComponent
* [Flame->Components->TiledComponent](https://docs.flame-engine.org/latest/flame/components.html#tiledcomponent)

* [Bridge Packages->flame_tiled](https://docs.flame-engine.org/latest/bridge_packages/flame_tiled/flame_tiled.html)

We should probably move all the components/tiledcomponent docs to the flame_tiled page, I think that is just left from before when there wasn't any bridge package section.

We should probably move all the components/tiledcomponent docs to the flame_tiled page, I think that is just left from before when there wasn't any bridge package section.

Done. Moved out the TiledComponent section to flame_tiled and added a section about TileAtlas.


How do you set the initial route?

Playing around with Saga pattern and stumbled onto your app here. How are you setting the initial route? I can add a second route in AppNavigation.js and change the initial state in NavigationRedux.js to point to this new route but it keeps loading LaunchScreen. I'm also accustomed to an older React Navigation release so maybe something changed there and that's my problem?

Since I've used Redux Integration in this kit, therefore you can find the relevant code in App/Redux/NavigationRedux

Look at that, figured it out as soon as I submitted the issue. Pure the persistor! Back to learning...


Go application instrumentation guide

This guide will include creating a basic Go application with Prometheus instrumentation

@juliusv @RichiH @brian-brazil This is ready for an initial review. Obviously there's a million ways we could take this. Let me know if y'all think this is a reasonable general approach.

@brian-brazil Okay, I've made another pass.

:+1: besides comments

@juliusv Somehow I'm super sloppy today 😉 I've gone through and smoothed over the rough edges AFAICT.

:+1:


Moveit_cpp Tutorial

Port of moveit_cpp tutorial to ROS2. This addresses issue #20
To launch the tutorial run:
`ros2 launch moveit2_tutorials moveit_cpp_tutorial.launch.py
Checklist

[x] Required by CI: Code is auto formatted using clang-format
[x] Convert launch files to ROS2
[x] Cleanup demo and add documentation

Should we remove run_moveit_cpp from the MoveIt2 repo and point users to this page .?

Changed were added in #69


2818 further socket usage optimizations

Lazily initialize the replica clients for replica/sync service
This is to optimize the connection count for the longhorn-manager engine
monitor loop, in a single loop the monitor executes the engine binary 8
times this leads to a total connection count of f() = 8e + 6 * 2r = 20
for a volume with 1 replica.
Since all the calls the monitor makes only require either the replica or
the sync client, we can reduce this further with this optimization to
g() = 8e + 6r = 14 per monitor loop.
The monitor loop executes 60/5 = 12 times per minute, so our total
connections per minute are reduced from 240 to 168. For volume with 3
replicas we end up with 312 connection per minute.
No further optimization on this end is possible, the next required task
is removal of the direct engine binary invocations by the longhorn-manager.
This will reduce the connection counts to h() = 1e + 2*r which as one
can see would lead to the desired behavior for each volume of 1 engine connection
and 2 connections per replica (replica / sync).
longhorn/longhorn#2818
Signed-off-by: Joshua Moody<EMAIL_ADDRESS>

Good to review, let me merge afterwards.


Maintain image rotation when zoom is applied

This is a (multiple allowed):

[x] bug

[x] enhancement

[ ] feature-discussion (RFC)

Swiper Version: 4.5.

Platform/Target and Browser Versions: Chrome.

What you did
I am currently using Swiper in react and using the react-id-swiper wrapper.  I am using the following parameters:
const params = {
  pagination: {
    el: ".swiper-pagination",
    type: "bullets",
    clickable: true
  },
  zoom: true,
  shouldSwiperUpdate: true,
  navigation: {
    nextEl: ".swiper-button-next",
    prevEl: ".swiper-button-prev"
  },
  getSwiper: s => (swiper = s),
  initialSlide: props.selectedItem,
  runCallbacksOnInit: true,
  on: {
    slideChange: () => {
      if (swiper) {
        if (swiper.realIndex !== undefined) {
          props.updateSelectedItem(swiper.realIndex);
        }
      }
    }
  }
};

Nothing too crazy here but mainly need to see that I am setting "zoom" to true.  My slide structure is as follows:
<div
  key={image._id + key}
  className="slide-container"
  data-key={key}
  data-id={image._id}
  data-url={`${image.src}`}
>
  <div
    className="swiper-zoom-container"
  >
      <img
        alt="something"
        src={image.src}
        className="slide-image"
        style={{
          transform: "rotate(0) scale(1) translate3d(0px, 0px, 0px)"
        }}
      />
  </div>
</div>

I have a function built that will rotate my image 90 degrees to the right or the left depending on if you click rotate right or rotate left which works perfectly.  This function also changes the image to fit the screen as large as it can without breaking the images original aspect ratio.  Again works perfectly.  My issue is that when zoom is initiated the "transform" property is overwritten with the new scale property but none of the original transform properties (ie. rotate) are retained.
I am currently retaining the scale property when I am rotating the image, meaning once zoomed I can rotate all I want but when I zoom back out the image rotates back to its initial rotate state of 0.  Usability is there but user experience isn't good when an image is moving when that movement was not initiated by them.
Expected Behavior
The expectation is that when zoom is initiated/uninitiated that the image would retain all former transform properties minus the scale property.
Actual Behavior
All original transform properties are not retained thus rotating the image back to its initial rotation.

I guess you need wrap image with extra custom container or put it inside of zoom container. Because custom transforms can't be maintained


Formatting Issue after v4.11.0

I am using codepipeline  notification to get informed about the execution status.
The message aws returned is like this:

But in the slack channel , the message was transformed into this:

The detail resources are missing.
Looks like array field and object field is missing after formatting.

Is there any chance this gets fixed?

Probably this has been fixed in the latest release v4.17.0.
Please reopen if the problem still exists.


add a CI test that lib/analysis_options.yaml analyzes cleanly

We should add a CI test that lib/analysis_options.yaml analyzes cleanly.

Ah, this is already handled as-is.


XdsClient: add tests for resource types where AllResourcesRequiredInSotW() returns true

Also fixes some bugs discovered while adding the test:

We were not setting the state in the cache entry to DOES_NOT_EXIST, so a subsequently started watcher was not getting the proper notification.
If the server sent an empty update because all of the subscribed resources have been removed, we failed to increment the resource version.

For context, this refers to the Listener and Cluster resource types, as described in https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol#grouping-resources-into-responses.

Please check if these fixes are also things that need to be backported

Please check if these fixes are also things that need to be backported

I suspect these fixes don't require back-ports in and of themselves, but the changes in #31446 almost certainly will, so we can do these at the same time.


Handle case where table-filter is not found

When there are no standard personas, the input[data-behavior=table-filter] element won't exist (see here). As a result, the following JS error is thrown:

TypeError: Cannot set properties of null (setting 'oninput')

This PR does an early return if that input is not found.
In addition to this bugfix, the following maintenance has been performed:

Bumped the version.
Switch to Cuprite. It's simpler to configure and would have caught this error with js_errors: true.
Removed Ruby 2.7 from the build matrix.
Removed Rails 6.0 from the build matrix.
Added Ruby 3.2 to the build matrix.
Fixed new Rubocop violations.

Looks like Rubocop is still running with TargetRubyVersion 2.7 and complaining.


What is "Error: unsupported content type: text/plain; charset=utf-8"?

What is the issue?
After changing to ollama version 0.2.1, when I run ollama create mymodel Modelfile, I get the following error message. the same error occurs when I change my model.
If anyone knows how to solve this problem, please let me know.
$ ollama create mymodel -f Modelfile
transferring model data
Error: unsupported content type: text/plain; charset=utf-8
OS
macOS
GPU
Apple
CPU
Apple
Ollama version
0.2.1

I faced same error and found that I downloaded the gguf pointer file not gguf file from huggingface by mistake, so that it come to this error.
After I download the right gguf file, the problem is solved.

Hey @k2rw, is it possible for you to provide a link to the file that you are using as well as your Modelfile so we can try and reproduce the issue? Thanks.

Hi @joshyan1,
Here a recipe extract to reproduce the issue.
cd $HOME
export RELEASE=0.3.3
echo Installing Ollama Release $RELEASE ...
curl -fsSL https://ollama.com/install.sh | sed "s#https://ollama.com/download#https://github.com/ollama/ollama/releases/download/v\$RELEASE#" | sh
# Get the Ollama source examples
git clone -b v$RELEASE https://github.com/ollama/ollama.git

# old method via llama.cpp
sudo tdnf install -y git-lfs git
git lfs install
cd $HOME/ollama/examples/langchain-python-rag-privategpt
git clone -b b2536 https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
pip3 install -r requirements.txt

# Use LLM: google-bert/bert-base-german-cased
export Model=bert-base-german-cased
export HuggingFacePath=https://huggingface.co/google-bert
git clone $HuggingFacePath/$Model
cp ./$Model/config.json ./$Model/config.json.1
sed "s/BertForMaskedLM/BertModel/" ./$Model/config.json.1 > ./$Model/config.json
rm ./$Model/config.json.1
python3 convert-hf-to-gguf.py ./$Model --outfile ./models/$Model.gguf --outtype f32
cd models
sudo cat <<EOF | sudo tee ./Modelfile
FROM ./bert-base-german-cased.gguf
EOF
ollama create bert-base-german-cased -f ./Modelfile
cd ..
cd ..

ollama create fails with the issue. The method is biased to the old llama.cpp b2536 release. In my case, bert-based-german-cased with the workaround does not work anymore.
Well, the main goal is make work embeddings models. Beside English and Chinese, especially European languages are not widespread in the meaning of fully functional embeddings models in Ollama. E.g. the goal in https://github.com/ollama/ollama/issues/3747 was to make work Dutch,
With a newer version e.g. b3505, a BPE pre-tokenization is necessary, see reference.
In https://github.com/ggerganov/llama.cpp/blob/master/convert_hf_to_gguf.py in the get_vocab_base_pre function, there are more than twenty embeddings models included, but not for bert-based-german-cased or Dutch, French, Spanish, Italian, etc.
If there is an easy fix for the utf-8 issue, that would help of course.

I had the same issue

you can check the file you use and see if it is just a link but not the real gguf

the same problem
`root@27d10c6f52c8:~/.ollama/TeleChat2-35B-Nov# more Modelfile
from config.json
from configuration.json
from configuration_telechat2.py
from generation_config.json
from generation_utils.py
from modeling_telechat2.py
from pytorch_model.bin.index.json
from pytorch_model_00001-of-00008.bin
from pytorch_model_00002-of-00008.bin
from pytorch_model_00003-of-00008.bin
from pytorch_model_00004-of-00008.bin
from pytorch_model_00005-of-00008.bin
from pytorch_model_00006-of-00008.bin
from pytorch_model_00007-of-00008.bin
from pytorch_model_00008-of-00008.bin
from tokenization_telechat2.py
from tokenizer.model
from tokenizer_config.json
root@27d10c6f52c8:~/.ollama/TeleChat2-35B-Nov# ollama create telechat -f Modelfile
transferring model data 100%
Error: unsupported content type: text/plain; charset=utf-8`


Use the built in tensorflow python tools in freeze_graph.sh

This is a way better way of calling freeze_graph and optimize_for_inference. 100% approved.
I'm going to use your PR also to fix a bug of the travis-ci pipeline (as you can see it fails, and the failure is not related to your changes as all)
Thank you for your contributions :+1:


Fix forgotten ::size_t for freebsd

Compiles and passes tests on FreeBSD again after this change.

Thanks!


How to break out of current stuck command

I get stuck in the middle of an operation and cannot figure out how to break out of it. The console becomes stuck and I cannot use this program at all
* hello
* LKJmweaaoruhewjroiwehjrrrrrrrrrrr
*
*
*
*
*
* werae
*
* when this happens.

It looks like this.
How can I break out and continue working? A semi-colon does not work.
I do not mean how do I quit the program.  I know how to do this.
This is the same question in another language: https://stackoverflow.com/questions/27591417/iex-how-to-cancel-multiline-command

You enter the multiline mode if you open a block or a C# statement and submit it into the REPL in the incomplete state.
The typical use case is to define a larger block of code e.g. a body of the method in multiple lines, as it's more convenient.
You exit by supplying the character that closes the given block.
For example if you opened the multiline mode by sending { to the REPL, you will close it by sending }. If you opened it by sending ( (for example an incomplete method call like  Foo() then you close it by sending ).
This is no different to closing a multi-line block in C# code in the IDE. If the block does not end correctly, the editor does not know what to do with it.

Ahh okay.
But there is no manual break as well?
Often I don’t know what the ending is so I can’t simply add it.

There is no explicit break at the moment.


[FEATURE REQ] Consider adding ExistsAsync to QueueClient

Library or service name.
Azure.Storage.Queues
Is your feature request related to a problem? Please describe.
I'm taking an existing code-base that used the v11 Storage SDK and moving it to use the newer V12 SDK.
The code in question has a long lived processing loop that is pulling from arbitrary containers.  At the start of the loop the the code calls .ExistsAsync from the v11 SDK on a CloudQueue (which for the v11 SDK would be a QueueClient), since if the queue does not exist it can early out of some work.  There are comments in the code mentioning that the Queue could be deleted between the existence check and when actual operations happen, so the code is written to keep that in mind, but even with this caveat, the check provides value.
Looking at the older V11 SDK, it seems like ExistsAsync() tried to fetch the metadata for a queue and if it could it decided the Queue exists.  So it's easy enough for me to add an extension method to the class to do this.  However, there does seem to be some custom logic in translating some responses (for example by my reading of the code if a response with the code PreconditionFailed failed is returned, the older v11 SDK would not throw an exception and instead return true), which means writing method to have the same semantics as the older SDK requires a little care.
It might be nice to add this method back, even though it is possible that by the time you observe the result of ExistsAsync() it is has changed because of some out of band operation.

Thanks for your suggestions! We actually already have an duplicate issue opened for this, so please follow that issue instead of any updates when that change gets added and merged.
https://github.com/Azure/azure-sdk-for-net/issues/7879


Adds the TypeScript transformer

The TypeScript transformer is designed to remove or transform most TypeScript-specific syntax.
This transformer elides TypeScript-specific nodes such as:

Interfaces
Type Aliases
Type Annotations
Ambient Declarations
TypeScript-specific modifiers (e.g. abstract, public, private, etc.)
implements heritage clauses on classes
Type assertions
Type parameter lists
Type argument lists

In addition, it transforms TypeScript-specific syntax into compatible down-level syntax, including:

Decorators
Async Functions
Property Declarations
Parameter property initializers
Enums
Namespaces
Exported declarations inside of a Namespace.

Some TypeScript-specific syntax will remain, specifically import and export declarations that will be handled directly by a later module transformation.
Related Pull Requests:

#6892 - Adds the visitor API foundation for tree transformations.
#6983 - Adds the Transform Flags concept for tree transformations.
#6986 - Adds the transformFiles API for tree transformations.
#6987 - Adds a simplified pretty printer for tree transformations.
#7191 - Adds the TypeScript transformer.
#7192 - Adds the JSX transformer.
#7193 - Adds the ES7 transformer.
#7194 - Adds the ES6 transformer.

Review status: 0 of 12 files reviewed at latest revision, 9 unresolved discussions, some commit checks failed.

src/compiler/transformers/destructuring.ts, line 23 [r1] (raw file):
"highlight" is vague, I can't tell if this is for a future correspondence between transformations or sourcemaps or something else

src/compiler/transformers/destructuring.ts, line 28 [r1] (raw file):
This gets a little hard to read. Please use complete sentences.

src/compiler/transformers/destructuring.ts, line 40 [r1] (raw file):
I don't see the definition of inlineExpressions.

src/compiler/transformers/destructuring.ts, line 231 [r1] (raw file):
Cache length, use below

src/compiler/transformers/destructuring.ts, line 267 [r1] (raw file):
You already have numElements above

src/compiler/transformers/destructuring.ts, line 279 [r1] (raw file):
numElements

src/compiler/transformers/destructuring.ts, line 300 [r1] (raw file):
These are getting somewhat difficult to reason about. The variable is named object, but that's vague enough that I though this was an object literal or binding pattern for whatever reason.

src/compiler/sourcemap.ts, line 70 [r1] (raw file):
I don't know what this is, leave a hefty comment on what it is and why I need it.

src/compiler/transformer.ts, line 29 [r1] (raw file):
Should we conditionally transform modules? Or is it better to unconditionally transform just in case?

Comments from the review on Reviewable.io

Review status: 0 of 12 files reviewed at latest revision, 10 unresolved discussions, some commit checks failed.

src/compiler/transformers/ts.ts, line 210 [r4] (raw file):
Just write "they will be emitted as part of `transformClassDeclaration`"
If these constructs are taken care of by transformClassDeclaration, shouldn't these branches be unreachable?

Comments from the review on Reviewable.io

Review status: 0 of 12 files reviewed at latest revision, 10 unresolved discussions.

src/compiler/transformers/destructuring.ts, line 23 [r1] (raw file):
This comment originally came from emitter.ts. I will update it.

src/compiler/transformers/destructuring.ts, line 28 [r1] (raw file):
This comment originally came from emitter.ts. I will update it.

src/compiler/transformers/destructuring.ts, line 40 [r1] (raw file):
inlineExpressions is in factory.ts

src/compiler/transformers/ts.ts, line 210 [r4] (raw file):
The members of the class are visited in transformClassDeclaration, which includes the constructor. This indicates that the constructor should be elided.

src/compiler/transformer.ts, line 29 [r1] (raw file):
We always need to run some module transform, even if the transform itself does nothing. This is due to the fact that we fall back to CommonJS if the module kind is unspecified (except when our target is ES6).

Comments from the review on Reviewable.io

Review status: 0 of 13 files reviewed at latest revision, 10 unresolved discussions.

src/compiler/sourcemap.ts, line 70 [r1] (raw file):
Done.

src/compiler/transformer.ts, line 29 [r1] (raw file):
Done.

src/compiler/transformers/destructuring.ts, line 23 [r1] (raw file):
Done.

src/compiler/transformers/destructuring.ts, line 28 [r1] (raw file):
Done.

src/compiler/transformers/destructuring.ts, line 231 [r1] (raw file):
Done.

src/compiler/transformers/destructuring.ts, line 267 [r1] (raw file):
Done.

src/compiler/transformers/destructuring.ts, line 279 [r1] (raw file):
Done.

src/compiler/transformers/destructuring.ts, line 300 [r1] (raw file):
Done.

src/compiler/transformers/ts.ts, line 210 [r4] (raw file):
Done.

Comments from the review on Reviewable.io


SPA template doesn't work

Can you post a step by step tutorial on how to setup and use Neutronium. The docs leave a lot to be desired and I can't even get the spa template working. There's too many deprecated dependencies

Did you use the Visual studio templates? If not what project did you use?

I tried using the Neutronium.Vue.Spa1 template

I actually can't get either Vue template to work. It could definitely be me, I'm new to C# development but I'm super excited about this project.
The SPA template gives me the following error:

And the Vue Application template gives me this error:

I didn't try the other template because I was mainly interested in the project with a Vue front end.

I can not reproduce. Make sure that you downloaded and install the template correctly. After project creation you have to restore the nuget to dowload the missing packages and the rebuild.

Here a link to instruction:
https://github.com/NeutroniumCore/Neutronium/blob/master/Documentation/Content/SetUp.md

@avianate  Also what is " too many deprecated dependencies"?

You do not have to update nugget dependencies to use the project. See https://github.com/NeutroniumCore/Neutronium.SPA.Demo/issues/2

@David-Desmaisons thanks for the response. The templates were installed correctly, but I had to install the "Data Sources for SQL Server support" component in order to get past the error with the SPA project. It's building now though, so now I can test it out!

Spoke too soon. After running the Nuget Restore, I still get the 2nd error I posted above.

There is no dependency beetween  Neutronium and SQL so the error is very likely linked to your environment and not to the template. What is the VS version you are using? Waht are the reproduction steps?

Any feedback on this @shawndrake2 ?

@David-Desmaisons I was able to get it up and running locally, but to do so I had to run a nuget restore first and then upgrade the packages through the nuget management for the solution. I didn't dig in deep enough to see which specific package(s) were causing the issue for me, though.

@shawndrake2 Thanks for the feedback. I am closing this for now. Please feel free to reopen if/when you have a reproducable scenario.


CC0008: Don't suggest for dynamic objects

Bug
CC0008 currently suggests to use object initializer, even for dynamic objects.
dynamic email = new Email();
email.From =<EMAIL_ADDRESS>email.To =<EMAIL_ADDRESS>
Current output after fix applied (if it is a code fix bug):
dynamic email = new Email()
{
    From =<EMAIL_ADDRESS>    To =<EMAIL_ADDRESS>}

Since this is a dynamic object, From and To might not be properties of the Email class and can therefore not be initialized with the object initializer syntax.

@pascalberger If From and To are not properties of the Email class the code will fail in the same way, will it not? The only difference is that the invocation is happening via dynamic dispatch in the first case, so CodeCracker will actually help you find an error.
The only scenario I can see this being a problem is with an ExpandoObject, or an object with similar patterns. So, in this scenario, this would raise an error where previously there was none, in a correct code. So, yes, this is a bug.

Closed in #860.


Alternative Redis client proposed for inclusion in Boost

Sorry for opening an issue for this, I did not find any better means of contacting you.
I would like to invite your community to write a review for an alternative Redis client library that is being proposed for inclusion in boost. As the author of a redis client yourself your opinion would be highly valuable. For more information see https://lists.boost.org/Archives/boost/2023/01/253871.php.
Thanks

Hello.
The contacts are not hidden. If you take a look through any header or source file of the library, you'll notice my email there. Furthermore, the email below my photo in profile (in a bit vague form, in order to avoid robot's email grabbing). I have familiarized myself with the review steps and rules. Email me via<EMAIL_ADDRESS>with a short list I could do for the review and I'll.
Regards.


Labels of 2 x-secreting cell types

Minor notes:
Should CL:0007021 'alarm substance cell' (subclass of ‘secretory cell’) be renamed 'alarm substance secreting cell' for consistency with its x-secreting siblings in the same branch? ’alarm substance cell' could stay as a synonym.
Update: 'alarm substance cell' is what's used in lit, so leave it as is but

[ ] add exact synonym 'alarm substance secreting cell'

Should CL:0000315 'tears secreting cell' be renamed 'tear secreting cell' for consistency with the use of singular rather than plural? 'tears secreting cell' could stay as a synonym.
Update: none of the two labels seems used as such, so yes go ahead and

[ ] rename as 'tear secreting cell'
[ ] add exact synonym 'tears secreting cell'

Hi @paolaroncaglia, I noticed the definition for CL:0007021 'alarm substance cell' has the title of the reference in brackets at the end even though the ISBN is included in the annotation.
Is the title in the definition redundant and should it be removed from the definition string?


After parsing, objects is undefined?

If parsing fails, will project.hash.objects be undefined? Has anyone had any experience with project.hash.objects being undefined? This is a react native project.
const project = pbxProject('ios/MyApp.xcodeproj/project.pbxproj').parseSync();

console.log({
  project,  // ok
  hash: project.hash,  // ok
  objects: project.hash.objects  // undefined
})

My bad, I diagnosed this issue wrongly. No issue here.


FMU/Camera trigger: initialize all FMU pins from FMU

@LorenzMeier I'm not sure if this is a good fix. The reason for it not currently working is that up_pwm_servo_init de-initializes everything first, so fmu was overriding the init from camera_trigger. We still need to modify the startup sequence so camera trigger comes after FMU to make the initial values work that it sets.
Potentially resolves #6092

Works for camera_trigger test after arming using the following params
nsh> param show TRIG*
Symbols: x = used, + = saved, * = unsaved
x   TRIG_INTERFACE [15,15] : 2
x   TRIG_INTERVAL [16,16] : 40.0000
    TRIG_POLARITY [-1,17] : 0
x + TRIG_ACT_TIME [17,18] : 2000.0000
x + TRIG_MODE [18,19] : 1
x + TRIG_PINS [19,20] : 56
x   TRIG_DISTANCE [20,21] : 25.0000

Also, this also works if FMU is started, which isn't always the case. Maybe we should init all pins also in camera trigger regardless.

@davids5 I'm not sure this is the right fix. Maybe you can come up with one that is less invasive and fixes the root cause, rather, than configuring everything on boot.

@AndreasAntener @LorenzMeier
I think there is a fundamental problem that we have code in the tree outside of drivers/stm32  that is accessing HW on STM32 directly.  This in general needs to be solved for portability but spcifiacly for this issue the driver should use the capture interface [here] (https://github.com/PX4/Firmware/blob/master/src/drivers/drv_input_capture.h)

@davids5 Understood your general argument. Therefore the access from FMU would also needed to change?
As for the capture interface: I might be missing something here but we're not capturing input in this case, only setting specific signals.
Looking at the hierarchy from the application point of view (camera_trigger) I guess the better approach would be to do IOCTL to FMU?

Looking at the hierarchy from the application point of view (camera_trigger) I guess the better approach would be to do IOCTL to FMU?

But that still requires FMU to initialize all pins.

Potentially related/duplicate : https://github.com/PX4/Firmware/issues/4941
Regarding IOCTLs, I would like to evaluate the performance impact (if any) on the high-resolution GPIO triggering if we go down that path.

@AndreasAntener - I feel I do not have good enough context on all the issues. Unfortunately,  I will be out until the 5th of Jan - can we have a chat after that to work through this?

@davids5 Sure we can do that, best is if Lorenz joins as I'm not overly familiar with the stm driver layer. @mhkabir noted.

Closing. This is fixed properly in https://github.com/PX4/Firmware/pull/6973.


Bluetooth: host: Enable CONFIG_BT_SETTINGS_CCC_STORE_ON_WRITE

Storing CCC right after it's written reduces risk of inconsistency of CCC values between bonded peers. The option should be enabled by default. The developer could explicitly disable it to reduce memory usage. After disabling the option explicitly, the developer is aware of related potential issues.
Fixes: #40758

Hi @alwa-nordic
Release changes were updated. Is there anything else needed or you can approve it ?


CurrentPage not updated when calling setCurrentPage

When calling setCurrentPage with a specific page number, the internal variable currentPage in CollectionViewPagingLayout is not updated.
This causes a possibly far to large step, even in the wrong direction when goToNextPage or goToPreviousPage is called.

Hi Matthias, Thanks for reporting the issue,
I made a pull request for this, could you check and confirm it's fixed?
thanks


Building fails with "Source forest creation failed" because "File exists"

Steps to reproduce with CLion 2017.1.3 and the Bazel plugin Version: 2<IP_ADDRESS>.1:

git clone https://github.com/danieldanciu/clion-bazel.git
import the bazel project, build it two times, notice ERROR: Source forest creation failed: /private/var/tmp/_bazel_ab/fc7ea4530f9bdd4f1119eb797c96880e/execroot/__main__/bazel-clion-bazel (File exists).

Syncing project...
Updating VCS...
Running Bazel info...
Command: /usr/local/bin/bazel info --tool_tag=ijwb:CLion --curses=no --color=no --noexperimental_ui --noprogress_in_terminal_title --

Command: git diff --name-status --no-renames 05ea74a8f7be2ee3e1271f0019f30ee1a705f629

____Loading package: @local_config_xcode//
Computing VCS working set...
  bazel-bin (added)
  bazel-clion-bazel (added)
  bazel-genfiles (added)
  bazel-out (added)
  bazel-testlogs (added)

Sync targets from project view:
  //...:all

Sync targets from working set:
  //:all
  //bazel-clion-bazel:all

Building IDE info files...
Command: /usr/local/bin/bazel build --tool_tag=ijwb:CLion --keep_going --experimental_build_event_binary_file=/var/folders/yd/nc6_vq355v352hm7_q86gfmw0000gn/T/intellij-bep-63b42403-b37b-4573-aced-3ebf948a0395 --noexperimental_build_event_binary_file_path_conversion --curses=no --color=no --noexperimental_ui --noprogress_in_terminal_title --aspects=@intellij_aspect//:intellij_info.bzl%intellij_info_aspect --override_repository=intellij_aspect=/Users/ab/Library/Application Support/CLion2017.1/clwb/aspect --output_groups=intellij-info-cpp,intellij-info-generic -- //...:all //:all //bazel-clion-bazel:all

____Loading package: bazel-clion-bazel
____Loading complete.  Analyzing...
____Loading package: @intellij_aspect//
____Loading package: @bazel_tools//third_party/java/jdk/langtools
____Found 2 targets...
____Building...
____Building complete.
____Elapsed time: 21.309s, Critical Path: 0.03s
____Waiting for build event protocol upload: 0s____Waiting for build event protocol upload: 0s
Total rules: 4, new/changed: 4, removed: 0
Reading IDE info result...
Loaded 4 aspect files, total size 3kB
Building IDE resolve files...
Command: /usr/local/bin/bazel build --tool_tag=ijwb:CLion --keep_going --experimental_build_event_binary_file=/var/folders/yd/nc6_vq355v352hm7_q86gfmw0000gn/T/intellij-bep-b73e5c10-4090-4c3d-8398-63de80f356ee --noexperimental_build_event_binary_file_path_conversion --curses=no --color=no --noexperimental_ui --noprogress_in_terminal_title --aspects=@intellij_aspect//:intellij_info.bzl%intellij_info_aspect --override_repository=intellij_aspect=/Users/ab/Library/Application Support/CLion2017.1/clwb/aspect --output_groups=intellij-resolve-cpp -- //...:all //:all //bazel-clion-bazel:all

____Loading package: @local_config_xcode//
____Loading complete.  Analyzing...
____Found 2 targets...
ERROR: Source forest creation failed: /private/var/tmp/_bazel_ab/fc7ea4530f9bdd4f1119eb797c96880e/execroot/__main__/bazel-clion-bazel (File exists).
____Elapsed time: 20.584s
____Waiting for build event protocol upload: 0s
Sync failed

This error is coming from Bazel. Which version of Bazel are you using?
Do you see the same error running that same bazel invocation from the command line? (how about if you remove the duplicate build targets, and just use '//...:all'?)

In the command line, it succeeds if //bazel-clion-bazel:all is left out.
I was using Bazel  0.5.4-homebrew. I upgraded to 0.6.0 and now I hit #136.

I get this problem with Bazel 0.6.0-homebrew also:
CLion 2017.1.3, Bazel 0.6.0-homebrew, plugin built from 015973d885a258d9b3921e5c06572bb4e1b30045 like this:
$ bazel build clwb:clwb_bazel_zip --define=ij_product=clion-latest

I run bazel clean, then press Sync, it succeeds, press Sync a second time, it fails:
Building IDE info files...
Command: /usr/local/bin/bazel build --tool_tag=ijwb:CLion --keep_going --experimental_build_event_binary_file=/var/folders/yd/nc6_vq355v352hm7_q86gfmw0000gn/T/intellij-bep-adf11386-12d1-4b9a-821f-0bb055d4bdb1 --noexperimental_build_event_binary_file_path_conversion --curses=no --color=no --noexperimental_ui --noprogress_in_terminal_title --aspects=@intellij_aspect//:intellij_info.bzl%intellij_info_aspect --override_repository=intellij_aspect=/Users/ab/Library/Application Support/CLion2017.1/clwb/aspect --output_groups=intellij-info-cpp,intellij-info-generic -- //...:all //:all //bazel-clion-bazel:all

____Loading package: bazel-clion-bazel
____Loading complete.  Analyzing...
____Found 2 targets...
____Building...
____Elapsed time: 25.549s, Critical Path: 0.01s
Total rules: 5, new/changed: 1, removed: 0
Reading IDE info result...
Loaded 1 aspect files, total size 1kB

Building IDE resolve files...
Command: /usr/local/bin/bazel build --tool_tag=ijwb:CLion --keep_going --experimental_build_event_binary_file=/var/folders/yd/nc6_vq355v352hm7_q86gfmw0000gn/T/intellij-bep-500cb595-2586-4516-b831-4745696a87e9 --noexperimental_build_event_binary_file_path_conversion --curses=no --color=no --noexperimental_ui --noprogress_in_terminal_title --aspects=@intellij_aspect//:intellij_info.bzl%intellij_info_aspect --override_repository=intellij_aspect=/Users/ab/Library/Application Support/CLion2017.1/clwb/aspect --output_groups=intellij-resolve-cpp -- //...:all //:all //bazel-clion-bazel:all

____Loading package: @local_config_xcode//
____Loading complete.  Analyzing...
____Found 2 targets...
ERROR: Source forest creation failed: /private/var/tmp/_bazel_ab/fc7ea4530f9bdd4f1119eb797c96880e/execroot/__main__/bazel-clion-bazel (File exists).
____Elapsed time: 25.316s
Sync failed

Closing this one as a duplicate of #136 -- though please open a Bazel-side issue if you think the error is spurious.

Filed https://github.com/bazelbuild/bazel/issues/3857


operator: Move CRD registration to operator

Brief description
This PR is the final piece to move the CRD registration responsibilities to cilium-operator. In the case of new CRDs, an upcoming PR will install the CRDs via Helm. In the case of upgrades, cilium-operator will handle the upgrades if Helm does not upgrade them. This will ensure that we are always running the most up-to-date CRDs.
See commit msgs.
Updates: https://github.com/cilium/cilium/issues/12737
Cilium Operator will now handle CRD operations on behalf of Cilium Agent

test-me-please

test-me-please

test-me-please

test-me-please

test-me-please

test-me-please

test-gke

test-me-please


proxy.autoconfig and security.OCSP.require (1212)

Description
PAC scripts does not work (Firefox does not use it at all) when security.OCSP.require (1212) is set to true.
After I'd got it with the real PAC script, I used a pretty simple one to test with:
function FindProxyForURL(url, host) {
    return "SOCKS5 <IP_ADDRESS>:9050";
}

Steps to reproduce:

Set security.OCSP.require to true
Add a valid URL containing code above to Preferences->Network Settings->Automatic proxy configuration URL (I've used valid public domain with HTTPS)
Start some Socks5 on localhost:9050 (e.g. tor daemon)
Try to load some show-my-ip page, you should see your real IP
Set security.OCSP.require to false
Click reload at Preferences->Network Settings->Automatic proxy configuration URL
Reload show-my-ip page, you should see your proxy exit IP (e.g. Tor exit node address)

Tested with:
GNU/Linux, amd64:

Firefox 64, Arch and Fedora builds
IceCat 60 (based on FF 60 ESR)
Firefox 57
Waterfox 56 (FF 56 fork)
including default profiles with empty user.js

According to #295 OCSP preference to hard-fail may cause some more proxy-related issues, so it may save plenty of time, if related to security.OCSP.require comments will contain some kind of related [WARNING] or [BREAKAGE] tag ( #545).
Also I'm not sure it this issue is worth reporting to Mozilla.

closing this with no changes (can revisit it in #605 for adding a breakage tag if needed) - the hard fail is just doing it's job: AFA-we-CT, it could be a FF bug if anyone wants to poke the beer :beer:  .. opps i meant poke the BEAR :bear: .... also (IANAExpert) it is unusual to load a PAC over like that (over https?)
Thanks @dvalter for the edge case :kiss:


Add feature for limiting number of characters in a textmessage

It would be very helpful to have an option to limit the maximum number of characters in a message.
If I was to implement it today I'd need access to the UITextViewDelegate in JSQMessagesComposerTextView, which is buried very deep into the structure of the component.
It would be nice to be able to set this value in a high level component.

Thanks @emmanuelay !
JSQMessagesViewController publicly declares conformance to UITextViewDelegate. You should be able to override any of these methods in your view controller. 😄


BetterDexRewards Mod Loading Error

Minecraft Crash Report - BetterDexRewards Mod Loading Error
Minecraft Version: 1.16.5
Forge Version: 36.2.34
Mod Name: BetterDexRewards
Mod Version: 3.2.4
Java Version: 1.8.0_51, Oracle Corporation
Pixelmon Version: 9.1.11
Description:
A mod loading error has occurred due to an unsupported class version in the BetterDexRewards mod.
Error Details:
java.lang.UnsupportedClassVersionError: com/envyful/better/dex/rewards/shade/envy/api/gui/factory/PlatformGuiFactory has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

You need to update to Java 11


Draft of Version 1.0

Changes so far

Removed deprecated code
Removed most of the code for Python 2 compatibility.

Codecov Report

Merging #925 (8d082b5) into master (44a20c8) will increase coverage by 0.38%.
 Consider uploading reports for the commit d54f685 to get more accurate results

@@            Coverage Diff             @@
##           master     #925      +/-   ##
==========================================
+ Coverage   86.82%   87.21%   +0.38%
==========================================
  Files          50       49       -1
  Lines        6711     6626      -85
==========================================
- Hits         5827     5779      -48
+ Misses        884      847      -37

Flag
Coverage Δ

unittests
87.21% <85.29%> (+0.38%)
:arrow_up:

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

Impacted Files
Coverage Δ

lark/common.py
100.00% <ø> (+6.45%)
:arrow_up:

lark/parsers/lalr_interactive_parser.py
77.77% <ø> (-0.69%)
:arrow_down:

lark/tree.py
63.63% <ø> (+0.92%)
:arrow_up:

lark/visitors.py
88.64% <ø> (-0.06%)
:arrow_down:

setup.py
0.00% <ø> (ø)

lark/utils.py
84.15% <28.57%> (+2.41%)
:arrow_up:

lark/__init__.py
100.00% <100.00%> (ø)

lark/exceptions.py
87.02% <100.00%> (+1.09%)
:arrow_up:

lark/lark.py
83.58% <100.00%> (+1.79%)
:arrow_up:

lark/lexer.py
91.71% <100.00%> (-0.08%)
:arrow_down:

... and 4 more

Continue to review full report at Codecov.

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

Tasks remaining:

Merge .pyi files into the code, and remove them.
Update the interface to be more self-consistent (ideas?)
Improve the code with Python3 features, where possible (optional/low priority)
Anything else?

About the type-merging, you can possibly use https://github.com/ilevkivskyi/com2ann to merge type comments to type annotations

@ThatXliner We are not using Type comments. We have separate stub files.

@ThatXliner We are not using Type comments. We have separate stub files.

Oh right. My bad.
I found https://github.com/ambv/retype but it wasn't what I remembered. Hope it helps, though

Anything else?

Remove
[bdist_wheel]
universal = 1

from setup.cfg.  It's intended for wheels that support both Python 2 and 3.

Here is a list of compatibility/deprecated code I have come across in case you want to remove some of it.

visitors.py:81: __visit_tokens__ backwards compatibility
lark.py:306: Python 2.7 compatibility
lark.py:371: Old resolve__antiscore_sum check
lark.py:403: Possible deprecation of lexer callbacks
exceptions.py:92: Default value of use_accepts is for backwards compatibility
exceptions.py:233: Possible deprecation of UnexpectedToken.expected
load_grammar.py:819: Python 2.7 code?
load_grammar.py:1070: Python 2.7 compatibility
utils.py:127: Issue with wraps in 2.7

Fixes some of the items @chanicpanic mentioned in this PR - https://github.com/lark-parser/lark/pull/993
Regarding

__visit_tokens__ - To be honest I'm not sure why it bothered us. I think it can stay the way it is.

deprecation of lexer callbacks - I used to think that maybe the transformer parameter should be enough, since we added support for tokens. But it's still useful for going over ignored tokens, so unless we let transformer run on ignored tokens too, I think we should leave it.

UnexpectedToken.expected - Maybe it's still worth keeping? I have no strong opinion atm

Btw, @chanicpanic & @MegaIng,
I think we should just merge this, and continue work over the master branch. Any objections?

That would mean that we are not going to release any other version before 1.0, not even a 0.12.1 release. But that would be fine with me.

We can always continue working on a 0.12 branch. But I'm not sure that we need to.

Fair enough. Merge is good IMO.

Or do we also want to rename to main in the process?

Seems pointless to me

Seems pointless to me

Fair enough. I dont have a strong opinion either, but this would be a prime opportunity.

No objections to merging from me.

Alright. I'll do it tomorrow then.

Lark master is now officially Python 3 only!


Implement JsonCursor using the new Cursor API

Adds methods to CursorAdapter to allow StackCursors to be templated over any type instead of just NodeData
Implement the previous JsonCursor as a factory function that creates a StackCursor using a custom adapter
Moves old JsonCursor code and its tests into legacy files

Note: jsonCursorLegacy.ts is unchanged from the previous jsonCursor.ts (same with the corresponding test files)

How does this extra indirection impact performance? Specifically whats the before and after for the "sum" benchmarks (they request values on all the nodes).

How does this extra indirection impact performance? Specifically whats the before and after for the "sum" benchmarks (they request values on all the nodes).

Ah right, I forgot to mention that. The benchmarks are all generally about the same with a few being a little faster using StackCursor, including the "sum" benchmarks for the few runs I tried.


python3Packages.hikvision: init at 2.0.4

Motivation for this change
Python module for interacting with Hikvision IP Cameras
https://github.com/fbradyirl/hikvision
This is a Home Assistant dependency.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 128653 run on x86_64-linux 1

2 packages built:

python38Packages.hikvision
python39Packages.hikvision


[auth-swift] Prep for keychain dependency injection (pt. 1)

#no-changelog

Fixing CI...

I'll rebase later this week to address the check issues.
the other tests should pass though.


Add index_select_along_batch/seq for nested data

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (c91fa21) 100.00% compared to head (0a2ab35) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #20   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           15        17    +2
  Lines          179       193   +14
  Branches        13        13
=========================================
+ Hits           179       193   +14

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[10.x] Added command to generate globally unique app-id

I found that writing prefixes depends on app_name, which may cause data confusion, such as cache prefixes. If the user does not change app_name, then multiple programs may use the same prefix.
So it is recommended to use app_id where unique is required.

All this does is adding an app-id:generate command that will put a string into the .env, right? Why not use this command in your own project? I mean it doesn't change anything about how laravel works, developers would still need to use that new APP_ID environment variable or the app.app_id config value.
As for the cache naming you can overwrite the prefix in your .env:
CACHE_PREFIX=my_unique_cache_prefix


create_and_add_item() only creates and adds the first prototype in the protoset

The title says it all basically. I assume the protoset is working correctly, since whenever i add items in the inspector it works just fine and i can also get any property of any item with get_property(). I'm probably doing something wrong, i just can't figure out what it is.

Yup, there was a bug. Luckily it was an easy fix.
create_and_add_item() should be working properly now.

Thanks!

Quick question if i may: how do i make the item icon bigger?


Fix - Default deadlines for grpc clients

Description
This PR adds deadlines to all non-streaming calls by implementing ClientInterceptors that are available in grpc. This allows us to set global defaults per service instead of having to require grpcDeadline everywhere.
Things to note:

we cannot use grpc-caller to create a grpc client, instead we now use the caller.wrap static method to be able to promisfy all of our grpc calls

all streaming calls failed when using grpc-caller to create a grpc client

Duplication between broker-cli/broker-daemon was on purpose to keep them as separate as possible
This PR is actually introducing the usage of grpcDeadline (we previously had no cases that it was being used other than healthcheck)

Related PRs
List related PRs if applicable
Todos

[ ] Tests
[ ] Documentation
[ ] Link to Trello

 Add deadline to all grpc commands in cli

@treygriffith RE: duplication. I felt the same way. Im not sure when we'll get to the split. The only file we have shared between the broker-cli and daemon is the CLI validations, everything else has been split


Export graphml, ignores types even if set to useTypes: true in config

 Issue by stefan-sev
Monday Aug 21, 2017 at 12:36 GMT
Originally opened as https://github.com/neo4j-contrib/neo4j-apoc-procedures/issues/556

Given scenario:
'Create (:Test{limit:<PHONE_NUMBER>000}), (:Test{limit: 2})'
Returns 2 nodes with the same label and the same properties, but once it is saved as int and the other time it is saved as long.
Now if I will create a dump in graphml with Types, there will be no key for limit and so for no types at all.
Here are to Code fragments causing this:
First it will set the type of limit to Long and on the second cycle it compares Long with int and sets the type to void.
https://github.com/neo4j-contrib/neo4j-apoc-procedures/blob/337b2e12401c0df95e44db0922946d9f5c643115/src/main/java/apoc/export/util/MetaInformation.java#L36-L47
Type void will be ignored.
https://github.com/neo4j-contrib/neo4j-apoc-procedures/blob/337b2e12401c0df95e44db0922946d9f5c643115/src/main/java/apoc/export/util/MetaInformation.java#L52
Possible solutions:

Aggregate types of key to the biggest type. In this example Long

Problem: What if there are two different Nodes, one node sets limit to String, the other node sets limit to Long. What type should be chosen?

Additional attribute type on data level instead of key block

Every data element defines the type separately, but this could be redundant information.

 Comment by StephanHasler
Friday Jan 11, 2019 at 17:14 GMT

I observed this bug too.
Whenever attributes with the same name are not all of the same type, no key entry is generated for this attribute name during graphml export.
One solution might be to have a separate key id for all combinations of attr.name and attr.type.

 Comment by conker84
Thursday May 13, 2021 at 08:06 GMT

fixed as highlited in #840

 Comment by conker84
Thursday May 13, 2021 at 08:11 GMT

looking better it may be worth of a double check

cf. https://github.com/neo4j/apoc/issues/35#issuecomment-2483397148

This behavior is due to a restriction of GraphML. GraphML assumes that all node or relationship properties with the same property name have property value of the same type. Neo4j allows mixed types per property name. If a property name has value of mixed value types, then its value are exported as a STRING.
If a node property name is associated with property value of different types, e.g. as in (:LabelA {prop: 123}), (:LabelB {prop: 'abc'}) or as in the example above, then no property type information is written to the graphml output for that node property name. The same holds for relationship properties.


Gclust fix

Reference Issues/PRs
Fixes and closes #201
What does this implement/fix? Explain your changes.

Fix n_component_ calculation
Add covariance_type_ attribute to denote the best covariance type
Change tests to check n_components rather than calculating this in the tests using bic_

Codecov Report

Merging #202 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #202      +/-   ##
==========================================
+ Coverage   86.03%   86.07%   +0.03%
==========================================
  Files          30       30
  Lines        1840     1838       -2
==========================================
- Hits         1583     1582       -1
+ Misses        257      256       -1

Impacted Files
Coverage Δ

graspy/cluster/gclust.py
93.25% <100%> (+0.95%)
:arrow_up:

Continue to review full report at Codecov.

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

Id like this merged ASAP


Support no application in Gitops

What does this PR do?:

Adds in the condition to only include deployment, svc and patches only if the software template supports an application
Which issue(s) this PR fixes:

https://issues.redhat.com/browse/RHDHPAI-84
PR acceptance criteria:
Testing and documentation do not need to be complete in order for this PR to be approved. We just need to ensure tracking issues are opened and linked to this PR, if they are not in the PR scope due to various constraints.

[x] Tested and Verified

[ ] Documentation (READMEs, Product Docs, Blogs, Education Modules, etc.)

How to test changes / Special notes to the reviewer:

In general it looks good to me. One question I have is about the RHOAI case. Do we still include this option when we want to use mode-only templates?

@thepetk no, we will not have RHOAI when using the model only template

In general it looks good to me. One question I have is about the RHOAI case. Do we still include this option when we want to use mode-only templates?

@thepetk no, we will not have RHOAI when using the model only template

Yeah I was guessing this should be it. So, do you think we should add an "and" condition when we re importing the rhoai directory (here). I'm on the fence if it's redudant or the supportApp automatically means that we don't support RHOAI. WDYT?

In general it looks good to me. One question I have is about the RHOAI case. Do we still include this option when we want to use mode-only templates?

@thepetk no, we will not have RHOAI when using the model only template

Yeah I was guessing this should be it. So, do you think we should add an "and" condition when we re importing the rhoai directory (here). I'm on the fence if it's redudant or the supportApp automatically means that we don't support RHOAI. WDYT?

@thepetk We don't need the condition. Thanks for the idea however, I have updated my Templates PR a bit and this is now gated by a SUPPORT_APP flag (Previously I had two flags, one for app support and one for RHOAI but you are right, RHOAI is only supported for apps right now) https://github.com/redhat-ai-dev/ai-lab-template/pull/59/files#diff-93f04871150a5282f08197ca6fb62209045c4db3f3c3a4b6a8b8abd09a8c4601R398-R401
and this is the Gitops Kustomize, there is no rhoai reference https://github.com/redhat-appstudio-mjf/modelserver-dec17-1-gitops/blob/main/components/modelserver-dec17-1/base/kustomization.yaml

In general it looks good to me. One question I have is about the RHOAI case. Do we still include this option when we want to use mode-only templates?

@thepetk no, we will not have RHOAI when using the model only template

Yeah I was guessing this should be it. So, do you think we should add an "and" condition when we re importing the rhoai directory (here). I'm on the fence if it's redudant or the supportApp automatically means that we don't support RHOAI. WDYT?

@thepetk We don't need the condition. Thanks for the idea however, I have updated my Templates PR a bit and this is now gated by a SUPPORT_APP flag (Previously I had two flags, one for app support and one for RHOAI but you are right, RHOAI is only supported for apps right now) https://github.com/redhat-ai-dev/ai-lab-template/pull/59/files#diff-93f04871150a5282f08197ca6fb62209045c4db3f3c3a4b6a8b8abd09a8c4601R398-R401
and this is the Gitops Kustomize, there is no rhoai reference https://github.com/redhat-appstudio-mjf/modelserver-dec17-1-gitops/blob/main/components/modelserver-dec17-1/base/kustomization.yaml

Makes sense. Thanks


[Bug-Candidate]:

Describe the issue:
When deploying to Polygon mainnet contract deploy fails due to low gas limit while it has been set to the max allowed value 15e6
{\"jsonrpc\":\"2.0\",\"id\":55,\"error\":{\"code\":-32000,\"message\":\"transaction underpriced\"}}","error":{"code":-32000},"requestBody":"{\"method\":\"eth_sendRawTransaction\"
The
Code example to reproduce the issue:
xdeploy: {
    contract: 'ERC1155Factory',
    salt: 'DeploySalt',
    signer: process.env.PRIVATE_KEY,
    networks: [
      'polygon'
  ],
    rpcUrls: [
      'https://polygon-mainnet.g.alchemy.com/v2/' + process.env.ALCHEMY_API_KEY
    ],
    gasLimit: 15_000_000 // optional; default value is `1.5e6`
  }

For Polygon average gaslimit reaches 30e6 so the hard limit of 15e6 might need to be updated
Version:
1.2.7
Relevant log output:
No response

@ahmadsghaier Thanks for opening this issue. I've been aware of this for many months and this is nothing I can solve on the xdeployer side. The main reason can be found here (it's not the gasLimit but the maxPriorityFeePerGas):

This is a known issue with BSC/Polygon, since they do not correctly implement the EIP-1559 standard.
Unfortunately for those networks, it is necessary to use a gas station (much like Ethereum did prior to EIP-1559). There isn't really a way to get good data (especially during times of congestion) from the blockchain directly.
My best advice would be that someone creates a sub-class of Signer, and overrides the getFeeData method to use a gas station instead. This is one reason why getFeeData is present there. :)
If someone creates a sub-class of Signer, let me know and I'll link to it from the docs. But I don't know there is much that ethers can do directly.

I would like to highlight that Polygon has an enforced minimum 30 gwei priority fee and ethers.js currently hardcodes the priority fee, where applicable, at 1.5 gwei. That's why deployments on Polygon are failing/pending forever.
I've discussed potential solutions in this discussion. Either you fork and adjust it as I describe there, or you can manually call yourself the contract using Polygonscan and MetaMask. I won't build a custom solution for one particular chain, because they can't get their job done properly. All other chains work smoothly. Closing this issue as no remediation is planned.


fix(apig-v1-adapter): lowercase headers

Description of change
Adding back the default behavior of emulating Node.js http by lowercasing all request headers. Large parts of JS ecosystem assume that these headers, particularly cookie header, can be accessed with the lowercase key.
This behavior was present in past versions of the ApiGatewayV1Adapter so please correct me if there is good reason that this was changed, but from my perspective it appears it may have just been missed. This past PR is an example, https://github.com/H4ad/serverless-adapter/pull/25.
Also, potentially related to #73
Pull-Request Checklist

[x] Code is up-to-date with the main branch
[x] npm run lint passes with this change
[x] npm run test passes with this change
[x] This pull request links relevant issues as Fixes #0000
[x] There are new or updated unit tests validating the change
[ ] Added documentation inside www/docs/main folder.
[ ] Included new files inside index.doc.ts.
[x] The new commits follow conventions outlined in the conventional commit spec

Did you had any issue with the headers not being flattered?
I changed to not lowercase because the headers are always lowercase when came from API Gateway V1, so for performance reasons, I just skipped the lowercase.

Thank you for looking!

Did you had any issue with the headers not being flattered?
We haven't had any issues with unflattened headers, was just attempting to reuse function that was already available to ensure the lowercasing. Happy to take a another pass to limit the operations to just casing in the interest of perf.

I changed to not lowercase because the headers are always lowercase when came from API Gateway V1, so for performance reasons, I just skipped the lowercase.
Very interesting! This has not been our observation. After updating from v2.17.0 to v4.2.1, we noticed our services were not receiving cookies anymore which ended up being due to the header now being the capitalized Cookie instead of just cookie. Downgrading serverless adapter resolved the issue.

Downgrading serverless adapter resolved the issue.

You can just copy the adapter that you modified to your own codebase and keep the newer version of the library.

which ended up being due to the header now being the capitalized Cookie instead of just cookie.

I'm fine with having back the behavior but this will require a breaking change release.
If you want to merge this PR and release as a feat, you can modify this PR and create a new flag option for this adapter called shouldLowercaseHeaders and make it default to false. In this way, you can mark it as true for your use-case and we can see if more people expect the header to be lowercase, what do you think?

Thanks @H4ad,
I've reworked the PR to involve an option to pass to the adapter constructor to avoid a breaking change.
Please let me know what you think.

Thanks again @H4ad,
Made two small tweaks. Please review

LGTM, thanks for the contribution!


Sync with https://github.com/practicalswift/swift-compiler-crashes

Add 342 compiler crashes.

Thanks!  I'll run tests on Linux and OS X and merge.

@practicalswift FWIW I think there are a bunch more test cases from swift-compiler-crashes that didn't get synced — I can't, for example, find this one: https://github.com/practicalswift/swift-compiler-crashes/blob/736d5c8bee75f676ff3750e4ad3165d81059fe03/crashes/26296-duplicate-subscript-declaration.swift

These tests don't crash on Linux and OS X, please move them to the directory for fixed crashers:
Failing Tests (4):
    Swift :: compiler_crashers/27818-swift-astvisitor.swift
    Swift :: compiler_crashers/28181-llvm-irbuilder.swift
    Swift :: compiler_crashers/28182-anonymous-namespace-favorcalloverloads.swift
    Swift :: compiler_crashers/28183-swift-typebase-isequal.swift

I know this isn't the best place to ask. How do you run the test ?

@stefanstefan2001 utils/build-script -RT.  More information in https://github.com/apple/swift/blob/master/docs/Testing.rst.

@gribozavr Thank you.

@gribozavr Let me know if any further adjustments are needed :-)

I think it's quite possible that my PRs #253, #266, and #272 will fix some of these, so might want to wait for them to be merged, then re-run the tests. (Or I could rebase, but I'd have to do it 3 times 😳)

Nice!  Thank you @practicalswift , you continue to be awesome!

@practicalswift One more thing: these two tests are actually valid programs, so they don't need not in their RUN line:
Failing Tests (2):
    Swift :: compiler_crashers_fixed/27818-swift-astvisitor.swift
    Swift :: compiler_crashers_fixed/28181-llvm-irbuilder.swift

@gribozavr Fixed! Sorry about this - still trying to grasp all aspects of the RUN annotations used in the project :-)

@radex Thanks for notifying! Your test case 26296-duplicate-subscript-declaration.swift is added as part of https://github.com/apple/swift/pull/294 :-)

:)


Failed to generate additional resources using 'generate': A JSON text must at least contain two octets!

Affected Puppet, Ruby, OS and module versions/distributions
PE 2016.1.2
mod 'iis',
  :git    => 'https://github.com/voxpupuli/puppet-iis.git',
  :commit => '35c41af1c6eb4d1f26009c184924e74f7660e482'

What are you seeing
Failed to generate additional resources using 'generate': A JSON text must at least contain two octets!
What behaviour did you expect instead
Resource purge without errors.
How did this behaviour get triggered
resources { 'iis_site':
  purge   => true,
}

Output log
Failed to generate additional resources using 'generate': A JSON text must at least contain two octets!
Any additional information you'd like to impart
This occurs when no sites are configured in IIS. A JSON error is returned because the underlying Powershell converted to JSON appears to return non-JSON string data. A catch should be put into all areas that are reading JSON from Powershell cmdlets using the JSON conversion method to check for improper results.
When I get time, I will attempt to send a PR on this issue myself.

Also occurs with:
IIS module from Github, skipping the Puppet Forge from now on for tighter control.
mod 'iis',
:git    => 'https://github.com/voxpupuli/puppet-iis.git',
:branch => 'release-3.0.0'

Is it possible to purge all iis_site's normally? Isn't there the default port 80 one, is that causing the issue?
If you want to PR to fix that would be awesomme 💃

Word of caution: release-3.0.0 is a just a release prep branch.

Yah I had found the same issue for a few days back as well.
https://github.com/voxpupuli/puppet-iis/issues/128

Yup just found this tonight. I always remove the default web site as soon as i install IIS. Its a security thing. no defaults means its  harder for someone to exploit the server.
Anyway, this used to work when i was using the forge version but i needed to resolve the issue with identitytype and now i have this one.... Guess ill have to create a new not so default site now... SIGH

There is a logic issue with it returning null sites which causes it to
fail. If you populate iis with one bogus sir it should work. Or disable the
default site.
On Sep 13, 2016 4:16 PM, "devoncustard"<EMAIL_ADDRESS>wrote:

Yup just found this tonight. I always remove the default web site as soon
as i install IIS. Its a security thing. no defaults means its harder for
someone to exploit the server.
Anyway, this used to work when i was using the forge version but i needed
to resolve the issue with identitytype and now i have this one.... Guess
ill have to create a new not so default site now... SIGH
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/voxpupuli/puppet-iis/issues/144#issuecomment-246809698,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAOu8VJg9UwhWMjRaf0aUvrTa5LlOaeks5qpwSugaJpZM4JCgVq
.

Hi. I'm going to close this Issue. We deprecated the module and the new version is available here: https://forge.puppet.com/puppetlabs/iis


changed nginx-rtmp fork and updated alpine to latest

Addresses #42 and #17 by changing compilation flags and utilizing a newer fork of the nginx-rtmp module.

Added an extra compilation flag for nginx for a successful compile

@reedog117 I tried your branch, but it seems that the hls endpoints are trying to use curl. I installed this from apk and then get a nice flood from curl on stdout:
nginx-rtmp_1  |   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
nginx-rtmp_1  |                                  Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
nginx-rtmp_1  | curl: (7) Failed to connect to localhost port 8080: Connection refused
nginx-rtmp_1  |   % Total    % Received % Xferd  Average Speed   Time    Time     Time2020/03/09 17:15:35 [notice] 1#1: signal 17 (SIGCHLD) received from 157
nginx-rtmp_1  |   Curren t2020/03/09 17:15:35 [notice] 1#1: unknown process 157 exited with code 7
nginx-rtmp_1  |
nginx-rtmp_1  | %   To t a l        %  Re ce i v ed   %   X fe r d    Av e r ag e   Sp e e d  D  lToiamed     U Tpilmoea d       TiTmoet a Clur r e nStp
nginx-rtmp_1  | e n t         L e f t    S p e e d
     0          0        0  D l  o a0d     U p0l o a d     0T o t a l    0  S p e n t  0  - - :L-e-f:t- -  Sp-e-e:d--
- - :0- - : - -  0       0 0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
     0           0        D0l o a d    0U  p l o0a d       0T  o t a l  0    S p e n t0   - - :L-e-f:t- -  -S-p:e-e-d:
- : -0- : - -    0      0
nginx-rtmp_1  | 0     0  c  0u r l  : 0   ( 7 )   F0a i l e d   t0o  -c-o:n-n-e:c-t-  t-o- :l-o-c:a-l-h o-s-t: -p-o:r-t-  8 0 8 0 0: Connection refused
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
nginx-rtmp_1  | curl: (7) Failed to connect to localhost port 8080: Connection refused
nginx-rtmp_1  |   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
nginx-rtmp_1  | curl: (7) Failed to connect to localhost port 8080: Connection refused
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 1#1: signal 17 (SIGCHLD) received from 161
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 1#1: unknown process 159 exited with code 7
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 1#1: unknown process 161 exited with code 7
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 1#1: unknown process 163 exited with code 7
nginx-rtmp_1  |   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
nginx-rtmp_1  |                                  Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
nginx-rtmp_1  | curl: (7) Failed to connect to localhost port 8080: Connection refused
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 1#1: signal 17 (SIGCHLD) received from 165
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 1#1: unknown process 165 exited with code 7
nginx-rtmp_1  | 2020/03/09 17:15:35 [error] 6#6: *4 hls: close fragment n=0, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 6#6: signal 17 (SIGCHLD) received from 171
nginx-rtmp_1  | 2020/03/09 17:15:35 [error] 6#6: *4 hls: ngx_rtmp_mpegts_close_file /opt/data/hls/show_720p2628kbs/1583774131425.ts, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
nginx-rtmp_1  |   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
nginx-rtmp_1  |                                  Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     02020/03/09 17:15:35 [notice] 6#6: signal 17 (SIGCHLD) received from 173
  0     0    2020/03/09 17:15:35 [error] 6#6: *4 Akamia: '/opt/data/hls/show_720p2628kbs/video.m3u8', client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
nginx-rtmp_1  | 0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
nginx-rtmp_1  | curl: (7) Failed to connect to localhost port 8080: Connection refused
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 1#1: signal 17 (SIGCHLD) received from 172
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 1#1: unknown process 172 exited with code 7
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 6#6: signal 17 (SIGCHLD) received from 176
nginx-rtmp_1  | 2020/03/09 17:15:35 [error] 6#6: *4 Akamia: '/opt/data/hls/show_720p2628kbs/manifest.m3u8', client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
nginx-rtmp_1  | 2020/03/09 17:15:35 [error] 6#6: *4 hls: ngx_rtmp_hls_write_variant_playlist file '/opt/data/hls/manifest.m3u8' (2: No such file or directory), client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 6#6: signal 17 (SIGCHLD) received from 178
nginx-rtmp_1  | 2020/03/09 17:15:35 [error] 6#6: *4 S3: '/opt/data/hls/manifest.m3u8', client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
nginx-rtmp_1  | 2020/03/09 17:15:35 [notice] 6#6: signal 17 (SIGCHLD) received from 180
nginx-rtmp_1  | 2020/03/09 17:15:35 [error] 6#6: *4 S3: '/opt/data/hls/video.m3u8', client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
nginx-rtmp_1  |   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
nginx-rtmp_1  |                                  Dload  Upload   Total   Spent    Left  Speed
  2020/03/09 17:15:35 [error] 6#6: *5 hls: close fragment n=0, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0--:--:--     0
nginx-rtmp_1  | curl: (7) Failed to connect to localhost port 8080: Connection refused

.. etc.

Also tried to update just the current repo with newer alpine (3.11) and it fails compiling on this:
cc -c -pipe  -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g   -I src/core -I src/event -I src/event/modules -I src/os/unix -I /tmp/nginx-rtmp-module-1.2.1 -I objs -I src/http -I src/http/modules \
	-o objs/addon/nginx-rtmp-module-1.2.1/ngx_rtmp_eval.o \
	/tmp/nginx-rtmp-module-1.2.1/ngx_rtmp_eval.c
/tmp/nginx-rtmp-module-1.2.1/ngx_rtmp_eval.c: In function 'ngx_rtmp_eval':
/tmp/nginx-rtmp-module-1.2.1/ngx_rtmp_eval.c:160:17: error: this statement may fall through [-Werror=implicit-fallthrough=]
  160 |                 switch (c) {
      |                 ^~~~~~
/tmp/nginx-rtmp-module-1.2.1/ngx_rtmp_eval.c:170:13: note: here
  170 |             case ESCAPE:
      |             ^~~~
cc1: all warnings being treated as errors
make[1]: *** [objs/Makefile:1395: objs/addon/nginx-rtmp-module-1.2.1/ngx_rtmp_eval.o] Error 1
make[1]: Leaving directory '/tmp/nginx-1.16.1'
make: *** [Makefile:8: build] Error 2

Which is probably due to newer gcc.

hmm i haven't tried the other alternative modules in depth yet, although i've changed the Dockerfile back to use the original module. Let me experiment a little bit more.

What's better using this fork of nginx-rtmp?

Hi @reedog117, is this still being worked on?

Closing. Feel free to re-open if you wish to continue working on this.


Travis packages are failing to upload.

The upload portion of the build seems to be failing (though the build is shown as successful).
https://travis-ci.org/omnia-md/conda-recipes/jobs/175758659
Uploading file omnia/openmoltools/0.7.4/linux-64/openmoltools-0.7.4-py27_0.tar.bz2 ...
Retrying after 5 seconds...
Traceback (most recent call last):
  File "/io/conda-build-all", line 447, in <module>
    sys.exit(main())
  File "/io/conda-build-all", line 119, in main
    return execute(args, p)
  File "/io/conda-build-all", line 432, in execute
    code = build_package(m, python, numpy, args)
  File "/io/conda-build-all", line 370, in build_package
    force=args.force, dev=args.dev)
  File "/io/conda-build-all", line 282, in upload_to_binstar
    raise err
  File "/io/conda-build-all", line 273, in upload_to_binstar
    check_call(cmd)
  File "/anaconda/lib/python3.5/subprocess.py", line 581, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '[not shown]' returned non-zero exit status 1
+ true

Working on this now.

I haven't been able to resolve this yet.
I revoked and reissued the anaconda cloud token after the security breach, and encoding this as a secure environment variable with travis encrypt seems to result in anaconda upload hanging waiting on login credentials. I've tried setting the secure environment variable through the UI as well. No luck as of yet.

I dont think this is still a problem, we can reopen if it is


Addapt cob4-4 configuration

@ipa-mdl please review

Looks fine so far..
Was the new vel_from_device tested properly? It alters the dynamic behaviour of the base.

The vel_from_device is wrong...
In my comment, I only suggested to replace p1 == nan with  p1 != p1, the rest of the conversion was torso specific and - of course - does not apply for the base!

Also can we hold this PR, until the monster #346 has been tested, settled and merged?

Please merge this PR as soon as possible, I have to open still PRs for cob4-3 and cob4-6 with these changes

As #346 also applies changes to cob4-4, #346 should be merged first....

This should be merged first, it is the template for all new base.
This PR is a sync, the other is a new feature (and should be splitted).

conclusion seems to merge this first. I'll do that now...


Include patch in generated SBOM?

Hello,
I'm exploring SBOM generation with Nix, using this tool. I've encountered an issue where patches specified in the Nix flake do not appear in the generated SBOM. Below is a flake example demonstrating the issue. This flake aims to generate an SBOM that should include at least two patches; however, these patches are missing from the final SBOM file.
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    systems.url = "github:nix-systems/default";
    bombon.url = "github:nikstur/bombon";
  };

  outputs = inputs@{ self, flake-parts, systems, ... }: flake-parts.lib.mkFlake { inherit inputs; } {
    systems = import systems;

    perSystem = { config, self', inputs', pkgs, system, lib, ... }: {
      packages = let
        contents = [
          (pkgs.php82.overrideAttrs (oldAttrs: {
            patches = oldAttrs.patches ++ [
              (pkgs.fetchurl {
                url = "https://gist.githubusercontent.com/drupol/f7b9bbe134338e0ce5e2fdac7bf6de0b/raw/e32f364d7e9f5793a8bd874af84ee609368d0bf0/php-ec.patch";
                hash = "sha256-rbuihwDMZOzlrGgBrDs9eY8God2B09jpeXZF43zYlN8=";
              })
            ];
          }))
          pkgs.php82.packages.composer
        ];
      in {
        sbom = inputs.bombon.lib.${system}.buildBom (pkgs.symlinkJoin { name = "sbom"; paths = contents; }) { };
      };
    };
  };
}

To reproduce this issue, execute nix build .#sbom (note: PHP compilation may take 5 to 10 minutes). For convenience, I have already generated the SBOM, which you can download here: sbom.json.
Interestingly, when I add the flag includeBuildtimeDependencies = true;, the patches appear in the SBOM. The updated SBOM can be downloaded here: sbom.json.
Taking Composer as an example, the current version of Nixpkgs applies a patch for CVE-2024-24821, which can be found at this link. This patch is included in the SBOM as follows:
{
  "type": "application",
  "bom-ref": "urn:uuid:ef7eaa20-7a20-4001-84de-a673a369c681",
  "name": "CVE-2024-24821.patch",
  "version": "",
  "purl": "pkg:nix/CVE-2024-24821.patch@"
}

However, the SBOM does not clearly indicate that the patch is associated with Composer.
I have two questions:

Is it expected behavior for patches not to appear in the SBOM when build dependencies are not included?
How can we enhance the representation of patches in the SBOM when including buildtime dependencies to clearly indicate their association with specific derivations?

Isn't a patch by definition a buildtime input because it modifies the source code?
We'd probably need to include the graph information in the SBOM. Cyclonedx already can do this. The question is how we can extract this nicely from Nix.

Isn't a patch by definition a buildtime input because it modifies the source code?

From that perspective, that's true. However, it would be nice to have this information in the SBOM.

We'd probably need to include the graph information in the SBOM. Cyclonedx already can do this. The question is how we can extract this nicely from Nix.

What kind of graph, do you have an example ?

I think he means dependency graph. Currently genericClosure flattens this and throws away this info
https://github.com/nikstur/bombon/issues/155