WIREFRAME: Manual Drone Control

Parent Epic: GUI_V2 #31
REPEATABLE
Multiple people can work on this story. Once a wireframe is completed, post it for discussion in the wireframes channel on the club discord.
Background
See the parent story for general details on the replacement GUI. We need a screen from which the user will be able to pilot the drone. The primary purpose of this functionality is to be able to test programmatically controlling the drone outside of brainwave piloting. The current MVP_GUI uses a button system:

The wireframe does not need to be similar to this button layout. It could use a joystick or some other control method. There is also an option to connect to the drone camera that is not implemented in the MVP version and could be in the improved version. In the lab, there are several different drone control apps available from the lab phones that can be used for alternative ideas on a piloting options.
Business Requirements
Users can manually pilot a drone with the application.
Technical Requirements
Using Figma create a wireframe with your design idea for the manual piloting screen. The options for the design are open ended, and the wireframing will also serve as brainstorming and opportunity for UI/UX discussion.

There needs to be an ability to trigger connecting to the drones's wifi.
Drone commands we need to be able to test:

Takeoff
Land
Up
Down
Rotate Counterclockwise
Rotate Clockwise
Left
Right
Forward
Backward
Flip

Acceptance Criteria

A wireframe is created in Figma.
The wireframe includes some ability for the user of this screen to interact with all required drone command functionalities.

For Midterm/Bounty submit a PR with a file to a directory named Wireframes

GUI is improved: new version uses tabs.


January Endgame

Endgame Schedule

January 23 Code freeze for the endgame
Febuary 1 Endgame done

Endgame Week
Monday, January 23

[x] Code freeze at 2am CET / 5pm PT
[x] All test items contain sufficiently comprehensive test descriptions by 3am CET / 6pm PT
[x] Ensure we have a green build on all platforms

Tuesday, January 24

[x] Test build starts at 7am CET / 10pm PT Monday
[x] Test plan ready by 8am CET / 11pm PT Monday
[x] Testing

Wednesday, January 25

[x] Morning issue triage
[x] Testing, Fixing
[x] Verification Since there are quite some old bugs to verify we verify by age, youngest first. The queries are:

Verification needed
Issues To Verify

Thursday, January 26

[x] Fixing last issues
[x] Verification
[x] Add/update shrink-wrap files for built-in extensions if needed (see instructions)  - endgame master
[x] Run OSS tool after merging shrink-wrap findings - endgame master

The LCA review of the ThirdPartyNotices.txt files is not needed anymore

[x] Check new OSS usage is entered into the OSS registry - endgame master

Friday, January 27

[x] Acknowledge Pull Requests in release notes. - endgame master
[x] Satellite modules/npm packages ready, version updated, smoke tested, PRs acknowledged

[x] vscode @bpasero
[x] vscode-generator-code @aeschli
[x] vsce @joaomoreno
[x] node debug @weinand

[x] Translation input - @dbaeumer
[x] Smoketest

[x] Windows - @dbaeumer
[x] OS X - @sandy081
[x] Linux - @joaomoreno

[x] Update the Release Notes (including notable fixes) and documentation.

[x] @alexandrudima
[x] @weinand
[x] @chrmarti
[x] @tyriar
[x] @dbaeumer
[x] @bpasero
[x] @egamma
[x] @isidorn
[x] @joaomoreno
[x] @jrieken
[x] @kieferrm
[x] @aeschli
[x] @rebornix
[x] @ramya-rao-a
[x] @roblourens
[x] @sandy081
[x] @mjbvz
[x] @mousetraps

[x] Freeze insider builds - endgame master
[x] Branch code to release/<x.y> and release master - endgame master
[x] Bump up the version in package.json - endgame master

Stabilisation Week: Jan 30 to Feb 3
Preparation

[x] Polish release notes @gregvanl
[x] Merge translations @dbaeumer
[x] Build stable - endgame master
[x] Smoketest stable, sanity check all release bits

[x] Windows - @jrieken
[x] OS X - @isidorn
[x] Linux - @aeschli

Release

[x] Tag the release: x.y.z - endgame master
[x] Unfreeze insider channel - endgame master
[x] Publish website @gregvanl
[x] Release stable
[x] Tweet about the release - @seanmcbreen

done!

This update is really incredible, great work everyone!


Update UG/DG for undo and load commands

Update UG/DG for undo and load commands

Codecov Report
Patch and project coverage have no change.

Comparison is base (94226ca) 59.25% compared to head (2d29608) 59.25%.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #158   +/-   ##
=========================================
  Coverage     59.25%   59.25%
  Complexity      528      528
=========================================
  Files           108      108
  Lines          2069     2069
  Branches        217      217
=========================================
  Hits           1226     1226
  Misses          760      760
  Partials         83       83

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Solve legibility for About Show and Press Release

type currently too small but some of those press releases are also very long. Suggestion to pull out the show description make the type larger, truncate the press release

@orta

OK, we're good here now :+1:


Fixing integration tests for ServicesTab

Note: Tabs are no longer present (Services|Deployments), hence the deleted test.

LGTM let's merge it.


Add source suggestions to admin interface

Currently there is a source suggestion that was added without a valid pubmed citation.  This will be fixed in the interface to avoid in the future, but it would be nice to be able to delete such entries...

Related issue in civic-client: https://github.com/genome/civic-meeting/issues/24


AST traversal to typecheck and add types to nodes

This means we need some kind of hashmap that maps AstNodeId -> TyId (potentially also ValueId) that is one of the outputs of the typechecking stage.


Legacy: Type declarations are broken in 4.0

Ive tested 4.0.189 from NPM and noticed that the type declaration file is broken for legacy with this version.

Error:
Could not find a declaration file for module 'pdfjs-dist/legacy/build/pdf.mjs'

The fix is simple. pdfjs-dist/legacy/build/pdf.d.ts should be renamed to pdfjs-dist/legacy/build/pdf.mjs.d.ts.

The file name should be  pdf.d.mts, not pdf.mjs.d.ts.
See https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/FalseCJS.md

A .d.mts file represents a .mjs file which is always an ES module; a .d.cts file represents a .cjs file which is always a CommonJS module; a .d.ts file represents a .js file whose module format is determined by the nearest package.json.


fix The NodeChannel should be canceled when failed to add block

Proposed changes
F20240704 15:35:33.724236 2556376 vtablet_writer.cpp:614] Check failed: block.rows() == request->tablet_ids_size() block rows: 12192, tablet_ids_size: 8128
*** Check failure stack trace: ***
@     0x5612d9ebf696  google::LogMessage::SendToLog()
@     0x5612d9ebc0e0  google::LogMessage::Flush()
@     0x5612d9ebfed9  google::LogMessageFatal::~LogMessageFatal()
@     0x5612d96a1770  doris::vectorized::VNodeChannel::try_send_pending_block()
@     0x5612d0541e98  doris::ThreadPool::dispatch_thread()
@     0x5612d0537251  doris::Thread::supervise_thread()
@     0x7f02d4061ac3  (unknown)
@     0x7f02d40f3850  (unknown)
@              (nil)  (unknown)
The reason for this issue is due to a failed return from append_to_block_by_selector. The reason for the failure here is that the memory exceeded the limit. The previous column append was successful, while the subsequent columns failed to allocate memory. The failure was directly returned from here, and the subsequent _cur_add_block_request was not executed.
However, if the NodeChannel is not cancelled, the next add block will succeed, causing the block's rows to have an additional batch size (4064) compared to the tablet id's size, ultimately triggering the failure of the check.

run buildall


A more useful DisposableStack constructor, or DisposableStack.of

If I'm reading it correctly, there's currently no way to create a DisposableStack which owns certain resources in a single step - instead, you have to make a stack and then .use things.
That seems kind of awkward for a lot of common cases. For example, imagine you're acquiring two locks, then performing some other work, then transferring ownership of those locks to someone else (if the other work succeeds):
{
  using stack = new DisposableStack();
  stack.use(getLock1());
  stack.use(getLock2());
  doOtherWork();
  transfer(stack.move());
}

This is exacerbated because the use method returns its argument, rather than (as for Set.prototype.add) its receiver, so it can't be chained. (That particular decision seems fine, I'm just noting it.)
It seems like it would be nicer to allow the creation and initialization to happen in a single step, for example by passing the resources as an iterable argument to the constructor, as for Set or Map:
using stack = new DisposableStack([getLock1(), getLock2()]);

Alternatively, say if we think the constructor arguments should be reserved for other uses in the future, we could add a helper like Array.of:
using stack = DisposableStack.of(getLock1(), getLock2());

This is also nicer for the "DisposableStack as wrapper for function" use case.

I believe the problem is what to do if an error occurs during iteration. The elements that have been iterated on should be disposed of. For AsyncDisposableStack that can only happen asynchronously, which means the "construction" operation needs to be awaited.
I do like the suggestion of the .of helper as that translated to an asyncOf for the async case.

Hm, even with of you run into the problem that evaluating a later argument might throw, leaving earlier ones one un-disposed. And there's no chance to handle that, since the result of evaluating the first argument disappears into the void. I don't see a way around that problem.

The of helper could guarantee that if it fails iteration, it will dispose of the element that have been iterated so far (aka call dispose() on itself).

Failing iteration isn't the only problem: consider
function getLock(name) {
  if (!locks.has(name)) throw new Error(`${name} is not a known lock`);
  return locks.get(name).lock();
}

using stack = DisposableStack.of(getLock('one'), getLock('two'));

What happens if two is not a known lock? The result of getLock('one') vanishes, never to be disposed.

Correct, and that's probably the difference between passing an iterable and passing multiple args or an array. If the iterable lazily allocates the resources, you're safe. Probably enough of a footgun to not provide such helpers.

It would be possible to do this with an executor callback that is expected to return an iterator (not iterable!) - in other words, make generator functions work:
{
  using stack = new DisposableStack(function*() {
    yield getLock1();
    yield getLock2();
  });
  doOtherWork();
  transfer(stack.move());
}

However, that syntax does not look much nicer than stack.use(…), and is one line longer. It's also trivial to implement yourself:
function disposableStackFrom(executor) {
  using stack = new DisposableStack();
  for (const res of executor()) stack.use(res);
  return stack.move();
}

DisposableStack went through a number of iterations. The earliest iteration had a .from(iterable) static method, but it was found that this was error prone for the exact reasons mentioned above. It's much more reliable to explicitly call .use for each item you create to ensure they are tracked correctly.

Yeah it's footgun, but if we don't have convenient constructor, I'm afraid that people will invent the similar helpers and create footguns eventually.

Yeah it's footgun, but if we don't have convenient constructor, I'm afraid that people will invent the similar helpers and create footguns eventually.

I'd rather the standard library not be the place to introduce such a footgun.


Updated dev branch from master changes

Questions
Answers

Description?
Updated dev branch from master changes

Type?
merge

BC breaks?
no

Deprecations?
no

