Unable to locate MIP Scanner

I have configured the MPARR collector, and I am able to run the DLP Template Report v2 in PowerBI but I cannot use the MIP Scanner report because there is no table called "MIPScanner"

Hi @jb382023 next week I´ll release new templates for Power BI, after the Webinar that is set to September 29 at 10.00AM CST, if you want to join, you can register yourself at https://aka.ms/KD-Events
On that event I´ll explain how to use some templates, and explain them, happens that you're ok, no MIP Scanner table exist on Logs Analytics, the table on Power BI is created using some KQL  queries and Power BI functions that collect the data from the common tables located on Logs Analytics.


Potential performance improvement

https://github.com/aws-cloudformation/cfn-lint/blob/46cbec6be520f898cc8f98e2eaad9221483fa75a/src/cfnlint/decode/cfn_json.py#L503
I don't have the time to make/test this change in your project, but I was working with the team over at Bridgecrew.io's checkov project and identified a potential performance improvement for them, where it was using a function like yours above.
If you're interested, the fix I proposed is here.
Thanks!

@noahjohnhay and @larryboymi thank you.  I think this is all merged in and published.


Network not accessible on single host due to too many connections

Some times the network on a single host not working properly,  containers on this host could not be reached for a short period randomly.
we found the network-manger on this host got following error
11/27/2017 9:05:28 AMtime="2017-11-27T17:05:28Z" level=info msg="CNI down" cid=b501a06ad7639c5af6e0c7c2d803b32ecaed5ad22e7589237e953f4824154408 networkMode=ipsec
11/27/2017 9:05:29 AMtime="2017-11-27T17:05:29Z" level=error msg="vethsync/utils: error deleting dangling veth: &{{8707 1500 0 vethrb501a06ad7 4e:73:da:cf:93:5b up|broadcast|multicast 69699 3 3 <nil>  0xc42502a0e8 0 <nil> ether} }"
11/27/2017 9:05:43 AMtime="2017-11-27T17:05:43Z" level=info msg="Setting up resolv.conf for ContainerId [7045e552225bf828374693da2aa1c240fe73840dd0d62c6a32b336408f225a1a]"
11/27/2017 9:05:43 AMtime="2017-11-27T17:05:43Z" level=info msg="CNI up" cid=7045e552225bf828374693da2aa1c240fe73840dd0d62c6a32b336408f225a1a networkMode=ipsec
11/27/2017 9:05:45 AMtime="2017-11-27T17:05:45Z" level=info msg="CNI up done" cid=7045e552225bf828374693da2aa1c240fe73840dd0d62c6a32b336408f225a1a networkMode=ipsec result=IP4:{IP:{IP:<IP_ADDRESS> Mask:ffff0000} Gateway:<IP_ADDRESS> Routes:[{Dst:{IP:<IP_ADDRESS> Mask:ffffffff} GW:<nil>} {Dst:{IP:<IP_ADDRESS> Mask:00000000} GW:<IP_ADDRESS>}]}, DNS:{Nameservers:[] Domain: Search:[] Options:[]}
11/27/2017 9:19:05 AMtime="2017-11-27T17:19:05Z" level=info msg="CNI down" cid=7045e552225bf828374693da2aa1c240fe73840dd0d62c6a32b336408f225a1a networkMode=ipsec

This issue happened several times on different hosts within our cluster.
Each time there are some services which have many connections from other hosts were scheduled on the host  that has unstable network issue.
We assume maybe it reach some kind of connection limit on particular host and the health-check agent on that host is monitoring too many backends  causing the network unstable . so we disable the health-check agent on that host, it kind fixed the problem on that host.
Just wondering do we actually have limit of connections on each host that may causing network-mangager unstable? how we can check/increase the limit?

Useful
Info

Versions
Rancher v1.6.10 Cattle: v0.183.22 UI: v1.6.23

Access
github admin

Orchestration
Cattle

Route
service.containers

Are your services seeing a high load (how many sustained connections)? Your service container might need tuning to accept more connections. That service might be overloaded and might not be able to respond to the health checks.

hi aemneina,
Thank you for your reply.
Yeah, on that host we have a service (A) that have ~500 connections.
But looks like  other services (B, C, D ....) on the same host, which don't have many connections on each container, also failed health-check randomly. (Totally number of these services is about 70.)
We assumed high totally connection number on the host make the network-manager not function properly, since healthcheck agent also have a lot of connections, so we disabled it on that host and the situation was alleviated a lot.  Reducing health check interval could also help .
Later on we also tried to scheduled service A to a separate host, and the network on the original host seems stable now.
But still wondering why network-manager got unstable (or something else that make the whole network on the host not work,  affecting all containers not only one ) when total connection on host is high?
another question, how can we check the actual backends number the healthcheck agent is monitoring?
Thanks again for the help.

With the release of Rancher 2.0, development on v1.6 is only limited to critical bug fixes and security patches.


Make sure webpack config has expected entries.

Also, update setuptools so that pip can install other packages properly.

Hi, @manthey, This looks cool.
I have noticed there is something changed with the girder master but didn't look into it.
This PR fixes the webpack resolve helper Hammer issue.
However, due to some change of girder master, this command will throw an error
girder-install web --watch-plugin minerva
Configuring plugin gravatar (plugin.yml, build=OFF)
Loading "plugin.js" tasks...ERROR
>> TypeError: Cannot read property 'module' of undefined

Do you have some idea on this error?

I have PR out in girder to fix that error.
https://github.com/girder/girder/pull/2315


feat: Add ratchet-from option

Fix #8
This PR finally adds the ratchet functionality. In essence, by adding e.g. ratchet-from: 'origin/main' to the with-block of the configuration for buildbreaker, only the lines changed from the main branch are considered.

Codecov Report

Merging #41 (3471295) into main (8561a6e) will increase coverage by 0.38%.
The diff coverage is 96.15%.

@@            Coverage Diff             @@
##             main      #41      +/-   ##
==========================================
+ Coverage   92.71%   93.10%   +0.38%
==========================================
  Files           6        6
  Lines         151      174      +23
  Branches       10       17       +7
==========================================
+ Hits          140      162      +22
- Misses         11       12       +1

Impacted Files
Coverage Δ

src/main.ts
91.93% <95.83%> (+1.69%)
:arrow_up:

src/sorald.ts
89.18% <100.00%> (+0.61%)
:arrow_up:

Continue to review full report at Codecov.

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

@algomaster99 Ready for final review. You can see my comments on imports, I think we should just leave it for a separate PR and restructure all imports according to some format.
Right now, I'm thinking that types (e.g. ClosedRange) should be imported with named imports. That's because they typically appear in type annotations, and as you said, typing ranges.ClosedRange can make something like a function declaration much longer than it needs to be.
As for functions, I prefer using them with the qualified name (e.g. ranges.overlapsAny), as it makes it clear where they come from, and they aren't used in function headers or the like and so the added length isn't that much of a problem.
WDYT?

I prefer using them with the qualified name (e.g. ranges.overlapsAny), as it makes it clear where they come from,

Keeping the conventions aside, this standalone makes sense and it indeed makes it clearer to identify where the function comes form.

can make something like a function declaration much longer than it needs to be.

But if you decide to create an instance first and then use the class methods, then this does not hold. Named export anyway sounds like a good idea. You could use default imports too but I think since it allows one to import it by any module name, the consistency might be lost if that module is used across a lot of file. For example, one file could import it as A, other B. Thus, I feel name imports will be better.

@slarse dropped my comments. Once you address them, I will mark the PR as approved. :)

@algomaster99 comments addressed


No longer assigning awaits to temporary variables.

Fixes #1201.

I'm pretty ambivalent about this change. I realize it would be a massive manual labor pain, but anything we can do to make it slightly pretty like
(await myContract.myMethod())
  .should.be.bignumber.gte(5)

instead of the very long lines?

I don't think any of the lines are massively long (or eslint would've complained), and quite like that they read very naturally as a single sentence e.g. (await this.token.balanceOf(investor)).should.be.bignumber.equal(expectedTokenAmount);, not sure if multiple lines would increase readability.
Of course, this is a case-by-case thing and not a hard and fast rule.

Good reasoning @nventuro! merge away :D


Enhance documentation in the readme

What is B1 B2 S1 S2?
What do the letters B & S mean?
What does B1 B2 S1 S2 do?
What do the number values mean?
What effect does each parameter have on the output?
What effect does each parameter have depending on the set value?
Should they all be used at a value above 0?
Why do the parameters have different maximum values?

In the readme of this repo, I vaguely explain a little bit what the controls do. They are not abbreviations, although I concede that it does not make an effort to explain anything further.
You might be interested in reading the paper from the original authors. If anyone wants to contribute to the repository to enhance readability, PRs are welcome.

After trying out forge, I realize you might have intended to open an issue in the official forge repo. To put it clearly, this extension has nothing to do with forge. This is not the code forge uses, it has a completely different purpose. This is an extension for a1111 webui, not forge. In a1111 webui freeu isn't builtin, but in forge it is.


AccessControlListNotSupported: The bucket does not allow ACLs

Describe the bug
I keep getting this error on terraform apply:
error creating S3 bucket ACL for my-bucket: AccessControlListNotSupported: The bucket does not allow ACLs

Am I missing something?
To Reproduce
module "s3_private_bucket" {
  source         = "trussworks/s3-private-bucket/aws"
  bucket         = "my-bucket"

  use_account_alias_prefix = false
}

Expected behavior
I see no error
Additional context
Terraform v1.1.9
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v4.54.0

@Clasyc We're in the process of publishing a new release to fix this. I'll post back here when it's available.


WIP: new Wasmi bytecode

This PR adds the wasmi_ir crate to the Wasmi workspace which defines the new Wasmi bytecode, its encoding and decoding as well as utility definitions.
This does not yet use the new Wasmi bytecode in the Wasmi crate.
This is the first step towards https://github.com/wasmi-labs/wasmi/issues/1101.
ToDo

[x] Visit API

[x] CheckedOpDecoder::visit
[x] UncheckedOpDecoder::visit
[x] OpEncoder::{visit, pop_visit}

[x] Dispatch API

[x] UncheckedOpDecoder::dispatch
[x] UncheckedOpVariantDecoder::decode

[x] Patch API

[x] OpEncoder::patch

[x] Iterator API

[x] OpEncoder::iter yielding Op.
[x] OpEncoder::iter_mut yielding OpMut.

[x] Create Wasm br.table equivalent Wasmi bytecode operator and efficient encoding.
[x] Trait EncodeSize and trait FixedEncodeSize and impls.

Used to improve error checking of OpEncoder::patch.

