text:
enable unittests for cmake builds

-Dtensorflow_BUILD_CC_TESTS=ON will build cc unit test
-Dtensorflow_BUILD_PYTHON_TESTS=ON will enable python kernel tests
This might still need to work. Tested under windows, it should also work for other platforms.
Not all tests are building and passing yet - the once that don't work are in the variable
tf_test_src_simple_exclude and we'll deal with one at a time (my hope is that exposing the tests makes it easier to recruit some help).

Can one of the admins verify this patch?

@tensorflow-jenkins test this please

Thanks for the contribution!
I will need to create a new build for this, and test it manually on jenkins.
I will do that in the afternoon.

Cool. If you turn on the cc unit tests: be patient with Jenkins ... lots of binaries that it builds. Took 10+ hours for me, which is not practical for CI but very helpful for overall quality. @mrry suggested we could take a sensible subset of tests for CI.
Or one could turn on only the python tests for CI - there are maybe 80 of those which is a ton better than nothing.

Thanks for the warning, I almost enabled all tests :)
I am starting a build now. I will see how the results look.

So I tried to create a jenkins job, it ran the following:
call "C:\program files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"
cd tensorflow/contrib/cmake
rmdir build /S /Q
mkdir build
cd build
"C:\program files\cmake\bin\cmake.exe" .. -A x64 -DSWIG_EXECUTABLE=C:\ProgramData\chocolatey\bin\swig.exe -DPYTHON_EXECUTABLE="C:\Program Files\Anaconda3\python.exe" -DCMAKE_BUILD_TYPE=Release -DPYTHON_LIBRARIES="C:\Program Files\Anaconda3\libs\python35.lib -Dtensorflow_BUILD_PYTHON_TESTS=ON"
"C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild" /p:Configuration=Release /maxcpucount:32 tf_python_build_pip_package.vcxproj
ctest -C Release

However, the result is:
http://ci.tensorflow.org/job/tensorflow-pull-requests-windows-cmake-python/1/
00:02:30.752 Test project C:/tf_jenkins/home/workspace/tensorflow-pull-requests-windows-cmake-python/tensorflow/contrib/cmake/build
00:02:30.757 No tests were found!!!

how should I modify my script?

I think there is a "" thing in your command line.
change:
-DPYTHON_LIBRARIES="C:\Program Files\Anaconda3\libs\python35.lib -Dtensorflow_BUILD_PYTHON_TESTS=ON"
to:
-DPYTHON_LIBRARIES="C:\Program Files\Anaconda3\libs\python35.lib" "-Dtensorflow_BUILD_PYTHON_TESTS=ON"

Thanks for noticing that, you are right.
Retrying build with the fixed script.
On Thu, Nov 3, 2016 at 2:51 PM, guschmue notifications@github.com wrote:

I think there is a "" thing in your command line.
change:
-DPYTHON_LIBRARIES="C:\Program Files\Anaconda3\libs\python35.lib
-Dtensorflow_BUILD_PYTHON_TESTS=ON"
to:
-DPYTHON_LIBRARIES="C:\Program Files\Anaconda3\libs\python35.lib"
"-Dtensorflow_BUILD_PYTHON_TESTS=ON"
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/pull/5364#issuecomment-258284780,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHlCObOEDm1TWiluQGHEcYJDIvPYKx_rks5q6ldtgaJpZM4Kn3d6
.

yes, sure, that is better. I'll update the pr later today.

Jenkins, test this please.

Sorry for the prolonged review.
Now this is what I am seeing:
http://ci.tensorflow.org/job/tensorflow-pr-win-cmake-pytest/1/
The script I execute is this:
call "C:\program files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"
cd tensorflow/contrib/cmake
rmdir build /S /Q
mkdir build
cd build
"C:\program files\cmake\bin\cmake.exe" .. -A x64 -DSWIG_EXECUTABLE=C:\ProgramData\chocolatey\bin\swig.exe -DPYTHON_EXECUTABLE="C:\Program Files\Anaconda3\python.exe" -DCMAKE_BUILD_TYPE=Release -DPYTHON_LIBRARIES="C:\Program Files\Anaconda3\libs\python35.lib" -Dtensorflow_BUILD_PYTHON_TESTS=ON
"C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild" /p:Configuration=Release /maxcpucount:32 tf_python_build_pip_package.vcxproj
ctest -C Release -DPYTHON_EXECUTABLE="C:\Program Files\Anaconda3\python.exe"

All tests seem to be failing, any idea what is wrong?
Also no logs are visible. Can we modify the tf tests cmake file to print out the test log in case of test failure?

Is it possible we need to create a virtualenv, pip install the package, then run the tests?

looked briefly over the output and didn't see something wrong. Don't think you need a virtual env, at least my jenkins is happy without.
Is there a directory 'Testing' in the build directory ? (I think this is where ctest keeps the last result).
Getting logs in case of failure: I can add a --output-on-failure.
We added the full python path to cmake ... did you use the pip that goes with that python ?

--output-on-failure ... I meant you can call ctest with
'ctest --output-on-failure'

All I run is the above command I printed, as you see I was missing the pip install stage.
However, I think we do need virtualenv, to make sure the builds stay isolated.
We do not want a pip package from a previous run to stay and cause some error messages on the machines.

fair, its better to create an environment. I should do this for my jenkins as well.

While I still see some test failures, the changes in this PR seem to be working fine.
The test failures can be addressed separately.

I was not able to get the test failures in jenkins, but when I ran my script manually on a windows machine, I run into issues during "import tensorflow".
It tells me it cannot load some dll's
Maybe we are not including all we should in the pip package?