Fixed ticket?
N/A

How to test?
N/A

Thanks @Progi1984


Tech dept P2 (EXPOSUREAPP-13177)

Ticket

Could some Todos result in follow up tickets, or are they all obsolete?

Obsolete


Zen command not using integer line when followed by words.

Proposed fix
Parse string for potential integer before using word search.

Doesn't that mean that there's a dev branch for this bug ?
Also, looking at the name, I thought it made sense, unless there's something I'm missing

Interesting, I don't see that.

@minalike could you self assign if you're working on this

Hm? No I am not working on this issue.

Alright cool, your creation of this branch made it seem like you were https://github.com/python-discord/bot/tree/zen-args-fix

@ChrisLovering I can take this if you'll assign it to me


Create new Weather_app

I want to contribute a new Weather app, Please assign me. Also tag #hacktoberfest

please assign this issue to me.


Fix secure channel after removing node IDs from rendezvous

Problem
After merging #4945, CHIP Python Controller is able to pair an accessory device successfully, but then the accessory is unable to decrypt ZCL messages. The reason is that the PR dropped usage of node IDs (in PASE session) which are necessary to identify a correct encryption key.
Summary of Changes
When nodeIDs are missing in CHIP messages use correct defaults to store encryption keys exchanged during the rendezvous session.
Fixes #5016

Approving because we likely need a fix for TE1.
However also for TE1, we probably expect devices to not use hardcoded nonde ids.
The removal of nodeids was intended exactly to highlight these kind of dependencies and adding them back seems problematic.

So what's your plan then? I thought your change wasn't meant to be a functional change, but now it turns out it did.
Are we backsliding here? Perhaps we should back out that change.

I tried the same use case with iOS CHIPTool, and it works fine. I understand that the behavior over PASE is not per spec (i.e. using/assigning the NodeIDs). Since the current change is temporary to support TE1, maybe we can mimic in Python control what iOS CHIPTool is doing as a stop gap solution.

I tried the same use case with iOS CHIPTool, and it works fine. I understand that the behavior over PASE is not per spec (i.e. using/assigning the NodeIDs). Since the current change is temporary to support TE1, maybe we can mimic in Python control what iOS CHIPTool is doing as a stop gap solution.

Indeed, I think I matched some C++ code since I needed chip-tool to work, however I may not have used python. I believe this requires some secondary passes or we wait until we have proper pase/case and then nodeid should be set at the proper time (i.e at opcreds setup time)

Approving because we likely need a fix for TE1.
However also for TE1, we probably expect devices to not use hardcoded nonde ids.
The removal of nodeids was intended exactly to highlight these kind of dependencies and adding them back seems problematic.

So what's your plan then? I thought your change wasn't meant to be a functional change, but now it turns out it did.
Are we backsliding here? Perhaps we should back out that change.

Agree, it was not meant to break things (but it did ... unfortunately I only tested command line chip tool).
I specifically kept some pieces of code with nodeid with 'TODO' in place to change it once appropriate and assumed I highlighted all awkward cases. Apparently this PR shows that we had one extra place that needs to be awkward, which is unfortunate.


Authentication fix

Switched cookie name to reflect SXM's current configuration. Fixes authentication issue.
See AngellusMortis/sxm-player#11

@phracker Does this resolve the issue of metadata not being properly queried?


Schema DDL: consider transformation of JSON Schema tuples into separate columns

Migrated from https://github.com/snowplow/schema-ddl/issues/55

Migrated to https://github.com/snowplow-incubator/schema-ddl/issues/42


Write 1st Plan document

Write a top-level planning document explaining

Summary Project Intent
How Project is Run
Invite to participate
Development Practices

This 1st PR is enough to get going


Update .travis.yml

Codecov Report

Merging #1848 (cc50244) into master (0ebf6ba) will decrease coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1848      +/-   ##
==========================================
- Coverage   72.33%   72.28%   -0.05%
==========================================
  Files          46       46
  Lines        4471     4471
==========================================
- Hits         3234     3232       -2
- Misses        894      896       +2
  Partials      343      343


Release overlap_comm & contiguous_gradients restrictions for ZeRO 1

The overlap_comm and contiguous_gradients options have been ignored in ZeRO stage 1 since https://github.com/microsoft/DeepSpeed/pull/1246. Back in that time, ZeRO 1 and 2 are separately implemented (see https://github.com/microsoft/DeepSpeed/tree/6ae756c03f12674f17aef90622e7664a8af9d2af/deepspeed/runtime/zero). ZeRO 1 does not have gradient hooks registered to overlap backward and gradient all-reduce, so it's fine to ignore overlap_comm and contiguous_gradients. However, in the current implementation, ZeRO 1 and 2 share almost the same implementation (stage_1_and_2.py). Features like overlap_comm and contiguous_gradients can also be enabled for ZeRO 1 (Please correct me if I made a mistake).
With this PR, turning on overlap_comm and contiguous_gradients for ZeRO 1 on the SFT task produces exactly the same training curve as the latest master.

I also see a ~1.05x e2e speedup by overlapping backward and gradient all-reduce. I can confirm by the trace that backward and all-reduce do overlap, and the separate gradients are indeed copied to a flat buffer. These options are also effective for ZeRO 1.

Related issue: https://github.com/microsoft/DeepSpeed/issues/2295

@li-plus, thanks so much for this PR. Your analysis of the problem is accurate. Previously, we did not have bandwidth to evaluate the correctness of enabling those optimizations for ZeRO-1. This is a great contribution. Thanks so much.


Added missing test files.

Fixes #376.

The current test failures in the Github Actions are caused by a broken Ubuntu mirror server and are not related to what I mention below.
Which version of keras are you using?


r1.4 build failed constexpr constructor calls non-constexpr function

BLUF:
Build fails on OSX.
./tensorflow/core/framework/variant.h(343): error: constexpr constructor calls non-constexpr function "std::__1::unique_ptr<_Tp, _Dp>::unique_ptr() [with _Tp=tensorflow::Variant::ValueInterface, _Dp=std::__1::default_deletetensorflow::Variant::ValueInterface]"
1 error detected in the compilation of "/var/folders/96/nq247q_92n99r8hkfvlxg_6w0000gn/T//tmpxft_00004cf5_00000000-7_beam_search_ops_gpu.cu.cpp1.ii".
ERROR: /Users/joa23/projects/tensorflow/tensorflow/contrib/seq2seq/BUILD:51:1: output 'tensorflow/contrib/seq2seq/_objs/python/ops/_beam_search_ops_gpu/tensorflow/contrib/seq2seq/kernels/beam_search_ops_gpu.cu.pic.o' was not created.
ERROR: /Users/joa23/projects/tensorflow/tensorflow/contrib/seq2seq/BUILD:51:1: not all outputs were created or valid.
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
10.13.1 (17B48)
TensorFlow installed from (source or binary):
Trying to compile with sources.
TensorFlow version (use command below):
r1.4 branch
Python version:
Python 3.6.3
Bazel version (if compiling from source):
0.7.0
GCC/Compiler version (if compiling from source):
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-8<IP_ADDRESS>)
Target: x86_64-apple-darwin17.2.0
Thread model: posix
CUDA/cuDNN version:
CUDA Driver Version: 8.0.61
cuDNN 6 April 2017
GPU model and memory:
NVIDIA GTX TITAN X, 12 GB, DVI, HDMI, 3 DP (3072 CUDA cores)
Exact command to reproduce:
bazel build --config=opt --config=cuda //tensorflow/tools/pip_package:build_pip_package --verbose_failures

Describe the problem
Failed to build with
./tensorflow/core/framework/variant.h(343): error: constexpr constructor calls non-constexpr function "std::__1::unique_ptr<_Tp, _Dp>::unique_ptr() [with _Tp=tensorflow::Variant::ValueInterface, _Dp=std::__1::default_deletetensorflow::Variant::ValueInterface]"
1 error detected in the compilation of "/var/folders/96/nq247q_92n99r8hkfvlxg_6w0000gn/T//tmpxft_00004cf5_00000000-7_beam_search_ops_gpu.cu.cpp1.ii".
ERROR: /Users/joa23/projects/tensorflow/tensorflow/contrib/seq2seq/BUILD:51:1: output 'tensorflow/contrib/seq2seq/_objs/python/ops/_beam_search_ops_gpu/tensorflow/contrib/seq2seq/kernels/beam_search_ops_gpu.cu.pic.o' was not created.
ERROR: /Users/joa23/projects/tensorflow/tensorflow/contrib/seq2seq/BUILD:51:1: not all outputs were created or valid.
Target //tensorflow/tools/pip_package:build_pip_package failed to build

I can build the last commit before the last changes to variant.h which is 9380e3a832
The changes at the following commit break the build for me so is probably a good place to start 105dd2aa22c7aaac401d2d8ed3131b5d81fdc227 although I'm not familiar with the Tensorflow code.
Like you I'm on CUDA 8 cuDNN 6 and am using OSX with an eGPU (1080TI).

@danbarnes333,
Thanks! Good to know someone else has the same setup. I was afraid it was hardware related.
Does the 9380e3a832 build than work for you? I managed to the build r1.3 branch but any Tensorflow hello world just hang. No stack trace. No Error message.

Yes I can build and run 1.3, no hangs. 9380e3a832 will build into a wheel but throws some errors when trying to import it which maybe isnt suprising as its not a release version.
I can build r1.4 head with GPU support (see below) and use in OSX by changing tensorflow/core/framework/variant.h(343)
std::unique_ptr<ValueInterface> value_;
to
std::shared_ptr<ValueInterface> value_;
But I cant really advise this without spending time going through the code it affects.
@ebrevdo you made the 105dd2aa22c7aaac401d2d8ed3131b5d81fdc227 commit. Do you have thoughts if the above change is ok?
Thanks for any thoughts / advice you have!
In [1]: import tensorflow as tf
In [2]: tf.__version__
Out[2]: '1.4.1'

In [3]: from mrg_beta.tf.utils import LocalDevices

In [4]: LocalDevices()
2017-11-28 10:59:31.406129: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:856] OS X does not support NUMA - returning NUMA node zero
2017-11-28 10:59:31.406316: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1030] Found device 0 with properties:
name: GeForce GTX 1080 Ti major: 6 minor: 1 memoryClockRate(GHz): 1.582
pciBusID: 0000:4f:00.0
totalMemory: 11.00GiB freeMemory: 2.31GiB
2017-11-28 10:59:31.406346: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1120] Creating TensorFlow device (/device:GPU:0) -> (device: 0, name: GeForce GTX 1080 Ti, pci bus id: 0000:4f:00.0, compute capability: 6.1)

In [5]:

Can you provide the full compile time error?
On Tue, Nov 28, 2017 at 3:02 AM, Dan Barnes<EMAIL_ADDRESS>wrote:

Yes I can build and run 1.3, no hangs. 9380e3a
https://github.com/tensorflow/tensorflow/commit/9380e3a8327e801bee5cf3ab34b98dcbd3c72bf7
will build into a wheel but throws some errors when trying to import it
which maybe isnt suprising as its not a release version.
I can build r1.4 head with GPU support (see below) and use in OSX by
changing tensorflow/core/framework/variant.h(343)
std::unique_ptr value_;
to
std::shared_ptr value_;
But I cant really advise this without spending time going through the code
it affects.
@ebrevdo https://github.com/ebrevdo you made the 105dd2a
https://github.com/tensorflow/tensorflow/commit/105dd2aa22c7aaac401d2d8ed3131b5d81fdc227
commit. Do you have thoughts if the above change is ok?
Thanks for any thoughts / advice you have!
In [1]: import tensorflow as tf
In [2]: tf.version
Out[2]: '1.4.1'
In [3]: from mrg_beta.tf.utils import LocalDevices
In [4]: LocalDevices()
2017-11-28 10:59:31.406129: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:856] OS X does not support NUMA - returning NUMA node zero
2017-11-28 10:59:31.406316: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1030] Found device 0 with properties:
name: GeForce GTX 1080 Ti major: 6 minor: 1 memoryClockRate(GHz): 1.582
pciBusID: 0000:4f:00.0
totalMemory: 11.00GiB freeMemory: 2.31GiB
2017-11-28 10:59:31.406346: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1120] Creating TensorFlow device (/device:GPU:0) -> (device: 0, name: GeForce GTX 1080 Ti, pci bus id: 0000:4f:00.0, compute capability: 6.1)
In [5]:
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/14898#issuecomment-347488587,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABtim-GuDfyZCm7BaT70eFt4GL6Mjcdmks5s6-g7gaJpZM4QrEsY
.

I cant seem to get any more verbose than the following
Thanks
./tensorflow/core/framework/variant.h(343): error: constexpr constructor calls non-constexpr function "std::__1::unique_ptr<_Tp, _Dp>::unique_ptr() [with _Tp=tensorflow::Variant::ValueInterface, _Dp=std::__1::default_delete<tensorflow::Variant::ValueInterface>]"

what version of clang are you using?  are you using the cmake build?

I used gcc and followed this tutorial step by step:
https://metakermit.com/2017/compiling-tensorflow-with-gpu-support-on-a-macbook-pro/

Not using cmake build, using the normal configure script and clang (with nvcc as the CUDA compiler).
@joa23 I dont believe on OSX you can actually build with gcc without some changes to the build files. Despite the question on at the end of the configure pointing to gcc thats by default a symlink back to clang. I tried separately to build with a version of gcc from homebrew, but it threw up a lot of errors because it was expecting clang.
Apple LLVM version 8.0.0 (clang-800.0.38)
Target: x86_64-apple-darwin16.6.0

xcode-select version 2347.

Unfortunately, Apple support for NVIDIA CUDA is not strong, so it is difficult for us to support TensorFlow CUDA on Mac OS X.

Confirmed that @danbarnes333 fix of changing line 343 of variant.h to
std::shared_ptr value_; works in getting TF 1.4 with cuDNN 6 and CUDA 8 installed and working using bazel 0.8 on OS X 10.12.6 however I also needed to comment out the line linkopts = [“-lgomp”] in tensorflow/third_party/gpus/cuda/BUILD.tpl

Closing this issue due to staleness. Please use the latest version of TensorFlow and build again.
Feel free to report any issues you encounter with latest TensorFlow. Thanks!


Add duplicate_of field to companies

Description of change
This adds a field to the Company model to indicate if a company is a duplicate of another company. This also blocks companies that have this field set from being unarchived.
Checklist

[x] Has a new newsfragment been created? Check changelog/README.rst for instructions
[ ] Have any relevant search models been updated?
[x] Have any relevant fixtures (fixtures/test_data.yaml) been updated?
[x] Have any relevant select-/prefetch-related field lists in the views and search apps been updated?
[x] Has the admin site been updated (for new models, fields etc.)?
[ ] Has the README been updated (if needed)?

Loaded the test data and because the merged company no longer has a name it isn't selectable in the admin company view. If this is by design this view could eventually get cluttered.

Also should this new duplicate company appear in the duplicates section of Mars Export ltd as it does not?

Loaded the test data and because the merged company no longer has a name it isn't selectable in the admin company view. If this is by design this view could eventually get cluttered.

Good spot, I left out a name by accident.

Also should this new duplicate company appear in the duplicates section of Mars Export ltd as it does not?

I think that's just related to the no-name problem, name is not optional so we should be OK there.


training with Resnet

Hello,
I've tried to train the network with resnet as encoder , I've downloaded the weighs from here :
link
but I get this error :
NotFoundError (see above for traceback): Tensor name "scale2/block2/b/beta" not found in checkpoint files DATA/weights/resnet_v1_101.ckpt
	 [[Node: save_1/RestoreV2_54 = RestoreV2[dtypes=[DT_FLOAT], _device="/job:localhost/replica:0/task:0/cpu:0"](_recv_save_1/Const_0, save_1/RestoreV2_54/tensor_names, save_1/RestoreV2_54/shape_and_slices)]]
	 [[Node: save_1/RestoreV2_479/_483 = _Recv[client_terminated=false, recv_device="/job:localhost/replica:0/task:0/gpu:0", send_device="/job:localhost/replica:0/task:0/cpu:0", send_device_incarnation=1, tensor_name="edge_5135_save_1/RestoreV2_479", tensor_type=DT_FLOAT, _device="/job:localhost/replica:0/task:0/gpu:0"]()]]

So we might be using two different checkpoints , is it possible to share you share your checkpoint file that you used for this part ?
thanks !

I have uploaded my weights here.

Thanks !

@MarvinTeichmann Your link can't be visited..

@bendidi Did you success to training it with Resnet as encoder? which dataset? how about the performance of training result?


Validation Steps fullEpoch added for Clarity

What does this PR do?
Fixes #3164
Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together? Otherwise, we ask you to create a separate PR for every change.
[x] Did you make sure to update the documentation with your changes?
[x] Did you write any new necessary tests?
[x] Did you verify new and existing tests pass locally with your changes?
[ ] If you made a notable change (that affects users), did you update the CHANGELOG?

PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

Issue: https://github.com/PyTorchLightning/pytorch-lightning/issues/3164

thanks for the PR! mind waiting a week until we finish refactors?

That works for me, thanks!

I don't think this is required. Everything is clearly mentioned in the docs.
https://pytorch-lightning.readthedocs.io/en/latest/api/pytorch_lightning.trainer.html#num-sanity-val-steps

@dulayjm mind sending another PR starting from the actual master, this was a bit hard...

Sure, sorry about that


Create additional info blocks

You can make your resume less official by adding more entertaining info, like your hobbies and interest, or what do you like, some interactive content or joke, easter egg, etc.

I love electronic music such as techno and house, I listen to it everyday and I like finding out new songs, perhaps learn how to mix one day. Also I enjoy reading about philosophical topics, books, etc. I think the inward is very important.


Release-workflow: Bug fix

This fixes https://github.com/pydata/xarray/issues/5232#issuecomment-833729171