[x] Have OpEncoder::get_mut API to quickly and easily mutate encoded Op.
[ ] Operators variants with 16-bit encoded immediate values:

[ ] i32 variants: saving 2 bytes per operator.
[ ] i64 variants: saving 6 bytes per operator.

[ ] f64-operator variants with 32-bit encoded immediate values.

This saves 4 bytes per operator and immediate.

Follow-Ups

[ ] Make every encoding 2 byte aligned so that most field (which are 2 byte in encoded size) have aligned memory access when decoded.
[ ] Maybe create fused i32.{and,or,xor}+i32.eqz fused operators as they exist in the current Wasmi bytecode.
[ ] Maybe re-create {copy, return}.span and copy.span.non-overlapping.

This is a much more efficient encoding scheme in certain scenarios. It has to be decided how common those scenarios actually are to make an assessment of how useful those operators are going to be.

Superseeded by https://github.com/wasmi-labs/wasmi/pull/1148.
We probably need a new attempt at this more involved Wasmi bytecode attempt at a later point in time.
This PR turned out to be far too complex to justify the new IR with way too much unsafe Rust code.
Fortunately, https://github.com/wasmi-labs/wasmi/pull/1148 turned out to be pretty simple and should still be able to deliver the possibility to implement new dispatching routines (and more) on top of it.


$util.share action

Documentation https://jasonette.github.io/documentation/actions/#utilshare
iOS Implementation here: https://github.com/Jasonette/JASONETTE-iOS/blob/develop/app/Jasonette/JasonUtilAction.m#L136

Added with https://github.com/Jasonette/JASONETTE-Android/commit/495be6857f9adc0a472917ae571cd10d7b9c9c5c


Support union type as index signature parameter type.

Given:
interface Foo {
  [key: string | number]: boolean;
}

I get
bleh.ts(2,4): error TS1023: An index signature parameter type must be 'string' or 'number'.

A workaround is:
interface Foo {
  [key: number]: boolean;
  [key: string]: boolean;
}

But, I need to match up the type of value, boolean. Since it's a repetition, it could be useful to programmers to specify index signature parameter type as string, number, string | number, or number | string.

If your string and number indexers are the same then you don't need to do this. A string indexer subsumes the numeric indexer. If there's something more involved for indexer types you needed maybe #2049 is relevant.


Texture Errors

[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]: ==================================================
[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]:   DOMAIN nuclearcontrol
[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]: --------------------------------------------------
[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]:   domain nuclearcontrol is missing 1 texture
[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]:     domain nuclearcontrol has 1 location:
[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]:       mod IC2NuclearControl resources at ...\mods\IC2NuclearControl-2.2.5a-GoingForTheKill.jar
[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]: -------------------------
[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]:     The missing resources for domain nuclearcontrol are:
[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]:       textures/blocks/light/lamp4.png
[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]: -------------------------
[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]:     No other errors exist for domain nuclearcontrol
[22:28:38] [Client thread/ERROR] [TEXTURE ERRORS]: ==================================================

Reposted from https://github.com/MyM-ModpackTeam/B2B/issues/9
Sorry if this is not the correct format for the post. Is their any other information you might need?

Although this is printed, it is not really an issue. I'll suppress it on our end so you don't see it in the chat.


Increase horizontal label padding

For iOS horizontal label padding the default is given in labelBeside:
https://github.com/react-navigation/react-navigation-tabs/blob/caa50fe78207be8c8a33d3ef3ba156ff84e6f544/src/views/BottomTabBar.js#L464
Example with react-navigation defaults (except for tint):

Example from Apple native padding:

In comparison I would say, the labelBeside needs a bit more space.
Something like 25 looks right:

re: the uikit default padding, it appears that the icon is also significantly larger in the react-navigation screenshot in your app. you may want to just shrink it when in horizontal mode, you can do this like so:
tabBarIcon: ({ horizontal, tintColor }) => <Icon name="whatever" size={horizontal? 20 : 25} color={tintColor} />

Good catch @brentvatne, I agree they do look a bit large! Sadly applying conditional size still does not give the expected result.
Btw icons should work with 25 pt with iPads [^1], don't they? iPad's TabBar is behaving differently, as compact != horizontal there. On iPad the UITabBar is never compact [^2], no matter what trait is used.
But that's already taken care of here:
https://github.com/react-navigation/react-navigation-tabs/blob/caa50fe78207be8c8a33d3ef3ba156ff84e6f544/src/views/BottomTabBar.js#L318
I'm using images (size @1 is 25px up to 75px @3) with the following navigationOptions for each of the tabs (including your suggested change now):
tabBarIcon: ({ focused, tintColor, horizontal }) => (
    focused
    ? <Image size={horizontal ? 20 : 25} source={Icons.productFilled} style={{ tintColor: tintColor }}/>
    : <Image size={horizontal ? 20 : 25} source={Icons.product} style={{ tintColor: tintColor }}/>
),

Still similar:

[^1]: https://developer.apple.com/design/human-interface-guidelines/ios/icons-and-images/custom-icons/ under "Tab Bar Icon Size"
[^2]: https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/adaptivity-and-layout/ under "Device Size Classes"

Verified the icon size not to be the source of the problem. Image is already fixed to 25 (px) in height and width with resizeMode: "cover". Using a very large icon (> 600px) I was able to verify the limits to be working correctly.
So it is actually the padding for labelBeside.


Add a withSpan (or similar) convenience API

We can close this issue since the question is addressed and we can create new issues for proposed convenience APIs
Originally posted by @dyladan in https://github.com/open-telemetry/opentelemetry-js-api/issues/164#issuecomment-1176500245
I propose we add an API which takes a callback, automatically creating and ending a span. This has been proposed in the past and blocked for administrative reasons explained in the previously linked ticket, but I think now is the time to address it.

For reference, we made those utils at my company:
import * as otelAPI from '@opentelemetry/api'
import * as otelCore from '@opentelemetry/core'

export function withSpan <T extends () => ReturnType<T>> (span: otelAPI.Span, fn: T): ReturnType<T> {
  return otelAPI.context.with(
    otelAPI.trace.setSpan(otelAPI.context.active(), span),
    fn
  )
}

export function withoutSpan <T extends () => ReturnType<T>> (fn: T): ReturnType<T> {
  return otelAPI.context.with(
    otelCore.suppressTracing(otelAPI.context.active()),
    fn
  )
}

export function newSpan (spanName: string, attributes: otelAPI.SpanAttributes) {
  return otelAPI.trace.getTracer('default').startSpan(spanName, {
    attributes
  })
}

type Unpromisify<T> = T extends Promise<infer U> ? U : T
export async function withNewSpan <T extends () => ReturnType<T>> (
  spanName: string,
  attributes: otelAPI.SpanAttributes,
  fn: T
): Promise<Unpromisify<ReturnType<T>>> {
  const span = newSpan(spanName, attributes)
  // note: we await even if not needed to ensure we end() the span when the function
  // as been fully executed
  // tslint:disable-next-line: await-promise
  const result = await withSpan(span, fn)
  span.end()
  return result as any
}

export function withNewSpanSync <T extends () => ReturnType<T>> (
  spanName: string,
  attributes: otelAPI.SpanAttributes,
  fn: T
): ReturnType<T> {
  const span = newSpan(spanName, attributes)
  const result = withSpan(span, fn)
  span.end()
  return result as any
}

I wonder if getTracer should return a "sugared" tracer which implements convenience APIs so that we don't have to implement in SDK (and bump required version)?
export class SugaredTracer implements Tracer {
  constructor(private _tracer: Tracer) {
    this.startSpan = _tracer.startSpan.bind(_tracer);
    this.startActiveSpan = _tracer.startActiveSpan.bind(_tracer);
  }

  startActiveSpan: Tracer['startActiveSpan'];
  startSpan: Tracer['startSpan'];

  withSpan <F extends (span: Span) => unknown>(name: string, options: SpanOptions, fn: F): ReturnType<F> {
    const span = this._tracer.startSpan(name, options);
    const ret = fn(span);
    if (ret instanceof Promise) {
      return ret.finally(() => span.end()) as ReturnType<F>;
    }
    span.end();
    return ret as ReturnType<F>;
  }
}

Above helpers require also @opentelemetry/core which would be problematic for API package.

only withoutSpan

Another decision point would be if such a helper made the span the active span or not (and/or if there should be an equivalent withActiveSpan if not).
Might be helpful to look at other languages that do this too:

Ruby uses a @tracer.in_span where you get a lambda parameter and it's auto-closed for you. It's explicitly called out in the API docs as the default you should use as an end-user.
Rust does the same as Ruby, and although it's not called out as the default the same way as Ruby, it's so much better than the alternative (you get to manage move semantics, whee!) that it's likely a de facto default. When you use in_span, the span in the lambda is the currently active span.
C++ introduces a scope-based lifetime when you mark a span as active, avoiding the need to close the span unless you must close it prior to going out of scope
Python extends the resource management metaphor of with to spans and has syntactical decorators to accomplish this, which are both not applicable for JS
.NET has resource management like Python (using/use) and similarly extends the metaphor to spans

I think most of the time you're trying to wrap a callback in a span you would want it to be active in the callback. Almost by definition everything that happens within the callback would be a child of the callback operation and should be reflected that way in tracing data.

Any concerns with implementing this? I'd be happy to contribute the sugared tracer design if that's preferred (it sounds like that would go in this repo and not the SDK repo?): https://github.com/open-telemetry/opentelemetry-js-api/issues/165#issuecomment-1176561224

@cartermp Are you working on this?
I would really like to see a SugaredTracer with some additional convenience functions.
If not, I would start to look into it myself.

@secustor I haven't started it no - was looking to see if anyone felt that was the right direction to go. But if you're keenly interested as well, I'd be more than happy to help review and discuss its usage. I too would love to see this added.

Moving this to the main JS repository since we have decided to merge the repositories together.


Targets (with variables in the name) not considered as whole symbol

Example:
$(PREFIX)test_app: ...
is interpreted as 2 symbols:
$(
)test_app

Fixed in release 1.0.5.


Optimization for DDL execution

Feature Request
Is your feature request related to a problem? Please describe:

In the current replication model, DDL is executed synchronously and blocks all DMLs in other tables. This could cause replication block in some scenarios

the DDL is slow, such add index to a large table.
the replication of one table is slow, other tables will have to wait for this table catch up because the DDL is a strong barrier.

Describe the feature you'd like:

[x] Currently DDL execution has no timeout, should we add some restriction. https://github.com/pingcap/ticdc/pull/936
[ ] Once the add index command has been sent to TiDB, even the client is timeout, we can ignore this error and continue replication.
[ ] Could we add some mechanism to allow single table DDL doesn't block DML replication of other tables.

/assign


allow multiple whalesong driver instances

This fix allows whalesong to support multiple firefoxdriver instances by setting a random marionette port instead of hardcoding the port in code.

What trouble will we run into if this was synchronous? I believe it needs to be synchronous since this is called only once during the driver initialization.

This needs to be synchronous since it is called in the class constructor. I do understand your concern but I tested it and there is no such delay as in performance except for the few seconds it waits. Your suggested start_server in asyncio is not best fit for this since we have to for the port number before we can proceed any further.

The only way we can use async in this context if we use factory pattern to init the driver. This would mean implementing a totally different way to initialize the driver. Do you think not using async in this case outweighs the benifits of using an async method?

One other way we can proceed about this is to let the user assign one himself. Should I do that?

Why you don't do it at this point? https://github.com/alfred82santa/whalesong/pull/96/files#diff-60f3e52bd1e97480f04fb0d902ecd524R72
In general, it's a bad practice to run sync external code (OS call) inside async code. Some times we need to do it, but I think it is not the case.

Made a pull request . Please review it .


Create a TensorFlow Addons Release to work with TF Nightly

Please create a TF Addons Release that includes #2829 so it works with TF Nightly and fixes https://github.com/keras-team/keras/issues/17986

@bhack

Nightly builds are built for the latest stable release of TF and we make no guarantees of compatibility with tf-nightly (We used to and it burned a ton of time for bugs out of our control):
https://github.com/tensorflow/addons#nightly-builds
We do publish on commit though so #2829 should have fixed this:
https://pypi.org/project/tfa-nightly/0.20.0.dev20230418095337/


Make TabIndex an DesignableProperty

I think the view position do not guarantee a tab order because it's handled by the View.TabIndex property. The user may want to change another tab order than the position. Should be a good idea to give to the user a way to change the TabIndex on the view properties UI.

Originally posted by @BDisp in https://github.com/gui-cs/TerminalGuiDesigner/issues/78#issuecomment-1232776365

I also think a good idea to add the same to the TabStop.


improve ding-dong bot

[x] ding-dong with text
[x] ding-dong with image from url
[x] ding-dong with image from local file
[x] file-box need to be improved
[x] pytype test issues
[x] watch dog

At last pr, python-wechaty is not a runnable version and there were many modules need to change. I have list some issues at the comment which we fix them all. I think this is the time that we can work on the small pr.

Merged.
Thank you very much for the great improvement for our Python Wechaty, cheers!

Six six six! Cheers! BTW, the module Memory-Card may take a few more days .


PlaneRenderer - Check the hitTest calls

Is the topMostPlane actually the top most here?
https://github.com/SceneView/sceneview-android/blob/7ad2ec401649fa45031d84a28140eb58d2dda7e6/arsceneview/src/main/kotlin/io/github/sceneview/ar/scene/PlaneRenderer.kt#L156

Yes it should
There is definetly something to do to clean this part:
https://github.com/SceneView/sceneview-android/blob/3140b34c66cc6c5306f5e79a978df04013cfdf33/arsceneview/src/main/kotlin/io/github/sceneview/ar/scene/PlaneRenderer.kt#L134-L162
Originally posted by @ThomasGorisse in https://github.com/SceneView/sceneview-android/issues/39#issuecomment-1066123186

Fixed: https://github.com/SceneView/sceneview-android/pull/39#issuecomment-1066123186


Fix layer_norm_eps in BERTEncoder on 0.9.x

https://github.com/dmlc/gluon-nlp/issues/1183#issuecomment-621659400

Job PR-1214/3 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-1214/3/index.html


ci: build and test portable-ruby

Thanks for taking up this torch, @xu-cheng !

So FYI, here is the current state of this PR.

The CI can now successfully build and test portable ruby on macOS and Linux x86_64.
For ARM64v8, the building should be fine. I need to fix its test though by using a different docker image. I will take a look at this issue late this week.
One outstanding issue is that running ARM binaries using QEMU simulation  is extremely slow. As such, it takes several hours to build the portable ruby. As far as I am aware of, there are two solutions to improve the performance in the future: (1) using native hardware; (2) using cross-compiling.
BTW, the current portable ruby for ARM64v8 merged in https://github.com/Homebrew/brew/pull/6595 should be updated. I just realized it was built against the glibc which is too new.  I have built a new one in CI with old glibc. It can be downloaded from https://github.com/Homebrew/homebrew-portable-ruby/suites/267549269/artifacts/132613 Though, test should be done before uploading it to Homebrew.
I was not able to make portable ruby for ARM32v6 work for now. The docker does provide official images for both ARM32v6 and ARM32v7. However, I have encountered following problems:

The old portable ruby (https://github.com/Homebrew/homebrew-portable-ruby/releases/download/2.3.7/portable-ruby-2.3.7.armv6_linux.bottle.tar.gz) cannot be used in ARM32v6. The reason is that the old portable ruby requires dynamic linker at /lib/ld-linux-armhf.so.3 whereas the docker image provides the dynamic linker at /lib/ld-linux.so.3. I am not sure whether this is the problem of the docker image or the old portable ruby. If someone has the actual hardware with ARM32v6 CPU, it would be helpful to let me know which dynamic linker should I build the portable ruby against. If it is /lib/ld-linux-armhf.so.3, I cannot find suitable docker image.
For ARM32v7, the dynamic linker is /lib/ld-linux-armhf.so.3.  So I can use the old portable ruby to bootstrap. However, we need to fix a bug in Homebrew to build ARM32v7 binaries. Currently, it passes the wrong -march flag.
All in all, I am not sure which arch we should support ARM32v6 or ARM32v7. It does not seem we can use the portable-ruby for them as different dynamic linkers are used.

/cc @sjackman for comments.

Thanks @xu-cheng. I'd like to propose (to @sjackman) that given the above we don't try to support both ARM versions for portable Ruby or, ideally, either. I don't see ARM machines as being nearly as likely for the end-user to not have root and we could instead modify the vendor-install code to instruct those users to install Ruby 2.6 manually through their distro instead.

Thanks @xu-cheng. I'd like to propose (to @sjackman) that given the above we don't try to support both ARM versions for portable Ruby or, ideally, either. I don't see ARM machines as being nearly as likely for the end-user to not have root and we could instead modify the vendor-install code to instruct those users to install Ruby 2.6 manually through their distro instead.

Building the portable-ruby bottle for ARM32 is quite a bit slower, taking hours, whether on real AMR hardware or emulating. I'm okay with dropping ARM32.
Building the portable-ruby bottle for AArch64 using @zbeekman's ARM64 hardware was quite painless, and took half an hour. I suggest that we build portable-ruby for x86_64 on macOS and Linux, but not for ARMv6 and ARM64, just for reasons of speed. Given how rarely we update portable-ruby, building the bottle manually doesn't seem like a big issue to me. We can include instructions in the README.md how to build the bottle for ARM64 using either real hardware or emulating using Docker Desktop for macOS.

All in all, I am not sure which arch we should support, ARM32v6 or ARM32v7? It does not seem we can use the same portable-ruby for both of them as different dynamic linkers are used.

It may be moot, but use the dynamic linker used by Raspbian, which is /lib/ld-linux-armhf.so.3. The primary reason to support ARM32 was for Raspberry Pi, which is a 32-bit user space, even when the hardware is 64-bit, like with the Raspberry Pi 4. I wonder if building portable-ruby on the Raspberry Pi 4 would be faster.

May I ask what hardware is Raspbian used? ARM32v6 or ARM32v7.

Raspbian the Linux distribution is targeted for ARMv6 to support running on the Raspberry Pi 1. They have only a single distribution that runs on all versions of the Raspberry Pi hardware.
Raspberry Pi the hardware:
RPi1 ARMv6
RPi2 ARMv7
RPi3 ARMv8, which supports both 64-bit AArch64 and 32-bit ARMv8
RPi4 ARMv8, which supports both 64-bit AArch64 and 32-bit ARMv8
See https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications

FYI, I can make ARM32v7 portable-ruby work with some bug fixes on Homebrew side.

What bug fixes are needed? Are far as I know, Homebrew/brew works fine on 32-bit ARM hardware, unless there's been bit rot.

I wonder whether the latest version of Raspbian has Ruby 2.6.3 or newer.

I think this PR is almost finished. Here are my proposal for moving forward.

The current ARM64 portable-ruby should be replaced as it is against glibc too new. We should update it to the one built in this PR. Since I don't have access to the release or Bintray, @sjackman would you mind to help this? You can download the new bottle here: https://github.com/Homebrew/homebrew-portable-ruby/suites/268830530/artifacts/136186
I will send a PR to homebrew to fix brew tests for ARM. The current test failed at some small problems, which should be easy to fix.
I will drop the support for AMR32 for now. But I can re-add support ARM32v7 (not ARM32v6) in the future.
There is a small problem. The docker linter reports a problem, which I believe is a false alarm. Should we remove the docker linter test in this case?
All in all, I think this PR is almost ready to be merged (after the portable-ruby for ARM64 is uploaded to Homebrew).

What bug fixes are needed? Are far as I know, Homebrew/brew works fine on 32-bit ARM hardware, unless there's been bit rot.

At least from my test using docker and simulation, the bottle buildings are failed due to incorrect -march=armv6 flag. If we pass -march=armv7, it will work fine.

What bug fixes are needed? Are far as I know, Homebrew/brew works fine on 32-bit ARM hardware, unless there's been bit rot.

At least from my test using docker and simulation, the bottle buildings are failed due to incorrect -march=armv6 flag. If we pass -march=armv7, it will work fine.

It's possible and fine to target -march=armv6 on armv7 hardware. We do a similar thing on x86_64 where we target the oldest supported macOS Intel hardware, regardless of which hardware we're actually building on.
That said, I'm fine dropping support for armv6 and moving to armv7, which drops support for the Raspberry Pi 1.

There is a small problem. The docker linter reports a problem, which I believe is a false alarm. Should we remove the docker linter test in this case?

Yeah, false positive. I'm fine with disabling just that one test.

The current ARM64 portable-ruby should be replaced as it is against glibc too new.

I can do that later today.

I think dropping armv6 is fine. rPi 1 is pretty old at this point.
I like the idea of cross compiling for ARM to speed things up, but given my (admittedly somewhat superficial) understanding of the complexities of homebrew compiler selection and environment sanitation makes me think that cross compiling portable ruby in a chroot will be challenging.

Cross compiling is likely to be quite difficult to get working in Homebrew.

Building the portable-ruby bottle for ARM32 is quite a bit slower, taking hours, whether on real AMR hardware or emulating. I'm okay with dropping ARM32.

👍

Building the portable-ruby bottle for AArch64 using @zbeekman's ARM64 hardware was quite painless, and took half an hour. I suggest that we build portable-ruby for x86_64 on macOS and Linux, but not for ARMv6 and ARM64, just for reasons of speed. Given how rarely we update portable-ruby, building the bottle manually doesn't seem like a big issue to me.

As the person who is rushing to get portable-ruby changes out based on Apple's unpredictable changes: it's a big deal to me. I'd rather we have something that I can run in a local Dockerfile (and in GitHub Actions) that might take several hours over something that relies on having access to the infrastructure of another maintainer.

The big questions that I'd love to be answered before we make any decisions on what we support/don't:

do we have any analytics on how many users there are of any of these bottles? If not: what are the download numbers like?
do any of the common Linux distributions for ARM provide Ruby 2.6.3? If not: what's the newest version of Ruby they provide? Are there any back ports online for a newer Ruby?

As the person who is rushing to get portable-ruby changes out based on Apple's unpredictable changes: it's a big deal to me. I'd rather we have something that I can run in a local Dockerfile (and in GitHub Actions) that might take several hours over something that relies on having access to the infrastructure of another maintainer.

CI needs to build and test portable-ruby for x86_64 on macOS and Linux using GitHub Actions and Docker. Those are our primary supported targets. Get those merged and shipped together.
In a second step, a developer (like me or Zaak) can build a bottle for AArch64 and/or ARM32 using emulation in Docker or real ARM hardware. That way ARM doesn't hold up our primary targets.

do any of the common Linux distributions for ARM provide Ruby 2.6.3? If not: what's the newest version of Ruby they provide? Are there any back ports online for a newer Ruby?

Distribution
Ruby Version

Ubuntu 16.04 (Xenial Xerus)
2.3.1

Ubuntu 18.04 (Bionic Beaver)
2.5.1

Debian 10
2.5.5

I have now find a way to build ARM32v6 portable ruby. Now I need help to upload them to releases and Bintray. @sjackman

ARM64v8: https://github.com/Homebrew/homebrew-portable-ruby/suites/268830530/artifacts/136186
ARM32v6: https://github.com/xu-cheng/homebrew-portable-ruby/suites/271156010/artifacts/142706

After this, I will be able to finalize this PR so it can be ready to be merged.

This PR now only depends on:

[ ] Final fix on brew tests:https://github.com/Homebrew/brew/pull/6618
[ ] Upload ARM32v6 and ARM64v8 bottles to:

[ ] Release
[ ] Linuxbrew Bintray

[ ] Updatevendor-install

If anyone else needs access to a physical aarch64 let me know. I think I can get it configured to run docker, so that would allow native container workflows. I sit on the same power grid as the White House (I think---it's nearby) and I've never had a power outage in the ~10 years that I've lived here. I'd be happy to maintain the hardware and make it available to Homebrew & maintainers if it would be useful. I agree with @MikeMcQuaid that we don't want to rely on maintainers' private hardware, but if it can help bootstrap docker images because of the native hardware, then I'm happy to lend it to the cause.
The machine in question is an RK3399 RockPro64 with a WD black NVMe SSD mounted via PCIe. I'm working on getting docker sorted as we speak.

In a second step, a developer (like me or Zaak) can build a bottle for AArch64 and/or ARM32 using emulation in Docker or real ARM hardware. That way ARM doesn't hold up our primary targets.

The problem with that approach is if you're bumping portable Ruby then anyone relying on the portable Ruby on ARM will have their Homebrew completely broken by a brew update. That no-one has complained about them still being broken does make me pretty dubious about the value they are providing.

After this, I will be able to finalize this PR so it can be ready to be merged.

Can this PR use the old Ruby until they are merged? I'd rather not have them merged until I can see that we have some sort of CI that can reliably build them.
If we have CI that demonstrates the ability to build them on my local machine using Docker: I'm begrudgingly OK with them being included. That's when @zbeekman's machine may be useful: building them on native hardware is going to be quicker for when we're uploading a new build.
I still question the value of providing these bottles when it appears their usage is low enough that in several weeks of people's installations being broken we've not had any bug reports/complaints.

The problem with that approach is if you're bumping portable Ruby then anyone relying on the portable Ruby on ARM will have their Homebrew completely broken by a brew update.

We have until the next stable release to build the ARM bottles without breaking users' installation.

That no-one has complained about them still being broken does make me pretty dubious about the value they are providing.

There's a chicken-and-egg problem here. To build a userbase for Homebrew on Linux on ARM, Homebrew on Linux needs to work on ARM. Homebrew on Linux on x86_64 took years to build a userbase (over 20k users now).

We have until the next stable release to build the ARM bottles without breaking users' installation.

In this case we missed that and have had two stable releases since.

There's a chicken-and-egg problem here. To build a userbase for Homebrew on Linux on ARM, Homebrew on Linux needs to work on ARM. Homebrew on Linux on x86_64 took years to build a userbase (over 20k users now).

That's fair. I guess there's a wider debate there about "do we wish to build a user base for Homebrew on Linux on ARM" and, moreso, "does the lack of portable Ruby on ARM make it impossible to run Homebrew on Linux on ARM".
The Ruby bumps tend to coincide with macOS version bumps or security updates which are already fairly stressful times with time pressure. I'd really like it if we can find some way that allows people to run Homebrew on Linux on ARM that doesn't rely on this repository and Homebrew/brew having to provide portable rubies in a timely fashion.
Perhaps vendor-install could source these URLs from e.g. a bash script in a tap which could also host the portable Ruby bottles? vendor-install could be updated to know about this script in this case and suggest that users run it or manually install their own Ruby if it's not available/updated yet.

All test passed.

We have until the next stable release to build the ARM bottles without breaking users' installation.

In this case we missed that and have had two stable releases since.

With @xu-cheng 's infrastructure in place, the technical aspect of building these bottles should be easier now. Any of @xu-cheng @zbeekman and myself are able to provide the people power needed to update the bottles, so I believe we have the resources in place to make this update more timely next time around.

That workflow is a thing of beauty. Nice work!

With @xu-cheng 's infrastructure in place, the technical aspect of building these bottles should be easier now. Any of @xu-cheng @zbeekman and myself are able to provide the people power needed to update the bottles, so I believe we have the resources in place to make this update more timely next time around.

Ok, I'll trust you all on that. Hopefully it's not for a while. Thanks all! A few comments and this should be good to go.

Great work here @xu-cheng!

Thank you for this work, @xu-cheng, and thanks for merging, Mike! 🎆


Support Provider.ifPresent(Consumer)

We have some code that uses if (getOrNull() != null) to allow for null values not to be handled. The code would look a lot better with introducing something akin to java.util.Optional.ifPresent(Consumer<T>).

Duplicate of #13401


[stable/locust] Fix NOTES

Description
Locust chart deployments with service type set to NodePort or LoadBalancer fails. This PR fixes it.
Checklist

[ ] Title of the PR starts with chart name (e.g. [stable/mychartname])
[ ] Github actions are passing

Thanks @zabudskyi! You will need to bump the chart version before it can be merged.

@max-rocket-internet Currently it is 0.9. Should I add patch version part?
So it will be 0.9.1


cargo bundle --release报错

$ cargo bundle --release
Updating crates.io index

error: failed to select a version for gdk-sys.
... required by package gdk v0.16.0
... which satisfies dependency gdk = "^0.16" of package gtk v0.16.0
... which satisfies dependency gtk = "^0.16" of package libappindicator v0.8.0
... which satisfies dependency libappindicator = "^0.8" of package tray-icon v0.9.0
... which satisfies dependency tray-icon = "^0.9.0" of package MessAuto v0.6.3 (/Users/david/MessAuto)
versions that meet the requirements ^0.16 are: 0.16.0
the package gdk-sys links to the native library gdk-3, but it conflicts with a previous package which links to gdk-3 as well:
package gdk-sys v0.18.0
... which satisfies dependency ffi = "^0.18" of package gdk v0.18.0
... which satisfies dependency gdk = "^0.18" of package gtk v0.18.1
... which satisfies dependency gtk = "^0.18" of package tao v0.23.0
... which satisfies dependency tao = "^0.23.0" of package MessAuto v0.6.3 (/Users/david/MessAuto)
Only one package in the dependency graph may specify the same links value. This helps ensure that only one copy of a native library is linked in the final binary. Try to adjust your dependencies so that only one package uses the links ='gdk-sys' value. For more information, see https://doc.rust-lang.org/cargo/reference/resolver.html#links.
failed to select a version for gdk-sys which could resolve this conflict
error: Result of cargo build operation was unsuccessful: exit status: 101

把 tao 的版本切回 0.22.3，因为和 tray-icon 依赖冲突，tray-icon 下个版本会更新依赖


Bump libstdc++ version to match devtools

This fixes #47

Thanks for catching this bug and contributing a fix!

This work has been released in 3.0.4. Thanks again @asl.


feat(membership): crud on membership histories

Proposed changes
Admins kan create, edit and delete membership histories. Can also list membership histories on user which is also noe paginated. PR in Kvark is needed for this merge
Issue number: closes #353
Pull request checklist
Please check if your PR fulfills the following requirements:

[x] CHANGELOG.md has been updated. Guide
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been reviewed and added / updated if needed (for bug fixes / features)
[x] The fixtures have been updated if needed (for migrations)

Note to self: Legg til sorting i Meta på membership-history og membership


Filter the tasks with a range of dates

Closes #2155
Replaced dateTimePicker by dateRangePicker
Here's a snapshot of the result:

Nice work, thanks @thomfresn !


Angular 4

I this compatible with Angular 4?
The tags for the plugin show both "angular" and "angularjs" so it's not clear ...

I'm also very interested to know the answer to this, because I would like to integrate it in an Angular 4 webapp

i had the same issue.. but in my cause was transpiling from ang4 to ang5  .. here i https://github.com/mariohmol/ang-jsoneditor


Inspector-less Node.js build

Should we make it clear that this is not designed to work on Node.js builds with inspector disabled? Or should we try to make it work? (I fear that a REPL that doesn't work with some Node.js configurations may be difficult to be accepted to core.)

we could factor out our inspector usage and stub it with other things when inspector isn't available.
e.g. Runtime.evaluate calls vm and Runtime.getProperties is just a function that throws or something.


Issue due dates not exported in gitea dump

Gitea version (or commit ref): 1.8.2
Git version: 2.17.1
Operating system: CentOS
Database:

[ ] PostgreSQL
[x] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[x] Not relevant

Log gist:

Description
When dumping a backup, the issue due dates in SQL dump are not valid.
The problem is the field deadline_unix of the table issue.
All the exported values equal -62135596800 if a due date is set, 0 otherwise.
0 is fine but negative value for a timestamp is wrong.
Once reimported, the due date show is the 1st of January 1970.
Screenshots

Could this be upstream xorm issue?

I will take a look at this.

Maybe we need a validate for deadline.
https://github.com/go-gitea/gitea/blob/2f060c5834d81f0317c795fc281f9a07e03e5962/routers/web/repo/issue.go#L2303-L2309


Improper versioning scheme

Jenkins and plugins versions report
n/a
What Operating System are you using (both controller, and any agents involved in the problem)?
n/a
Reproduction steps
n/a
Expected Results
n/a
Actual Results
n/a
Anything else?
https://github.com/jenkinsci/wxwork-notification-plugin/blob/3e55c42b449d91384198f83a99bca6f9e76aa5f1/pom.xml#L19-L20 does not follow CD versioning formats recommended by https://www.jenkins.io/doc/developer/publishing/releasing-cd/#update-maven-pom-and-config, so the current release has a "rc" (release candidate) version number.

ok, already fixed


Document only annotated models and their annotated fields

Greetings,
I've started documenting my project with Swagger and wanted to make it, so that only models, which have the @ApiModel annotation enter the generated documentation. Furthermore, I do not want either non-annotated properties of the model to be included, nor fields from superclasses.
The thing is however, that, not only do non-annotated fields of superclasses get included, but also some random classes which have no annotations and absolutely nothing to do with the specified model.
@ApiModel
public class MyModel extends 3rdPartyClass {
 .   public String propertyIdoNotWantDocumented;
 .   @ApiModelProperty(...)
 .   public String propertyIWantDocumented;
}
The thing that happens is that both propertyIWantDocumented and propertyIdoNotWantDocumented enter the documentation, as well as all fields of 3rdPartyClass. And if 3rdPartyClass happens to have some Objects as fields, these objects also get documented.
By the looks of it, the JaxrsReader automatically includes all these classes in the documentation, even though they are not annotated.
This is really annoying imo, and I think that at least a property should be added for the documentation of only annotated classes and fields.

By the looks of it, the JaxrsReader automatically includes all these classes in the documentation, even though they are not annotated.

This is propably as designed.
By default, this plugin should document the parameters how they are actually received by jax-rs.
However, there should (imo) be at least a setting to only check fields / methods / classes if they actually have swagger annotations.

Any update? I met the same issue, too many redundant models are created... Is there any way to solve this?


fix api-input in a wrong const

This repo fixes an issue with an -a (api) flag being read from a wrong constant. Instead of agrs, it's under flags.
Issue: flagsmith get [ENVIRONMENT] [-o ] [-a ]
The -a value will not be read by the command/get code because it's inside flags not args.
This PR attempts to fix that.

Doh, thank you @vladaCizek!


Use a multi-stage Dockerfile

Previously, we needed a script to build a minimal docker image without build
dependency.
Docker's new multi-stage builds allow us to specify all of this logic in the
Dockerfile, eliminating the need for the dockerize script.
Fixes #43
@olix0r https://github.com/moby/moby/releases/tag/v17.05.0-ce was released on 2017-05-05.

Thanks, Tamir! We will take a look!


Locations Endpoint: location-id filter not working

According to the swagger docs here, location-id is the url param to use to filter by a single location.
Both requests below will return 692 locations (the whole catalog) for LRH.
https://cwms-data.usace.army.mil/cwms-data/locations?location-id=Bluestone-Lake&office=LRH
https://cwms-data.usace.army.mil/cwms-data/locations?name=Bluestone-Lake&office=LRH
Top snippet of the response:
{
    "locations": {
        "query-info": {
            "time-of-query": "2022-10-17T19:12:53Z",
            "process-query": "PT4.465S",
            "format-output": "PT0.362S",
            "requested-format": "JSON",
            "requested-office": "LRH",
            "requested-items": [
                {
                    "name": "*",
                    "unit": "EN",
                    "datum": "NATIVE"
                }
            ],
            "total-locations-retrieved": 2359,
            "unique-locations-retrieved": 692
        },
        "locations": [

Using names=Bluestone-Lake is perhaps the previous way to filter by location?  and still works.
https://cwms-data.usace.army.mil/cwms-data/locations?names=Bluestone-Lake&office=LRH

For the swagger controllers there is generally a getOne endpoint and a getAll endpoint.  The getOne endpoints usually have some sort of Id in the path.  That is the location-id field you are seeing.  Some of the endpoints also have a legacy implementation that calls pl/sql and returns raw results.  If there is a new implementation it's usually JsonV2.
In your output I see that it's going to the old pl/sql and it thinks that the names field to the query is "*".  Which tells me that the id isn't getting through to the pl/sql.
Maybe we should be checking for extra unmatched parameters and throwing an error or something

Maybe a long way of saying the parameter should be names and not location-id or name.
For some of the endpoints we've deprecated some of the older parameters or ones that were wrongly cased or typo'd.  I think all those parameters are documented with a deprecated tag in the docs but it's possible I missed something.  I know there was a mixup between name and names in at least one Controller so it's also possible something got ninja edited on you but in general we've just been deprecating the old parameters and supporting both.  I don't think any have been intentionally broken or removed yet

The url provided doesn't have a slash after the locations portion so the parameter should be names


chore(doop): remove auth and pass initial filters per appProp

Summary
This PR removes the authentication integration from the application, simplifying the access process and allowing a full preview of the application within a PR. Additionally, it introduces a new appProp called initialFilters, which allows default filters to be applied when initializing the application. Lastly, it fixes rendering issues related to react-markdown, ensuring proper display of markdown content.
fixes: #493
Changes Made

Remove authentication
Introduces a new attribute initialFilters
Fixes several issues in react-markdown

Related Issues

Issue 1: [link to issue]

Screenshots (if applicable)

Testing Instructions

npm i
npm run TASK

Checklist

[x] I have performed a self-review of my code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] New and existing unit tests pass locally with my changes.
[x] I have made corresponding changes to the documentation (if applicable).
[x] My changes generate no new warnings or errors.

Will it work if I approve this PR, or should we wait for the other PRs to be approved first?


Password Protection

Is there anyway to include Password Protection?

Right now, if you choose "Encrypt", the key functions as sort of a password protection:
http://example.com/view//
Without the last part of the URL, the paste will not be viewable. Of course, for this to be secure, the site should be using HTTPS (and also it could persist in the browser history).
I can consider adding this feature in the future though, if there is interest.

I would like password protection because if I make this accessible though a domain, other (unauthorized) people can't create a paste.

I would like password protection because if I make this accessible though a domain, other (unauthorized) people can't create a paste.

This....Im not sure how whitelisting works in this case.

I would like password protection because if I make this accessible though a domain, other (unauthorized) people can't create a paste.

This....Im not sure how whitelisting works in this case.

It would only allow people with a user to create notes. However, I do believe the creator of every note should be able to choose whether or not a note they created is available to everyone or only people with an account. Also, I believe there should not be any "create account" button, as that would destroy the purpose. Only admins should be able to create new users.


CODE: Enhance Description Field

As a user, I want to be able to see the Description field as I choose (either all at once, or a small amount) and be able to edit the text in both forms. The user should be able to toggle between full text and partial text, with proper indicators for both.
Primary

Update description field to include 'Markdown Supported' with proper Markdown image (from official Markdown documentation).
Enhance Description field to allow for collapsing and minimizing (toggle) text to fall between max-height of 190-200pixels and full text. The user should be able to perform these actions both when the Description field is in an editable and uneditable state.
If the Description field is minimized and in edit mode, a user should be able to scroll inside of the field, if they do not want to expand the Description field to its full height.

Secondary

Move 'Write in Markdown' and 'Preview in HTML' to align properly in a form layout.

VC:

UX has approved designs as expressed (attach any wireframes, prototypes or videos to show designs).
Leads have approved updated interactions and usage (Monica, Catherine, Pete/Todd).
Developers have been shown new interactions during a UX Review session.

PR merged on Planner.


chore: fix some typos

fix a bunch of typos

Codecov Report

Merging #2025 (3941e6a) into main (ecee192) will decrease coverage by 57.40%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             main    #2025       +/-   ##
===========================================
- Coverage   72.98%   15.59%   -57.40%
===========================================
  Files         427      427
  Lines       52305    52306        +1
===========================================
- Hits        38174     8156    -30018
- Misses      14131    44150    +30019

Flag
Coverage Δ

integration-tests
15.59% <0.00%> (-3.86%)
:arrow_down:

unit-tests
?

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

Impacted Files
Coverage Δ

bin/reth/src/test_eth_chain/runner.rs
0.00% <0.00%> (ø)

crates/consensus/common/src/validation.rs
0.00% <ø> (-82.40%)
:arrow_down:

crates/interfaces/src/test_utils/generators.rs
0.00% <ø> (-98.25%)
:arrow_down:

crates/net/discv4/src/proto.rs
0.00% <0.00%> (-92.55%)
:arrow_down:

crates/net/downloaders/src/bodies/request.rs
0.00% <0.00%> (-85.28%)
:arrow_down:

crates/net/ecies/src/stream.rs
27.58% <ø> (-41.38%)
:arrow_down:

crates/net/eth-wire/src/types/message.rs
24.13% <ø> (-31.04%)
:arrow_down:

crates/net/nat/src/lib.rs
26.61% <0.00%> (-18.71%)
:arrow_down:

crates/net/network/src/eth_requests.rs
76.69% <ø> (ø)

crates/net/network/src/flattened_response.rs
84.61% <ø> (ø)

... and 20 more

... and 296 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Incompatible Node Versions

Bug Description
It is pretty difficult to get create-eth-app generated without a very specific version of node.
Steps to Reproduce

Attempt 'yarn create eth-app'
With any random version of Node..

Expected Behavior
The engine "node" is incompatible with this module. Expected version ">=12". Got "10.16.0"
^ Or erhaps some other nodejs building error during your yarn create process somewhere.. I have also ran into errors fetching specifics heads with other node versions..
To resolve this; nvm install v12.22.2 && nvm use 12.22.2
then npm install -g yarn and u should be good to do 'yarn create eth-app' without error. Just submitting this to an issue as requested per @paulrberg

Thanks for reporting, @royhodge! I'll either update the README or fix the node incompatibility issue.

no problem. Happy to help.

As explained by @mljlynch, the minimum version of node.js required is now v14:

error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version ">=14.0.0". Got "12.19.0

Happy to take care of updating the README for you if you would like

Just took care of this in https://github.com/paulrberg/create-eth-app/commit/f99416b0b8846b5ba07b56d537fc26d85aec8444.


fix(#3433): Deprecate platform trait create default option

Deprecate option to create default integration platform as part of the trait
Option to create default integration platform needs to be explicitly enabled (e.g. with auto=true, create-default=true)
Usually platform gets automatically created already as part of the operator installation startup procedure
Fix trait documentation

Release Note
fix(#3433): Deprecate platform trait create default option

Fixes #3433

Auto creation of an integration platform is only one aspect of the trait. In addition to that the trait is there to set the integration into "waiting for platform" state. it generally checks that there is an integration platform available for the integration.


Fix flaky tests for quantize and requantize

Description
fix flaky tests for quantize and requantize in #12028 #11747
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

@pengzhao-intel @marcoabreu

Tests have passed.
[INFO] 9995 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=2127644814 to reproduce.
[INFO] 9996 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=2127644814 to reproduce.
[INFO] 9997 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=2127644814 to reproduce.
[INFO] 9998 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=2127644814 to reproduce.
[INFO] 9999 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=2127644814 to reproduce.
[INFO] 10000 of 10000: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=2127644814 to reproduce.
ok

----------------------------------------------------------------------
Ran 1 test in 62.163s

OK
INFO:root:Nosetests terminated with exit code 0

Thanks a lot for addressing this so quickly!
I noticed that the testing seed is always the same. Would you mind un-setting it and using random ones?

@marcoabreu okay, still can pass. I paste wrong log:)

@haojin2 https://github.com/apache/incubator-mxnet/issues/11747

@xinyu-intel Thanks for the investigation.

Sorry, I'm currently swamped with high priority tasks and I don't have time to review your pull request.


Lambda Function

Description 📜
Audio Contribution of Lambda Function #574

Type of change 📝

[x] Au#dio (Should be in mp3 format Includes speech clarity, Concise ,Low distortion)

Domain of Contribution 📊

[x] Python_#Domain

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

Screenshots / Gif (Optional) 📸

@adityabisoi this looks good to me and can be merged.


stress: add a 'stress' cmd for perf testing of dist-spec registries

Signed-off-by: Ramkumar Chinchani<EMAIL_ADDRESS>
What type of PR is this?

Which issue does this PR fix:
What does this PR do / Why do we need it:
If an issue # is not available please add repro steps and logs from IPAMD/CNI showing the issue:
Testing done on this change:

Automation added to e2e:

Will this break upgrades or downgrades. Has updating a running cluster been tested?:
Does this change require updates to the CNI daemonset config files to work?:

Does this PR introduce any user-facing change?:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

https://github.com/project-zot/zot/blob/main/pkg/compliance/v1_0_0/check.go
^ pls look at this for all the different API usages.


froide: init at 0-unstable-2024-11-22

Adding web app froide, a portal for creating and following freedom of information act requests. Used by FragDenStaat project.
Adding it only as Python module as such it can also be used by other projects - in my use case https://github.com/NixOS/nixpkgs/pull/349750
Related:

https://github.com/NixOS/nixpkgs/pull/355390
https://github.com/okfde/froide/issues/893
https://github.com/okfde/froide/issues/902
https://github.com/okfde/froide/issues/901

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Thank you @pluiedev fixed it :)


BigQuery: Load and dump schema from/to a file

Addresses #1919
This pull request adds the ability to load a BigQuery table schema from a JSON file (or other JSON source). And to write the schema of an existing table schema to a file. The file format is the same as the CLI JSON file.
@quartzmo I need some help with the doctest: I can't figure out how to stub File.write with minitest mocks for the scope of the doctest.
@blowmage In your gist you suggested class methods Schema::load and Schema::dump. Those are easy enough to implement, but while trying to document them, I realized that I have no idea when you would actually use that. Can you provide a suggestion? (It seems to me that Schema is always used within the context of a table in which case there's an instance of it already.)

@jeremywadsack Great to see this PR! I'll look through it soon.

I need some help with the doctest: I can't figure out how to stub File.write with minitest mocks for the scope of the doctest.

I think we just monkeypatch (rather than mock) for doctest. Take a look at File.read in the Storage doctest helper.

@quartzmo Thanks, updated the doctest.
CI failures are in the DataTransfer client. I think they are unrelated to this pull request.

In your gist you suggested class methods Schema::load and Schema::dump. Those are easy enough to implement, but while trying to document them, I realized that I have no idea when you would actually use that. Can you provide a suggestion? (It seems to me that Schema is always used within the context of a table in which case there's an instance of it already.)

My suggestion for Schema.dump and Schema.load is to match the interface used by Marshal.dump/Marshal.load, and JSON.dump/JSON.load. The Ruby idiom is that these are available as class methods.

@blowmage Code review addressed except for my open question about @original_json. The more I think about that the more I think it should be changed?. Just as if you were adding fields with any of the add_fields methods.

I'm not sure what's going on with the CI failures. The test fail in the coveralls run (I think) but they pass in the unit test run. They look like they are running the code from the penultimate commit, but the coveralls report has the right sha. When I run rvm-exec 2.4.2 bundle exec rake test:coverage locally for the google-cloud-bigquery folder I don't get any errors. Thoughts?

@jeremywadsack I had restarted the failed build just before you pushed your last commits. I cancelled my restart. rake ci passes for me locally. (It did before, too.)

The CI build has failed again with the same errors as before. I am unable to reproduce locally. rake ci passes for me.

  1) Error:

Google::Cloud::Bigquery::Schema::mock_bigquery#test_0008_can dump the schema as JSON to a filename:

NoMethodError: undefined method `[]' for nil:NilClass

    /home/ubuntu/google-cloud-ruby/google-cloud-bigquery/test/google/cloud/bigquery/schema_test.rb:577:in `block (2 levels) in <top (required)>'

  2) Error:

Google::Cloud::Bigquery::Schema::mock_bigquery#test_0007_can dump the schema as JSON to a File:

NoMethodError: undefined method `[]' for nil:NilClass

    /home/ubuntu/google-cloud-ruby/google-cloud-bigquery/test/google/cloud/bigquery/schema_test.rb:501:in `block (2 levels) in <top (required)>'

  3) Failure:

Google::Cloud::Bigquery::Schema::mock_bigquery#test_0010_can write write a schema with the class method [/home/ubuntu/google-cloud-ruby/google-cloud-bigquery/test/google/cloud/bigquery/schema_test.rb:661]:

--- expected

+++ actual

@@ -1 +1 @@

-["name", "age", "score", "active", "avatar", "started_at", "duration", "target_end", "birthday", "alts"]

+[nil, nil, nil, nil, nil, nil, nil, nil, nil, nil]

I wonder if CI failure is related to changing keys from string to symbol in
the hash we use to generate json. It seems to have the right number of json
objects but wrong attributes.
On Tue, Apr 24, 2018 at 4:43 PM Chris Smith<EMAIL_ADDRESS>wrote:

The CI build has failed again with the same errors as before. I am unable
to reproduce locally. rake ci passes for me.

Error:

Google::Cloud::Bigquery::Schema::mock_bigquery#test_0008_can dump the schema as JSON to a filename:
NoMethodError: undefined method []' for nil:NilClass    /home/ubuntu/google-cloud-ruby/google-cloud-bigquery/test/google/cloud/bigquery/schema_test.rb:577:in block (2 levels) in <top (required)>'  2) Error:Google::Cloud::Bigquery::Schema::mock_bigquery#test_0007_can dump the schema as JSON to a File:NoMethodError: undefined method []' for nil:NilClass    /home/ubuntu/google-cloud-ruby/google-cloud-bigquery/test/google/cloud/bigquery/schema_test.rb:501:in block (2 levels) in <top (required)>'

Failure:

Google::Cloud::Bigquery::Schema::mock_bigquery#test_0010_can write write a schema with the class method [/home/ubuntu/google-cloud-ruby/google-cloud-bigquery/test/google/cloud/bigquery/schema_test.rb:661]:
--- expected
+++ actual
@@ -1 +1 @@
-["name", "age", "score", "active", "avatar", "started_at", "duration", "target_end", "birthday", "alts"]
+[nil, nil, nil, nil, nil, nil, nil, nil, nil, nil]
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-ruby/pull/2061#issuecomment-384114562,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOurLF7ZDxy1oGjC21cJe6n2I3O6jfZks5tr7izgaJpZM4TelgR
.

--
Jeremy Wadsack

@blowmage Can you pull this branch and run rake ci locally to see if you can reproduce the error on Circle CI?

@quartzmo I just pushed a change to move some of the hash keys back to strings. This should let us know if that's the cause of the failure because the root elements will work but any nested ones would still fail.

I've identified why the coverage CI task is failing. The coverage task loads and runs all libraries together, and other libraries have a dependency on ActiveSupport. ActiveSupport has their own protocol for JSON serialization, which looks like you are intending to support by supporting *args on the to_json method. But AS also expects to get primitive objects/non-JSON string by calling as_json. This functionality is provided by the different named method json_hash, so AS serializes the object instance variables instead. That causes the JSON structure to be different and the tests to fail.
One way to correct this is to use the naming that AS expects:
diff --git a/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb b/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb
index b817def07..7931b735d 100644
--- a/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb
+++ b/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb
@@ -544,18 +544,18 @@ module Google

           # @private
           def to_json *args
-            json_hash.to_json(*args)
+            as_json(*args).to_json
           end

           # @private
-          def json_hash
+          def as_json *args
             h = {
               name: name,
               type: type,
               mode: mode
             }
             h[:description] = description if description
-            h[:fields] = fields.map(&:json_hash) if record?
+            h[:fields] = fields.map { |field| field.as_json(*args) } if record?
             h
           end

I don't love this, to be honest. I don't like the use of *args, as we aren't actually implementing the JSON serialization options that AS expects. I think a far more idiomatic approach is to use standard conversion methods.
diff --git a/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb b/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb
index b817def07..23f625a65 100644
--- a/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb
+++ b/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb
@@ -543,19 +543,19 @@ module Google
           end

           # @private
-          def to_json *args
-            json_hash.to_json(*args)
+          def to_json
+            JSON.dump to_hash
           end

           # @private
-          def json_hash
+          def to_hash
             h = {
               name: name,
               type: type,
               mode: mode
             }
             h[:description] = description if description
-            h[:fields] = fields.map(&:json_hash) if record?
+            h[:fields] = fields.map(&:to_hash) if record?
             h
           end

Either approach will work, but I have a strong preference for the latter.
Regardless of which approach is chosen, we should also document the usage of the JSON library by adding the require to the file:
diff --git a/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb b/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb
index b817def07..82be4c0bd 100644
--- a/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb
+++ b/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb
@@ -13,6 +13,8 @@
 # limitations under the License.

+require "json"
+
 module Google
   module Cloud
     module Bigquery

Great sleuthing, @blowmage! I agree that we should avoid implementing ActiveSupport's API unless there is a really good reason to do so (in which case, my understanding has always been to implement as_json). How does this sound, @jeremywadsack?

@quartzmo This sounds great. @blowmage Thank you for figuring this out. I'm perfectly happy to implement the latter solution. I'll get that change later this afternoon or tomorrow.

I implemented a mix of the two solutions in 9e12b7c, but this may still fail. I couldn't get to_json without arguments to work. It failed in tests with "wrong number of arguments given":
ArgumentError: wrong number of arguments (given 1, expected 0)
    google-cloud-ruby/google-cloud-bigquery/lib/google/cloud/bigquery/schema/field.rb:547:in `to_json'
    google-cloud-ruby/google-cloud-bigquery/lib/google/cloud/bigquery/schema.rb:258:in `to_json'
    google-cloud-ruby/google-cloud-bigquery/lib/google/cloud/bigquery/schema.rb:258:in `dump'
    google-cloud-ruby/google-cloud-bigquery/test/google/cloud/bigquery/table_schema_test.rb:309:in `block (2 levels

Even though I'm not passing arguments when I call the Fields#to_json method, it was receiving a JSON::Ext::Generator::State object as a single argument. From what I can tell this is part of how the ruby JSON implementation works. I'll wait to see if that's still an issue for AS or not.

Hooray, CI passed!

@blowmage Thanks. I still have several test cases to cover for @quartzmo that are on my task list when I get time to look at it again. I hope to wrap that up this week.

@jeremywadsack Need any help with this one? I need to release another BigQuery feature soon (PR #2069), it would be convenient to release this at the same time if possible.

Sorry @quartzmo won't be able to wrap that up in the short term. I need to
get my head around how BigQuery handles updates in order to finish the
tests. Really crushed right now; hopefully I can look at this next week.
If you have something else to release, I'd say don't wait on me. Sorry.
On Fri, May 4, 2018 at 12:03 PM Chris Smith<EMAIL_ADDRESS>wrote:

@jeremywadsack https://github.com/jeremywadsack Need any help with this
one? I need to release another BigQuery feature soon (PR #2069
https://github.com/GoogleCloudPlatform/google-cloud-ruby/pull/2069), it
would be convenient to release this at the same time if possible.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-ruby/pull/2061#issuecomment-386664891,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOurABqY0AVyLf3L11frKDajke7pD0zks5tvIn0gaJpZM4TelgR
.

--
Jeremy Wadsack

@jeremywadsack We have another BIgQuery release approaching for #2081. How's your bandwidth?

@quartzmo The new commits include the unit tests that you asked for and fix the documentation. I was able to remove the File monkey patch by using (and removing) real files for the doctests.
Let me know if there's anything I missed or if I need to update any tests or documentation. Once this is approved, I can squash and rebase (if needed).

This file should be in acceptance, not test.

It's used for the test suite not the acceptance suite. Would you rather I
try to mock the file read for the unit test?
On Thu, May 17, 2018 at 7:44 AM Mike Moore<EMAIL_ADDRESS>wrote:

This file should be in acceptance, not test.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-ruby/pull/2061#issuecomment-389892029,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOurGQbcSsZb9qQsaUroduN0lwn4lD_ks5tzYzbgaJpZM4TelgR
.

--
Jeremy Wadsack

@jeremywadsack I'd definitely prefer to avoid using a real file in both doctests and unit tests. We consider monkey-patching acceptable for doctests. For unit tests, can you borrow from this File.stub usage?

@quartzmo Ok, I'll change that back. I thought you had asked me to remove the monkey patch  in the doctests. I misunderstood.
Thanks for the link to the File.stub example. That will help for the unit tests.
We can't stub that in doctest (because there's no block and no doctest.around) and we determined that we couldn't monkey patch File.read because it's required to run tests. So I think that means we have to skip doctest for any test that reads a file.

Yes, sorry for the misunderstanding. I was wondering: If the doctest is skipped, do we still need the monkeypatch? Apologies, this does get a bit confusing.

@quartzmo Yeah I can skip the tests that depend on the monkey patch you'd rather go that route. You're call.

@quartzmo @blowmage I changed the doctests to the monkey patch and skip any examples that would read from a file. For unit tests I removed that schema file and rewrote the tests I had to use StringIO instead of File for IO handling. I think that addresses your concerns. However, when I I did a quick check I saw that lots of existing unit tests read files from acceptance/data/. Let me know if this is what you want here or if you need any more changes.

@jeremywadsack Thank you! I've pulled your updates and will take a look this weekend. If we can approve and merge it, it will be released very soon!

Acceptance tests failed on CI on all nodes with:
  1) Failure:

Google::Cloud::Bigquery::Schema::mock_bigquery#test_0010_can dump a schema with the class method [/home/ubuntu/google-cloud-ruby/google-cloud-bigquery/test/google/cloud/bigquery/schema_test.rb:691]:

Expected: 10

  Actual: 11

  2) Failure:

Google::Cloud::Bigquery::Schema::mock_bigquery#test_0008_can dump the schema as JSON to a filename [/home/ubuntu/google-cloud-ruby/google-cloud-bigquery/test/google/cloud/bigquery/schema_test.rb:607]:

Expected: 10

  Actual: 11

  3) Failure:

Google::Cloud::Bigquery::Schema::mock_bigquery#test_0007_can dump the schema as JSON to a File [/home/ubuntu/google-cloud-ruby/google-cloud-bigquery/test/google/cloud/bigquery/schema_test.rb:531]:

Expected: 10

  Actual: 11

Investigating, and I will push a fix when I figure it out.

This is likely because we added support for NUMERIC while this PR was being approved. The default schema now includes a NUMERIC field.


Build Error

protobuf-3.7.0/src/google/protobuf/compiler/java/java_extension_lite.cc: (Empty error message)
tar: Error exit delayed from previous errors.

could you elaborate your problem? we do support macOS / Linux, make sure you have read docs:
https://developer.trustwallet.com/wallet-core/contributing
https://developer.trustwallet.com/wallet-core/linux


Enable building even when there are errors

Sometimes (e.g. due to typings updates), there will appear errors in the
source which prevents the package to be built, even though it works.
To remedy this, noEmitOnErrors has been set to false and the
build script has been updated to package even when there were
TypeScript errors.

You should not ignore TypeScript errors.

What is actual error? I may be able to fix.

The errors are a hint, and some can safely be ignored. But I admit, I was a bit too lazy to go through them. It seems like the problem is inside a typings file:

shadowRoot?: webcomponents.ShadowRootPolyfill;
~~~~~~~~~~

typings/globals/webcomponents.js/index.d.ts(48,5): error TS2403: Subsequent variable declarations must have the same type.  Variable 'shadowRoot' must be of type 'ShadowRoot', but here has type 'ShadowRootPolyfill'.

shadowRoot?: webcomponents.ShadowRootPolyfill;
~~~~~~~~~~

typings/globals/webcomponents.js/index.d.ts(48,5): error TS2687: All declarations of 'shadowRoot' must have identical modifiers.

Thank you for the log. I'll check the type definition. Type definition may be updated for Polymer 2.

No problem :)


r-modules/generic-builder: Add missing iconv library to fix build on darwin

Motivation for this change
Executing nix-shell --packages 'rWrapper.override{packages = [ rPackages.SparseM ];}' fails with the error:
ld: library not found for -liconv
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/nix/store/saj094y98yryxgi7q1ja36hkbq52yvkf-R-3.6.2/lib/R/share/make/shlib.mk:6: SparseM.so] Error 1
ERROR: compilation failed for package 'SparseM'