there is some stuff from contrib missing (its bugging me a lot and I'll look at that next) but a plain
import tensorflow
will work. I can download the wheel from your jenkins and see if it complains on my box.

Let me try a few things, and see if it works.
If not, I will create an issue and we can continue discussion there.
On Fri, Nov 4, 2016 at 4:12 PM, guschmue notifications@github.com wrote:

there is some stuff from contrib missing (its bugging me a lot and I'll
look at that next) but a plain
import tensorflow
will work. I can download the wheel from your jenkins and see if it
complains on my box.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/pull/5364#issuecomment-258569682,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHlCOZ0DKHrHzppG6LumEuzYsh9M1JAjks5q67v1gaJpZM4Kn3d6
.

authors: gunan guschmue tensorflow-jenkins vrv


text:
Improve Scalability and Efficiency of Python SDK

Improve Scalability and Efficiency with Graph Optimization and Streaming Support
Issue Description
The current implementation of Indexify's Python SDK may face challenges with very large graphs or high-throughput scenarios on SDK side. We need to add support for streaming and parallel processing to improve execution efficiency and handle continuous data flows more effectively.
Current Limitations

Large Graph Handling: The Graph class in indexify/functions_sdk/graph.py loads all nodes and edges into memory, which may not be efficient for very large graphs.

Synchronous Execution: The _run method in LocalClient (indexify/local_client.py) processes nodes sequentially, which may not be optimal for large graphs or high-throughput scenarios.

Lack of Streaming Support: The current implementation doesn't have native support for processing continuous data streams efficiently.

Examples from Codebase

Graph Loading (indexify/functions_sdk/graph.py):
class Graph:
    def __init__(self, name: str, start_node: IndexifyFunction, description: Optional[str] = None):
        self.nodes: Dict[str, Union[IndexifyFunction, IndexifyRouter]] = {}
        self.routers: Dict[str, List[str]] = defaultdict(list)
        self.edges: Dict[str, List[str]] = defaultdict(list)

This in-memory representation may not scale well for very large graphs.

Synchronous Execution (indexify/local_client.py):
def _run(self, g: Graph, initial_input: bytes, outputs: Dict[str, List[bytes]]):
    queue = deque([(g._start_node, initial_input)])
    while queue:
        node_name, input = queue.popleft()
        # Process node...

This sequential processing may become a bottleneck for large graphs or high-throughput scenarios.

Lack of Streaming Support:
There's currently no dedicated mechanism for handling continuous data streams efficiently.

Proposed Solution

Graph Optimization:

Implement lazy loading of graph nodes and edges.

Improved Execution Engine:

Refactor the execution engine to support parallel processing of independent nodes.
Implement a work-stealing scheduler for better load balancing across available resources.

Streaming Support:

Introduce a new StreamProcessor class that can handle continuous data inputs.
Modify the Graph class to support infinite loops for stream processing.
Implement windowing operations for aggregating streaming data.

Testing:

Develop comprehensive test suite for new features.

Additional Notes

Very vague idea but we can explore adding a graph analysis step to identify opportunities for optimization (e.g., combining compatible nodes, identifying parallelizable sections).
Performance benchmarks should be established before and after these changes to quantify the improvements.

@diptanu yeah you're right, working with indexify sdk today and skimming the rust code makes me realize we can chuck Graph Optimization and Improved Execution Engine. those make no sense. I still think that Streaming Support can be helpful and yeah @indexify_generator decorator that you suggested seems like a better approach. It's simple, requires less modification to existing Indexify architecture, the api will be intuitive given the decorator approach is consistent with existing Indexify function decorators

source: gharchive/issue

repo: tensorlakeai/indexify

license_type: permissive

license_source: github-api


text:
Enable watcher on all non-perf pipelines

Stress test pipeline seems to be stable with watcher enabled, time to turn it on in other pipelines

currently blocked by #6763

repo: tenstorrent-metal/tt-metal


text:
ttnn.sum operation does not work bfloat8_b

ttnn.sum operation does not work when input tensor is bfloat8_b. Documentation does not mention that limitation. We are getting:
Cannot pad tilized tensor with specified formatTT_FATAL @ ../ttnn/cpp/ttnn/operations/data_movement/pad/device/pad_op.cpp:32: input_tensor.get_dtype() == DataType::FLOAT32 || input_tensor.get_dtype() == DataType::BFLOAT16

Steps to reproduce
Checkout main branch.
You can reproduce this error with sweep test tests/sweep_framework/sweeps/reduction/sum.py. To run:
python3 tests/sweep_framework/runner.py --elastic cloud --module-name reduction.sum

Results can be found on elastic cloud as explained here: https://github.com/tenstorrent/tt-metal/tree/main/tests/sweep_framework

This might be something with the test.
The following works
import pytest
import torch
import ttnn
from tests.ttnn.utils_for_testing import assert_with_pcc
from models.utility_functions import torch_random

@pytest.mark.parametrize(
        "width", [5]
        )
def test_reduce(device, width):
    torch.manual_seed(0)

    #input_shape = (1, 1, 1, 12, width)
    input_shape = (1, 12, width)
    reduce_dim = -1

    torch_input_tensor = torch.rand(input_shape, dtype=torch.float32)
    torch_output_tensor = torch.sum(torch_input_tensor, dim=reduce_dim, keepdim=True, dtype=torch.float32)

    input_tensor = ttnn.from_torch(torch_input_tensor, dtype=ttnn.bfloat8_b, layout=ttnn.TILE_LAYOUT, device=device)

    output_tensor = ttnn.sum(input_tensor, dim=reduce_dim)
    output_tensor = ttnn.to_torch(output_tensor)

    assert_with_pcc(torch_output_tensor, output_tensor)

and uses bfloat8_b
                     Op | DEBUG    | Launching Device Operation: "Reduce"
                     Op | DEBUG    | Program Hash: 0
                     Op | DEBUG    | Program Cache Hit: false
                     Op | DEBUG    | Attributes:
                     Op | DEBUG    | 	math_op = ReduceOpMath::SUM
                     Op | DEBUG    | 	dim = ReduceOpDim::W
                     Op | DEBUG    | 	scaler = 1
                     Op | DEBUG    | 	output_mem_config = MemoryConfig(memory_layout=TensorMemoryLayout::INTERLEAVED,buffer_type=BufferType::DRAM,shard_spec=std::nullopt)
                     Op | DEBUG    | 	output_dtype = DataType::BFLOAT8_B
                     Op | DEBUG    | 	compute_kernel_config = WormholeComputeKernelConfig(math_fidelity=HiFi4,math_approx_mode=0,fp32_dest_acc_en=1,packer_l1_acc=0,dst_full_sync_en=0)
                     Op | DEBUG    | Tensors Args:
                     Op | DEBUG    | 	0: Tensor(storage=DeviceStorage(memory_config=MemoryConfig(memory_layout=TensorMemoryLayout::INTERLEAVED,buffer_type=BufferType::DRAM,shard_spec=std::nullopt)),tensor_spec=TensorSpec(logical_shape=SimpleShape([1, 1, 12, 5]),tensor_layout=TensorLayout(dtype=DataType::BFLOAT8_B,page_config=PageConfig(config=TilePageConfig(tile=Tile(tile_shape={32, 32},face_shape={16, 16},num_faces=4))),memory_config=MemoryConfig(memory_layout=TensorMemoryLayout::INTERLEAVED,buffer_type=BufferType::DRAM,shard_spec=std::nullopt),alignment=Alignment([32, 32]))))
                     Op | DEBUG    |
                 Always | INFO     | End op: Reduce

@asandhupatlaTT could you please try to reproduce?

authors: bbradelTT nemanjagrujic

repo: tenstorrent/tt-metal


text:
CCL ops support for Galaxy 2D grid configuration

Proposal:
Add optional parameters in CCL ops to all_gather or all_reduce along a specific axis if device_mesh is initialized as a 2D  grid.
1. All-reduce along y:
FF2_act = ttnn.all_reduce(FF1_output, op=ttnn.ReduceOp.SUM, cluster_axis=1)
2. All-gather along x:
output = ttnn.all_gather(output, dim=3, cluster_axis=0)
Open questions:

[ ] Does multi-device tensors know how to gather on a specific cluster axis?
[ ] Should we pass in device_mesh to the CCL ops, and should device_mesh contain in the info of the cluster shape?

Example:
First open device mesh with this config:
  device_grid, device_ids = ttnn.DeviceGrid(4, 8), ttnn.get_device_ids() # User determined
  multi_device = ttnn.open_device_mesh(device_grid, device_ids)

Then shard activations and weights in this way:
act = ttnn.from_torch(
    act_pt,
    dtype=ttnn.bfloat16,
    layout=ttnn.TILE_LAYOUT,
    device=device_mesh,
    mesh_mapper=ShardTensor2dMesh(device_mesh, dims=(3, None), cluster_shape=cluster_shape),
)
# shape=Shape([1, 1, 32, 2048]) on 32 devices
weights = ttnn.from_torch(
    weights_pt,
    dtype=ttnn.bfloat8_b,
    layout=ttnn.TILE_LAYOUT,
    device=device_mesh,
    mesh_mapper=ShardTensor2dMesh(device_mesh, dims=(2, 3), cluster_shape=cluster_shape),
)
# shape=Shape([1, 1, 2048, 4096]) on 32 devices

Llama FF1_output tensors after matmul on 32 devices sharded on a (4,8) grid each is Shape([1, 1, 32, 4096]),
We want to all-reduce along the x axis in groups of 4
All-Reduce along x axis
FF2_act = ttnn.all_reduce(FF1_output, op=ttnn.ReduceOp.SUM, cluster_axis=0)
FF2_act is replicated along the x axis 4 times, shape is (1, 1, 32, 4096)
After FF2 matmul we want to all-reduce along the y axis in groups of 8
All-Reduce along y axis
output = ttnn.all_reduce(FF2_output, op=ttnn.ReduceOp.SUM, cluster_axis=1)
output is replicated along the y axis 8 times, shape is (1, 1, 32, 2048)
Finally we do an All-Gather along the x axis to assemble the final output back to
the original shape of (1, 1, 32, 8192) with every device having a complete activation tensor
output = ttnn.all_gather(output, dim=3, cluster_axis=0)
Diagram:

@SeanNijjar Do you know the status of AllReduce op? If there are any plans to add that op anytime soon?

@aliuTT There is currently no all-reduce op but this general ask applies to all CCL ops since it's more of a mesh (tensor) and op invocation concern.

Requested support from ttnn multidevice:

ttnn.all_gather with a multidevice tensor, device mesh, dim, and cluster axis firing off all the linear allgathers that are necessary

Eg.
The user would supply a multi-device tensor initialized from the 2d cluster shape (4,8) , calling output = ttnn.all_gather(output, dim=3, cluster_axis=0) would group the first 4 tensors in a group and linearly all-gather them on dim=3. The result would be the same tensor replicated 4 times in the first row and similariy the other rows would also linear all-gather on dim=3.

Hey @mikevin920 / @cglagovichTT, I synced with @SeanNijjar and @aliuTT. To make progress on this issue we need:

https://github.com/tenstorrent/tt-metal/pull/9909 to be merged
https://github.com/tenstorrent/tt-metal/issues/10166

Once those are merged, I can make progress on your request.

I've merged changes for getting devices by row and col: https://github.com/tenstorrent/tt-metal/issues/10166.

Raising priority to P0 since this is blocking llama bring up on Galaxy's.

Is there anything else blocking progress here?

I'm unblocked to make progress on this issue. I'll prioritize this work to unblock llama galaxy bringup

btw in terms of the workaround that model team is currently doing to get the model working on TG (i.e. copying back to host and running all-gather). Is there a reason we're not just manually invoking the parallel all-gather ops per line, similar to how we used to invoke all gather several months ago by manually launching the all-gather kernel per chip (but in this case it's per row/col)?

Launching each line-all-gather in parallel is definitely what we want. Does that mean that all of the logic has to be within launch_op?

Launching each line-all-gather in parallel is definitely what we want. Does that mean that all of the logic has to be within launch_op?

We can't do it in the op because multiple rows/cols worth of tensors will be presented and it will be ambiguous how many line gathers are desired and where. Instead, I'm proposing that until the syntactic sugar is added, you could do something like:
full_galaxy_input_tensors = ttnn.get_device_tensors(input_mesh_tensor)
per_row_tensors = [ # This could be saved somewhere for reuse
[<I don't know the exact ID's but these would correspond the the chip order],
[],
[],
[],
]

outputs = []
for r in range(nrows):
  # If mesh tensor enabled
  row_mesh_tensor = ttnn.aggregate_as_tensor([full_galaxy_input_tensors[i] for i in per_row_tensors[r]])
  output_mesh_tensor = ttnn.line_all_gather(row_mesh_tensor, ... rest of args)
  outputs.append(output_mesh_tensor)

  # if no mesh tensor
  row_tensors = [full_galaxy_input_tensors[i] for i in per_row_tensors[r]]
  row_outputs = ttnn.line_all_gather(row_tensors, ... rest_of_args)
  outputs.append(row_outputs)

# This might need to be reverse mapped to match the chip order
output_mesh_tensor = ttnn.aggregate_as_tensor(itertools.chain(outputs))

authors: SeanNijjar aliuTT cfjchu cglagovichTT mikevin920 uaydonat


text:
#10226: Added or refactored BH SFPU functions

Ticket
#10226
Problem description
Some functions are not added/enabled for BH.
What's changed
Within the scope of this PR, the following changes are introduced:

SFPU mask - added _int version
SFPU reshuffle rows - added missing files
* A follow-up coming soon for test infra fix
SFPU reciprocal - modified to use submodule LLKs
SFPU sqrt - modified to use submodule LLKs
SFPU trunc OP - enabled for BH

Checklist

[ ] Post commit CI passes
[ ] Blackhole Post commit (if applicable)
[ ] Model regression CI testing passes (if applicable)
[ ] New/Existing tests provide coverage for changes

Since Blackhole only has SD/FD C++ tests on pipelines, can you also run this pytest -svv tests/tt_eager/python_api_testing/sweep_tests/pytests/tt_dnn/test_eltwise_unary.py and make sure it still passes since it has not been added to CI yet?

Also how has the reshuffle_rows been tested?

Since Blackhole only has SD/FD C++ tests on pipelines, can you also run this pytest -svv tests/tt_eager/python_api_testing/sweep_tests/pytests/tt_dnn/test_eltwise_unary.py and make sure it still passes since it has not been added to CI yet?

Tested, pass ✅

Also how has the reshuffle_rows been tested?

No, the work will be continued as a part of #11816

I'd like to request that some sample of the uses cases of the sweep tests mentioned by @rtawfik01 be added to tests/ttnn/unit_tests