@TomNicholas & @alexamici... If you still want to use this, you may want to delete the old release/tag and re-publish it :( Sorry for the extra work

Also, feel free to merge this at your earliest convenience

this should be ready to go (no need to wait on RTD)


1.9.0 01-SimpleLightBulb erroring out

Trying to run 01-SimpleLightBulb with version 1.9.0  and getting below error.
Rebooting...
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13260
load:0x40080400,len:3028
entry 0x400805e4
E (303) psram: PSRAM ID read error: 0xffffffff
Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x400da1f5  PS      : 0x00060a30  A0      : 0x800d39a0  A1      : 0x3ffb21d0
A2      : 0x3ffc4684  A3      : 0x00000001  A4      : 0x3ffb8a60  A5      : 0x3ffc4924
A6      : 0x00000000  A7      : 0x00000000  A8      : 0x00000000  A9      : 0x3ffb21b0
A10     : 0x3ffb8aec  A11     : 0x00000004  A12     : 0x3ffbda54  A13     : 0x00000000
A14     : 0x3ffb7c80  A15     : 0x00000000  SAR     : 0x00000019  EXCCAUSE: 0x0000001d
EXCVADDR: 0x00000000  LBEG    : 0x400ee63d  LEND    : 0x400ee647  LCOUNT  : 0x00000000
Backtrace: 0x400da1f2:0x3ffb21d0 0x400d399d:0x3ffb2260 0x400e53a6:0x3ffb2290

ELF file SHA256: 394896f4370ce8c0

Tools tab screenshot

1.8.0 compiled and uploaded fine but getting error after scanning the sample setup code/setting a custom one i get below error.

on retrying i get this

Apologies in advance if i've missed something trivial as i'm new to this.

I cannot reproduce the reboot error under 1.9.0, but I do not have an ESP32 with PSRAM.  What specific ESP32 are you using?  Are you sure the settings are flash=DIO and not flash=QIO?
Also, try uploading with the erase-flash option "enabled" to ensure there are no flash corruption issues.  Can also try running with PSRAM disabled.
Re the Unable to Add Accessory:  it seems like the first pairing may have failed before completing, but HomeSpan may think the pairing succeeded.  If you type 'H' into the CLI, this will erase all pairing info.  Note that erasing the flash before uploading (as per above) will erase all stored HomeSpan info automatically.

Using a ESP32-WROOM-32D.
Updating the settings recommended by you(flash=QIO and PSRAM=disabled) and erasing the pairing info fixed both the issues.
Such a well architected and documented library. Thank you.


Availability ui component

@evanrs @ripleyaffect Dealt with all code comments. How does it look?

The code looks clean to me, I would just ask that the PR have an English description of what the work is, design goals and constraints, context, relevant tickets and other PRs, what's left to do after this PR is rolled out, etc.  For example, since there are already multiple availability components throughout the system, I'd appreciate a discussion of what's the same and what's different about this one compared to the others.

Good point! Editing now.

Done.

:+1:


Build problem with recent Clang releases

Tested versions

Reproducible with Godot master (4.4 - 83d54ab2ad476ae265b323c2b88f4623b922f4c6)

System information
MacOS 14.6.1 - Xcode Version 16.0 (16A242 - Release Candidate)
Issue description
It seems that a stricter Clang is triggering a problem in Godot.
The issue seems to be that Objective-C++ code includes vulkan.h, which uses an extern 'C' block and then includes the C stdint.h, but for some reason recent Clang++ map '#include stdint.h' into importing the C++ module 'std_stdint_h', which is not allowed to be done from C.
The build error is like this:
In file included from platform/ios/keyboard_input_view.mm:33:
In file included from platform/ios/display_server_ios.h:42:
In file included from platform/ios/rendering_context_driver_vulkan_ios.h:36:
In file included from ./drivers/vulkan/rendering_context_driver_vulkan.h:46:
In file included from thirdparty/vulkan/include/vulkan/vulkan.h:11:
In file included from thirdparty/vulkan/include/vulkan/vulkan_core.h:8325:
In file included from thirdparty/vulkan/include/vk_video/vulkan_video_codec_h264std.h:24:
thirdparty/vulkan/include/vk_video/vulkan_video_codecs_common.h:25:5: error: import of C++ module 'std_stdint_h' appears within extern "C" language linkage specification [-Wmodule-import-in-extern-c,15]
   25 |      #include <stdint.h>
      |      ^
thirdparty/vulkan/include/vk_video/vulkan_video_codecs_common.h:17:1: note: extern "C" language linkage specification begins here [2]
   17 |  extern "C" {
      |  ^

I am using this workaround, which seems a bit like brute force, hence why this is not a PR:
diff --git a/platform/ios/SCsub b/platform/ios/SCsub
index cf565db049..1ee114e59e 100644
--- a/platform/ios/SCsub
+++ b/platform/ios/SCsub
@@ -95,6 +95,8 @@ else:
 # (iOS) Enable module support
 env_ios.Append(CCFLAGS=["-fmodules", "-fcxx-modules"])

+env_ios.Append(CCFLAGS=["-Wno-module-import-in-extern-c"])
+

 def combine_libs(target=None, source=None, env=None):
     lib_path = target[0].srcnode().abspath

Steps to reproduce
To reproduce this issue you need a recent clang, like the one that was just released for Xcode 16.0.
Build Godot on MacOS, like this:
scons p=ios

Minimal reproduction project (MRP)
None is needed, just upgrading Xcode 16.0

FYI we have a fix for this issue, just need to replace the usual vulkan inclusion block with this:
#ifdef USE_VOLK
#include <volk.h>
#else
#include <stdint.h>
#define VK_NO_STDINT_H
#include <vulkan/vulkan.h>
#endif

If this is acceptable, then we can provide a PR.

FYI we have a fix for this issue, just need to replace the usual vulkan inclusion block with this:
#ifdef USE_VOLK
#include <volk.h>
#else
#include <stdint.h>
#define VK_NO_STDINT_H
#include <vulkan/vulkan.h>
#endif

If this is acceptable, then we can provide a PR.

This seems like a workaround. I think the issue should be fixed in the Vulkan headers if they're doing something illegal - or in Clang if it's misled.
How should one import for the C stdint.h in C code used from Obj-C++ with that Clang version? That's something that should be reproducible in a minimal example and can be discussed upstream with LLVM. It would seem weird to me that the solution is to stop using stdint.h in C code.

This is not a limitation with Objective-C++, it happens with plain C++ with newer clang.
Simple repro:
demo.cpp:
extern "C" {
#include <stdint.h>
}

Compile with:
$ c++ -c -fcxx-modules -fmodules demo.cpp
a.cpp:2:1: error: import of C++ module 'std_stdint_h' appears within extern "C" language linkage specification [-Wmodule-import-in-extern-c]
    2 | #include <stdint.h>
      | ^
a.cpp:1:1: note: extern "C" language linkage specification begins here
    1 | extern "C" {
      | ^
1 error generated.

The combination that triggers this is -fcxx-modules and -fmodules.
I found the documentation here:
https://clang.llvm.org/docs/Modules.html

Thanks, I can reproduce it on Fedora 40 too with Clang 18.1.6 and the above demo, with just clang++ -fmodules demo.cpp:
demo.cpp:2:1: error: import of C++ module '_Builtin_stdint' appears within extern "C" language linkage specification [-Wmodule-import-in-extern-c]
    2 | #include <stdint.h>
      | ^
demo.cpp:1:1: note: extern "C" language linkage specification begins here
    1 | extern "C" {
      | ^
1 error generated.

It seems like just changing #include <stdint.h> to #include <cstdint> fixes it?

I just updated xcode on my mac and am also now encountering this issue.  Do we have a fix or recommended workaround while this is being looked into?

I have manually applied this patch to my checkout of the 4.3 branch and I can confirm for people on 4.3, that this patch does allow building on MacOS 15.1 using Xcode 16.1.


Rm coverage threshold

With the hard limit, may even prevent developer from fixing typo, which is not covered before.

/retest

/retest

@LiZhenCheng9527

/lgtm
There's nothing wrong with removing the threshold.

/retest


Warning: The Client driver version is different than Server version

OrientDB Version
v2.2.6 on both server and client
Operating System
Server running on Docker Container from the latest official Docker image running on Mint/Ubuntu OS
Client running from Java API on Mac OS
Expected behavior and actual behavior
Expected: Connect to server
Actual:
WARNING: The Client driver version is different than Server version: client=36, server=32. You could not use the full features of the newer version. Assure to have the same versions on both
Steps to reproduce the problem
Java:
final ODatabaseDocumentTx db = new ODatabaseDocumentTx("remote:localhost").open("admin", "admin");
Gradle:
compile group: 'com.orientechnologies', name: 'orientdb-core', version: '2.2.6'
compile group: 'com.orientechnologies', name: 'orientdb-client', version: '2.2.6'
compile group: 'com.orientechnologies', name: 'orientdb-enterprise', version: '2.2.6'
compile group: 'com.googlecode.concurrentlinkedhashmap', name: 'concurrentlinkedhashmap-lru', version: '1.4.2'

I setup a similar scenario, doing a docker pull orientdb:latest and using a Main that connects to the localhost in remote.
First, in your connection url you don't state the db name:
final ODatabaseDocumentTx db = new ODatabaseDocumentTx("remote:localhost").open("admin", "admin")
rather than:
final ODatabaseDocumentTx db = new ODatabaseDocumentTx("remote:localhost/DB_NAME").open("admin", "admin")
Dependency check: orientdb-enterprise isn't needed anymore, the module is now collapsed inside client. Even com.googlecode.concurrentlinkedhashmap, because it is a transitive dependency that I hope gradle is able to download (I'm a maven user, but AFAIK gradle dependency resolution works the same way).
So, check your client dependencies, don't know in gradle, but with maven I will do a mvn dependency:tree just to understand what jars are effectively used.

First, in your connection url you don't state the db name:
final ODatabaseDocumentTx db = new ODatabaseDocumentTx("remote:localhost").open("admin", "admin")
rather than:
final ODatabaseDocumentTx db = new ODatabaseDocumentTx("remote:localhost/DB_NAME").open("admin", "admin")

I have tried both and I get the same error either way

Dependency check: orientdb-enterprise isn't needed anymore, the module is now collapsed inside client. Even com.googlecode.concurrentlinkedhashmap, because it is a transitive dependency that I hope gradle is able to download

I only included them because the manual says they are required to use the Document API

I will fix documentation about dependencies.
BTW, can you check your dependency tree with gradle dependencies command?
Can you post the docker command used to run Orientdb?
Check the OrientDB server log with docker logs <container_hash> to be sure that is the right version.
It is not clear if the docker is running in a separate linux box or on your mac, in the second case, what is the ip address of the docker container? Are you using docker for mac or docker toolbox?
Can you connect to the running orientDB via the studio web interface? (http://<docker_container_ip>:2480)
Thanks

Thanks, @robfrank. Problem solved. Turned out Docker has been using an old image pulled 3 months ago. My fault I assumed that docker run orientdb will always pull the latest. Removing the image and re-running the container fixed it. See below for details.
I only have one question: Why I got stuck at this warning in the first place? I may have a server running for months, and the client just happens to use the latest version. Shouldn't that still work?

BTW, can you check your dependency tree with gradle dependencies command?

+--- com.orientechnologies:orientdb-core:2.2.6
|    +--- org.xerial.snappy:snappy-java:<IP_ADDRESS>
|    \--- com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:1.4.1 -> 1.4.2
+--- com.orientechnologies:orientdb-client:2.2.6
|    \--- com.orientechnologies:orientdb-core:2.2.6 (*)
+--- com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:1.4.2

I only needed to include:
compile group: 'com.orientechnologies', name: 'orientdb-client', version: '2.2.6'
+--- com.orientechnologies:orientdb-client:2.2.6
|    \--- com.orientechnologies:orientdb-core:2.2.6
|         +--- org.xerial.snappy:snappy-java:<IP_ADDRESS>
|         \--- com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:1.4.1

Can you post the docker command used to run Orientdb?

docker run -d --name orientdb -p 2480:2480 -p 2424:2424 -v /mnt/orientdb/databases:/orientdb/databases -e ORIENTDB_ROOT_PASSWORD=$ORIENTDB_ROOT_PASSWORD orientdb

Check the OrientDB server log with docker logs to be sure that is the right version.

INFO  OrientDB Server v2.1.14 (build 2.1.x@r4d21d805fc9574c11b334a453161920cc1ed9cb7; 2016-03-30 15:26:04+0000) is starting up... [OServer]
INFO  Databases directory: /orientdb/databases [OServer]
INFO  Listening binary connections on <IP_ADDRESS>:2424 (protocol v.32, socket=default) [OServerNetworkListener]
INFO  Listening http connections on <IP_ADDRESS>:2480 (protocol v.10, socket=default) [OServerNetworkListener]

It is not clear if the docker is running in a separate linux box or on your mac, in the second case, what is the ip address of the docker container? Are you using docker for mac or docker toolbox?

I am running Docker on a remote Linux server and accessing it from my Mac through SSH tunneling

Can you connect to the running orientDB via the studio web interface? (http://<docker_container_ip>:2480)

Yes, I have always been able to connect to the studio web interface at localhost:2480

Well done. Yes, docker never pull an image again. You can use the versioned tag instead of latest, e.g.: orientdb:2.2.6


feat(rust): Start new vault crate

Start a new crate for vault. Let me know if this structure is okay and if so I'll continue with it.

the structure looks good 👍
the commit linter want lower case commit messages. the rules are here https://github.com/ockam-network/ockam/blob/develop/commitlint.config.js

odd. my commit message is all lowercase

The error has something to do with Vagrant. See here

Thanks, just looked at the build log
https://dev.azure.com/ockam-network/ockam/_build/results?buildId=1664&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=bd05475d-acb5-5619-3ccb-c46842dbc997&l=3385
Does this have to do with the newly added crate?

   Compiling ockam-vault v0.1.0 (/vagrant/implementations/rust/vault)
   Compiling ockam-vault-sys v0.8.0 (/vagrant/implementations/rust/crates/ockam-vault-sys)
   Compiling ockam v0.8.0 (/vagrant/implementations/rust/crates/ockam)
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/vagrant/implementations/rust/target/debug/deps/ockam_vault_sys-52044698ced42fd9.1edtumcprzy4i8fs.rcgu.o" "/vagrant/implementations/rust/target/debug/deps/ockam_vault_sys-52044698ced42fd9.24dg50kpbxb13xy1.rcgu.o" "/vagrant/implementations/rust/target/debug/deps/ockam_vault_sys-52044698ced42fd9.3cf5nc24v4pmqluf.rcgu.o" "/vagrant/implementations/rust/target/debug/deps/ockam_vault_sys-52044698ced42fd9.4dgg9p8hlsbtzx8i.rcgu.o" "/vagrant/implementations/rust/target/debug/deps/ockam_vault_sys-52044698ced42fd9.urnkzjknx7ujctj.rcgu.o" "-o" "/vagrant/implementations/rust/target/debug/deps/ockam_vault_sys-52044698ced42fd9" "/vagrant/implementations/rust/target/debug/deps/ockam_vault_sys-52044698ced42fd9.40j30mrpj54hj6ma.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/vagrant/implementations/rust/target/debug/deps" "-L" "/vagrant/implementations/rust/target/debug/build/ockam-vault-sys-ce6e216f900da611/out/ockam_vault/build/Debug/lib" "-L" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,--whole-archive" "-lockam_vault" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-lockam_vault_default" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-lockam_memory" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-lockam_random" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "-lockam_random_urandom" "-Wl,--no-whole-archive" "/vagrant/implementations/rust/target/debug/deps/liblibc-6a54935c1aa17625.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtest-48cf79d5a79901bb.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libterm-bf84c77a9073903b.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts-902f2c7ee89233ac.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunicode_width-6ace3ed54c97ba6a.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_std-8ab2eab4fe2b9a29.rlib" "-Wl,--start-group" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-c32b051c3aafd36c.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-eabf8b29c0a244dd.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-5c336cc1b5ec2048.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-c7631f762b1ba6d9.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace-db0f6c539591c951.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace_sys-32c2dc6fbc292c9c.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-84e9c510dc249620.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-13bc027534de0b4c.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-b3c13ecda1794c6c.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-72dc11de859645e9.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-a78b04f112feb31a.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-29469f6c53ac35f8.rlib" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-0eb3c513c640c4a6.rlib" "-Wl,--end-group" "/opt/rust/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-0b278345638bce90.rlib" "-Wl,-Bdynamic" "-lutil" "-ldl" "-lutil" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
  = note: /vagrant/implementations/rust/target/debug/deps/libockam_vault.a(ockam_vault.4mzh883eaairdgzq.rcgu.o): In function `__rust_alloc':
          4mzh883eaairdgzq:(.text.__rust_alloc+0x0): multiple definition of `__rust_alloc'
          /vagrant/implementations/rust/target/debug/deps/ockam_vault_sys-52044698ced42fd9.40j30mrpj54hj6ma.rcgu.o:40j30mrpj54hj6ma:(.text.__rust_alloc+0x0): first defined here
          /vagrant/implementations/rust/target/debug/deps/libockam_vault.a(ockam_vault.4mzh883eaairdgzq.rcgu.o): In function `__rust_alloc_zeroed':
          4mzh883eaairdgzq:(.text.__rust_alloc_zeroed+0x0): multiple definition of `__rust_alloc_zeroed'
          /vagrant/implementations/rust/target/debug/deps/ockam_vault_sys-52044698ced42fd9.40j30mrpj54hj6ma.rcgu.o:40j30mrpj54hj6ma:(.text.__rust_alloc_zeroed+0x0): first defined here
          /vagrant/implementations/rust/target/debug/deps/libockam_vault.a(ockam_vault.4mzh883eaairdgzq.rcgu.o): In function `__rust_dealloc':
          4mzh883eaairdgzq:(.text.__rust_dealloc+0x0): multiple definition of `__rust_dealloc'
          /vagrant/implementations/rust/target/debug/deps/ockam_vault_sys-52044698ced42fd9.40j30mrpj54hj6ma.rcgu.o:40j30mrpj54hj6ma:(.text.__rust_dealloc+0x0): first defined here
          /vagrant/implementations/rust/target/debug/deps/libockam_vault.a(ockam_vault.4mzh883eaairdgzq.rcgu.o): In function `__rust_realloc':
          4mzh883eaairdgzq:(.text.__rust_realloc+0x0): multiple definition of `__rust_realloc'
          /vagrant/implementations/rust/target/debug/deps/ockam_vault_sys-52044698ced42fd9.40j30mrpj54hj6ma.rcgu.o:40j30mrpj54hj6ma:(.text.__rust_realloc+0x0): first defined here
          collect2: error: ld returned 1 exit status

Looks like it. There might be overlap with how I'm doing the naming. I'll change it from libockam_vault to something else temporarily.

merged.


Exclude fields?

Hello
I have a usage case where I need to keep a field on a model which I don't want to have versioned. How can I exclude a field from the simple_history model?
Thanks in advance for you help.

If anyone (@luzfcb?) wants to take a stab at this (and possibly also add support for both a 'included fields' and 'excluded fields' list) the code that populates new historical records is in create_historical_record(), and the code that defines historical models from the original model is in HistoricalRecords.copy_fields().
I'm not entirely sure how recreating the original model would work, with only part of the data recorded though. Maybe just raise an error if only part of the model's data is being tracked. That code can be found in get_instance().

Is there any movement on this? I'm just looking at simple history now, and I can see it may be a problem for my app - I have some fields that are essentially a cached calculated field. They 'change' as a result of changes in other inputs, but the change isn't interesting from a rollback/audit point of view, and the value can easily be recalculated.
I might take a crack at it if it's not already in progress.

I don't believe anyone is working on this issue right now @howardjones, anything you could contribute would be welcome.

I've been looking at this a bit more today, and there are two separate parts to this:

Don't copy fields in a list of excluded fields to the historical copy
Don't record a change if the only changed fields are excluded

It's the second one that I really care about personally. I have a few things where I use auto_now DateTimeFields just so the UI can show when an item has changed, but the actual change is in a child item (e.g. line item in an order) so there is no data change in the object other than the last_change field. Updating a child makes the child tell its parent that things have changed, and I get a little cascade of history records, even though only one is a "real" change. I just opened #214 for part of that, but this is what I meant by excluding fields.
Is that in line with other folks' use-case?

+1
Something like this would be very nice. We have a few auto_now fields that don't really need to be tracked.

I will do this now.

I did this in PR: https://github.com/treyhunner/django-simple-history/pull/238

We're using django-extensions' AutoSlugField in conjunction with HistoricalRecords on some of our models. AutoSlugField attempts to create new slugs on create, which includes those historical rows. We would love to see this land!

I came along a similar need as described by @howardjones (case 2), and since I have not yet seen this feature request implemented, here is a solution/workaround one could adopt.
The code is meant to allow for specifying explicitly the fields, the change of which should cause a history of the model being saved (note: all fields are still being saved!).
In short, the idea is:

use a decorator for model classes which enables tracking fields' changes (using pre_save signal of a given model). The decorator issues its own signal once done.
connect a custom-made signal receiver to the decorator's signal to mark if django-simple-history should store this particular change or not (we would use skip_history_when_saving)

Here is the code:
ad 1) Here is a e.g. decorators.py file
from django.db.models.signals import pre_save
from django.dispatch import Signal

## signal sent whenever a data tracking is performed
track_data_performed = Signal(providing_args=["instance"])

def track_data(*fields):
    """
    Based on David Cramer's  track_data.py
    See: http://cramer.io/2010/12/06/tracking-changes-to-fields-in-django

    Here we just add a single line to issue the track_data specific
    signal.
    """

    UNSAVED = dict()

    def _store(self, data=None):
        "Updates a local copy of attributes values"
        if self.id:
            if data:
                self.__data = {f: getattr(data, f) for f in fields}
            else:
                self.__data = {f: getattr(self, f) for f in fields}
        else:
            self.__data = UNSAVED

    def inner(cls):
        # contains a local copy of the previous values of attributes
        cls.__data = {}

        def has_changed(self, field):
            "Returns 'True' if 'field' has changed since initialization."
            if self.__data is UNSAVED:
                return False
            return self.__data.get(field) != getattr(self, field)
        cls.has_changed = has_changed

        def old_value(self, field):
            "Returns the previous value of 'field'"
            return self.__data.get(field)
        cls.old_value = old_value

        def whats_changed(self):
            "Returns a list of changed attributes."
            changed = {}
            if self.__data is UNSAVED:
                return changed
            for k, v in self.__data.iteritems():
                value = getattr(self, k)
                if v != value:
                    changed[k] = value
            return changed
        cls.whats_changed = whats_changed

        # Ensure we are updating local attributes on model pre_save
        def _pre_save(sender, instance, **kwargs):
            if not kwargs.get('raw', False):
                inst = None
                if instance.id:
                    # get old values
                    try:
                        inst = sender.objects.get(id=instance.id)
                    except sender.DoesNotExist:
                        pass
                _store(instance, inst)

                # we emit a unique signal so that others can connect to
                track_data_performed.send(sender=cls, instance=instance)
        pre_save.connect(_pre_save, sender=cls, weak=False)

        # Ensure we are updating local attributes on model save
        def save(self, *args, **kwargs):
            save._original(self, *args, **kwargs)
            _store(self)
        save._original = cls.save
        cls.save = save
        return cls
    return inner

ad 2) Here is how to use it in your models.py for a model you wish to be track'ed by django-simple-history
from django.db import models
from simple_history import register as history_register
from decorators import track_data, track_data_performed

@track_data('field_1', 'field_2')
class MyModel(models.Model):
    field_1 = models.CharField(max_length=128)
    field_2 = models.CharField(max_length=128)
    field_3 = models.CharField(max_length=128)
history_register(MyModel, inherit=True)

@receiver(track_data_performed, sender=MyModel)
def user_save_history(sender, instance, **kwargs):
    if not instance.whats_changed():
        instance.skip_history_when_saving = True

Note that only the change of any of the indicated fields will trigger historical object of MyModel to be saved. So if nothing but a field_3 is changed, no history will be stored.
I hope some of you find it useful. Enjoy!
(tested with Django 1.8 and django-simple-history version 1.8.1).

This was fixed in #274 . Releases >=1.9.0 should have an excluded fields option.

I've been looking at this a bit more today, and there are two separate parts to this:

Don't copy fields in a list of excluded fields to the historical copy
Don't record a change if the only changed fields are excluded

It's the second one that I really care about personally. I have a few things where I use auto_now >DateTimeFields just so the UI can show when an item has changed, but the actual change is in a child >item (e.g. line item in an order) so there is no data change in the object other than the last_change >field.  I just opened #214 for part of that, but this >is what I meant by excluding fields.

Sorry to dredge up an old issue, but going back to @howardjones's message further back, it seems that the excluded_fields function is the first solution. I'm wondering @rossmechanic if the second is possible?
Basically, I have a number of status fields (i.e. modified_on) that I don't mind being saved on the historical version, but when no other fields are updated I don't want a change to that field to trigger saving a historical version. I couldn't figure out a way to have it essentially ignore those fields - but still store them in the history when it does save a historical record.

I haven't found an existing solution within django-simple-history.
But you may check my comment above. It is exactly a working solution for problem 2 (i.e. don't record a history if the only changed fields are those who are not relevant to be traced). Looks to me that this should fits your needs too.
(Obviously there is a cost involved of querying db to see whats changed).


Moving Into Serverless Project?

Hey,
I was wondering what the developers here would think about moving this into a serverless project (in particular, a project that is usable under the serverless framework here http://serverless.com/). It would probably simplify a lot of the config and deploying that we have here.
What would you guys think about that? I'm probably going to make a fork of it myself into a serverless project anyway for what I need to get done. Would that be something you would want to integrate into mainline?
Thanks.

I would definitely support this, for any framework! I actually talked about
a contribution/merge with the Serverless Framework team long ago (they were
still JAWS) and I do not see any blocker, if not my lack of time.
On Sat, Aug 6, 2016 at 10:49 PM, David Wilcox<EMAIL_ADDRESS>wrote:

Hey,
I was wondering what the developers here would think about moving this
into a serverless project (in particular, a project that is usable under
the serverless framework here http://serverless.com/). It would probably
simplify a lot of the config and deploying that we have here.
What would you guys think about that? I'm probably going to make a fork of
it myself into a serverless project anyway for what I need to get done.
Would that be something you would want to integrate into mainline?
Thanks.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/danilop/LambdAuth/issues/53, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABeoO5b8UHEm-DIjncE4xl0dHNRW0VYTks5qdQFjgaJpZM4JeX3y
.

Just as an aside, Serverless uses CloudFormation templates to set up resources on AWS, and as far as I know, there are various limitations (you can't create Cognito Identity Pools, for one).
Personally, I'd love to see this using Serverless as well, but given that they've just released v1 betas, I would hold off till it's stable (the API changed massively from pre-v1).

Hey guys,
Philipp from the Serverless team here. I would really like to see this project using the Serverless framework as authentication is a tedious, but often necessary feature!
We've just introduced Serverless v1 beta.1 recently and are about to introduce the second beta next week. The final, stable Serverless v1 will be ready soon.
I'd love to see this project running on Serverless. The docs are a good starting point to understand the new Serverless concepts to get things up and running quickly.
Let me know if you have any questions or need any help when you're about to move it to Serverless v1.

Thanks for the quick update! I was looking through the milestones on the project's Github page, and saw stuff relating to KMS in the upcoming beta (which is why I suggested waiting).
Do you have any best-practice recommendations on setting up a Cognito Identity Pool from Serverless? Or would that be something better handled by a Serverless plugin?

@hassankhan as you mentioned CF is not natively supporting Cognito yet, so it would have to be integrated in some other way. Our Plugin API is pretty simple so getting something in place that can support Cognito together with LambdaAuth should be straight forward I think

@hassankhan here's a link to the plugin documentation where you can read more about plugin developmen: https://github.com/serverless/serverless/blob/master/docs/developing-plugins/building-plugins.md
Furthermore you might also want to look into our core plugins to see some real world examples.
E.g. here's the implementation of the package plugin which will zip the service for Serverless: https://github.com/serverless/serverless/tree/master/lib/plugins/package

I've written plugins for Serverless 0.5, seems like things have changed again :(
Is there a list of plugins that will by supported by core, so we can avoid duplicating work? I would love to help out but I don't want to step on anyone's toes :)

Hey @hassankhan yes, the plugin system was updated / rewritten from scratch.
We've just started to announce our plans for our milestones in separate issues.
You can find them with the help of the "milestone-discussion" label:
https://github.com/serverless/serverless/labels/milestone-discussion
Furthermore we've introduced the "help-wanted-easy" and "help-wanted" labels we use to tag functionality where we need help from our awesome community:
https://github.com/serverless/serverless/labels/help-wanted-easy
https://github.com/serverless/serverless/labels/help-wanted
Would be great if you could look around and jump into the issue discussions (like you already did 🎉 !)

+1000

+1

+1 👍

+1


Support arbitrary expressions as functions

It would be helpful for Vale (F*) to support unnamed functions as expressions, not just explicitly named expressions.

It has been a TODO item for a while to support expressions of the form EXP ( EXP , ... , EXP ) rather than just  f ( EXP , ... , EXP ) and f #[ TYPE , ... , TYPE ] ( EXP , ... , EXP ).  The parser already supports EXP rather than f and the internal AST already supports EApply of exp * ... rather than just EApply of id * ..., so some of the work is already done.  There are two cases for function application.  First, for f ( EXP , ... , EXP ), the type checker looks up f's type and requires/ensures.  This case is already implemented.  If the first case does not apply, the type checker should go on to the second case: for EXP0 ( EXP1 , ... , EXPn ), the type checker should check that EXP0 has the appropriate function type.  This case still needs to be implemented.  Note that the second case does not subsume the first case, because function types are simple types without requires/ensures, so not every function f can be given a function type.
Example:
procedure{:typecheck} Test()
{
  let f:fun(int) -> int := lambda x:int :: x + 1;
  let a:int := f(10);
}


metrics: allow custom batcher for Meter

From the spec here, there are different type of Integrator (which is our Batcher), we should allow to define a custom one for a given meter and use UngroupedBatcher if none is provided.
It will also allow user (like me) to implement their own aggregator :)

Closed via #933


Can't move window version 3.4.4

Hi,
I just "auto updated" to version 3.4.4, and now cannot move the window.
I can resize on all sides, but cannot move by grabbing the title bar.
See video https://vimeo.com/353476890

Damn, ok so the update I released yesterday was for the new version of messenger and stupidly assumed Facebook would have migrated everyone to it by now (it was announced it June they'd have it done in the following months, and judging by your video looks like you're still on the older version)
Let me have a think how I can swap between the 2 different style sheets - else I'll revert the changes.

Cool I've just added back the old style for just dragging the window - could you let me know if that works?
I'm hesitant to load the full pre-3.4.4 CSS, as the old layout for messenger.com will soon be going away, and don't want to spend time on something which will be gone in a couple weeks / months time.
Hopefully that should be enough to get it usable again until the new version of messenger.com rolls out to everyone.

yup that fixed it . .thanks


Invalid route action in demo page

I'm opening this issue not as an issue in the code, but rather in the demo.
the problem: Invalid route action: [App\Http\Controllers\sdf].

Demo doesn't have any controller like sdf
Sceondly you didn't pass method name.
Correct format is App\Http\controllerName@methodName
On Wed 5 Feb, 2020, 5:08 PM Ilyes Chouia<EMAIL_ADDRESS>wrote:

I'm opening this issue not as an issue in the code, but rather in the demo.
the problem: Invalid route action: [App\Http\Controllers\sdf].
[image: image]
https://user-images.githubusercontent.com/21331907/73836725-355a2c00-4810-11ea-85ca-d3227b132c75.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Codexshaper/laravel-menu-builder/issues/6?email_source=notifications&email_token=ALZKHYX3CXCIQBWRPLRJ32TRBKM4JA5CNFSM4KQJE462YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ILFP7UQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALZKHYSNTSREEGJNDGSPVULRBKM4JANCNFSM4KQJE46Q
.

@Codexshaper thank you for your response.
looks like the issue has been solved. thank you again!

@celyes you are welcome. If you like this package want to get more packages, don't forget to press the star button.


momentum-constructor-font-icon

Need run in javascript
Update config format
Use momentum-constructor-common to read momentum file path as default

Use momentum-constructor-common to read the path
const { MomentumAbstractType, reader } = require('momentum-constructor-common');
const iconPath = reader.path(MomentumAbstractType.icon);

You can remove the dependencies of momentum-abstract if you add momentum-constructor-common

config
1 merge fontPath and fontName to one option, maybe 'output'
2 rename tokenRegExp and content, they need like be in one group
3 contentReg maybe like the following way
contentReg: {
      '.html': `/as/g`,
      '.html': /as/g,
      '.scss': /sas/g
    },

You can use eval to convert string to RegExp
var a; eval('a=/$ad/g');a;

need usage in Javascript.
build(config);
init(config);

It will be nice if we have test files


Updates some docs for help

I accidentally built this off of #80, which then created a merge conflict.
got the branch sorted!

merci


after VS update (16.2.0 Preview 3.0) all methods reference show as error but compiles well.

Thanks for contacting us, @HelvioBlazor.
@ajaybhargavb can you please look into this? Thanks!

@HelvioBlazor what is the error you see when you hover over the red squiggly?

@HelvioBlazor - the syntax for event handlers has changed. These should be updated to use directive attributes - event handlers in C# now start with @.
Ex:
<button @onclick="@MyMethod">

If you're using the latest VS, make sure you also have the latest .NET Core SDK preview (currently 3.0 preview 6). The tools will continue to change to keep pace with the latest SDK until we get to the 3.0 release.

Oh duh. I didn't notice the lack of @. I agree with what @rynowak said 😄

All methods call have the "@" look row 195 to 198. the SDK is Preview 5, I will update it.

I just updated to Preview 6 I have the @ but still show Fake error.

Another view

Ohhh Sorry I got!!!!! Thank you


Tests fail against Django's main (5.0) branch

Issue Summary
Our tests seem to fail against Django's main branch with AttributeError: 'IndexView' object has no attribute 'add_facets' as of a few days ago.
Possible cause: https://github.com/django/django/pull/16495
Will investigate later.

Sounds like it's failing again for a different reason this time, but it fails really hard. I wonder what's causing it...

Yep, very weird. Looks like the new failure was introduced in dde2537f and is specific to Postgres. Was wondering if outdated postgres / psycopg versions might be the cause (i.e. the new Django commit is a breaking change against older versions, intentionally or not) but it doesn't seem so - Django's test suite passes in the same environment that Wagtail's test suite is massively failing on.

Thanks for verifying the commit, I had guessed it was that one but I hadn't tested it. It's strange though as the commit seems harmless.
One of the reasons why it's massively failing is because the user login for the tests, either with the utilities provided by WagtailTestUtil or self.client.login, doesn't seem to work. There's a signal handler that updates the last login timestamp, and it calls save(update_fields=[...]) but it doesn't affect any rows.
I'm reopening this until we figure it out.

Reopening as one test fails after https://github.com/django/django/pull/16621. Fix is at #10242.

Failing again after https://github.com/django/django/pull/16632. (Great PR that finally solves Django's ticket 16055, a pain point for us.)
Per https://github.com/django/django/pull/16632#discussion_r1169839703, it's possible that the case with get_reverse_joining_fields was overlooked.

Actually, not going to reopen as I suspect the issue is in upstream. I'll investigate when I have the time.


refactor: alter error type flow in deployment, prep for trace

This change is

Codecov Report
Attention: Patch coverage is 76.19048% with 10 lines in your changes are missing coverage. Please review.

Project coverage is 75.09%. Comparing base (a7d5cfb) to head (529b50a).
Report is 5 commits behind head on main.

Files
Patch %
Lines

crates/blockifier/src/execution/execution_utils.rs
46.66%
5 Missing and 3 partials :warning:

...lockifier/src/execution/deprecated_syscalls/mod.rs
80.00%
1 Missing :warning:

crates/blockifier/src/execution/syscalls/mod.rs
80.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1734      +/-   ##
==========================================
- Coverage   75.15%   75.09%   -0.06%
==========================================
  Files          59       59
  Lines        8553     8646      +93
  Branches     8553     8646      +93
==========================================
+ Hits         6428     6493      +65
- Misses       1701     1728      +27
- Partials      424      425       +1

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


New installation requires /Users/$USER/.prismacloud to exist

Describe the bug
initial acceptance of support policy requires /Users/$USER/.prismacloud to pre-exist
Expected behavior
Expected that initial install will create /Users/$USER/.prismacloud
Current behavior
❯ pc version
# Community Supported
This template/solution is released under an as-is, best effort,
support policy. These scripts should be seen as community
supported and Palo Alto Networks will contribute our expertise as
and when possible. We do not provide technical support or help in
using or troubleshooting the components of the project through our
normal support options such as Palo Alto Networks support teams,
or ASC (Authorized Support Centers) partners and backline support
options. The underlying product used (Prisma Cloud) by the scripts
or templates are still supported, but the support is only for the
product functionality and not for help in deploying or using the
template or script itself.

Unless explicitly tagged, all projects or work posted in our
GitHub repository (at https://github.com/PaloAltoNetworks) or
sites other than our official Downloads page on
https://support.paloaltonetworks.com are provided under the best
effort policy.

Type yes to confirm you have read the message above: yes
Message accepted.
Traceback (most recent call last):
  File "/usr/local/bin/pc", line 8, in <module>
    sys.exit(cli())
  File "/Users/lkaut/Library/Python/3.10/lib/python/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/Users/lkaut/Library/Python/3.10/lib/python/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/Users/lkaut/Library/Python/3.10/lib/python/site-packages/click/core.py", line 1651, in invoke
    cmd_name, cmd, args = self.resolve_command(ctx, args)
  File "/usr/local/lib/python3.10/site-packages/click_help_colors/core.py", line 101, in resolve_command
    cmd_name, cmd, args[1:] = super(HelpColorsMultiCommand, self).resolve_command(ctx, args)
  File "/Users/lkaut/Library/Python/3.10/lib/python/site-packages/click/core.py", line 1698, in resolve_command
    cmd = self.get_command(ctx, cmd_name)
  File "/usr/local/lib/python3.10/site-packages/prismacloud/cli/__init__.py", line 135, in get_command
    mod = __import__(f"prismacloud.cli.{module_type}.cmd_{cmd_name}", None, None, ["cli"])
  File "/usr/local/lib/python3.10/site-packages/prismacloud/cli/cwpp/cmd_version.py", line 4, in <module>
    from prismacloud.cli.api import pc_api
  File "/usr/local/lib/python3.10/site-packages/prismacloud/cli/api.py", line 264, in <module>
    pc_api.configure(map_cli_config_to_api_config())
  File "/usr/local/lib/python3.10/site-packages/prismacloud/cli/api.py", line 33, in map_cli_config_to_api_config
    settings = get_cli_config()
  File "/usr/local/lib/python3.10/site-packages/prismacloud/cli/api.py", line 100, in get_cli_config
    community_supported()  # Check if support message has been shown and accepted
  File "/usr/local/lib/python3.10/site-packages/prismacloud/cli/api.py", line 78, in community_supported
    with open(community_support_accepted, "w") as _accepted:
FileNotFoundError: [Errno 2] No such file or directory: '/Users/lkaut/.prismacloud/.community_supported_accepted'

Possible solution
programmatically create ~/.prismacloud/ directory
workaround --> `mkdir /Users/$USER/.prismacloud
Steps to reproduce
New install per user
Screenshots

Context

Your Environment
Using MacOS Python3.10

I will try to contribute this fix myself.

Submitted PR https://github.com/PaloAltoNetworks/prismacloud-cli/pull/80


RuntimeWarning: coroutine 'Redis.close' was never awaited

I'm using aioredis in a pytest fixture, (using pytest-asyncio), and just upgraded to 2.0.0.
At the end of my test run, I'm getting the following warning:
/home/brian/repos/medigator/venv/lib/python3.8/site-packages/aioredis/client.py:1047: RuntimeWarning: coroutine 'Redis.close' was never awaited
  pass
Object allocated at (most recent call last):
  File "/home/brian/repos/medigator/venv/lib/python3.8/site-packages/aioredis/client.py", lineno 1045
    loop.run_until_complete(self.close())

I'm not sure exactly why it's happening, maybe it has something to do with the way pytest-asyncio is managing the loop, but it isn't really critical (I'm not saying aioredis is doing anything wrong).
I was wondering if it would be possible to add the if conn check that close() does to __del__() also, such that if I make sure to manually clean it up beforehand, the close() coroutine won't get created at __del__ time.
Happy to open a PR if it would help.

@brianmaissy, since v2.0 you shouldn't close the Redis
https://aioredis.readthedocs.io/en/latest/migration/#cleaning-up

I'm seeing this too and haven't fixed it yet. I'll take a closer look!

I've been seeing this as well (on 2.0.0).  It seems to be related to the following code in client.py, specifically (I'm guessing) the create_task case:
def __del__(self):
    try:
        loop = asyncio.get_event_loop()
        if loop.is_running():
            loop.create_task(self.close())
        else:
            loop.run_until_complete(self.close())
    except Exception:
        pass

I'm at a loss as to why it's not being awaited, though.  The errors I'm seeing at the end of my test suite look like this:
aioredis/client.py:1047: RuntimeWarning: coroutine 'Redis.close' was never awaited
sys:1: RuntimeWarning: coroutine 'Connection.disconnect' was never awaited

Try asyncio.run_coroutine_threadsafe https://docs.python.org/3/library/asyncio-task.html#asyncio.run_coroutine_threadsafe Not sure if the coroutine is even put into queue for execution (you'll prob need to monitor the connections in redis-cli).

Try asyncio.run_coroutine_threadsafe https://docs.python.org/3/library/asyncio-task.html#asyncio.run_coroutine_threadsafe Not sure if the coroutine is even put into queue for execution (you'll prob need to monitor the connections in redis-cli).

Following up on this, I'm afraid using run_coroutine_threadsafe did not, in itself, fix or change the issue.  I'll continue looking at it to see if I can figure out specifically what's going on.

Any updates on this issue?

Any updates on this issue?

Not an update but I use non-optimal workaround with aiohttp in my code (aioredis==2.0.0):
async def redis_init(app):
    app['rc'] = aioredis.from_url("redis://<IP_ADDRESS>")
    del type(app['rc']).__del__

async def redis_close(app):
    await app['rc'].close()

def run():
   app = web.Application()
   app.on_startup.append(redis_init)
   app.on_cleanup.append(redis_close)

This code cleanups Redis connection on exit but skips __del__ call which produces this never awaited warining. The __del__ method is useless if you using aiohttp because .close() was actually never called.

Again, at least in django, we manually close any cache backend manuallly in a post-request hook. I'm +1 on just removing the __del__ method entirely and have the user manually call a disconnect method.

I have the same problem.
So far I am using the workaround suggested by jar3b but looking forward to clear solution.

@DemX86 please check master as we've merged a potential solution.

@DemX86 please check master as we've merged a potential solution.
That's great, thanks a lot!
That master with the solution commit will be released soon with a new package version, right?

Soon is iffy at the moment. @seandstewart thoughts on just releasing current version as patch? Incremental patching would help more people to slowly migrate.

Yeah I think that's a good idea. The migration to the latest redis client has numerous big changes so we'll want to have a separate release cycle and not block patches to the current version. We just need to make sure these changes make it into the new version as well.

So this should be resolved by #1227?

Yes. Closing for now. If it appears again, we'll reopen this issue.


Mapsui.Samples.Maui fails to build for Android

Mapsui Version
master as of today with modifications from PR https://github.com/Mapsui/Mapsui/pull/2084, which are necessary to restore the sln with VS4Mac (branch janusw:building_xamarin_forms_on_mac)
Mapsui Platform
MAUI
Device
Android 13
Describe the bug
Building Mapsui.Samples.Maui does not work when targeting Android (using VS4Mac v17.6). I see the following errors:
Mapsui/Samples/Mapsui.Samples.Maui/Platforms/Android/AndroidManifest.xml:
Error APT2260: resource mipmap/appicon (aka com.companyname.mapsui.samples.maui:mipmap/appicon) not found.
This error is likely caused by an issue with the AndroidManifest.xml file or an Android manifest generation attribute in a source code file. (APT2260) (Mapsui.Samples.Maui)

Mapsui/Samples/Mapsui.Samples.Maui/Platforms/Android/AndroidManifest.xml:
Error APT2260: resource mipmap/appicon_round (aka com.companyname.mapsui.samples.maui:mipmap/appicon_round) not found.
This error is likely caused by an issue with the AndroidManifest.xml file or an Android manifest generation attribute in a source code file. (APT2260) (Mapsui.Samples.Maui)

/usr/local/share/dotnet/packs/Microsoft.Android.Sdk.Darwin/33.0.68/tools/Xamarin.Android.Aapt2.targets(3,3):
Error APT2067: failed processing manifest. (APT2067) (Mapsui.Samples.Maui)

Is this currently still an issue?

On current master (shortly after 4.1.0-preview.1), these errors seem to be gone, and Mapsui.Samples.Maui builds well for Android (with VS4Mac 17.6.4).


The range of distances

Hi, I'm using the package for fuzzy matching and want to convert the distance measure to a similarity measure. I would like to use min-max normalization to convert the distance to [0, 1] and use (1 - normalized distance) as my similarity measure. Is there any chance I could know about the upper bound of the distance between two Chinese characters in DimSim? Thanks!

Maybe you can use tanh?


Add Listing Page Top-Bar. Responsive and According to Design.

And some other minor css changes

Test it here : https://adityamahajan-io.github.io/skill-board/


How to use with composition API?

I try to use this plugin with a vue 3 application written in typescript. After loading the plugin in main.ts this way (removed various imports):
import VueMousetrapPlugin from "vue-mousetrap"
createApp(App).use(store, key).use(VueMousetrapPlugin).mount("#app")

But how to call it from a component that use the new composition API with <script setup lang="ts">?
Here $mousetrap, this.$mousetrap and other variations are not defined. For a Vuex store, that has a similar interface (this.$store) with the new composition API there is a call that returns a store that replaces this.$store. Any suggestion? Thanks!

I've had the same (or at least a very similar) problem, and I managed to solve it by replacing this package with a typed version of index.js, combined with the instructions on type-declaring globalProperties found in the Vue3 docs:
import { createApp, App as AppType } from 'vue';
import mousetrap, { MousetrapStatic } from 'mousetrap';
import App from './App.vue';

// Based on https://github.com/g33kio/vue-mousetrap/blob/master/index.js
const VueMousetrapPlugin = {
  install(app: AppType): void {
    app.config.globalProperties.$mousetrap = mousetrap;
  },
};

// See https://v3.vuejs.org/guide/typescript-support.html#augmenting-types-for-globalproperties
declare module '@vue/runtime-core' {
  export interface ComponentCustomProperties {
    $mousetrap: MousetrapStatic
  }
}

createApp(App).use(VueMousetrapPlugin).mount('#app');

Perhaps I'll play around with adding something like the above to the package directly when I have time. I'm not very familiar with making npm packages, so perhaps someone more experienced could do it more quickly.

Thanks for the suggestion!  Also I'll try the inject way. Thanks!


do not use go list to find go.mod file

The go list command fails if the go.mod file isn't well formed (like for
example one of the replace directives refers to a non-existent target).
This can be a problem, so find the go.mod file by looking directly for
it instead.

@myitcv @mvdan

Any particular reason you're looking for the file rather than, say, running go env GOMOD?

Any particular reason you're looking for the file rather than, say, running go env GOMOD?

Yup, the particular reason was that I didn't know about go env GOMOD :)
Will change to use that.


Uncaught TypeError: Cannot read properties of null (reading 'classList')

I'm using CDN and I think I properly followed this plugin according to the README.md example.
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bs-stepper/dist/css/bs-stepper.min.css">

<script src="https://cdn.jsdelivr.net/npm/bs-stepper/dist/js/bs-stepper.min.js"></script>

I create Stepper instance with jQuery and Vanilla way, but this always gives me error
util.js:20 Uncaught TypeError: Cannot read properties of null (reading 'classList')
    at a (util.js:20:107)
    at new e (index.js:51:7)
    at <anonymous>:1:11

My instantiation
jQuery
let stepper = new Stepper($('.bs-stepper')[0])

Vanilla
let stepper = new Stepper(document.querySelector('.bs-stepper'))

You haven’t added the .bs-stepper class to your html tag.

You haven’t added the .bs-stepper class to your html tag.

Edited the code, yesterday I was using the same code from the readme file.
I tried using both vanilla and jQuery way, and it still didn't find the .bs-stepper class.
Today I try again and it just works, turns out I was including the wrong blade file which didn't contain the stepper element.
Thank you for your response.


Logic exception on php artisan optimize.

Laravel Version
11.20.0
PHP Version
8.3
Database Driver & Version
MySQL 8.0.33
Description
hi, i'm using laravel breeze with fortify for authentication. Recently i updated to latest laravel version. using composer update. When i use php artisan optimize before deployment. im getting logic Exception error for optimizing routes. the erorr message was like
Unable to prepare route [confirm-password] for serialization. Another route has already been assigned name [password.confirm].
I never had the route named password.confirm apart from the one which ships with laravel. After looking in to route list
there are two routes named password.confirm.

password.confirm › Auth\ConfirmablePasswordController
password.confirm › Laravel\Fortify › ConfirmablePasswordController

As i never touched the routes that ships from laravel. I tried the same with the fresh installation of laravel with breeze and fortify. The error message still exists. help me solve this.
Steps To Reproduce
a fresh laravel install with breeze and fortify.
and the Optimization command
php artisan optimize

Laravel Breeze doesn't requires Laravel Fortify. Why would you install both?

oops! my bad. thanks a lot.


Improvments on UI / UX

I've changed a little the UI and added support for datetime inputs (to create a backfill for a specific hourly process for example)

Hi Leo,
Thanks a lot for your contribution. I am approving your PR :)


eslint Unsafe assignment error on users.getByUsername() results

An eslint error occurred after updating to the latest npm release. The change in openapi-types.ts at line 37676 may have introduced an ambiguity that eslint has trouble with.  vscode appears to be confused as well.  This was found in gitgitgadget dependabot pull request failing.  This was referenced in a octokit/rest.js/ comment.  The error is:
error  Unsafe assignment of an "any" value  @typescript-eslint/no-unsafe-assignment
The code compiles okay but gets errors in vscode and eslint.  There may be some confusion between 200 and 202 status codes both being successful but this is just a guess.

Thanks Chris for opening the issue, I'll try to have a look into it tomorrow US Pacific time

I understand this may be caused by eslint needing a better understanding of what is returned now that there is a new status.  It may be choosing differently than the compiler.
However, how is a 202 status supposed to work with a users.getByUsername() request?  Is it really a valid response?

I'm looking into this now.
To start out, here is a TypeScript playground that reproduces the problem
import { Octokit } from "@octokit/rest"

const octokit = new Octokit()

const { data: user } = await octokit.users.getByUsername({ username: "" });
user.login // should be string but is any, see https://github.com/octokit/openapi-types.ts/issues/77

const { data: repo } = await octokit.repos.get({ owner: "", repo: "" });
repo.name // is typed correctly

Thanks for looking.
Changing playground to get past the problem:
import { Octokit } from "@octokit/rest"

const octokit = new Octokit()

const response = await octokit.users.getByUsername({ username: "" });

if ( response.status === 200 ) response.data.login;

Still wondering about why a 202 was added.

Thanks! I have to take care of something else first I should get to it today

Still wondering about why a 202 was added.

It was most likely added to the OpenAPI spec.
Which brings up the question: this is probably not a bug, but a feature? The docs say that a 202 response is possible: https://docs.github.com/en/rest/reference/users#get-a-user
But I don't see how a 202 response makes sense here. Could you please open an issue at https://github.com/github/rest-api-description about this? The current specification can be found here: https://github.com/github/rest-api-description/blob/main/descriptions/api.github.com/api.github.com.yaml, in there search for "/users/{username}". There should be a 202 key in the responses object, and I think that is incorrect.

Which brings up the question: this is probably not a bug, but a feature?

Or is it a compiler bug?  Should the compiler require a status check in order to infer what it is dealing with?

But I don't see how a 202 response makes sense here. Could you please open an issue at https://github.com/github/rest-api-description about this? The current specification can be found here: https://github.com/github/rest-api-description/blob/main/descriptions/api.github.com/api.github.com.yaml, in there search for "/users/{username}". There should be a 202 key in the responses object, and I think that is incorrect.

Done.

blocked by https://github.com/github/rest-api-description/issues/288

blocked by github/rest-api-description#288

What does this mean?  Nothing can happen here without the referenced issue being resolved?  Any idea how long that can take?
One reason I am asking (not to hijack) is file-commit has many optional fields that seem like they should be required and  thinking I should open an issue for it.

Nothing can happen here without the referenced issue being resolved

correct. There are no manual edits in this repository, it is all automated. All we do is transpile the OpenAPI spec files from github/rest-api-description to TypeScript declaration files. Sometimes there are bugs in the transpilation process, that is something we have to fix here, but in most cases the problem is at the source, which has to be addressed in github/rest-api-description

This should be fixed now. The issue upstream has been fixed. If this is still an issue, please feel free to holler


Possible perf improvement

I am not sure as to the performance improvements but for reading a long string, there will be a multiple allocations. This is because strings in Javascript are immutable and adding a character to a string causes a new allocation. Instead this change using an Array to temporary aggregate the characters and then at the end, join them together. There seems to be some change in benchmarks but they varied a lot.

Good point! We should definitely look into this, although it will likely only pay off for larger strings. String building in JS is tricky — it's fast up until the string is 12 characters, then it gets slow. See this thread https://twitter.com/mourner/status/973664460291411969
We should probably try some more benchmarks (with different string lengths) to see how this affects performance, and also maybe try buffered concatenation like above.

Agreed. String building is weird in JS. I recently benchmarked some code and was surprised to find that simple string concatenation was nearly twice as fast as allocating a buffer of exactly the write size and writing into it.

Yes, I noticed this in reading an attribute in a MVT which is a longer string.

This is a pretty unscientific test but this is the difference this pull request makes between the two in panning in Openlayers with a layers which include longer strings in a Vector Tile. Looks like a large reduction in memory allocated for the PBF (see readUTF8 at the top of the first list). Also we could include a check if end > 12 use string concatenation otherwise use arrays but this could be a micro-optimization for Chrome...

@nicholas-l note that profiling like this can be misleading — e.g. V8 has weird optimizations that can change which function allocations are attributed to, but the total size (~7.5MB) looks about the same.

This was addressed in #109 — should be much faster for long strings in the browser now.


A3-1-5: Exclude instantiated templates and compiler generated members

Affected rules

A3-1-5

Description
Exclude instantiated templates from this rule here:
https://github.com/github/codeql-coding-standards/blob/main/cpp/common/src/codingstandards/cpp/Class.qll#L184
Also exclude compiler generated members.
Example

there is no example, so it is a bit unclear what the goal is - based on the cited library location already specifying member functions that are not involved in instantiated templates
however, when looking at this rule perhaps this issue had something to do with this part of the rule not being constrained to avoid template instantiations here
all in all, I think the rule logic needs more work though and that will be captured in this issue

Apologies, I should have provided a permalink here, this was the line I meant we needed to change:
https://github.com/github/codeql-coding-standards/blob/76440323596bc43ad125cbf8f3eb72c1b4c4933b/cpp/common/src/codingstandards/cpp/Class.qll#L195


the prediction results are all black

I fixed the errors in the model prediction in the same way as you, but now the prediction results are all black. What's the problem. What I did was a dichotomy. During the test, there was such a warning:

I solved the above problem, but the predicted result looks very bad

the tensorboard is as follows：

I can't see your tensorboard.

I can't see your tensorboard.

Can I see your hparam.py? I guess you set 'croporpad' in a wrong way.

I set the same parameters of hparam.py as you

I haven't changed anything except my own dataset

You should modify 'croporpad' at your own dataset.

Different cases in my data have different sizes，so how can I set the croporpad according to my own data?

In many slices in my case, some contain the parts to be segmented and some do not (the label is all black). Do I need to remove the slices that do not contain the parts to be segmented?

Yes.


Extraction of the Operation History list as a downloadable JSON file

Closes #4498
Changes proposed in this pull request:

Enabled the extraction of the Operation History list of actions, which is a JSON object, by downloading as a JSON file, called "history.json"
On the Extract operation history dialog, added a button that can be used to initiate the above task, and placed it on the same level as the "Select all", "Unselect all" buttons, with a right float (to be placed close to the JSON textarea).

For the purpose of creating the downloadable file and actually downloading it on the user's computer, I used a small utility function from the following StackOverflow answer: https://stackoverflow.com/a/18197341/5564816
This approach works with HTML5, however, it could be prone to potential compatibility issues with old browsers.
If you have a better approach to accomplish this task, please share them with me in order to adapt and use them on the code! Also, as this is my first PR, please forgive me if I have missed anything else and I would really appreciate your feedback!

Ah, also, if you feel like it, you could add a UI test for this feature:
https://docs.openrefine.org/technical-reference/functional-tests