Adding the missing iconv library for darwin fixes the issue.
Things done

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

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

See https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/r-modules/default.nix#L267 for an example.

@peti Thanks for the hint. I reverted the changes in generic-builder.nix and added the libconv library to the r-packages that I used and were breaking directly. In addition, I did a refactoring in a second commit (with statement scope & sorting using sort -t '=' -k 2).

@peti Ok, I reverted the refactoring changes.


Add Express Object Workflow, Permissions and Approval

Description
To do: Add more detail here.
Example
To do: Add more detail here.

Related to: https://github.com/concrete5/concrete5/issues/7085

This doesn't need to exist, let's just keep #7085.


Causes crash on develop branch

{
  "$jason": {
    "head": {
      "data": {
        "posts": [
          {
            "title": "title1"
          },
          {
            "title": "title2"
          }
        ]
      },
      "templates": {
        "sections": {
          "{{#each posts}}": [
            {
              "items": [
                {
                  "components": [
                    {
                      "type": "label",
                      "text": "{{title}}"
                    }
                  ]
                }
              ]
            }
          ]
        }
      }
    }
  }
}

should add: iPhone 7plus, IOS 10.1, "develop" branch

@darenr Two things:

When using the #each command in a template, you need to have an object as its child, not an array. #each simply iterates through the item (posts in this case) with its child template and generates the resulting array.