We are working to enable the fast-dispatch-post-commit workflow on BH CI which should cover these cases, there is a PR up where we are disabling the current failing tests on BH (see https://github.com/tenstorrent/tt-metal/tree/mchiou/11919-enable-ttnntteager-on-bh-ci)

source: gharchive/pull-request

authors: abhullar-tt ncvetkovicTT rtawfik01


text:
event listener for when all resources are loaded in the app at runtime

Hi Tentone,
I was wondering if there is some sort of event listener for when the app loads the entire stuff. there is the app.onload I think, but this event is raised when the software is ready to draw the first frame, but I have observed textures and meshes come a little bit later and so on.
I know there is a lot of work to be done, specially on performance and other areas, but I was wondering if now we have or can have :) a listener as to when the entire thing is drawing everything. I had the idea of fire up a timer of couple secs on the initialize function, but although effective to some degree this solution, I think it will be cleaner to have an event listener outside the update iterator.
thanks!

Hi
Right now there is no event to indicate that all resources are loaded. It is a bit difficult to know when the texture is actually ready to use since WebGl does not provide any feedback about it.
Thanks a lot!

Ok men. What a pitty they dont do that.
Thanks!
On Sat, Mar 30, 2019, 7:51 AM Tentone notifications@github.com wrote:

Hi
Right now there is no event to indicate that all resources are loaded. It
is a bit difficult to know when the texture is actually ready to use since
WebGl does not provide any feedback about it.
Thanks a lot!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tentone/nunuStudio/issues/285#issuecomment-478238543,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQLGlelnfzMZDN3jzF7pZFJ3Q78FMR6Pks5vb0--gaJpZM4cMrVQ
.

repo: tentone/nunuStudio

license: MIT


text:
Less verbose cargo

During the work on Cumbertrade I've noticed that cargo is producing a lot of noise during a build of cargo2nix-ed packages. Related issue is here: https://github.com/tenx-tech/engineering-program/issues/721
This PR won't just remove the -vvv flag from cargo invocation in mkRustCrate, but will make the verbosity level configurable since I believe that this high verbosity was added for a reason and still might be useful in some cases.
cc @workflow @ebkalderon

Let's respect nixpkgs NIX_DEBUG variable. User can enable verbose build per crate using overrides.

I like the idea behind this PR! Let's respect NIX_DEBUG as well, as @trha suggested.

@trha @ebkalderon I've tried this approach, please take a look!

We actually don't need to change code generation for this. User can specify NIX_DEBUG for all crates using:
rustPkgs = pkgs.rustBuilder.makePackageSet' {
  packageOverrides = pkgs: [
    (pkgs.rustBuilder.rustLib.makeOverride {
      overrideAttrs = _: { NIX_DEBUG = "7"; };
    })
  ];
};

@trha please check

authors: ebkalderon eupn trha


text:
Info.plist must contain an NSCameraUsageDescription

Crashing with following error
This app has crashed because it attempted to access privacy-sensitive data without a usage description.  The app's Info.plist must contain an NSCameraUsageDescription key with a string value explaining to the user how the app uses this data.

Solved by adding Privacy - Camera Usage Description

repo: teocci/RTSP-Server-iOS


text:
Added run configurations for spotless

Guidelines
Added run configurations for spotless
Types of changes
What types of changes does your code introduce?

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

Preparing a pull request for review
Ensure your change is properly formatted by running:
$ ./gradlew spotlessApply

Please correct any failures before requesting a review.

@zeobot set lc to pass

repo: teogor/ceres


text:
should upgrade docker-compose to 1.11.2 release

this is the latest release now

we need to remove the version release specification, by default, always install the latest version of docker-compose, this will be improved later.

repo: teracyhq/dev


text:
WOQLClient.connect() doesn't update server property

Describe the bug
When providing a config object in WOQLClient.connect() the server property isn't updated.
If a server url was not specified in the WOQLClient constructor it throws an error that the given argument «is not a valid Terminus DB API endpoint».
If a server url was specified in the WOQLClient constructor it connects to the url provided in the constructor.
To Reproduce
import {WOQLClient} from '@terminusdb/terminusdb-client'
const Client = new WOQLClient()
await Client.connect({server: 'https://127.0.0.1:6363/', user: 'admin', key: 'root'})
    .then((s) => console.log('connected succesfully'))
    .catch(error => console.log('error', error))

Expected behavior
The client should connect to the server specified in the config object.
(If it needs to be specified in the constructor, a different error should be thrown)
Error logs
error URIError: Invalid argument to
            connect.
            https://127.0.0.1:6363/
            is not a valid Terminus DB API endpoint
    at WOQLClient.connect ([…]/node_modules/@terminusdb/terminusdb-client/lib/woqlClient.js:235:31)

System information (please complete the following information):

~OS: [e.g. Ubuntu 18.04]~
~Browser/NodeJS version [e.g. chrome, safari]~
terminus-client version: 4.1.0

Additional context
This line should probably not be commented out, but this.setServer seems to be undefined…
https://github.com/terminusdb/terminusdb-client-js/blob/b0af6a16d565ed172756aa68712440a825e42ad3/lib/connectionConfig.js#L61

Thanks for this. We will discuss in our documentation and issue triage in the TerminusDB Discord server tomorrow at 2pm GMT. Feel free to join, but will report back anyhow!

We're sorry, but the documentation shows the old way to connect with terminusDB.
Thanks for reporting it.
I have updated the description of the connection method in the online documentation.
We are working at a new documentation and for the API it will be generated from the code automatically.
You can pass the serverUrl only in the constructor
import {WOQLClient} from '@terminusdb/terminusdb-client' const Client = new WOQLClient('https://127.0.0.1:6363/') await Client.connect({user: 'admin', key: 'root'})     .then((s) => console.log('connected succesfully'))     .catch(error => console.log('error', error))

authors: Francesca-Bit fidelthomet luke-feeney

repo: terminusdb/terminusdb-client-js


text:
Add german language (DE) entries

As requested, to make german language available "de" has been added in line 8 and 28.
https://github.com/terra-money/station/pull/32#pullrequestreview-887891679

Combine #32 with this please.

Thanks a lot for your effort :)

authors: BlockJayn simcheolhwan

repo: terra-money/station


text:
feat!: Upgrading AWS provider minimum required version to 5.0.0