templates must have a name. And the default template is body, which renders into $jason.body by default. You can decide to have multiple templates and render them by specifying the template option if you want to (but that's an edge case so you'll probably not need this). So in this case you simply need to wrap your template inside body.

So in this case, this should work:
{
"$jason": {
"head": {
"data": {
"posts": [
{
"title": "title1"
},
{
"title": "title2"
}
]
},
"templates": {
"body": {
"sections": {
"{{#each posts}}": {
"items": [
{
"components": [
{
"type": "label",
"text": "{{title}}"
}
]
}
]
}
}
}
}
}
}
}
}
p.s.
See https://github.com/Jasonette/Jasonpedia/tree/gh-pages/template for more examples on using templates.

thanks for the link and the example, but that didn't work either, it rendered two empty sections. Knowing that #each generates an array itself is helpful.
I'll play around with and go through the link examples and see if I can figure it out. The example I gave was actually stripped down and what I really want to do is next loops but I'll first get this simple one to work before tacking that.


OnDeserialize failed error before actual NullReferenceException

I accidentally accessed a SyncVar string variable within it's hook, which was null. The error that I received misled me into thinking something was wrong with the serialization instead of telling me it was a NullReferenceException:
OnDeserialize failed for: object=Player(Clone) component=Hololux.UniLensKit.HoloLens.CustomizedToolkitScripts.CustomPlayerController sceneId=0 length=33. Possible Reasons:
  * Do Hololux.UniLensKit.HoloLens.CustomizedToolkitScripts.CustomPlayerController's OnSerialize and OnDeserialize calls write the same amount of data(33 bytes)?
  * Was there an exception in Hololux.UniLensKit.HoloLens.CustomizedToolkitScripts.CustomPlayerController's OnSerialize/OnDeserialize code?
  * Are the server and client the exact same project?
  * Maybe this OnDeserialize call was meant for another GameObject? The sceneIds can easily get out of sync if the Hierarchy was modified only in the client OR the server. Try rebuilding both.

System.NullReferenceException: Object reference not set to an instance of an object
  at MixedRealityToolkit.Examples.SharingWithUNET.PlayerController.PlayerNameChanged (System.String update) [0x00008] in D:\Helios\HeliosWindowsClient\Assets\Helios\Avatars\PlayerController.cs:114
  at MixedRealityToolkit.Examples.SharingWithUNET.PlayerController.OnDeserialize (Mirror.NetworkReader reader, System.Boolean initialState) [0x0005a] in <96e62e17db724a588617bceda85b64e1>:0
  at Hololux.UniLensKit.HoloLens.CustomizedToolkitScripts.CustomPlayerController.OnDeserialize (Mirror.NetworkReader reader, System.Boolean initialState) <0x3becc730 + 0x0007a> in <96e62e17db724a588617bceda85b64e1>:0
  at Mirror.NetworkIdentity.OnDeserializeSafely (Mirror.NetworkBehaviour comp, Mirror.NetworkReader reader, System.Boolean initialState) [0x00081] in D:\Helios\HeliosWindowsClient\Assets\Mirror\Runtime\NetworkIdentity.cs:650
UnityEngine.Debug:LogError(Object)
Mirror.NetworkIdentity:OnDeserializeSafely(NetworkBehaviour, NetworkReader, Boolean) (at Assets/Mirror/Runtime/NetworkIdentity.cs:655)
Mirror.NetworkIdentity:OnDeserializeAllSafely(NetworkBehaviour[], NetworkReader, Boolean) (at Assets/Mirror/Runtime/NetworkIdentity.cs:683)
Mirror.NetworkIdentity:OnUpdateVars(NetworkReader, Boolean) (at Assets/Mirror/Runtime/NetworkIdentity.cs:744)
Mirror.ClientScene:ApplySpawnPayload(NetworkIdentity, Vector3, Quaternion, Vector3, Byte[], UInt32) (at Assets/Mirror/Runtime/ClientScene.cs:345)
Mirror.ClientScene:OnSpawnPrefab(NetworkConnection, SpawnPrefabMessage) (at Assets/Mirror/Runtime/ClientScene.cs:398)
Mirror.<>c__DisplayClass6_0`1:<MessageHandler>b__0(NetworkMessage) (at Assets/Mirror/Runtime/MessagePacker.cs:127)
Mirror.NetworkConnection:InvokeHandler(Int32, NetworkReader) (at Assets/Mirror/Runtime/NetworkConnection.cs:205)
Mirror.NetworkConnection:TransportReceive(ArraySegment`1) (at Assets/Mirror/Runtime/NetworkConnection.cs:236)
Mirror.NetworkClient:OnDataReceived(ArraySegment`1) (at Assets/Mirror/Runtime/NetworkClient.cs:126)
UnityEngine.Events.UnityEvent`1:Invoke(ArraySegment`1)
Mirror.TelepathyTransport:ProcessClientMessage() (at Assets/Mirror/Runtime/Transport/TelepathyTransport.cs:69)
Mirror.TelepathyTransport:LateUpdate() (at Assets/Mirror/Runtime/Transport/TelepathyTransport.cs:96)

Maybe I'm dumb, but I did not expect the actual cause, the NullReferenceException, being a second entry within the same error. I'd say this should be either a separate error message, or the NullReferenceException is thrown first

@paulpach I also agree with this, what do you say?

I vaguely remember that there was a case where UNET (or the Weaver) would swallow exceptions in OnSerialize. possibly because UNETStaticUpdate was called from within Unity back then. or it was because something that happened in/before Start.
someone would have to test all possible cases before throwing exceptions there again.
but really, the Error message is there and if people click it then they see exactly what went wrong.

We could just Debug.LogException separately.

@vis2k you normally do not expect two errors in one error message but the stacktrace for the one error

I just had this today and it was driving me nuts. In my case it turned out that I was using a SyncDictionary with a callback registered, and there was an exception in the callback. Very confusing way to expose that error. Is that by design?

closing this for now, because the error message is there and tells users how to debug it.
if anyone prefers a different way then please open a pull request :)

@vis2k Ran into this again and want to propose a change again.
As @curtca also points out, the error is really misleading, telling you all kinds of things about serialization which in case of an error in the hook, is not. The fact it's an error and 99% of the errors you usually encouter contain a single error message. This setup completely distracts you from the second error which you would usually just gaze over and think it's the StackTrace.
So what I tried was to find out how to get to this particular error message and what the difference of the Exception is between custom and Mirror code. Since I don't know about the internals of the code generation for all the Sync-Attributed variables, the most obvious was the Exceptions.Source property. In case it was any exception I caused in the linked hook (NullRef, IndexOutOfBounds...), it contained my product name and in the one case it was able to cause an actual serialization error, it pointed to Mirror.
So my suggestions are:

Distinguish between errors happening in Mirror:

            catch (Exception e)
            {
                // show a detailed error and let the user know what went wrong
                if (e.Source.Equals("Mirror"))
                {
                    Debug.LogError("OnDeserialize failed for: object=" + name + " component=" + comp.GetType() + " sceneId=" + m_SceneId.ToString("X") + " length=" + contentSize + ". Possible Reasons:\n  * Do " + comp.GetType() + "'s OnSerialize and OnDeserialize calls write the same amount of data(" + contentSize + " bytes)? \n  * Was there an exception in " + comp.GetType() + "'s OnSerialize/OnDeserialize code?\n  * Are the server and client the exact same project?\n  * Maybe this OnDeserialize call was meant for another GameObject? The sceneIds can easily get out of sync if the Hierarchy was modified only in the client OR the server. Try rebuilding both.\n\n" + e);
                }
                else
                {
                    Debug.LogError(e);
                }
            }

Log the exception separately, which draws the necessary attention to it


Removing Atomic negative margin classes targeting all values

Fixes #435

Is this not ready for review? LGTM though.

I was going to check it but you got to it before me :)


Adding option to ignore .env file requirement

The Ruby dotenv implementation has 2 load methods (load, load!). The load method ignores a missing .env file for the case where you are in a non-development environment and have your environment variables set by some other method.
I would like the same options for phpdotenv.
For backwards compatibility I have added an optional flag to load() to ignore the requirement of having a .env file. By default it is true.

yes please. 💯

Sorry, didn't see this. #242 has been merged now, since it fits the BC promise of this library better. Adding a parameter to a public function in a non-final class is technically a BC break in PHP.


Show approx CPU temp

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

This can be covered here #30


Revert "hetman hat and cossack uniform"

Reverts space-wizards/space-station-14#15654

:cl: lzk

remove: remove cossacks jumpsuit and hat

spite pr moment


Evolve ResolveVars into ResolveProgram

Supersedes https://github.com/stateful/runme/pull/508. "Program" as in "Cell Shell Program".
Notable changes are:

[x] Service solely decides the resolution/prompt status of variables. Based on the mode mode passed by the client.
[x] Only top-level export vars are being considered. We don't want to interfere with anything tangled up in flow control.
[x] Service rewrites scripts (returned as command sequence) to remove unresolved vars to be passed as part of ENV store.
[x] Integrated with extension
[ ] Integration with CLI pending.
[ ] Removing option to pass commands since ResolveProgram will be responsible for turning shell scripts into commands sequence (skipped for shebang).

In a future version, a script to command normalization will be included, too. However, we can wait until further progress is made on the runnerv2alpha1 refactor. Service is ported to runnerv2. However, the tests are somewhat incomplete (todos).
Example: https://us-central1.stateful.com/cell/clsyzdcv4000088eiccrten9s

I'm going to merge this on a successful build @adambabik. It'd still be interested in your review, please.


Stable/0.6.x

fence_ipmilan.txt
Updated manifests/stonith/fence_ipmilan.pp to accept a different fence-agent-ipmilan package name as in Ubuntu all the agents are available via a single package: fence-agents
Probably this could be extended to all the fencing agents.

Thank you for contributing to openstack/puppet-pacemaker!
openstack/puppet-pacemaker uses Gerrit for code review.
If you have never contributed to OpenStack before make sure you have read the
getting started documentation:
http://docs.openstack.org/infra/manual/developers.html#getting-started
Otherwise please visit
http://docs.openstack.org/infra/manual/developers.html#development-workflow
and follow the instructions there to upload your change to Gerrit.


Add to CI: Link checks

Overview
TL;DR
We want the travis tests to run to include tests for valid links.
cc @github/services-training
Extra Detail

We don't want to publish content with broken links. 🔗
This was discovered because we had some broken links.
We already use this type of test in other repositories, like on-demand-github-pages.

How to Contribute

[ ] Comment on this issue if you'd like to work/collaborate on it!
[ ] Fork the repository.
[ ] Use the GitHub Flow to make changes to your fork. This is a refresher course if you're unsure about how to make a change on GitHub.
[ ] Push your changes to your repository.
[ ] Submit a Pull Request

Base Dropdown: github/training-kit
Compare Dropdown: Your fork

Testing Locally
If you'd like to make and test changes locally (and see how they would look if merged), do the following:

In your command line:

Install Git
Install Ruby
[ ] Run script/setup
[ ] Run script/server.

When successful, the script will initiate a local server at http://<IP_ADDRESS>:4000/on-demand.

Questions?

Leave a comment on this issue! Make sure to use @ mentions if you want a specific person's attention!

Running bundle exec htmlproofer --external_only ./_site/ gets you most of the way there... only there are a few false positives I think... I'm also unsure how to "run tests" for your build (looks to be manual testing?), so not sure I can make anything happen.

Duplicate of #547


Fix issue 191

The ascii test data, although in the repo, were not showing up in the pip install despite being in the manifest.
Found a discussion here which led me to add the ascii files to setup.py via
package_data={
      'mth5': ['data/*.asc'],
    },

This branch had master and patches merged in, so @kujaku11 if you are ok with the change to setup.py then please merge.