Description
Upgrade the minimum required version of the AWS provider to 5.0.0
Motivation and Context
Upgrading to get the latest changes from AWS provider
Breaking Changes
No
How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[x] I have tested and validated these changes using one or more of the provided examples/* projects
[x] I have executed pre-commit run -a on my pull request

This module doesn't require version 5.0 to function, so this PR is unnecessary.

authors: antonbabenko cristidas

repo: terraform-aws-modules/terraform-aws-acm

license_source: bigquery


text:
Support Automatic Subnet Tagging

Is your request related to a new offering from AWS?

No.
Is your request related to a problem? Please describe.

AWS EKS used to automatically tag the subnets associated with a cluster. This behavior has been removed as of 1.19: https://docs.amazonaws.cn/en_us/eks/latest/userguide/network_reqs.html#vpc-subnet-tagging
Describe the solution you'd like.

An optional feature to apply the kubernetes.io/cluster/<cluster-name>: shared tag to all subnets associated with a cluster.
Describe alternatives you've considered.

Adding these tags ourself as a consumer of this module using Terraform hashicorp/aws ec2_tag. This is the approach we will have to use for now until this feature is implemented.
Additional context

From https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html

If you're using the AWS Load Balancer controller version v2.1.1 or earlier, subnets must be tagged in the format that follows. If you're using version 2.1.2 or later, tagging is optional. However, we recommend that you tag a subnet if any of the following is the case. You have multiple clusters that are running in the same VPC, or have multiple AWS services that share subnets in a VPC. Or, you want more control over where load balancers are provisioned for each cluster.

In my case the subnet is created by another team and at that time the cluster name is not known, or the cluster name may change if the infra is destroyed and re-provisioned for whatever reason.

repo: terraform-aws-modules/terraform-aws-eks


text:
feat: Ignore changes to .aws_iam_role..role_last_used

Description
Ignore changes to role_last_used for aws_iam_role.this[0], module.eks_managed_node_group[*].aws_iam_role.this[0], and module.eks_managed_node_group[*].aws_iam_role.irsa[0].
Motivation and Context
Without this commit, there is useless noise in drift detection in Terraform Enterprise, for example.
Breaking Changes
I shouldn't think so.
How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[ ] I have tested and validated these changes using one or more of the provided examples/* projects

[x] I have executed pre-commit run -a on my pull request

can you provide a reproduction that shows this reoccurring issue within plans and applies? this is the first I am hearing of this being an issue

Sure, I'll try, Maybe this is something TFE specific, so I updated the description.

Related upstream issue https://github.com/hashicorp/terraform-provider-aws/issues/30861

This PR is included in version 19.15.0 :tada:

Seems to produce an error:
Error: Unsupported attribute

   on .terraform/modules/kubernetes.eks/main.tf line 324, in resource "aws_iam_role" "this":
  324:       role_last_used,

 This object has no argument, nested block, or exported attribute named
 "role_last_used".`

ya, my apologies - the attribute being ignored as added in 4.64 of the provider and I overlooked this. We will revert since it appears this is not resolving the underlying issue and will chase the upstream issue for resolution

authors: antonbabenko bryantbiggs eli-kaplan yurrriq


text:
Feature/eks policy depends on

Description

Motivation and Context

Breaking Changes

How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[ ] I have tested and validated these changes using one or more of the provided examples/* projects

[ ] I have executed pre-commit run -a on my pull request

Woops, wrong repo.

repo: terraform-aws-modules/terraform-aws-iam


text:
fix: Update CI workflow versions to latest

Description

Update CI workflow versions to latest

Motivation and Context

Updates our workflows to use the latest versions
Removes warnings for Python 3.12 in runners

Breaking Changes

No

How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[ ] I have tested and validated these changes using one or more of the provided examples/* projects
[x] I have executed pre-commit run -a on my pull request

This PR is included in version 1.4.1 :tada:

authors: antonbabenko bryantbiggs


text:
Var with default value in order to prevent the error

Error applying plan:
1 error(s) occurred:

module.database.module.db_instance.aws_db_instance.this (destroy): 1 error(s) occurred:

aws_db_instance.this: InvalidParameterValue: The parameter FinalDBSnapshotIdentifier is not a valid identifier. Identifiers must begin with a letter; must contain only ASCII letters, digits, and hyphens; and must not end with a hyphen or contain two consecutive hyphens.
status code: 400, request id: xxxxx

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

duplicated

repo: terraform-aws-modules/terraform-aws-rds


text:
name = display_name

Add boolean to set name the same as display_name rather than using guids

Can this be closed now with 0.2.0?

Closed by PR #3

authors: matt-FFFFFF richeney


text:
Simplify support for running module directly

I expected to be able to do python -m terraform_compliance as we would with pip or other python tools, but it didn't work. Instead I had to do python -m terraform_compliance.main.
This fixes that problem.

@eerkunt

I am very interested how you invoke terraform-compliance with python. Could be a nice documentation!

authors: eerkunt mungojam

repo: terraform-compliance/cli


text:
fix(deps): update terraform ibm to latest for deployable architectures

This PR contains the following updates:

Package
Type
Update
Change

ibm (source)
required_provider
patch
>= 1.71.1 -> >= 1.71.2

Release Notes

IBM-Cloud/terraform-provider-ibm (ibm)
v1.71.2
Compare Source
Bugfixes

Tags support config aggregator & Bug fix for settings api (5783)
fix(partner center sell): fix patch nested fields (5785)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 1.3.10 :tada:
The release is available on:

GitHub release
v1.3.10

Your semantic-release bot :package::rocket:

repo: terraform-ibm-modules/mock-module


text:
chore(deps): update ci dependencies

This PR contains the following updates:

Package
Type
Update
Change

common-dev-assets

digest
6980d55 -> f2e1cf2

github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper
require
minor
v1.26.3 -> v1.27.2

Release Notes

terraform-ibm-modules/ibmcloud-terratest-wrapper (github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper)
v1.27.2
Compare Source
Bug Fixes

deps: update module github.com/ibm/platform-services-go-sdk to v0.56.3 (#749) (2f431a0)

v1.27.1
Compare Source
Bug Fixes

deps: update module github.com/ibm/platform-services-go-sdk to v0.56.2 (#747) (d6dbbcb)

v1.27.0
Compare Source
Features

delete iam policy (#745) (82603f4)

v1.26.5
Compare Source
Bug Fixes

deps: update gomod (#743) (1ab2e92)

v1.26.4
Compare Source
Bug Fixes

deps: update gomod (#738) (a9275e6)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

/run pipeline

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


text:
chore(deps): update common-dev-assets digest to c0b9fc9

This PR contains the following updates:

Package
Update
Change

common-dev-assets
digest
dda6d1f -> c0b9fc9

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

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


text:
doc: add supporting doc for complex object type inputs

Description
Issue: https://github.com/terraform-ibm-modules/terraform-ibm-event-streams/issues/251

Release required?

[ ] No release
[ ] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

:tada: This PR is included in version 2.1.0 :tada:
The release is available on:

GitHub release
v2.1.0

Your semantic-release bot :package::rocket:

authors: akocbek terraform-ibm-modules-ops


text:
chore(deps): update module github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper to v1.10.17

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper
require
patch
v1.10.16 -> v1.10.17

Release Notes

terraform-ibm-modules/ibmcloud-terratest-wrapper (github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper)
v1.10.17
Compare Source
Bug Fixes

deps: update module github.com/ibm/platform-services-go-sdk to v0.44.0 (#602) (d141e39)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

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


text:
chore(deps): update common-dev-assets digest to 4d733b1

This PR contains the following updates:

Package
Update
Change

common-dev-assets
digest
65b2a12 -> 4d733b1

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

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


text:
chore(deps): update common-dev-assets digest to a9f51b2

This PR contains the following updates:

Package
Update
Change

common-dev-assets
digest
89ff022 -> a9f51b2

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

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


text:
fix(deps): update required_provider

This PR contains the following updates:

Package
Type
Update
Change

ibm (source)
required_provider
minor
>= 1.45.0 -> >= 1.48.0

restapi (source)
required_provider
minor
>= 1.17.0 -> >= 1.18.0

Release Notes

IBM-Cloud/terraform-provider-ibm
v1.48.0
Compare Source
Features

Support for Powervs

DataSources

ibm_pi_disaster_recovery_location
ibm_pi_disaster_recovery_locations
ibm_pi_volume_group
ibm_pi_volume_groups
ibm_pi_volume_group_details
ibm_pi_volume_groups_details
ibm_pi_volume_group_storage_details
ibm_pi_volume_group_remote_copy_relationships
ibm_pi_volume_flash_copy_mappings
ibm_pi_volume_remote_copy_relationship
ibm_pi_volume_onboardings
ibm_pi_volume_onboarding

Resources

ibm_pi_volume_onboarding
ibm_pi_volume_group
ibm_pi_volume_group_action

Support for KMS

DataSources

ibm_kms_instance_policies

Resources

ibm_kms_instance_policies
ibm_kms_key_with_policy_overrides

Enhancements

Enable cross account KMS boot volume encryption for VPC Cluster (4128)
Deprecate Whitelist for IBM-cloud-databases and Introduce allowlisting (3852)
Support wait_till for cluster provisioning with normal state (4139)
Disable/Enable Rotation Policy support for kms key (4110)
Support operating_system argument for cluster workerpool creation (4133)
Update Catalog Management resources and datasoruces with latest API changes (4126)
Added support for Event streams targets (4161)
Support Public Ingress Routing for VPC routing table routes (4157)
Support VPC network acl before rule patch (4136)
Improvements to the Continuous Delivery resources and datasources for the ga release (4145)
feat(Cloud Databases): Allow users to edit configuration on database creation (4186)
Support AS prepend specific_prefixes for Direct Link (4179)
LoadBalancerPool HealthMonitor Port Nullable (4129)
Access Tags for VPC Volumes (4127)
Add tagging and access tags support for is_snapshot (4134)
Remove credential passphrase and group support from scc (4140)

Bugfixes

Fix endpoint URL via the env variable for KMS resources/datasources (4120)
Fix docs typo for cloud databases (4143)
Firewall rules Paused is not reflected only at the first execution (4142)
set subscription manager release and disable eus for Satellite host script (4175)
Wait for scaling task to complete (4188)
Update worker_pool host_labels usage and fix blank entry in array (4189)
ibm_resource_instance data source should not need resource group id (4137)
private endpoint in data resource ibm_secrets_manager_secret is incorrect (4187)
Fix: fixed pi_volume_group_action, pi_volume_group & data pi_volume_group_storage_details resources (4193)
Fix the provision failure of lbass (4197)

v1.47.1
Compare Source
BUG FIXES

Support to add retry fetch of tags using global search API's when we reach ratelimit (4125)
Fix len out of range for IBM Satellite Cluster host labels (4149)

v1.47.0
Compare Source
Features

Support for Kubernetes Service

Resources

ibm_container_vpc_worker

Support for APP Configuration

DataSources

ibm_app_config_snapshot
ibm_app_config_snapshots

Resources

ibm_app_config_snapshot

Support for DirectLink

DataSources

ibm_dl_route_reports
ibm_dl_route_report

Resources

ibm_dl_route_report
Enhancements

Update schema validation to latest schema methods (4068)
Support Private end-point for APP Configuration (4048)
supported CoreOS-enabled clusters (default worker pool) and workerPools in satellite clusters (3985)
support cos one rate plan (4092)
Fix GRE tunnel in cloud connection (4093)
support floating_bare_metal_server attribute for resource ibm_is_bare_metal_server_network_interface_allow_float (4115)
added support for catalog images for enterprises (3994)
Support rhel8 in attach script (4033)

BUG FIXES

data source: ibm_is_backup_policies, expected 'the empty list', but returned 'no BackupPolicies found' (4079)
Add fix for storage capacity & system pool output (4074)
fixes the endpoint; updates go sdk for Atracker (4073)
fix(vpn_gateway_connection): adding support to null patch ike_policy and ipsec_policy on vpn_gateway_connection (4058)
fix(bare_metal_server_network_interface_allow_float) : reordered the wait logic in bare metal nics (4101)
Update VNF Scalability NIC in docs (4047)
fix(iam-access-groups): added retry logic for access groups read (4098)
ibm_satellite_attach_host_script shows incorrect syntax for labels (4099)
fix(bm-nic): added check for 0.0.0.0 reserved ip on nic availability (4122)

v1.46.0
Compare Source
Features

Support for Power Instance

DataSources

ibm_pi_instance_action
ibm_pi_shared_processor_pool
ibm_pi_shared_processor_pools
ibm_pi_spp_placement_group
ibm_pi_spp_placement_groups

Resources

ibm_pi_shared_processor_pool
ibm_pi_spp_placement_group

Support Security and Compilance

DataSources

ibm_scc_posture_profile_import
ibm_scc_posture_scan_initiate_validation

Resources

ibm_scc_posture_scan_initiate_validation

Support App Configuration

DataSources

ibm_app_config_collection
ibm_app_config_collections
ibm_app_config_property
ibm_app_config_properties

Resources

ibm_app_config_collection
ibm_app_config_collection

Support Virtual Private Cloud

DataSources

ibm_is_instance_groups
ibm_is_bare_metal_server_network_interface_reserved_ip
ibm_is_bare_metal_server_network_interface_reserved_ips

Enhancements

Update CD Toolchain resources and datasources with latest SDK (3933)
Support uset tags in volumes of instance, instance template and volume attachement (3993)
Add replication enabled attribute in pi volume resource (4007)
Update Subnets on LoadBalancer (4026)
Support for lifecycle status and reasons in VPC instance (4017)
Support VPC reference in VPN gateway (4039)
Examples and docs updated for HPCS COS support (4034)
Deprecate connection strings for IBM-cloud-databases (4050)
Revert volume replication attribute in pi volume resource (4059)
added support for new ciphers (4018)

BUG FIXES

terraform ibm_is_instance_template volume_attachments removal from configuration not changing resource (3972)
docs in is_instance_template do not cover volume_attachments completely (3967)
Note section is not in proper format (3970)
Wrong tagging for TOC (4019)
ibm_kms_key unhelpful deprecation box (3923)
"data iam_authorization_policy" is "data iam_authorization_policies" (4015)
ibm_scc_rule vs ibm_scc_configuration_rule (3908)
ibm_cos_bucket.abort_incomplete_multipart_upload_days is undocumented (3799)
Updated Description for Deployment type EPIC (4037)
Doc corrections for resource group to intimate id and subnet floating ip changes (4025)
fix(ibm_is_vpn_gateway): reordered the setting of id in ibm_is_vpn_gateway resource to taint the resource properly (4055)
fix(docs): added details about user data and update link for ibmcloud docs (4066)

v1.45.1
Compare Source
Enhancements

Support location argument to target the respective Schematics region service (4030)

Mastercard/terraform-provider-restapi
v1.18.0
Compare Source
New

Add ability to send specific data structures when performing update and delete actions. Thanks for PR #182, @jgrumboe!

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

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


text:
ci(deps): update terraform-ibm-modules/common-pipeline-assets action to v1.16.1

This PR contains the following updates:

Package
Type
Update
Change

terraform-ibm-modules/common-pipeline-assets
action
patch
v1.16.0 -> v1.16.1

Release Notes

terraform-ibm-modules/common-pipeline-assets
v1.16.1
Compare Source
Bug Fixes

fix bug in CRA config logic (#498) (49cd1df)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

repo: terraform-ibm-modules/terraform-ibm-kms


text:
chore(deps): update common-dev-assets digest to 5a7da53

This PR contains the following updates:

Package
Update
Change

common-dev-assets
digest
ec50ee2 -> 5a7da53

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 4.0.0 :tada:
The release is available on:

GitHub release
v4.0.0

Your semantic-release bot :package::rocket:


text:
chore(deps): update terraform terraform-ibm-modules/cos/ibm to v8.5.2

This PR contains the following updates:

Package
Type
Update
Change

terraform-ibm-modules/cos/ibm (source)
module
patch
8.5.1 -> 8.5.2

Release Notes

terraform-ibm-modules/terraform-ibm-cos (terraform-ibm-modules/cos/ibm)
v8.5.2
Compare Source
Bug Fixes

update bucket DAs dependencies (#654) (e311989)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

:tada: This issue has been resolved in version 7.19.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


text:
chore(deps): update terraform github.com/terraform-ibm-modules/terraform-ibm-resource-group to v1.0.4

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/terraform-ibm-resource-group
module
patch
v1.0.2 -> v1.0.4

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox. ⚠ Warning: custom changes will be lost.

This PR has been generated by Renovate Bot.

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


text:
chore(deps): update ci dependencies

This PR contains the following updates:

Package
Type
Update
Change

common-dev-assets

digest
a958729 -> 20ea4bb

github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper
require
patch
v1.23.8 -> v1.23.9

Release Notes

terraform-ibm-modules/ibmcloud-terratest-wrapper (github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper)
v1.23.9
Compare Source
Bug Fixes

deps: update gomod (#680) (f4dbcb9)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline


text:
chore(deps): update module github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper to v1.21.2

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper
require
patch
v1.21.1 -> v1.21.2

Release Notes

terraform-ibm-modules/ibmcloud-terratest-wrapper (github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper)
v1.21.2
Compare Source
Bug Fixes

Add Outputs to test options (#640) (bfaeb70)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

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


text:
Should n2n be scaled by keff?

In globalFluxInterface.calcReactionRates, the number of neutrons produced through fission is scaled by keff to account for situations when keff isn't equal to 1.0:
https://github.com/terrapower/armi/blob/4fcea827c16b471e067fff809f775caec54e2de8/armi/physics/neutronics/globalFlux/globalFluxInterface.py#L1056-L1059
Two lines later in the same method, the number of neutrons produced through (n,2n) reactions is calculated. However, that term is not scaled by keff, even though it is a production term similar to fission.
Should the (n,2n) production rate also be scaled by keff?
Or alternatively, should the keff scaling on the fission term be removed? If the flux being used is already scaled to account for non-unity keff, then I don't think that the reaction rate should be scaled again.
Not sure which option would be correct here, but I think that the two values are being calculated inconsistently. But of course let me know if I'm wrong.

My guess is that this looks right. I imagine that DIF3D is solving "leakage + absorption = scattering + 1/keff * fission". The solver achieves equality by finding the k-eff value that forces this balance to occur; so, the fission rate (by conceptually scaling nu) is the knob that's adjusted to artificially make this happen. If k-eff is not exactly 1.0, then an adjustment was necessary to the fission rate to achieve balance. The other terms in the equation are not affected by this adjustment, such as (n,2n) reaction rate (which I am guessing is buried in the scattering term?).
After the solver is done, if you were to get the flux from the solver and multiply it by the fission XS alone, that fission rate would be wrong by a factor of 1/keff because that was the adjustment factor that was needed to achieve balance. All other edits using "flux * cross section" would be correct, though.

Agree with @Nebbychadnezzar. Extra info: n,2n production is indeed buried in the scattering term as its own special scattering matrix. The loss part of (n,2n) capture is in the absorption term. An example n,2n production matrix from an ISOTXS file may be found here.

authors: Nebbychadnezzar keckler ntouran

repo: terrapower/armi


text:
from-linear script broken due to updates in Linear Schema

Hey folks,
Thank you for taking the time out to build this.
However, the script from-linear is now breaking due to a field queried - integrationResources
Output Dump
2023/07/17 15:37:44 fetching oldest 50
2023/07/17 15:37:44 failed to fetch 50 after  (retrying in 5 minutes): 400 Bad Request: got body "{\"errors\":[{\"message\":\"Cannot query field \\\"integrationResources\\\" on type \\\"Issue\\\".\",\"locations\":[{\"line\":44,\"column\":5}],\"extensions\":{\"code\":\"GRAPHQL_VALIDATION_FAILED\",\"type\":\"graphql error\",\"userError\":true,\"meta\":{}}}]}\n"

RCA
Upon checking with the Linear GraphQL schema and their updates, I figured that the script is using the field deprecated in February 2023.
Link to Changelog
Maybe some other things are also broken but I could not move beyond trying to import issues from linear to local corpus.

Hitting same errer

repo: terrastruct/byelinear

license: ISC


text:
Add labels to Renovate PRs

Add the "bot" and "renovate" labels to PRs generated by Renovate so
we can easily differentiate them in tools that work with GitHub.
In addition, Renovate renamed the preset with the recommended
settings from base to recommended, so change the config to use
the new name.

#647  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

repo: terraware/web-components


text:
Add PermalinkUtil

This util helps creating and applying a permalink for the given map.
Reads and writes links like
http://fake?zoom=3&center=10;20&layers=peter;pan

Thanks for review!

repo: terrestris/ol-util


text:
bluetoothctl - fix scan on arguments

Remove " " wrapping "scan on".

indeed. I did test only with cached

authors: baylanger raphmur


text:
Fix: Correct onScale method signature in CKCamera.kt (again)

Summary
#559 seems to have broken a change in #551, regarding override types. This restores the fix. The app was not able to build for React Native 0.72 without this change as the signatures are different.

Thanks!

authors: elliottkember scarlac

repo: teslamotors/react-native-camera-kit


text:
asking for micr tessdata  && cmc7 font  tessdata

asking for micr tessdata  && cmc7 font  tessdata /

if any available ................

and thank
:cry:

Please use the Tesseract user forum for questions.

authors: ahmadkisswani stweil

repo: tesseract-ocr/tessdata


text:
Container.followOutput() leaks thread

Container.followOutput() uses LogUtils.attachConsumer(), which opens a long-running okhttp request and processes it using a FrameConsumerResultCallback.
The problem is that the FrameConsumerResultCallback, so it can't be closed after stopping the container, and the server side doesn't close the connection either, so the processing thread stays alive forever.
Our test suite uses an inheritable ThreadLocal to track and report thread leaks, and this is what it reports:
23:30:59,651 ERROR [TestSuiteProgress] Test failed: UNKNOWN.ThreadLeakChecker
org.infinispan.commons.test.ThreadLeakChecker$LeakException: Leaked thread: tc-okhttp-stream-1282372255 << testng-GracefulShutdownRestartIT << UNKNOWN
	at org.testcontainers.shaded.org.scalasbt.ipcsocket.UnixDomainSocketLibrary.read(Native Method) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.shaded.org.scalasbt.ipcsocket.UnixDomainSocket$UnixDomainSocketInputStream.doRead(UnixDomainSocket.java:149) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.shaded.org.scalasbt.ipcsocket.UnixDomainSocket$UnixDomainSocketInputStream.read(UnixDomainSocket.java:136) ~[testcontainers-1.12.4.jar:?]
	at java.io.FilterInputStream.read(FilterInputStream.java:133) ~[?:?]
	at org.testcontainers.dockerclient.transport.okhttp.UnixSocketFactory$1$1.read(UnixSocketFactory.java:46) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.shaded.okio.Okio$2.read(Okio.java:140) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.shaded.okio.AsyncTimeout$2.read(AsyncTimeout.java:237) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.shaded.okio.RealBufferedSource.request(RealBufferedSource.java:72) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.shaded.okio.RealBufferedSource.require(RealBufferedSource.java:65) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.shaded.okio.RealBufferedSource.readHexadecimalUnsignedLong(RealBufferedSource.java:307) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.shaded.okhttp3.internal.http1.Http1ExchangeCodec$ChunkedSource.readChunkSize(Http1ExchangeCodec.java:492) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.shaded.okhttp3.internal.http1.Http1ExchangeCodec$ChunkedSource.read(Http1ExchangeCodec.java:471) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.shaded.okhttp3.internal.connection.Exchange$ResponseBodySource.read(Exchange.java:286) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.shaded.okio.RealBufferedSource.exhausted(RealBufferedSource.java:61) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder$FramedSink.accept(OkHttpInvocationBuilder.java:363) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder$FramedSink.accept(OkHttpInvocationBuilder.java:352) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.lambda$executeAndStream$3(OkHttpInvocationBuilder.java:314) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder$$Lambda$1863/0x0000000100fd5840.run(Unknown Source) ~[?:?]
	at java.lang.Thread.run(Thread.java:834) ~[?:?]
Caused by: org.infinispan.commons.test.ThreadLeakChecker$LeakException: testng-GracefulShutdownRestartIT << UNKNOWN
	at org.infinispan.commons.test.ThreadLeakChecker$ThreadInfoLocal.childValue(ThreadLeakChecker.java:107) ~[infinispan-commons-test-11.0.0-SNAPSHOT.jar:11.0.0-SNAPSHOT]
	at org.infinispan.commons.test.ThreadLeakChecker$ThreadInfoLocal.childValue(ThreadLeakChecker.java:104) ~[infinispan-commons-test-11.0.0-SNAPSHOT.jar:11.0.0-SNAPSHOT]
	at java.lang.ThreadLocal$ThreadLocalMap.<init>(ThreadLocal.java:411) ~[?:?]
	at java.lang.ThreadLocal.createInheritedMap(ThreadLocal.java:276) ~[?:?]
	at java.lang.Thread.<init>(Thread.java:450) ~[?:?]
	at java.lang.Thread.<init>(Thread.java:709) ~[?:?]
	at java.lang.Thread.<init>(Thread.java:630) ~[?:?]
	at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.executeAndStream(OkHttpInvocationBuilder.java:319) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.executeAndStream(OkHttpInvocationBuilder.java:295) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.get(OkHttpInvocationBuilder.java:89) ~[testcontainers-1.12.4.jar:?]
	at com.github.dockerjava.core.exec.LogContainerCmdExec.execute0(LogContainerCmdExec.java:42) ~[testcontainers-1.12.4.jar:?]
	at com.github.dockerjava.core.exec.LogContainerCmdExec.execute0(LogContainerCmdExec.java:12) ~[testcontainers-1.12.4.jar:?]
	at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.execute(AbstrAsyncDockerCmdExec.java:56) ~[testcontainers-1.12.4.jar:?]
	at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.exec(AbstrAsyncDockerCmdExec.java:21) ~[testcontainers-1.12.4.jar:?]
	at com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.exec(AbstrAsyncDockerCmdExec.java:12) ~[testcontainers-1.12.4.jar:?]
	at com.github.dockerjava.core.command.AbstrAsyncDockerCmd.exec(AbstrAsyncDockerCmd.java:21) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.utility.LogUtils.attachConsumer(LogUtils.java:99) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.utility.LogUtils.followOutput(LogUtils.java:36) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.utility.LogUtils.followOutput(LogUtils.java:51) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.containers.Container.followOutput(Container.java:391) ~[testcontainers-1.12.4.jar:?]
	at java.util.ArrayList.forEach(ArrayList.java:1540) ~[?:?]
	at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:412) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.containers.GenericContainer.lambda$doStart$0(GenericContainer.java:317) ~[testcontainers-1.12.4.jar:?]
	at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:81) ~[duct-tape-1.0.8.jar:?]
	at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:315) ~[testcontainers-1.12.4.jar:?]
	at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:302) ~[testcontainers-1.12.4.jar:?]
	at org.infinispan.server.test.ContainerInfinispanServerDriver.start(ContainerInfinispanServerDriver.java:146) ~[test-classes/:?]
	at org.infinispan.server.test.InfinispanServerDriver.start(InfinispanServerDriver.java:109) ~[test-classes/:?]
	at org.infinispan.server.test.InfinispanServerRule$1.evaluate(InfinispanServerRule.java:86) ~[test-classes/:?]

Sorry that we’ve not had a chance to look into this yet. Let’s reopen.

@rnorth actually, it should be moved to docker-java now :)

I forgot about this issue, because I had modified our tests to ignore any tc-okhttp-stream-.* thread leaks.
The good news first: upgrading to testcontainers 1.15.0-rc1 (which includes docker-java 3.2.5) fixed the leak.
The bad news is that there is still a thread leak, with a new thread name pattern: docker-java-stream--.*. It appears because calling DockerClientFactory.instance().client() creates a Ryuk container, and a log callback to monitor the progress of Ryuk in case it fails to start that needs a thread, but closing the log callback does not stop the thread:
org.infinispan.commons.test.ThreadLeakChecker$LeakException: Leaked thread: docker-java-stream--98336395 << testng-InfinispanRuleBasicTest << org.infinispan.server.test.junit4.InfinispanRuleBasicTest
	at app//org.testcontainers.shaded.com.github.dockerjava.okhttp.UnixDomainSocket.recv(Native Method)
	at app//org.testcontainers.shaded.com.github.dockerjava.okhttp.UnixDomainSocket$UnixSocketInputStream.read(UnixDomainSocket.java:250)
	at java.base@11.0.7/java.io.FilterInputStream.read(FilterInputStream.java:133)
	at app//org.testcontainers.shaded.com.github.dockerjava.okhttp.UnixSocketFactory$1$1.read(UnixSocketFactory.java:45)
	at app//org.testcontainers.shaded.okio.Okio$2.read(Okio.java:140)
	at app//org.testcontainers.shaded.okio.AsyncTimeout$2.read(AsyncTimeout.java:237)
	at app//org.testcontainers.shaded.okio.RealBufferedSource.request(RealBufferedSource.java:72)
	at app//org.testcontainers.shaded.okio.RealBufferedSource.require(RealBufferedSource.java:65)
	at app//org.testcontainers.shaded.okio.RealBufferedSource.readHexadecimalUnsignedLong(RealBufferedSource.java:307)
	at app//org.testcontainers.shaded.okhttp3.internal.http1.Http1ExchangeCodec$ChunkedSource.readChunkSize(Http1ExchangeCodec.java:492)
	at app//org.testcontainers.shaded.okhttp3.internal.http1.Http1ExchangeCodec$ChunkedSource.read(Http1ExchangeCodec.java:471)
	at app//org.testcontainers.shaded.okhttp3.internal.connection.Exchange$ResponseBodySource.read(Exchange.java:286)
	at app//org.testcontainers.shaded.okio.RealBufferedSource$1.read(RealBufferedSource.java:436)
	at app//org.testcontainers.shaded.com.github.dockerjava.core.FramedInputStreamConsumer.accept(FramedInputStreamConsumer.java:30)
	at app//org.testcontainers.shaded.com.github.dockerjava.core.FramedInputStreamConsumer.accept(FramedInputStreamConsumer.java:12)
	at app//org.testcontainers.shaded.com.github.dockerjava.core.DefaultInvocationBuilder.lambda$executeAndStream$1(DefaultInvocationBuilder.java:275)
	at app//org.testcontainers.shaded.com.github.dockerjava.core.DefaultInvocationBuilder$$Lambda$181/0x00000008402da440.run(Unknown Source)
	at java.base@11.0.7/java.lang.Thread.run(Thread.java:834)
Caused by: org.infinispan.commons.test.ThreadLeakChecker$LeakException: testng-InfinispanRuleBasicTest << org.infinispan.server.test.junit4.InfinispanRuleBasicTest
	at org.infinispan.commons.test.ThreadLeakChecker$ThreadInfoLocal.childValue(ThreadLeakChecker.java:111)
	at org.infinispan.commons.test.ThreadLeakChecker$ThreadInfoLocal.childValue(ThreadLeakChecker.java:108)
	at java.base/java.lang.ThreadLocal$ThreadLocalMap.<init>(ThreadLocal.java:411)
	at java.base/java.lang.ThreadLocal.createInheritedMap(ThreadLocal.java:276)
	at java.base/java.lang.Thread.<init>(Thread.java:450)
	at java.base/java.lang.Thread.<init>(Thread.java:709)
	at java.base/java.lang.Thread.<init>(Thread.java:582)
	at org.testcontainers.shaded.com.github.dockerjava.core.DefaultInvocationBuilder.executeAndStream(DefaultInvocationBuilder.java:280)
	at org.testcontainers.shaded.com.github.dockerjava.core.DefaultInvocationBuilder.get(DefaultInvocationBuilder.java:66)
	at org.testcontainers.shaded.com.github.dockerjava.core.exec.LogContainerCmdExec.execute0(LogContainerCmdExec.java:42)
	at org.testcontainers.shaded.com.github.dockerjava.core.exec.LogContainerCmdExec.execute0(LogContainerCmdExec.java:12)
	at org.testcontainers.shaded.com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.execute(AbstrAsyncDockerCmdExec.java:56)
	at org.testcontainers.shaded.com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.exec(AbstrAsyncDockerCmdExec.java:21)
	at org.testcontainers.shaded.com.github.dockerjava.core.exec.AbstrAsyncDockerCmdExec.exec(AbstrAsyncDockerCmdExec.java:12)
	at org.testcontainers.shaded.com.github.dockerjava.core.command.AbstrAsyncDockerCmd.exec(AbstrAsyncDockerCmd.java:21)
	at org.testcontainers.utility.ResourceReaper.start(ResourceReaper.java:101)
	at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:197)
	at org.infinispan.server.test.core.ContainerInfinispanServerDriver.getDockerBridgeAddress(ContainerInfinispanServerDriver.java:86)
	at org.infinispan.server.test.core.ContainerInfinispanServerDriver.<init>(ContainerInfinispanServerDriver.java:79)
	at org.infinispan.server.test.core.ServerRunMode$2.newDriver(ServerRunMode.java:17)
	at org.infinispan.server.test.core.TestServer.initServerDriver(TestServer.java:139)
	at org.infinispan.server.test.junit4.InfinispanServerRule$1.evaluate(InfinispanServerRule.java:67)
	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
	at org.testng.junit.JUnit4TestRunner.start(JUnit4TestRunner.java:82)
	at org.testng.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:70)
	at org.testng.TestRunner$1.run(TestRunner.java:570)
	at org.testng.TestRunner.runJUnitWorkers(TestRunner.java:717)
	at org.testng.TestRunner.privateRunJUnit(TestRunner.java:601)
	at org.testng.TestRunner.run(TestRunner.java:502)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:455)
	at org.testng.SuiteRunner.access$000(SuiteRunner.java:40)
	at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:489)
	at org.testng.internal.thread.ThreadUtil$1.call(ThreadUtil.java:52)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	... 1 more
Caused by: org.infinispan.commons.test.ThreadLeakChecker$LeakException: org.infinispan.server.test.junit4.InfinispanRuleBasicTest

I'm not sure if it's a testcontainers issue or a docker-java issue, but since it's a single thread I'm ok ignoring the new thread name pattern for now.

@danberindei Thanks for the update! I re-opened the issue so that we remember to investigate Ryuk's leak 👍

I am seeing this issue as well

authors: bsideup danberindei eastlondoner rnorth

repo: testcontainers/testcontainers-java

license: mit


text:
Symfony 3.4 compatibility

Hello, is this bundle compatible with 3.4? Thanks 😃

Yes it is but in the config.yml file you have to use the twig namespace syntax :
use this
twig;
    form_themes:
        - '@TetranzSelect2Entity/Form/fields.html.twig'

instead of
twig:
    form_themes:
        - 'TetranzSelect2EntityBundle:Form:fields.html.twig'

The doc should be update.

authors: bettinz sbnet


text:
Deprecate autotools and fix versioning, build with MinGW

Now CMake loads the version from TRAVIS_TAG, git describe --always or local .version.
Implementation of discussion in #431, for v.2.0.0
@texane what do you think? Could you review-merge?

Does it still compile on Windows with Mingw32 ? Does not look so
to me (ie. doc/mingw.md). I agree to remove autotools, but all the
currently supported systems must work and the corresponding
doc be up to date.
Appart from that, looks fine to me.
2016-06-18 16:24 GMT+02:00 Jerry Jacobs notifications@github.com:

Now CMake loads the version from TRAVIS_TAG, git describe --always or
local .version.
Implementation of discussion in #431
https://github.com/texane/stlink/issues/431, for v.2.0.0
@texane https://github.com/texane what do you think? Could you
review-merge?
You can view, comment on, or merge this pull request online at:
https://github.com/texane/stlink/pull/434
Commit Summary

Deprecate autotools and load version from TRAVIS_TAG, git command or
local .version file

File Changes

M .travis.sh
https://github.com/texane/stlink/pull/434/files#diff-0 (21)
M .travis.yml
https://github.com/texane/stlink/pull/434/files#diff-1 (11)
A .version https://github.com/texane/stlink/pull/434/files#diff-2
(1)
D ACKNOWLEDGMENTS
https://github.com/texane/stlink/pull/434/files#diff-3 (2)
D AUTHORS https://github.com/texane/stlink/pull/434/files#diff-4
(19)
M CMakeLists.txt
https://github.com/texane/stlink/pull/434/files#diff-5 (72)
D COPYING https://github.com/texane/stlink/pull/434/files#diff-6
(27)
M ChangeLog
https://github.com/texane/stlink/pull/434/files#diff-7 (9)
D Makefile.am
https://github.com/texane/stlink/pull/434/files#diff-8 (59)
D NEWS https://github.com/texane/stlink/pull/434/files#diff-9
(0)
D README https://github.com/texane/stlink/pull/434/files#diff-10
(335)
D README.md
https://github.com/texane/stlink/pull/434/files#diff-11 (1)
A README.md
https://github.com/texane/stlink/pull/434/files#diff-12 (251)
D TODO.md https://github.com/texane/stlink/pull/434/files#diff-13
(11)
D autogen.sh
https://github.com/texane/stlink/pull/434/files#diff-14 (2)
D configure.ac
https://github.com/texane/stlink/pull/434/files#diff-15 (59)
R doc/build_mingw.md
https://github.com/texane/stlink/pull/434/files#diff-16 (3)
A doc/release.md
https://github.com/texane/stlink/pull/434/files#diff-17 (10)
D src/tools/gui/Makefile.am
https://github.com/texane/stlink/pull/434/files#diff-18 (30)
M src/usb.c
https://github.com/texane/stlink/pull/434/files#diff-19 (2)

Patch Links:

https://github.com/texane/stlink/pull/434.patch
https://github.com/texane/stlink/pull/434.diff

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/texane/stlink/pull/434, or mute the thread
https://github.com/notifications/unsubscribe/AAEeHz3E5Sz3hMsU-qYDgcVhIakPieS9ks5qM_-GgaJpZM4I49RN
.

OK. We will wait for the merge then. Thanks for your work !
2016-06-18 16:37 GMT+02:00 Jerry Jacobs notifications@github.com:

I totaly agree, I have forgotten to update the documentation. I also will
add a linux mingw build so we can see it compiles as windows target
platform. I must investigate how it behaves on windows-os itself and try
with app-veyor and mingw. As you know, autotools under windows is a pain in
the ass.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/texane/stlink/pull/434#issuecomment-226945752, or mute
the thread
https://github.com/notifications/unsubscribe/AAEeH63exr_BCGBSsTpveeQmXKaw_9-lks5qNAK7gaJpZM4I49RN
.

With appveyor with some time and effort we can build visual studio and mingw builds under windows systems. But for now I will stick with only mingw because I have seen #include <unistd.h> which is totaly not native windows.

It almost works, but I have forgotten i need libusb -_-":
https://ci.appveyor.com/project/xor-gate/stlink/build/job/t0roxh150had32im

Finaly it eats libusb, but there are people who did break the tooling to build at windows completely:
https://ci.appveyor.com/project/xor-gate/stlink/build/7/job/8kmopkqgxmxhlham#L197
[ 56%] Linking C executable st-flash.exe
libstlink.a(common.c.obj): In function `map_file':
c:/projects/stlink/src/common.c:957: undefined reference to `mmap'
libstlink.a(common.c.obj): In function `unmap_file':
c:/projects/stlink/src/common.c:975: undefined reference to `munmap'
collect2.exe: error: ld returned 1 exit status

@texane, it took me more time then expected to integrate with AppVeyor MSYS Makefile generator project. I have it now building for 32 and 64 bit systems. I still need to update the documentation. What do you think?
Important: I would like you to activate AppVeyor integration for texane/stlink with the config file pointing to custom path: .appveyor.yml. Would you like to do this. For me it would be better to move stlink project into a separate organisation so the integrations don't impact your own account and you don't need to configure (sometimes complex) continues integration/continues deployment.
The Pro of having a separate organisation would also be when in the upcoming time I will push binary releases from Travis CI and AppVeyor CI into github/bintray we need to have deployment keys which need to configured. Also for my own stlink continues integration setup I would like to add extra code coverage output (so we know most targets, and all flash loader variants work).
Thank you for your time.
Let me know how we can continue to extent and ease the first-time users and existing users.

Hi,
regarding the Windows support, let me know when the documentation is
updated and we will merge. Thanks for that !
It is good to  add some support for continuous integration, but I do not
want
it to drive important decisions such as changing the project organization,
or
put constraints on the maintainers personal accounts.
2016-06-19 9:04 GMT+02:00 Jerry Jacobs notifications@github.com:

@texane https://github.com/texane, it took me more time then expected
to integrate with AppVeyor MSYS Makefile generator project. I have it now
building for 32 and 64 bit systems. I still need to update the
documentation. What do you think?
Important: I would like you to activate AppVeyor integration for
texane/stlink with the config file pointing to custom path: .appveyor.yml.
Would you like to do this. For me it would be better to move stlink project
into a separate organisation so the integrations don't impact your own
account and you don't need to configure (sometimes complex) continues
integration/continues deployment.
The Pro of having a separate organisation would also be when in the
upcoming time I will push binary releases from Travis CI and AppVeyor CI
into github/bintray we need to have deployment keys which need to
configured. Also for my own stlink continues integration setup I would like
to add extra code coverage output (so we know most targets, and all flash
loader variants work).
Thank you for your time.
Let me know how we can continue to extent and ease the first-time users
and existing users.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/texane/stlink/pull/434#issuecomment-226983031, or mute
the thread
https://github.com/notifications/unsubscribe/AAEeH-JD0CMMDHgibk-4kOYLNpD_9Ve9ks5qNOoYgaJpZM4I49RN
.

@texane I have updated the build instructions and added a build helper for windows. Now we only need a MinGW64 gcc toolchain without MSYS. I have tested this myself and it compiles and runs. For some reason there are some issues with device-claim under windows (but that is a different question to fix):
C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --serial
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
303636454646343835353530373535

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --descr
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
L4 device

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --flash
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
0xzx

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --sram
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
0xzx

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --probe
Found zu stlink programmers

Thanks !
2016-06-20 17:01 GMT+02:00 Jerry Jacobs notifications@github.com:

@texane https://github.com/texane I have updated the build instructions
and added a build helper for windows. Now we only need a MinGW64 gcc
toolchain without MSYS. I have tested this myself and it compiles and runs.
For some reason there are some issues with device-claim under windows (but
that is a different question to fix):
C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --serial
libusb: error [init_device] device '\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
303636454646343835353530373535
C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --descr
libusb: error [init_device] device '\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
L4 device
C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --flash
libusb: error [init_device] device '\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
0xzx
C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --sram
libusb: error [init_device] device '\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
0xzx
C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --probe
Found zu stlink programmers
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/texane/stlink/pull/434#issuecomment-227168784, or mute
the thread
https://github.com/notifications/unsubscribe/AAEeH550Nx1iHbA3UBYT5zP_3XDOTvQWks5qNqtbgaJpZM4I49RN
.

I have seen working AppVeyor and Travis with the stlink/stlink, so when this is happen to be merged and everything is in place you may disable integration for your account. Keep in mind, that no pull requests are build then.

I will, thanks
2016-06-20 20:25 GMT+02:00 Jerry Jacobs notifications@github.com:

I have seen working AppVeyor and Travis with the stlink/stlink, so when
this is happen to be merged and everything is in place you may disable
integration for your account. Keep in mind, that no pull requests are build
then.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/texane/stlink/pull/434#issuecomment-227226850, or mute
the thread
https://github.com/notifications/unsubscribe/AAEeH1S_oNU9fi9Tde3XOoqtq1CvOlMBks5qNtsJgaJpZM4I49RN
.

Some days have passed, another contributor updated the CMake files in PR #444 but first this should be merged. Then PR #444 could rebased on this.

I will be on vacations for the next 2 weeks. Will take a look when coming
back.
2016-07-13 21:14 GMT+02:00 Jerry Jacobs notifications@github.com:

Some days have passed, another contributor updated the CMake files in PR
#444 https://github.com/texane/stlink/pull/444 but first this should be
merged. Then PR #444 https://github.com/texane/stlink/pull/444 could
rebased on this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/texane/stlink/pull/434#issuecomment-232457554, or mute
the thread
https://github.com/notifications/unsubscribe/AAEeHz6My-h8k56BnimDWFtSf73ph9neks5qVTkSgaJpZM4I49RN
.

As discussed some time ago, we will be moving away from autotools. As people get confused and makes issue solving problematic. If there are any questions with cmake or the build system, don't hesitate to open a issue new issue for further discussion.

Hi Jerry,
could we take this discussion back ?
As I understand, there are 3 topics to be discussed:
. Moving away from autotools: seems OK to me, but still has
to build on all the platforms currently supported, without loss
of quality as regard with what is currently provided.
. Windows support: still has to work. Can't we just take the
currently generated MSYS Makefile and live with them ? We
do not often change these, do not have to be generated at
every pull request.
. Adding a third party service to ease the Windows build: it
does not seem justified to me, esp. regarding the impact it
has on the project or owner accounts, as discussed earlier.
So my answer to this point is definitely no.
I hope we will make some progress,
2016-08-03 20:15 GMT+02:00 Jerry Jacobs notifications@github.com:

As discussed some time ago, we will be moving away from autotools. As
people get confused and makes issue solving problematic. If there are any
questions with cmake or the build system, don't hesitate to open a issue
new issue for further discussion.
I have merged myself as I know you sometimes are short in time, I try to
make good decisions which always can be discussed beforehand.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/texane/stlink/pull/434#issuecomment-237321187, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEeH5TawhtKmbv2Z0dNJXcc84xzzSKdks5qcNq_gaJpZM4I49RN
.

I will comment on the following points:

No quality is lost, it is even enforced on multiple platforms (Linux, MinGW, Mac OS). By using multiple compilers and environments.
The windows build is working with CMake and I have put a few hour effort to make it compile again. Generating static build files and putting it aside cmake is double and will confuse people again. We are unable with static build files to compile to multiple targets: Debug (debug symbols and coverage, Release (stripped from cruft for easier distribution).
I understand, but how can you guarantee "quality/working" as mentioned in point 1 without continues integration?

2016-08-04 9:09 GMT+02:00 Jerry Jacobs notifications@github.com:

I will comment on the following points:

No quality is lost, it is even enforced on multiple platforms
(Linux, MinGW, Mac OS). By using multiple compilers and environments.

OK

The windows build is working with CMake and I have put a few hour
effort to make it compile again. Generating static build files and putting
it aside cmake is double and will confuse people again. We are unable with
static build files to compile to multiple targets: Debug (debug symbols and
coverage, Release (stripped from cruft for easier distribution).

Just to understand: building on Windows works fine with CMake. If that is
so,
we can drop autotools then ...

I understand, but how can you guarantee "quality/working" as
mentioned in point 1 without continues integration?

As we did in the past: if the build fails on a platform, users will report
it. We
have the same problem to functionally test that a pull request wont break a
target, and it works fine.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/texane/stlink/pull/434#issuecomment-237471139, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEeHxqmVsWVhvwxvmgLxNoP79IBzlXSks5qcZAsgaJpZM4I49RN
.

authors: texane xor-gate

repo: texane/stlink


text:
why I can see all secret shares in one party?

I don't know if i use this framework correctly.but  i think this problem really confused me.
such as an example: examples/application/simple-average/run-remote.sh
firstly, i comment out the last line:
secondly, i run run-remote.sh,
thirdly,I use pycharm  debug  'run.py',
and then i can see all secret shares of input's element,

obviously,i can reconstruct the input according ot the secret shares,and it is not secure.
I wander if i didn't use it correctly,could you please solve this confusion?thanks!

I think some party should know only a part of secret shares or nothing,and no party can know all secret shares.
but May be i don't understand the design principle of tf-encrypted

You are right, some party should know only a part of secret shares or nothing. Unfortunately, there is no access control in tf-encrypted, and mainly because tensorflow doesn't have one. You could see share0 and share1 are on different devices, but the master device(process run run.py) still can access them, there is no access control. We don't have a solution for this problem without modifying source code of tensorflow until now, so we suggest not to use tf-encrypted for production purpose.

OK,Thanks for your answer!

authors: huajinghua zjn-code

repo: tf-encrypted/tf-encrypted


text:
Heroku Support

Hi, I checked a lot of bots that are not working for Dailymotion but only yours is working. Can you please make it possible to deploy to Heroku? As I know nothing python so it's not possible for me to add Heroku support. I don't want to abuse the bot hosted by yourself 😅

Check it here?
https://devcenter.heroku.com/articles/getting-started-with-python

How about a deployable button in your repo?

Do you have any example for this button? It would be better if there's any hints or tutorials.

Check this repo
https://github.com/ysfchn/SamFetch

It's working now - please apply your own app_id and app_hash at https://my.telegram.org/apps and deploy to heroku.

authors: BennyThink UsamaKarim

repo: tgbot-collection/ytdl-bot


text:
upsert bug?

When saving a bookshelf record more than one time but with same id, it fails with a postgre sql error:
Unhandled rejection error: insert into "article" ("reference", "title") values ($1, $2) returning "reference" - duplicate key value violates unique constraint "article_reference_unique"
[...]

I prepared a sample for reproducing this issue: https://github.com/strarsis/bookshelf-upsert-issue

UPSERT was added to PostgreSQL in version 9.5 but the sample reproduction code is using v9.1. I believe you're not allowed to insert any records with the same unique id more than once in v9.1.

Thank you for looking into this issue.
Now I tried this also with 9.5/9.6/latest postgres version, but I still get the same error.
You can clone and try it here: https://github.com/strarsis/bookshelf-upsert-issue/tree/postgres_latest

So this issue also persists with a recent postgresql server.
How can I further debug this?

So the reason why this fails is that upsert isn't even implemented in underlying knex yet: https://github.com/tgriesser/knex/issues/54

authors: dmlittle strarsis

repo: tgriesser/bookshelf


text:
BUG: Having doesn't work with function as column

See this runkit for a quick example: https://runkit.com/friend0/59e6fa9e8caff40012a0c1cd
var knex = require("knex")({client: 'pg'})
const query = knex.select().from('A').groupBy('count').having(function (){
    return this.having('1', '=', 'null')
})

console.log(query.toString());

const query1 = knex.select().from('A').groupBy('count').where(function (){
    return this.where('1', '=', 'null')
})

console.log(query1.toString());

Produces:
>>> "select * from \"A\" group by \"count\""
>>> "select * from \"A\" where (\"1\" = 'null') group by \"count\""

I expected:
>>> "select * from \"A\" group by \"count\"" having (\"1\" = 'null')
>>> "select * from \"A\" where (\"1\" = 'null') group by \"count\""

(the queries are non-sense, of course)
where accepts a function as parameter for composing complex sequences.
having, it appears, also supports this (poking through the source, doesn't seem to be documented) but doesn't produce the query I'd expect. Am I doing something wrong, or is this a bug I should look into?
This issue appear to be long-lived, but wasn't tagged well. https://github.com/tgriesser/knex/issues/1771

Thanks for the excellent report! This like many other place in knex certainly needs more complete tests to check that all the parameters are accepted as they should be.

No problem :)
I can take a look at this - seems like the implementation should mirror what happens with where.
Will report back and PR if I can figure it out.

Why are you using .having with a callback function? I didn't spot it in
the docs.
if you:
knex.select().from('A').having('1', '=', 'null').groupBy('count')

will result into
"select * from \"A\" group by \"count\" having \"1\" = 'null'"

Isn't that what you're looking for?
On Wed, Oct 18, 2017 at 8:05 AM, Ryan notifications@github.com wrote:

See this runkit for a quick example: https://runkit.com/friend0/
59e6fa9e8caff40012a0c1cd
var knex = require("knex")({client: 'pg'})
const query = knex.select().from('A').groupBy('count').having(function (){
return this.having('1', '=', 'null')
})
console.log(query.toString());
const query1 = knex.select().from('A').groupBy('count').where(function (){
return this.where('1', '=', 'null')
})
console.log(query1.toString());
Produces:

"select * from "A" group by "count""
"select * from "A" where ("1" = 'null') group by "count""

I expected:

"select * from "A" group by "count"" having ("1" = 'null')
"select * from "A" where ("1" = 'null') group by "count""

(the queries are non-sense, of course)
where accepts a function as parameter for composing complex sequences.
having, it appears, also supports this (poking through the source,
doesn't seem to be documented) but doesn't produce the query I'd expect. Am
I doing something wrong, or is this a bug I should look into?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tgriesser/knex/issues/2274, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJBTN4z54TM-tzwFdPPJtORI2kjRryYks5staM1gaJpZM4P9PzS
.

--
Rui Pedro Lima

Why are you using '.having' with a callback function? I didn't spot it in
the docs.
if you:
knex.select().from('A').having('1', '=', 'null').groupBy('count')

will result into
select * from \"A\" group by \"count\" having \"1\" = 'null'

Isn't that what you're looking for?

Right, it’s not in the docs, but the piping is there in the source. I realize that this can be accomplished as you wrote, but should also work with a callback. Also, I will not be composing queries by hand, rather my queries will be built using come custom objects. Having the callback makes my code much cleaner, and I don’t need special logic and raw statements to wrap my expressions in parentheses correctly.

Utilizing undocumented features is normally frowned upon, but regardless I agree this should probably be fixed.

Using function syntax is fundamental feature in knex to be able to group ands and ors in a way that parenthesis are set right. Wouldn’t hurt to have that documented also for having.

@friend0 @elhigu I just ran into this issue. I was going to attempt a PR when I realized that it does work, except that you have to use where within the having callback. There is a test for it here, where you can clearly see the weirdness: https://github.com/tgriesser/knex/blob/master/test/unit/query/builder.js#L1393-L1404
I have to imagine that was an accident? If so, there is an easy fix. Change 'where' to 'having' here: https://github.com/tgriesser/knex/blob/master/src/query/compiler.js#L325
I would make this change but I'm not sure if you want to since people might be relying on the where behavior now. Could be considered a breaking change.

@aldeed  Huh, it indeed looks like an intended behavior :o I think it would be just easiest to document current functionality of nested having for now and not touch it.

repo: tgriesser/knex


text:
Factors bluebird out of the cli module.

Begins to address #1588.
Also of note:

The readFile and writeFile functions I've defined can be replaced with util.promisify wrapped fs.readFile and fs.writeFile any time after Node 6 is no longer supported.

Now that I think of this dropping bluebird from here is actually harmful instead of helpful.
This change would need another round of cleanup when node 6 support is dropped and since bluebird dependency is already dropped from here it will be harder to remember to clean this up later on.
So benefit of this change is now pretty much zero and drawbacks are that we might forget to clean this up later on.
I'd rather fix this and all other places where bluebird is used at the same time when Bluebird dep is remove or after we drop support for node 6 (next April).
I'll try to open discussion again about schedule when to go forward with dropping bluebird.

Unfortunate, but understood. I will return next April.

Indeed. I'm sorry for your trouble.

authors: elhigu qubyte


text:
Add support for Eleven (aka stock LineageOS player)

I got this app off f-droid, but it doesn't detect the stock music app. I'd rather not install another one, so I hope support can be added at some point.

Forgot I made this issue. At some point it started working. Not sure if there was a problem on my end before, or if support was silently added. Anyway, closing this issue.

repo: tgwizard/sls