Change blacklist and whitelist nomenclature

Signed-off-by: Chen Dai<EMAIL_ADDRESS>Description
Change blacklist and whitelist nomenclature: from blacklist and whitelist to denylist and allowlist.
Issues Resolved
https://github.com/opensearch-project/sql/issues/464
Check List

[ ] New functionality includes testing.

[x] All tests pass, including unit test, integration test and doctest

[ ] New functionality has been documented.

[ ] New functionality has javadoc added
[ ] New functionality has user manual doc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #560 (c0af10a) into main (c8b58da) will decrease coverage by 31.82%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##               main     #560       +/-   ##
=============================================
- Coverage     94.59%   62.76%   -31.83%
=============================================
  Files           276       10      -266
  Lines          7454      658     -6796
  Branches        550      118      -432
=============================================
- Hits           7051      413     -6638
+ Misses          349      192      -157
+ Partials         54       53        -1

Flag
Coverage Δ

query-workbench
62.76% <ø> (ø)

sql-engine
?

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

Impacted Files
Coverage Δ

...nsearch/storage/script/ExpressionScriptEngine.java

.../opensearch/sql/expression/FunctionExpression.java

...search/sql/expression/NamedArgumentExpression.java

...opensearch/sql/planner/logical/LogicalProject.java

...rg/opensearch/sql/analysis/symbol/SymbolTable.java

...ch/sql/expression/aggregation/NamedAggregator.java

...l/opensearch/data/value/OpenSearchExprIpValue.java

...pensearch/sql/expression/function/FunctionDSL.java

...ensearch/sql/ppl/utils/PPLQueryDataAnonymizer.java

...expression/function/BuiltinFunctionRepository.java

... and 256 more

Continue to review full report at Codecov.

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


.NET 7 support

Probably not the correct place to open this discussion, but I've noticed in the snapshot articles for Godot 4 the articles talk about potentially supporting .NET 7. While keeping up with the latest is a good idea, I wonder if it would make more sense to focus on the LTS releases of .NET, and with .NET 8 coming out as a LTS release this year, it might make sense to skip 7 and go from 6 to 8 later this year.
Microsoft's release schedule / support policy: https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core
Happy to discuss more on this, thanks!

A PR was opened a couple days ago: https://github.com/godotengine/godot/pull/71241

While there's a difference in the amount of time an LTS release is officially supported compared to a non-LTS release, other than that all .NET releases have the same level of support and there's no particular change in development that makes an LTS release "safer" or more "stable" than a non-LTS one.
The reason why we may want to update Godot to .NET 7 is to take advantage of some of the new features that would allow us to improve the GodotSharp implementation.
However, we also have to keep in mind that if the GodotSharp library targets .NET 7, that also means that users' projects need to target .NET 7, that's probably fine for most but some users may be reluctant to update to a non-LTS release (maybe due to company policy) and this would make things difficult for them.
There are probably a few ways in which this could be solved, such as multi-targeting, but first we'd have to decide whether we want to update to .NET 7 or stay in .NET 6, it seems .NET 7 also includes some breaking changes that may complicate the update so it may be safer to stay in .NET 6 considering how close we are to the 4.0 release.

Great discussions and thanks for the PR link, somehow missed my search queries.


Quasar license?

What license does Quasar have?
Only indication is GPL-2.0 on the main Sourceforge project page but it seems there is nothing directly attached to the source code.
Recommend contacting the authors.

Sent a message to user trukfixer (https://sourceforge.net/u/trukfixer) who seems to be active.
Message text

Hi,
I wonder what the license of Quasar (https://sourceforge.net/projects/qua/) is? The Sourceforge project page says GPL, but nothing within the download says anything about a license. It would be nice if sharing and modifying would be allowed.
Thanks and many regards,
Trilarion

I didn't get a reply for over a month. There does not seem to be any other contact method. I give up.


[FormRecognizer] Rename for cross-language API consistency

Part of #8610

/azp run js - formrecognizer - tests

The failing live tests should be passing after we merge #8749 as we will no longer passing the charset part.

/cc @kristapratico @samvaity @maririos @annelo-msft


[ocaml-close] Reach a consensus an merge/close the RFC

https://github.com/MinaProtocol/mina/pull/10058 reach consensus on slack with matthew and nathan

The PR is closed.


Use dirname(@FILE) instead of Pkg.dir

Add testing against 0.5 to Travis
this runs the most recent release candidate now, release once final tags are done
add Compat to REQUIRE and Distributions to test/REQUIRE
instead of assuming they will be present as indirect dependencies
And just a note so you're aware, the way in which you're doing conditional dependencies here for optional Blink and Escher integration is deeply incompatible with precompilation. If the set of packages present at precompile time does not match the set of dependencies present at runtime, you will get either less functionality or errors. Until extern gets implemented, the only reliable way to do this would be to separate the conditional dependencies into a separate package that can depend on both.

Thanks @tkelman. If factoring out the package into another package is the best way to handle this, then I might as well add them to REQUIRE directly for now.


Migrate “Dynamic Admission Control” to concepts section

This is a Feature Request
What would you like to be changed

Review https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/
-Decide what counts as reference documentation, and identify any sections that are better documented inside Concepts or Tasks
Make appropriate changes OR log new issues for the tasks you identified (and then close this one)

Why is this needed
https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/ is a mix of Task- and Concept- shaped documentation. Though aimed at advanced readers it is not reference content.

/kind feature

/priority backlog

/remove-lifecycle stale

/remove-lifecycle stale


Proposal Tasks

Temporal

[x] Introduction: @mahm00d27
[ ] Data Science Techniques: @jennifer-hoang

Dashboard

[ ] Add Sketch: @jessie
[ ] Conclusion: @shyan0903

#12
Added Intro to temporal model.


Support Configuration of OIDC

Describe the solution you'd like
It would be great if the Terraform provider supported the OpenID Connect Integration.
Additional context
There are already REST APIs for OIDC configuration and identity mappings.

Dup of #26

Don't know how I missed that and the 3 other open OIDC issues 😱
Thanks.

@critchtionary I moved the issue from Artifactory provider repo to this Platform provider repo 😄. This is why you didn't see these dups until now.


Fix remaining issues with snapshot expiration for branching and tagging

This updates https://github.com/apache/iceberg/pull/4578 to fix a few remaining issues.
@amogh-jahagirdar, I was going to comment on the last issue about how to compute the unreferenced snapshots to retain, but I thought it was easier to demonstrate with a PR instead.
I also went ahead and expanded a few tests and fixed problems in the tests, like creating branches from hard-coded snapshot IDs.

Thanks @rdblue for cleaning it up, yeah I think the complex map is not really needed. I had it because I thought it would be more efficient to avoid having traverse different branches multiple times. once a branch's lineage was traversed it could reside in memory. But this may be overkill and not the dimension to optimize for. Thanks for adding more tests as well!


ModuleLauncher does not allow to take remoteRepositories that need username and password.

Let's assume I need to launch a module that sits in a private maven repo (which needs a user/pwd):
java -jar target/spring-cloud-stream-module-launcher-1.0.0.BUILD-SNAPSHOT.jar --modules=io.myorg.custom.module:elasticsearch-sink:1.0.0.BUILD-SNAPSHOT -spring.cloud.stream.bindings.input=ticktock --remoteRepositories=http://mvnrepo.myorg.org/repositories/snapshots

The code will fail with an unauthorized error (401). For some reason there is no way to pass in the repository identifier that defined the password in ~/.m2/settings.xml.
Maybe something simple like the convention below will be good enough?
--remoteRepositories=<repoIdentifier>::http://mvnrepo.myorg.org/repositories/snapshots

This <repoIdentifier> could be used instead of the autogenerated on in the code and needs to match the server entry in settings.xml. If none is given, the auto-generated one could be used. However, the code still needs to be 'fixed' to also consider settings.xml, which currently seems to be ignored.
Let me know if that makes sense. I can do a PR....

We shall add support for repository authentication.
I'm not sure we want (or can even, as I'd have to have a look at how Aether works) the code to rely on a local settings.xml file. Generally speaking, it is assumed that the admin (and hence the deployer implementation) may be running in a cloud environment, where no previous human installation/interaction has happened. Ideally, all configuration should be done through Spring Cloud Dataflow, not through the native tools (this relates to my comment about the kubernetes. options in your kubernetes deployer implementation)
I created https://jira.spring.io/browse/XD-3634 to track this

This is already in scope for the generic cloud deployer w-i-p.


[NEW ICON] Pygame, SvelteKit, AlpineJS, Netlify, Heroku

Skill Name
Pygame, SvelteKit, AlpineJS, Netlify, Heroku
Why?
Pygame; Very popular python game library
SvelteKit - Popular meta framework for svelte
AlpineJS - Another frontend framework
Netlify and Heroku - Popular hosting services
Reference Image
Pygame:

SvelteKit:

AlpineJS:

Netlify:

Heroku:

@SuPythony These icon requests are alright, but SvelteKit might be a duplicate, as both Svelte and SvelteKit has the same logo minus the text.

@skepfusky Yeah, that's a problem. But Svelte and SvelteKit are different skills, so I believe they should have different icons too.

@SuPythony Ah, I can see why. But I guess it'll be placed under a different background color perhaps? I'm not sure :p

@skepfusky The Svelte icon in this repo is not the original one but with inverted colors. So I think we can use the original Svelte logo for SvelteKit. Also, the text would be necessary like only SK can be written to differentiate it from Svelte.

Heroku already exists, I'll work on adding the other ones when I'm less busy next week.

@tandpfun Heroku isn't there in the readme list

I can't find a pygame logo, I think svelte & sveltekit are branded in the same way, so the svelte icon covers that.

Added in a50fa57465e82a1147fa512fb3d64cc5902df578


[devtools] update WNDT65

What's changed, or what was fixed?

add x-refs and updates to WNDT65

Fixes: #5670
Target Live Date: 2018-02-09

[x] This has been reviewed and approved by @kaycebasques (myself)
[x] I have run gulp test locally and all tests pass.
[x] I have added the appropriate type-something label.
[x] I've staged the site and manually verified that my content displays correctly.

CC: @petele

:tada: This has been pushed live to https://developers.google.com/web/


Problems compiling BlueCryptor with CommonCrypto

When I try to swift build BlueCryptor on OSX, I get:
BlueCryptor/Packages/CommonCrypto-0.1.0/module.modulemap:18:12: error: header '/usr/include/CommonCrypto/CommonCrypto.h' not found
header "/usr/include/CommonCrypto/CommonCrypto.h"
^
BlueCryptor/Sources/Digest.swift:21:9: error: could not build Objective-C module 'CommonCrypto'
import CommonCrypto
^
...
BlueCryptor builds fine on Linux.

On OS X, you need to install Xcode Command Line Tools. The instructions are located here -> https://developer.apple.com/library/ios/technotes/tn2339/index.html#//apple_ref/doc/uid/DTS40014588-CH1-WHAT_IS_THE_COMMAND_LINE_TOOLS_PACKAGE
I'll update the README.md to reflect this.

Fixed in 0.1.8 of BlueCryptor.


Release schedule after netopeer2 v2.1.71

Hello folks,
I would like to roughly know the release schedule for netopeer2 versions after v2.1.71.
Thanks as always.

We would definitely like to make a new release this year but there are still some major changes being finished so I am not sure we will make it. Generally, we make a new release every 2 months but we are late for that already.


Add draft feature flag for monthly statistics

Context
We need to see the November and December reports before being published, so I am creating a feature flag for checking the draft monthly statistics reports.
Link to Trello card
https://trello.com/c/xfHhFuVU/894-monthly-statistics-reactivate-the-monthly-statistics-page

Minor but something to consider – should we put this under the permanent feature flags? I know we discussed earlier about alternative approaches we could take after this month, that would not require us to manage the feature flag, but that is still undecided.

Minor but something to consider – should we put this under the permanent feature flags? I know we discussed earlier about alternative approaches we could take after this month, that would not require us to manage the feature flag, but that is still undecided.

I moved to permanent @JR-G


[SNAP-1427] Use serialization into direct ByteBuffers at Oplog and transport layers

Changes proposed in this pull request
This set of changes primarily targets two areas creating multiple copies with lots of garbage:
a) Oplog layer: Serialization of incoming objects is done into a flat byte[] then that is copied into a ByteBuffer again which is then written to channel in chunks. This creates unnecessary copies as well as lot of garbage for each write.
b) Connection layer: Like above MsgStreamer and MsgDestreamer classes create unnecessary copies and garbage. The chunking code in these can be replaced with leaner direct channel streaming. The MsgDestreamer class also causes totally avoidable thread-context switches.
Apart from the above, this set of changes also address a long standing problem in GemFire messaging -- the lack of scalability due to per-thread connection model with conserve-sockets=false. The last change is in fact required to fix hangs seen in bulk column tables inserts with redundancy in Colo environment.
Oplog changes:

Added DirectByteBufferDataOutput extending from Kryo's ByteBufferOutput
to provide a DataOutput on top of an expanding direct ByteBuffer
(kryo's impl already uses DirectByteBuffer by default). Also corresponding
DirectByteBufferDataInput to provide a DataInput on top of a DirectByteBuffer.
Use a new UnsafeHolder.reallocateDirectBuffer above that uses Unsafe.reallocateMemory
that will do inline expansion if possible. Embed a custom Runnable into the Cleaner
of DirectByteBuffers that can be reset to not free memory in case reallocation
was done to expand and create a new DirectByteBuffer.
Changed the APIs in DiskEntry, OplogSet etc to pass through ValueWrapper which
has been changed to contain a ByteBuffer instead of a byte[]. In lower level
internal APIs ByteBuffer is passed directly when "isSerializedObject" flag
is no longer required.
Changed Oplog/OverflowOplog to use ChannelBufferUnsafeDataOutputStream instead of
channel and separate writeBuffer; this existing stream already uses a DirectByteBuffer
to buffer data, as well as provides a pass-through for large DirectByteBuffers (>16K)
in its write(ByteBuffer) method so the serialized output in DirectByteBufferDataOutput
can be directly fed to this avoiding any copying for large enough buffers. Likewise reads
now directly get a DirectByteBufferDataInput from channel and deserialize region value from it.
This also simplifies lot of custom serialization, flush code in the two Oplog classes.

P2P connection changes:

Added MsgChannelStreamer and MsgChannelDestreamer classes that extend
ChannelBufferUnsafeData* classes to provide a direct ByteBuffer based DataInput/DataOutput.
MsgChannelStreamer now uses a non-blocking channel to write only as much as possible in
one go and then move on to writing to other servers (when message has to be sent to multiple
servers) for best performance.
New property p2p.useNIOStream (true by default) that switches to use these two classes
directly on the underlying SocketChannel; for conserve-sockets=true case appropriate locking
is done in the channels till whole message is sent
New connection pooling using Apache commons-pool2. A new QueryKeyedObjectPool
implementation adapted from commons-pool2 GenericKeyedObjectPool has been added that also
allows for iterating all objects by key etc (where key is a DistributedMember).
Sending side now uses the above pool with conserve-sockets=false (which has been made the
default) with pool expiration to keep the total number of connections in check. No selector on
receiving side since with modern linux NPTL threads, idle threads are no scalability problem except
for the heap (so selector is only useful to reduce total memory consumption while effort/risk is high).
P2P Handshake no longer has the additional total size, ID and such fields which are no longer
useful rather some like total size are not possible to fill in without pre-serializing data fully into buffer
(or fallback to previous chunking which has other issues like hangs, context switches etc).

Patch testing
Store and SnappyData precheckin. Extensive TPCH performance testing. Long discussions in email
chains on the gains in GC and performance have been detailed.
ReleaseNotes changes
The change in the connection model to be pool based from per-thread based with
conserve-sockets=false (which is also the default now).
Other PRs
See corresponding PR on SnappyData side.

Merging after correcting all new issues in store regression.


Running daprd in docker-compose failed to load components

Note: If you have a general support question and are looking for a quicker response, please checkout our discord channel for answers from the community:
https://aka.ms/dapr-discord
In what area(s)?

/area runtime

/area operator

/area placement

/area docs

/area test-and-release

Ask your question here
I have a components folder locally with my statestore.yaml file. When I am running docker-compose to start daprd, it fails to load the component and spit error "no such file or directory".
I have created the correct volume with its mapping directory. Could anyone advise what possibly go wrong in this docker-compose file?
This is the error message I get:

pluggable-component-dapr-1        | time="2023-02-24T02:31:43.723916529Z" level=info msg="Initialized name resolution to mdns" app_id=client instance=7acc903d120a scope=dapr.runtime type=log ver=nightly-2023-02-23
pluggable-component-dapr-1        | time="2023-02-24T02:31:44.372734361Z" level=info msg="pluggable component 'quickstore' was successfully registered for 'dapr.proto.components.v1.StateStore'" app_id=client instance=7acc903d120a scope=pluggable-components-grpc-connector type=log ver=nightly-2023-02-23
pluggable-component-dapr-1        | time="2023-02-24T02:31:44.372809447Z" level=info msg="loading components" app_id=client instance=7acc903d120a scope=dapr.runtime type=log ver=nightly-2023-02-23
pluggable-component-dapr-1        | time="2023-02-24T02:31:44.372832843Z" level=warning msg="failed to load components: open : no such file or directory" app_id=client instance=7acc903d120a scope=dapr.runtime type=log ver=nightly-2023-02-23

This is the docker-compose I get:
services:
  client:
    build:
      context: .
      dockerfile: FirstDaprStateClient/DockerFile
    ports:
      - "50002:50002"
    depends_on:
      - redis
      - quickstore
      - placement
    networks:
      - hello-dapr
  dapr:
    image: "daprio/daprd:nightly-2023-02-23-linux-amd64"
    command: [
      "./daprd",
      "--app-id", "client",
      "-app-port", "3000",
      "--dapr-grpc-port", "50002",
      "--enable-api-logging", "true",
      "--unix-domain-socket", "/tmp/dapr-components-sockets",
      "--placement-host-address", "placement:50006", # Dapr's placement service can be reach via the docker DNS entry
      "--log-level", "debug",
      "--resources-path", "/components"
     ]
    volumes:
        - "./components:/components"
        - "/tmp/dapr-components-sockets:/tmp/dapr-components-sockets"
    depends_on:
      - client
      - quickstore
      - redis
    network_mode: "service:client" # Attach the nodeapp-dapr service to the nodeapp network namespace
  quickstore:
    build:
      context: .
      dockerfile: quickstore/DockerFile
    volumes:
      - "/tmp/dapr-components-sockets:/tmp/dapr-components-sockets"
    networks:
      - hello-dapr
  placement:
    image: "daprio/dapr"
    command: ["./placement", "--port", "50006"]
    ports:
      - "50006:50006"
    depends_on:
      - quickstore
    networks:
      - hello-dapr
  redis:
    image: "redis:alpine"
    ports:
      - "6379:6379"
    networks:
      - hello-dapr
networks:
  hello-dapr: null

@superwalnut It looks like you're trying to map your local Dapr UDS folder /tmp/dapr-components-sockets to both the daprd and pluggable component containers.  At least on Mac, this is known not to work (i.e. Docker Desktop doesn't support propagating UDS files between the local host and running containers.
Instead, create a volume within the composition and have the containers each map that to /tmp/dapr-components-sockets.  Note that your component container should also use network_mode: "service:client" as it's running as a sidecar to the application in the same way as Dapr (that is, it would be if deployed to k8s).


chore: make vcr tests pretty-print JSON

This makes recordings of HTTP requests and responses more readable at the cost of a little more code.
cc @lamchau @anuraaga as I'm still learning python, so possibly my approach isn't ideal. Changes welcome!
Fixes #127

looks tidy

@codefromthecrypt this is so much cleaner! very slick approach

thanks for the look, folks


Extending cargo test with extra steps

It would be nice if I could specify additional commands/steps to run when running cargo test. The example would be to run cargo fmt -- --write-mode diff as a sub-test, or running the binary (not just its tests) with supplied parameters. Now, I have to type all these commands before committing my code, or wrap them in a makefile.
But, to be honest, I don't have a concrete idea how the configuration would look like while preserving some amount of platform-independence. I know I can create a fake integration test with no harness and do these steps from there, but that sounds a little overcomplicated.

@vorner,
You should use either Makefile or cmd/sh script.
Cargo isn't designed as a replacement for them.

Either after or before, I don't really care about the order.
So, is the right way to use cargo to actually wrap it into something? From all the tutorials I got the impression it should be the user-facing tool, not a backend.

@vorner,
Yes, you should wrap it into something.
You can use build.rs to do something before, but it is antipattern.
Look at https://github.com/rust-lang/cargo/issues/545

So, if you explained this likely isn't going to happen and why, should I close the issue, or is the intention to leave it here just in case the idea gets revisited? Maybe I'm old-school, but I kind of expected a „WontFix“ resolution by now O:-)

@vorner,
Your issue is duplicate of #545.
This is why I suggested you to close your issue.

That one looks similar, but runs at different time, so I don't think it is a direct duplicate (that one talks about post-build, I talk about running during tests). And I didn't get the suggestion to close it myself O:-). OK.


Marker disappearing when zooming in

Hi,
found some weird display bug. When I use two types of markers they sometimes disappear when I zoom in. See code below.:
import pandas as pd
import numpy as np
from lightweight_charts import Chart

def calculate_sma(data: pd.DataFrame, period: int = 50):
   def avg(d: pd.DataFrame):
      return d['close'].mean()

   result = []
   for i in range(period - 1, len(data)):
      val = avg(data.iloc[i - period + 1:i])
      result.append({'time': data.iloc[i]['date'], 'value': val})
   return pd.DataFrame(result)

if __name__ == '__main__':
   chart = Chart(maximize=True)

   df = pd.read_csv('ohlcv.csv')
   chart.set(df)

   line = chart.create_line()
   sma_data = calculate_sma(df)
   line.set(sma_data)
   df['Gain'] = df['close'] - df['open']
   longs = df.query('Gain < -20')
   shorts = df.query('Gain > 20')
   for index, row in longs.iterrows():
      chart.marker(row['date'], 'below', 'arrow_up', 'green', 'L')
   for index, row in shorts.iterrows():
      chart.marker(row['date'], 'above', 'arrow_down', 'red', 'S')

   chart.show(block=True)

Somehow if I only use the "longs" markers, they will not disappear when zooming in.
Video of the bug:
https://github.com/louisnw01/lightweight-charts-python/assets/104310309/4b7ef48a-002e-41d0-a62b-4f06da46b579

Hey @Zartexo,
It appears this happens when markers are placed in a non chronological order. You could append each marker to a list and then sort the list by date before placing them:
markers = []
for index, row in longs.iterrows():
markers.append((row['date'], 'below', 'arrow_up', 'green', 'L'))
for index, row in shorts.iterrows():
markers.append((row['date'], 'above', 'arrow_down', 'red', 'S'))

for marker_item in sorted(markers, key=lambda x: x[0]):
   chart.marker(*marker_item)

Maybe I could implement auto sorting of the markers, but this could cause long loading times if someone is using a very large dataset.

Hi @louisnw01 ,
thank you. I adjusted my code and the problem is solved 👍
I think it is better to keep the loading times small and maybe have a note in the documentation instead.


customEnv is ignored for ingress-controller Pod

Using these helm values to set the timezone for kong pods:
customEnv:
   TZ: "Europe/Berlin"

Unfortunatelly this is applyed by kong proxy and the init container pods but disregarded by the ingress-controller pod.
_helpers.tpl:382
{{- $completeEnv := mergeOverwrite $autoEnv $userEnv -}}
should probably be like this:
{{- $completeEnv := mergeOverwrite $autoEnv $userEnv  $customEnv -}}

Indeed. Would you be interested in submitting a PR to add it? It should source from a separate .ingressController.customEnv key since it's not necessarily the same set of variables provided to the Kong containers. You'd also need to populate it before adding $userEnv to the merge:
{{/*
    ====== CUSTOM ENVIRONMENT VARIABLES ======
*/}}

{{- $customEnv := dict -}}
{{- range $key, $val := .Values.ingressController.customEnv }}
  {{- $upper := upper $key -}}
  {{- $var := printf "%s" $upper -}}
  {{- $_ := set $customEnv $var $val -}}
{{- end -}}


Dismissible should have onDragStart and onDragEnd events to prevent re-rendering the tree while user is dragging it

The Dismissible widget should have onDragStart and onDragEnd events, to prevent any odd behavior like setState() being called by an async function while user is interacting (dragging) with the dismissible. Such case will result the dismissible jumping back to its initial position while user was dragging it. If there were  methods like onDragStart and onDragEnd, we could use a flag to prevent such odd behaviors while the user is dragging the dismissible.
Using a GestureDetector inside the Dismissible will not help either, since calling methods like onHorizontalDragStart will block dismissible's normal behavior (it will not drag at all!).
Steps to reproduce such odd behavior:

create a ListView with Dismissible children, where dismissing an item from it will call an async http call to an api to load another item into the list, and after each item is loaded, call setState() so that the new item becomes visible in the tree.
Try dismissing a few items rapidly, now if you start dragging another item, it will jump back to its initial position if any of the previous async functions have been finished (since it calls setState to make the new item visible).

a simple pair of onDragStart and onDragEnd for the Dismissible widget would simply make us able to prevent any setState() calls while the Dismissible is being dragged, deferring it to either onDismissed or onDragEnd ("dismissing cancelled).

Hi @ramtinq
can you please provide your flutter doctor -v?
Also, to better address the issue, would be helpful if you could post a minimal code sample to reproduce the problem
Thank you

Hi @ramtinq
Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


Inline external stylesheet links inside templates

[x] CHANGELOG.md has been updated
Fixed issue #600 where <link rel=stylesheet> inside a <template> was not inlined.  If you want to exclude a specific stylesheet from inlining, you can add its path the the excludes option (or --exclude on command line).

cc @ergo


WSL2 Frontend reload

This is not the recommended way to work with WSL and docker reloading, but it is the easiest for the end-user.

Addresses #292

I don't think I can review this because I don't have a windows machine.


Filter by ID in datasource with JOINS

Hello, i have some problem with filtering by ID. We have datasource builded from JOINS more tables.
When you try fitler by ID, you will get Exception (Integrity constraint violation: 1052 Column 'id' in where clause is ambiguous) in
SELECT COUNT(`ticket`.`id`)
FROM `ticket`
LEFT JOIN `user` ON `ticket`.`user_id` = `user`.`id`
WHERE (`user`.`id`) AND ((`id` LIKE '%6008%'))

Solution:
SELECT COUNT(`ticket`.`id`)
FROM `ticket`
LEFT JOIN `user` ON `ticket`.`user_id` = `user`.`id`
WHERE (`user`.`id`) AND ((`ticket`.`id` LIKE '%6008%'))

Exist any way how to filter by ID in Datasource with JOINS?

when adding filter you shoud write full column name
so instead of ->setFilterText();
you can call >setFilterText('table.id');

Thanks a lot 👍


Can't find variable: name in NavBar

Exception when using NavBar, exception message as below:
ReferenceError: Can't find variable: name

This error is located at:
  in NavBar (at theme/index.js:33)
  in _class (at LoginComponent.js:30)
  in RCTView (at View:.js 35)
  in View (at SafeAreaView.js:40)
  ...
  ...

Located in NavBar.js:47
if (name || back) {
My env
react: 16.8.6
react-native: 0.60.5
galio: 0.6.0

Hi @mamkkl ,
Change the name variable to leftIconName. This should solve the problem locally. I'll make a hotfix for this issue as soon as possible.
🧜🏽♂

Hi @palingheorghe ,
I can run the app by change name to leftIconName. I will create a pull request for it.
Thank you.

Closed this because I fixed this with a merge in v0.6.1, you can find out more about this hotfix here: https://github.com/galio-org/galio/releases/tag/v0.6.1


Feature/jobs db footer 2

a new version of footer for hk in english

It would be great if we could call this something other than Footer2 😂
If it legitimately is HK only for now, might be best to make it a subcomponent of the existing footer, and return this component if the hk country code prop is passed in.  That way consumers don't have to have to reference a temporary component name or make the decision themselves.

@mengtzu I am thinking the final goal is using ver 2 to replace ver 1.
how u think we name it as 'hk footer' first?

HKFooter would be fine.  Move it inside the existing footer, return it instead of the existing footer if the country prop is hk, eventually just replace it entirely.  Consumers don't need to make any changes that way.

WIP ;-)
The followings are pending to be done.

Add makeDefaultHrefLink() the default props
Rename footer2 to HKFooter
Embed localization under component

@mengtzu @chiwongseekasia @patrickliu-sa should be available for another round of review, pls feel free to drop comments :-)


BUGFIX: Fix DoctrineCheckpointStorage transaction handling

Roll back transaction only on failure (see #2)
Commit transaction in updateAndReleaseLock()

Furthermore this adds some tweaks and improvements:

Fail if DB platform is not MySql/PostgreSql
because we can't guarantee behavior for other platforms
Remember locked sequence number to skip UPDATE if it
didn't change
Add unit and integration tests

Note: To run the integration test, the DB_DNS environment
variable has to be set (or configured via PhpUnit config file, see https://phpunit.readthedocs.io/en/9.5/configuration.html#the-env-element

Actually.. looking at it, we can skip the additional variable


[Bug]: Issues when signing up.

What happened?
When creating a account when you tap "Signup" the first time you get a issue, when you tap it the second time as well you get a issue...
It works the third time and your account gets created, although sometimes it sticks with the second time error - Failed to create record, and doesn't create the account at all.
FIRST TIME:

SECOND TIME:

Version
v0.2.2
Duplicate Issues

[X] There are no duplicate issues/the solutions provided don't work for me.

You are literally trying to make an account called test.

You are literally trying to make an account called test.

Same issue came when I made a real account?

also why should the issue come if the account is called test??

also why should the issue come if the account is called test??

Because it already exists. It's used internally I think

You are literally trying to make an account called test.

Same issue came when I made a real account?

Username is too short. I need to make more descriptive errors.

also why should the issue come if the account is called test??

Because it already exists. It's used internally I think

Ok, but when I created a account called "Ken" I faced the same issue. First click I got the first issue, second time I got the second issue then I tapped again and the acc created.

You are literally trying to make an account called test.

Same issue came when I made a real account?

Username is too short. I need to make more descriptive errors.

Yes, please. Or make it so that users can't create usernames under certain characters.

You are literally trying to make an account called test.

Same issue came when I made a real account?

Username is too short. I need to make more descriptive errors.

Yes, please. Or make it so that users can't create usernames under certain characters.

They can't. My db won't allow it

You are literally trying to make an account called test.

Same issue came when I made a real account?

Username is too short. I need to make more descriptive errors.

Yes, please. Or make it so that users can't create usernames under certain characters.

They can't. My db won't allow it

Oh okay, no worries.

Reopening until fixed...


automation: allow to run the tests out of the container

This PR needs some more work but I would like to get some feedback. It is working on my Fedora 32 VM but some tests are failing. I need to investigate if it is related to something missing in the script or anything else.
In addition, I need to add documentation for the run-test-system.sh script.
Thanks!

The CI failed with automation/tests-machine-utils.sh: No such file or directory

The CI failed with automation/tests-machine-utils.sh: No such file or directory

Oops. I didn't commit the file. Fixed. Thanks!

Rebased and ready for review. Thanks!

Does this fix #904, too?

Does this fix #904, too?

Not sure. If the interfaces are named as "eth1" and "eth2" before running the tests, yes. If not, this is not going to work because the script is creating eth1 and eth2 veths.

Changes done, thanks! @cathay4t


[Feature Request] - package agnostic runner

I've recently tried moving from serverless to SST ION and noticed that it requires yarn as the default package manager based on the OpenNext deployment.
Trying to run the application with another package manager throws errors such as missing the package manager, or
Error: Next.js requires react >= 18.2.0 to be installed.
I would like to be able to execute the deployment and dev environments using the package manager of my choice (in this case Bun)
Thank you.

OpenNext does support the 4 package manager (i.e. npm, pnpm, yarn and bun).
The error you show has nothing to do with OpenNext, Error: Next.js requires react >= 18.2.0 to be installed is thrown by Next not OpenNext


Documentation: Add "usage info" that describes the flags

Instead of throwing an exception in case of unrecognized flags...

Added a usage info in case of unrecognized parameters - suppressed exception

It does show the usage info now, but the flags do not work. I always get the same look and feel (the original one).
Even, if you specify something other than classic and onenote, the editor starts with the old layout:
./ownNoteEditor --lookAndFeel IdontExist
Option lookAndFeel found: IdontExist
[snip]

I'm using --lookAndFeel="oneNote" and that works on my end

yes, this works, but in that case the help text is confusing:
Valid options are:
 -lookAndFeel,--lookAndFeel <arg>   Layout to use - "classic" or "onenote"

This help text tells me that the argument is either --lookAndFeel classic or --lookAndFeel onenote.
Btw, the text also states onenote, which does not work either. -> case sensitivity
It should say something like:
Valid options are:
 -lookAndFeel,--lookAndFeel="<arg>"   Layout to use - <arg> can be "classic" or "oneNote"

Thats why you need users to build usable software :-) Hopefully, now it works as expected

thanks, it works.


"Error in RecurringService" bug fix.

Fixes #434
This change adds some more helpful hints as to where the RecurringService
is running into errors by adding a "tag" attribute to RecurringService jobs.
example:
ERRO[0000] Error in RecurringService [Kube Resource Populator] : json: cannot unmarshal string into Go struct field ServicePort.targetPort of type int
ERRO[0031] Error in RecurringService [Kube Resource Populator] : json: cannot unmarshal string into Go struct field ServicePort.targetPort of type int
ERRO[0061] Error in RecurringService [Kube Resource Populator] : json: cannot unmarshal string into Go struct field ServicePort.targetPort of type int
ERRO[0091] Error in RecurringService [Kube Resource Populator] : json: cannot unmarshal string into Go struct field ServicePort.targetPort of type int
ERRO[0121] Error in RecurringService [Kube Resource Populator] : json: cannot unmarshal string into Go struct field ServicePort.targetPort of type int

This change also fixes the annoying bug listed in the example above by using a interface{}
in the service port type. This does not seem to cause an issue with any other services yet.
type ServicePort struct {
	Name       string      `json:"name"`
	Port       int         `json:"port"`
	Protocol   string      `json:"protocol,omitempty"`
	NodePort   int         `json:"nodePort,omitempty"`
	TargetPort interface{} `json:"targetPort,omitempty"`
}

Coverage decreased (-0.02%) to 55.305% when pulling 21b3e641b1856430c2a4d9320a34ce7b934fc6f9 on gopherstein:master into afeef465333f16ae0d15ae677e8e2aad276b53aa on supergiant:master.


Overhaul of ServiceX Docs for 3.0 release

Major PR for the documentation of 3.0 client library
This resolves #446

As a final step to merge to 3.0_develop, removing the doc_week entry from the docs.yml file.

This resolves docs: Add link back to GitHub repository from the documentation #446

Just for future reference (doesn't matter here), putting text in front of Resolves #XXX breaks the operations. So it needs to literally be just
* Resolves #446


🌸 Gardening.

Changing the name of the service is not a good idea
It's better to launch a service with the same wasm file but with a different service name


Add GDScript Module

Describe the feature
With the new GDScript language server support, and the now somewhat stable emacs-gdscript-mode package, I think it makes sense to combine these into a new lang module.

I'm down for that, considering I use godot myself. That said, I'm swamped at the moment, so it'll be a while until I get to it. I'll keep you posted.

If you're too busy, I'll give it a shot! I use doom emacs daily, the least I can do is contribute back.


Add link command

Add link command.
Using the existing GlobalModulesDir constant.
Using filepath.join() instead for GlobalModulesDir constant.
Add unlink command.
Add the link & unlink command to commands description.
Add a test for utils.v.
TODO: Give a better description of those 2 commands.
TODO: Add tests for this.

Thanks @spytheman for the review

You should also mention these commands in readme.


Rotary Embedding for unpadded sequences

This PR fixes an issue encountered when using RoPE with the pad/unpad logic where all the sequences in a batch are smaller than the global max sequence length. This issue can be fixed by always padding to the maximum sequence length, but there is an even better solution where we apply the rotary embeddings to each sequence without padding.
This brings some speed improvements especially for long sequences and bigger models(up to 10% for bert-base at 4096).
This is done by combining the functionality of ApplyRotaryEmb and ApplyRotaryEmbQKV_. None of these two classes expects  unpadded sequences of QKV as an input but they can be adapted to do so. This is what ApplyRotaryEmbUnpad does, it takes a tensor of shape (total_nnz, 3, nheads, headdim) and applies the rotary kernel inplace to the queries and the keys.
This also adds a test in the tests directory which compares the output of the forward and backward passes of the unpadded RoPE against a PyTorch implementation.

LGTM (although I am not an expert with these kernels, so if someone else can do a review it would be cool).
To me the  qkv = self.rotary_emb(qkv, cu_seqlens=cu_seqlens, max_seqlen=max_seqlen, seqlen_offset=seqlen_offset) could be mutualized between fa2 and not fa2 but besides that it's fine.
I launched a sanity check run to compare the results of the previous implementation and this one.

I added a single rotary kernel path which also passes the tests.
If we want to be a bit more thorough, we could follow flash_attn and test against the GPT-NeoX Transformers code.

@warner-benjamin not really familiar with GPT-NeoX so feel free to add the test.

is it normal that the GLUE test in test_glue.py is failing?

For the cos/sin caches, we can tie them at the model level so they are stored only as one in memory.

@staghado I'm merging this into main so we can use it for ablations. We can add cos_sin_cache tying in a future PR.


CFE-1037: Fix issues pertaining to DNSNameResolver controller.

This PR adds the support to provide port on which the CoreDNS is listening on as an input. RBAC permissions are added for getting events related to DNSNameResolver status updates. It also fixes the issue of deadlock condition in the resolver. New unit tests are added to increase code coverage.

/retest-required

/assign @alebedev87

/remove-lifecycle stale


VITE_ASSETS_ABSOLUTE_PATH meaning?

Hello,
VITE_ASSETS_ABSOLUTE_PATH - can you please specify which path i need to specify? Do i need so specifiy of path of B2b package or theme bundle path URL?

Hello @sunilit42 - This variable is for you to add your hosting domain when building the project for deployment, you can see more details in this section of the README:
https://github.com/bigcommerce/b2b-buyer-portal?tab=readme-ov-file#deploying-the-project

@bc-victor Thanks for reply. for local which value i need to set? as i see that value when we do deploy on server

@sunilit42 For local development the value is not used, therefore the value is irrelevant


Pairsfile for Inloc dataset

Hi, authors. I would like to use the image retrieval benchmark with the InLoc dataset but get no pairsfile when creating the global map. Can you provide it?
Thanks a lot!

Hi!
May I ask how you created the global map for Inloc? Running the normal point triangulation will not work because the images have not enough overlap in order to create sufficient 3D points.
Independent of this, the pairfiles creation is the first thing our benchmark script does. For this, global features are needed. Which one did you use?
Best,
Martin

Thanks for your quick response! I finally made the map using the global features.


Typo fix in Python server comment link to documenation.

Replacing a # with // in https://stripe.com/docs/api/checkout/sessions/create

Thank you!


ArrayBuffer as body must not be passed directly to XHR

When fetch is invoked with an ArrayBuffer as body, that ArrayBuffer is passed directly to the XMLHttpRequest, but invoking xhr with an ArrayBuffer is deprecated. Thus this causes a warning in some browsers, e.g. Safari. It should be wrapped in an ArrayBufferView: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send
When executing this fiddle with Safari, the warning is shown in the console:
https://jsfiddle.net/gkp1swke/4/

I tried passing an ArrayBufferView directly as a body to fetch, but this also yields an error, as explained in #344.

+1


Advanced creation should prompt for static site config before creating account

Originally from https://github.com/microsoft/vscode-azurestorage/pull/550#discussion_r362671685
Right now advanced creation will prompt for account, create account, prompt for config, change config. We want it to prompt for account, prompt for config, create account, change config

Per offline discussion: at some point, static website configuration was removed from advanced create. So add it back in using this order:

We want it to prompt for account, prompt for config, create account, change config


node: unrestrict node version to allow 18.x

You may disregard these recommendations if you used the Edit on GitHub button from dvc.org to improve a doc in place.

❗ Please read the guidelines in the Contributing to the Documentation list if you make any substantial changes to the documentation or JS engine.
🐛 Please make sure to mention Fix #issue (if applicable) in the description of the PR. This causes GitHub to close it automatically when the PR is merged.
Please choose to allow us to edit your branch when creating the PR.
Thank you for the contribution - we'll try to review it as soon as possible. 🙏

Nice! I believe this needs docs updates though? E.g. https://dvc.org/doc/contributing/docs#development-environment

@rogermparent @yathomasi, is it possible to make sharp an optionalDependency? I like to be on the latest version, so it's always painful to use dvc.org. I guess it's sharp that usually holds us back to support the latest version.

is it possible to make sharp an optionalDependency?

I am afraid it's not. Gatsby itself uses sharp to process and optimize the images.
The best approach would be to use the node version manager locally.

https://github.com/nvm-sh/nvm
https://volta.sh/ ( I prefer this)


v1.15 Backports 2024-07-03

[x] #33519 (@aanm) :warning: resolved conflicts
[x] #33528 (@aanm)

Once this PR is merged, a GitHub action will update the labels of these PRs:
 33519 33528

/test-backport-1.15


[UI][v0.6.0-rc-2] Uploading pattern through "/configuration/patterns" UI route returns error "Failed to upload pattern file: failed to import pattern: parse {file content}...: net/url: invalid control character in URL"

Current Behavior

MesheryPatterns component does not include a ‘pattern_data.pattern_file’ property on Post request to upload pattern endpoint after clicking the “Upload Pattern” button and returns  error "Failed to upload pattern file: failed to import pattern: parse {file content}...: net/url: invalid control character in URL"
Desired Behavior

Pattern file should be uploaded without errors through Meshery UI's MesheryPatterns component
Screenshots/Logs

Environment

Browser: Chrome
Host OS: Mac
Meshery Server Version: v0.6.0-rc-2
Meshery Client Version: v0.6.0-rc-2
Platform: Docker Kubernetes

Contributor Guides and Resources

🎨 Wireframes and designs for Meshery UI in Figma
🖥 Contributing to Meshery UI
🙋🏾🙋🏼 Questions: Layer5 Discussion Forum and Layer5 Community Slack

Thank you, @MarioArriaga92!


raft: resume paused followers on receipt of MsgHeartbeatResp

Previously, paused followers were resumed upon sending a MsgHearbeat.
Fixes #7037

I'm not sure what the travis failure is about. I can't reproduce that locally, but running ./test has other problems for gosimple and unused when I'm running on my Mac laptop.

@petermattis @xiang90 The travis failure is not related to this change. Seems like one of our external testing tool made some breaking changes. Will file an issue there. Thanks!

I worry this change will cause process paused all the time.
If a snapshot is sent and the FinishedStatus is reported, the process will be paused until getting the MsgAppendResp from the follower.
If the message is missing, the process status can not be changed if no resume in heartbeat later.

@siddontang @petermattis
I will give this a close look early next week. I will be on vacation for the next few days.

@siddontang Can you elaborate on your concern? If a follower is paused in state probe (e.g. after a snapshot has been sent) the leader will still send MsgHeartbeat messages and whenever a MsgHeartbeatResp is received the follower will be resumed and a MsgApp will be sent. If no MsgHeartbeatResp or MsgAppResp messages are being sent by the follower (or they are not being received by the leader), why should the leader continue to send MsgApps?

@petermattis
If the progress is paused, it can't be resumed until getting MsgHeartbeatRes, and leader won't send any following new entry to the follower:
// sendAppend sends RPC, with entries to the given peer.
func (r *raft) sendAppend(to uint64) {
	pr := r.prs[to]
	if pr.IsPaused() {
		return
	}

Of course, the leader can still send heartbeat to follower, but the progress can't be resumed in MsgHeartbeatResp.

@siddontang
This is a trade-off between fast recovery and cost saving. The recovery delay can be as long as a round trip time (~200ms) across continents after this change as you mentioned. Or we will waste CPU cycles to generate quite a few append entries requests. See https://github.com/cockroachdb/cockroach/issues/12485 for details.
For etcd, this is fine. The downtime is usually ~minutes, so 200ms additional down time seems fine to me.
For CockroachDB, they are aware of this problem, and they seems to be OK with it.
What is your concert? @siddontang
I do not quite get

but the progress can't be resumed in MsgHeartbeatResp.

Can you explain more?
/cc @manishrjain Any concern from dgraph? @aaronlehmann Any concern from swarmkit?

@xiang90 @petermattis
Sorry that I don't see this PR handle resume in heartbeat response. I think it is ok now.

For etcd, this is fine. The downtime is usually ~minutes, so 200ms additional down time seems fine to me.
For CockroachDB, they are aware of this problem, and they seems to be OK with it.

This is true for CockroachDB as well. Adding a few hundred milliseconds to the time to recover a replica is a small price in comparison to the wasted CPU cycles of trying to send Raft log entries that will likely be dropped at the RPC layer. To give a more concrete example of what we are seeing and which this PR alleviates:

Run a 3-node cluster.
Take one node down for 5 min.
While the node is down, every 200ms (our configured heartbeat interval) Raft generates a MsgHeartbeat to the down node which resumes the follower. The next proposal then triggers a MsgApp to the down node.
The size of the MsgApp messages to the down node increase over time as Raft helpfully includes up to MaxMsgSize bytes of Raft log entries.

If there were only a small number of Raft groups the generation of the MsgApp messages for the down node wouldn't be too noticeable. But CockroachDB can have O(10k) Raft groups per node.
@xiang90 No rush on reviewing. I'm leaving on my own vacation tomorrow.

This change seems fine for SwarmKit. Fast recovery isn't very important for us. It seems logical to avoid generating MsgApp traffic until the recipient node is confirmed to have recovered. I don't think the current approach has caused us any problems, though.

Sounds good for Dgraph as well. It's the logical thing to do.

LGTM


Web example does not work

Woops messed up the version last push, I just pushed another version that should work, can you give it a go? Thank you!

Thanks for quick answer
Still see the problem

Ah ok but that's a different error now! That seems like WebGPU isn't supported :/
I haven't tested on Brave - I think it still requires some flags to enable WebGPU. Additionally, the website requires a Chrome origin trial, so Brave might not like that. On chrome that's enabled with [enable-unsafe-webgpu](chrome://flags/#enable-unsafe-webgpu)
You can try out whether WebGPU works here: https://webgpu.github.io/webgpu-samples/?sample=texturedCube

https://webgpu.github.io/webgpu-samples/?sample=texturedCube
it works
and egui works https://emilk.github.io/ehttp/index.html

And your web app also works now =)

Ahh ok phew :D Maybe was just some cache not clearning then. Closing this but do lmk if it breaks again / other issues, thanks!


OHVectorImage.renderAtSize() fails on iOS 10 beta 2

Example swift code:
let image = OHVectorImage(PDFURL:url)
let renderedImage = image.renderAtSize(CGSizeMake(60,60))

This will crash in OHPDFPage.m on line 108 with EXC_BAD_ACCESS

Well, FWIW in iOS 10 beta 3 the crash is gone.

Thx for the update 😉


combined timer, chat, translation, sending, maxlength

combined the latest versions for chat functionalities and external api


Fix "ng help" typo in README.md

Documentation says "ng --help", but the actual command is "ng help".

I signed it!

Dupe of #3159. Please search through PRs before submitting a new one.

Closing as a dupe, but thank you for taking the time to make the PR.


Return version from latest tag when no new commits

Where there are no new commits checked in since last release version, the returned version should be the same as the last tagged release.
Otherwise you risk releasing again on the same commit if you start a new build in the CI.
Premise: The base version is 1.2.0, and the latest release tag is v1.2.8 at git HEAD.
Running jx-release-version should return 1.2.8 and not 1.2.9.

Anyone has any thought about this?

If your latest git tag is 1.2.3 and your build automation file is 1.2.0 then jx-release-version will return 1.2.4

If the latest git commit has the git tag 1.2.3, then every time you run jx-release-version it will increment release. You could end up building multiple releases of the exact same git commit.
For instance taken from this repository could look like this:
482265f (tag: v1.0.17), (tag: v1.0.18), (tag: v1.0.19), (tag: v1.0.20), (tag: v1.0.21) Merge pull request #22 from almerico/master
It would be much better if running  jx-release-version could keep giving 1.1.17 if there are no changes.

/remove-lifecycle stale

I hope this can be done with jx-release-version.
Otherwise I need to perform my own checks prior to running jx-release-version.
Otherwise we risk releasing the same commit for each time we run a build on it.

Though I do see that it could be a use case to know the next release version, regardless of HEAD being already tagged. Perhaps it could be implemented with an additional flag on the command line.
jx-release-version > v1.1.1
jx-release-version --force > v1.1.2


Markdown body rendering escape characters

When my HTML is rendered, the body is rendering the HTML tags incorrectly:
For example:
## YOLO
Chia quinoa meh, you probably haven't heard of them sartorial Holowaychuk pickled post-ironic. Plaid ugh vegan, Sixpoint 8-bit sartorial artisan semiotics put a bird on it Mission bicycle rights Club-Mate vinyl.

becomes in the page source:
<h2 id="yolo">YOLO</h2>
<p>Chia quinoa meh, you probably haven’t heard of them sartorial Holowaychuk pickled post-ironic. Plaid ugh vegan, Sixpoint 8-bit sartorial artisan semiotics put a bird on it Mission bicycle rights Club-Mate vinyl.</p>

Which does not render correctly in the browser.
Changing the markdown file to:

YOLO

Chia quinoa meh, you probably haven't heard of them sartorial Holowaychuk pickled post-ironic. Plaid ugh vegan, Sixpoint 8-bit sartorial artisan semiotics put a bird on it Mission bicycle rights Club-Mate vinyl.

Produces the same output.
I have set escape: false in the front matter, and have tried setting escape: false both in my gulp task and in the marked config options, none of which change the behaviour.
If it helps, my gulp task is as follows:
gulp.task('projects', function() {
  return gulp.src('src/markdown/test/*.+(md|markdown)')
    .pipe(data(function(file) {
      return JSON.parse(fs.readFileSync('./tmp/json/test/' + path.basename(file.path, path.extname(file.path)) + '.json'));
    }))
    .pipe(nunjucksMd({
      path: ['src/templates/']
    }))
    .pipe(rename({ extname: '.html' }))
    .pipe(gulp.dest('tmp/projects'));
});

Does anyone have any clue as to what I am doing wrong?

I have found a solution to this.
Where the body is called in the nunjucks template, apply the safe filter like so:
{{ body|safe }}

The string will no longer be escaped.

@Grrrotbag Thanks for pointing out. Setting escape was only supported though global option till now.  Setting escape through frontmatter was documented but was never implemented.
Checkout the new version of this plugin. It should solve your problem.


Finetuning deeplab/FCN

How do I fine tune deeplabv3 ?

You can use the training code in https://github.com/pytorch/vision/tree/master/references/segmentation, load the pre-trained model there and change the last classifier / dataset.


♻ PROD URL - Do we need them?

Cc: @adamcogan @bradystroud @BrookJeynes @Aibono1225
Hi team
Pain
I recently found this prod link on Google Search Console: https://prod.ssw.com.au/rules/password-ages/
The link is up and running but I feel it shouldn't exist, or at least shouldn't be found on searches
Tasks

[ ] 1. Please investigate and fix (or give reasons to keep it up)

Screenshots

Figure: 117 "prod" pages found by Goggle
Thanks!

The prod. domain is used in frontdoor to direct traffic to the old site. Chris mentioned we could change it to legacy. but this will need investigations into whether it will break anything.

Hi @BrookJeynes / @chrisschultzssw

Can we hide from Google?
https://developers.google.com/search/docs/crawling-indexing/block-indexing

The prod. domain is used in frontdoor to direct traffic to the old site. @chrisschultzssw mentioned we could change it to legacy.

Not a fan of the rename - especially since legacy suggests that the site is ye'd (which is not the case)

Can we hide from Google?
https://developers.google.com/search/docs/crawling-indexing/block-indexing

Yes, that FrontDoor route can have a rule which appends the header X-Robots-Tag: noindex applied to all requests. This should prevent indexing without modifying the underlying robots.txt file.

that FrontDoor route can have a rule which appends the header X-Robots-Tag: noindex applied to all requests. This should prevent indexing without modifying the underlying robots.txt file.

Updated the original task to reflect that ;)

Not a fan renaming - some of the content on the old site has not been migrated and is still "production".

agreed

As per my conversation with @chrisschultzssw, we've gone ahead and added X-Robots-Tag: noindex to the header. This was done by manual configuration in the server settings.

We changed this solution from a HTTP Response Header setting to a URL Rewrite outbound rule
            <outboundRules>
                <rule name="Add X-Robots-Tag for requests to prod.ssw.com.au" patternSyntax="Wildcard">
                    <match serverVariable="RESPONSE_X-Robots-Tag" pattern="*" />
                    <conditions>
                        <add input="{HTTP_HOST}" pattern="*prod.ssw.com.au*" />
                    </conditions>
                    <action type="Rewrite" value="noindex" />
                </rule>
            </outboundRules>


limit on the /Me/links/encounters/{id} endpoint is broken

passing a limit parameter doesn't affect the number of encounters returned

fixed, per that last commit.


list with dates and types to import in calendar

Request
Hi Bram,
Been a long time user, and still very happy with the options your CC offers, it's the main alerter in my HA config ;-)
yet, we now have the native calendar integration, and given the new script options in HA 2023.7 will offer us returning data, and the release party showed Frenck displaying his calendar events for his waste management, I tried to create a calendar in HA with Afvalwijzer dates.
Only to find we can not do that, if only because we just have 2 entities (next_type and next_date) and a few sensors for the specific waste types.
In the old days of this CC, we still had an option for the full year list, or at least that was used to create the other entities.
Couldnt this somehow be returned, into a form so that we could use it for creating calendar events, or maybe even automate that using some import?
Please have a look if you didn't already,
anyways, cheers,
Marius
Additional information
I did see we can dl a pdf with all dates. I tried to manually import those into the Mac calendar app, but as the PDF holds many formatting issues (not all have a hot popup, and many have wrong ones setting an activity in the wrong month) that PDF isnt super useful in itself....
maybe there still is a hidden date list in that website somewhere

Keep

Currently I'm working on a new release supporting all Dutch waste providers. I'll take this into account as well.


Disable tokio dependency for rdkafka

Pull request
Disable tokio dependency for rdkafka and also remove explicit dep to rdkafka-sys by ugrading to a git tag: https://github.com/fede1024/rust-rdkafka/commit/2901a4b9027c3cce6fcae48c124fe5296397704a slightly beyond release 0.24.
Description
We include tokio for rdkafka, which we dont need. We still need tokio for tokio-postgres, but it still makes sense.
Checklist

[x] The RFC, if required, has been submitted and approved
[x] Any user-facing impact of the changes is reflected in docs.tremor.rs
[x] The code is tested
[x] Use of unsafe code is reasoned about in a comment

Let's wait with this untill we can pull a package and not a git hash


Make sure we don't use C# 6

Added LangVersion = 5 to make sure we don't accidentally use C# 6 (for now).

Argh! Mono... Why do we still build for Mono 2.0?

Because mono3 is a buggy pile of cack generally :)

I think we should look at the latest version of Mono, anything under 3.10 I had problems with but after 3.10 haven't had much if any issues.
Would be good to ditch 2.0.

I won't bother with this. We desperately need to update our Mono infra to support newer stuff.

@khellang seeing as we now target latest mono (4.2.2) and C# 6 syntax is supported as of Mono 4.0, maybe we should force the langversion to 6 ?

I don't think there's a need to force LangVersion.
Since it's not specified anywhere, VS will assume you want to use latest, so if you have VS2015, it wants you to use C# 6.
The reason this was proposed was because we didn't want it to suggest using C# 6 because Mono didn't support it.
Since we're off the old Mono version, I don't see any reason not to go nuts with C# 6 :grin:

@khellang :+1: let's have a chat about this tomorrow and make a united decision

Surely we just run R# Clean Code ;)
On Monday, 22 February 2016, Andreas Håkansson<EMAIL_ADDRESS>wrote:

@khellang https://github.com/khellang [image: :+1:] let's have a chat
about this tomorrow and make a united decision
—
Reply to this email directly or view it on GitHub
https://github.com/NancyFx/Nancy/pull/1970#issuecomment-187323296.


Idea: Vehicle capacity checker

If service vehicle has too high capacity, it can cause problems because now that vehicle is going to have far more buildings to visit.
Example: Hearse with 20 capacity is potentially visiting 19 other buildings before reaching the last one. Meanwhile, a hearse with 2 capacity at most only visits one building before last one.
Maybe iterate the service vehicles to check capacities and list any that might be problematic?
https://github.com/CitiesSkylinesMods/TMPE/wiki/Vanilla-capacities

ok, so the problem with capacities is when vehicle could not find path to next building - it will be despawned and collected "things" return to source to be collected again, right?

ok, so the problem with capacities is when vehicle could not find path to next building - it will be despawned and collected "things" return to source to be collected again, right?

That might happen too. Certainly if vehicle has more buildings to visit there is more chance of path fail.
However, the main issue I noticed was just amount of time it would take to visit all buildings when capacity is too high. The service building sends out fewer vehicles (because higher capacity = each vehicle expected to visit more buildings). I'd end up with load of building warning notifications because instead of having a herd of hearses out doing work, the crematorium only sent like 2 hearses expecting them to visit 40+ buildings each.  Meanwhile, buildings all over the city were turning in to vertical graveyards and shutting down due to stale corpses piling up.


Prepare for -sys release 0.5.0

I messed up #41 by forgetting to also bump -sys.

Fwiw I also tried to update the vendored secp-zkp library, but that results in test failure which under valgrind shows that something is going very wrong memory wise and valgrind is pointing to something being wrong with the context. My hypothesis is that the preallocated context size changed in secp-zkp, but since we're reusing the Context from rust-secp, which is behind in C-libsecp the Context doesn't have the updated preallocated context size.

Just trying to be useful, but I can confirm that tests fail with latest secp-zkp. And I get the exact same result using the previously used commit (f3708a1ecb445b1b05a0f8fcd1da6a88f83d89c4).

We can update the library in rust-secp to match rust-secp-zkp since we are about to do a major release anyway.
@jonasnick suggested to me in another channel that he was working on this, so I'll leave that to him.

@jonasnick Any chance we can get a release out without the changes to the vendored C library? I would like to get rid of Git dependencies :)


RDMA support

Description
This pull request enable RDMA over Converged Ethernet support for ps-lite.
In order to send data with RDMA, the data should be put on a registered memory buffer.

src/rdma_van.h implements Van interface with rdma_cm and ibverbs.
include/ps/internal/allocator.h implements the memory allocator to manage this area.
bfc_allocator.h and bfc_allocator.cc implements the memory allocation alogrithm which is encapsulated by allocator.h.
Class SRMem in include/ps/srmem.h provides array-like access method on this region and can be constructed from SArray and C-like array.

Compile & Test
The patch depends on libibverbs and librdmacm and assumes there is a NIC with RDMA support and all drivers are working.
make -j $(nproc) USE_RDMA=1

and run the binaries under tests/ with env DMLC_ENABLE_RDMA=1
The tests programs should run well on multiple machines.
Acknowledgement
Thanks @snowzjx for supplying the BFC algorithm, and this allocation algorithm could be replaced by other better or more appropriate algorithms. Thanks @byronyi and @snowzjx for giving many valuable suggestions.
Comments
The SArray currently maintains a shared pointer, and implements zero-copy operation by moving the pointer to userspace data, and allocate and deallocate the memory with new and delete. Under RDMA and GPU Direct circumstance, the devices(NIC, GPU) need to register its own memory region. The use of new and delete by SArray cannot satisfy the device's memory management requirement.
Would it be a good idea to pass an extra allocator parameter to SArray thus allocation and deallocation can be managed by the device relevant allocator?

Hi @mli, mind to check again? We spent a lot time on this PR and would love if you could find a reviewer for it.

Thanks, the results look great. I put the code review request into our
internal system.
On Sat, Feb 17, 2018 at 4:53 AM, Bairen Yi<EMAIL_ADDRESS>wrote:

Hi @mli https://github.com/mli, mind to check again? We spent a lot
time on this PR and would love if you could find a reviewer for it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dmlc/ps-lite/pull/124#issuecomment-366439635, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZv4QxoJqNrM4Azh0mec_0LoQJbXhLFks5tVsu1gaJpZM4RuR96
.

Both one of our team members and me will help this PR together.

Fantastic. Happy lunar new year!

Thanks for your response and comments @mli !! I will fix above comments and answer your questions in the next following days as early as possible.

hi, I have one question about it: compared with the raw ps-lite working on IPoIP, can this implementation gets over 20% speedup? According some previous discussions, it seems the ZMQ library is pretty efficient for data transmission!

@crazyboycjr @byronyi Did you get a chance to address Mu's comments above?

Hi, @limingfan we haven't compared it with ps-lite on IPoIB, but we did some test on 100GbE TCP network. The acceleration ratio depends on factors of model, batch-size, PS and worker's network topology and overlap of back propagation and parameter synchronization.
We have done tests on some CNN models. The results shows that the AlexNet and VGG models can achieve more than 1.5x acceleration easily. However models like ResNet-50 cannot accelerate more because of the well overlap of computation and communication.
By the way, hi, @rahul003 , because we found that on models like Inception-BN, the rdma implementation slows down the training, so I'm trying to figure out the reason. I want to resolve Mu's comments after I address the slowing down problem.
Sorry about my late response:pray::pray::pray:.

@crazyboycjr @byronyi any update?

Hi all,
Along with our effort on BytePS (https://github.com/bytedance/byteps), we just open sourced our internal RDMA implementation (https://github.com/bytedance/ps-lite) for PS-Lite at Bytedance. It is based on @crazyboycjr's implementation (actually @crazyboycjr also worked on it during his internship here). @ymjiang and I has been tinkering with it for several months. Now it consistently outperforms ZMQ TCP across every model we benchmarked (e.g. AlexNet, ResNet, VGG, Inception).
I'd be happy to open a PR to send the patch upstream if there is enough interest. Let me know how you'd like to proceed.

I would like to complement @changlan 's statement. Let me share some end-to-end results on distributed training.
We use Tesla V100 GPUs, and set batch size as 32. Each machine (no NVLink) has 8 GPUs, and machines are inter-connected by 100 Gbps networking (can support TCP and RoCEv2). When using TCP, we are referring to the vanilla ZeroMQ implementation of ps-lite.
Note: The values are images per second.
Resnet50:

#GPU
TCP
RoCEv2

8
1008
2019

16
2279
4037

32
5048
7798

64
6954
14780

VGG16:

#GPU
TCP
RDMA

8
163
303

16
361
692

32
694
1393

64
1370
2777

Since AWS does provision 100Gbps RDMA via EFA, I imagine this would be more relevant :)

Users should refer to #151 as it is merged. @crazyboycjr @limingfan I am leaning to closing this one. Any comments?

Sure, I'm OK with it. @byronyi

Merged in #151


analyzer="path_hierarchy" not recognized?

Setting a field to:
path = String(analyzer="path_hierarchy")

... causes the following error:
elasticsearch.exceptions.RequestError: TransportError(400, 'MapperParsingException[Analyzer [path_hierarchy] not found for field [path]]')

I'm wondering why it recognizes analyzer="snowball" (as in the persistance example) but not analyzer="path_hierarchy"?

Ok, just figured it out: snowball is an analyzer ([link] (http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/analysis-analyzers.html)) whereas path_hierarchy is a tokenizer ([link] (http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/analysis-tokenizers.html)).
And, there doesn't seem to be a "path" analyzer :(
Sorry for the non-issue.

No worries, I want to have support for Analyzer objects in the future - allowing you to define them in python using another mini dsl. In the mean time, however, you need to define them manually and use their string names.

That'd be cool!


Fantastic Things has Fantastic Errors

Hi, Your framework was the exact thing I needed, But I cant running it on Colab. Many Errors, Too many library and package mismatches and so on...
If there is Running Colab Version which could be run correctly and been able to edit Mistral, That would be nice.
But a question?
Why we couldn't use Kaggle's TPU with above 300GB of ram and much faster?
Is there any solution to run it on Kaggle at all?
Best Wishes and thanks again

Thanks for labeling, As a reminder I should add that The kaggle has a Direct Model Loading Section, means we can load the model, Fix and Edit it, And Save it into our working directory, and Re upload it for further use on the kaggle itself.
Thanks again

It seems that the omegaconf is incompatible with Colab, but you can click cancel when they push the warning.
https://colab.research.google.com/drive/1lBmYw7AHkwUXAUGajPer9ZPK_bAoD0GA#scrollTo=WZvRsequGCTW
I have tested the GPT-2 model, it seems that Mistral is too large and colab does not have enough RAM.
As to the Kaggle's TPU, this would take some time as we haven't tested our code on TPU environment.
Thanks.

hi buddy, have you solved your issue yet?

Hi, Actually not. Still trying to find a memory efficient way to using it on Kaggles TPU. Do you have some good news?

hi Guys, Any update?

Not much, It's also the my first time to try TPU.
Give me some time.

I have some findings and need to discuss them with you, I searched and couldn't find any contact. here is my Email
<EMAIL_ADDRESS>it's important.
Thanks

Sorry for being late, you can find me via<EMAIL_ADDRESS>


WIP: fix sporadic slepian failures

This replaces the implementation for signal.slepian with one that uses a better algorithm (hat tip to nitime).
This ought to fix #3675.
The reason I've labeled this a work in progress is that I think the original slepian code was incorrect.  Going back to the original source we see that there is a missing factor of 2 in the original code. (Compare https://github.com/scipy/scipy/blob/master/scipy/signal/windows.py#L1316 with Eq. 18)   So we can keep our incorrect definition or we can break back compat and change it to something recognizable.

@ev-br up to @pv, but I suspect it's a bit late now.

@ev-br up to @pv, but I suspect it's a bit late now.

@ewmoore how about addressing the minor comment on junk I made above and rebasing, then merge it? And leave the bw compat issues for another time?

@ewmoore how about addressing the minor comment on junk I made above and rebasing, then merge it? And leave the bw compat issues for another time?

@rgommers comment addressed and rebased.

Thanks @ewmoore, merged.


Removed @babel/polyfill

Summary
Minimum iOS version is 10.3, so @babel/polyfill and check for iOS version < 10.x are no longer needed

Thanks @sergeyzhukov for the pull request!
Per the CONTRIBUTING.md file displayed when you created this pull request, we need to add you to the list of approved contributors for the Mattermost project.
Please help complete the Mattermost contribution license agreement?
This is a standard procedure for many open source projects. Your form should be processed within 24 hours and reviewers for your pull request will be able to proceed.
Please let us know if you have any questions.
We are very happy to have you join our growing community! If you're not yet a member, please consider joining our Contributors community channel to meet other contributors and discuss new opportunities with the core team.

@sergeyzhukov this is still needed by Android, or can you confirm otherwise?

@sergeyzhukov this is still needed by Android, or can you confirm otherwise?

No need to use babel-polyfill for android because you have updated JSC. Also, babel-polyfill is deprecated. Tested on Android 9.0 emulator and Android 7 device.

Hey @sergeyzhukov the PR has some conflicts and for some reason is also including a commit that is not part of the PR.
I also checked that the polyfill is not needed anymore, thanks for this.

@enahum Updated PR to remove duplicated commit and conflicts, sorry for that


AMBARI-23376. Create topic handler for small agent actions. Like restart_agent, clean_caches etc.

For bigger actions containing a lot of info or special workflow and a new topic would be required. Small actions like restart_agent/clean_cache make sense to be sent in one general topic

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/1421/
Test FAILed.
Test FAILured.


What is the pretrained model (mtts_can.hdf5) trained on?

Could you provide some information which data was used to train the available pretrained (mtts_can.hdf5) model? Was the MMSE-HR/UBFC dataset part of the training? Thanks.

No, it is AFRL dataset. Please refer to our NeurIPS paper.


Parse parameters affected by the name munging in Roslyn (those with hyphens in the name)

As seen in this Roslyn issue, Roslyn doesn't support parameter names with hyphens in them. For example, adding a parameter for 'Content-Type' results in a param tag of 'Content-Type-Type' in the XML annotation file.
Given that getting Roslyn to support this scenario might be difficult, we should consider having the CSharpAnnotation reader expect that duplication in the name. In the above example, it would know to interpret 'Content-Type-Type' as 'Content-Type'. We might also want to pass an optional argument to the config object to override this behavior.

Fix available in Microsoft.OpenApi.CSharpAnnotations.DocumentGeneration.1.0.0-beta048.nupkg


Building on OS X

$ ~ brew list
... gflags libpng ...
$ ~/git/guetzli make
==== Building guetzli (release) ====
guetzli.cc
guetzli/guetzli.cc:24:10: fatal error: 'gflags/gflags.h' file not found
#include "gflags/gflags.h"
         ^
1 error generated.
make[1]: *** [obj/Release/guetzli.o] Error 1
make: *** [guetzli] Error 2

Anyone gotten this to work?

Try brew update && brew install libpng gflags.

$ ~ brew update && brew install libpng gflags
Already up-to-date.
Warning: libpng-1.6.28 already installed
Warning: gflags-2.2.0 already installed

I think it might be something to do with the way gflags is linked? I've done both brew unlink and brew link on it however.

 brew unlink gflags && brew link gflags

doesn't help.
It's not a link error though. It's missing include path.

I downloaded and unpacked the archive and then CLI'd into the unpacked folder and ran make and it worked just fine. This is after doing brew update && brew install libpng gflags

Add path to headers and the libraries guetzli.make will solve your problem.
Because Homebrew will install headers and libraries to /usr/local/include and /usr/local/lib by default.

See also: Homebrew/homebrew-core#11190 (seems to work fine for El Capitan and Sierra)

Someone's gotta make a simple app around this

I'll be adding it to ImageOptim.

Nice. I was just about to suggest that!

Thanks @pornel ! I'm excited to share this with our design team.

BTW if someone is planning to built it with libpng gflags installed via MacPorts you have to edit guetzli.make similar as CliffsDovers suggestion above. But for MacPorts it has to point to /opt/local/lib
In both lines beginning wie LIBS you have to add:
 -L/opt/local/lib
like   LIBS += -L/opt/local/lib -lpng -lgflags_nothreads -lz -lpthread

@Pesthauch666 Does MacPorts cause pkg-config to report correct paths?

@robryk
I'm not that familar with this tool (I'm still a rookie after all), but:
pkg-config --libs libpng
reports
-L/opt/local/lib -lpng16


Changing log level

Please let me know how to change the log level. Currently, all the logs are displayed.  I tried the following, but it complained: syntax error: non-declaration statement outside function body
Error: failed to build operator binary
atom := logf.Log.NewAtomicLevel()
atom.SetLevel(logf.Log.ErrorLevel)
var log = logf.Log.WithName("controller_moss")

I see this doc for --zap-level, but it talks about command line command against containers & I cannot find any example on how to use it:
https://github.com/operator-framework/operator-sdk/blob/master/doc/user/logging.md

@mossuchida The main.go that gets scaffolded sets up the zap flagset, and the sets up a logger that is configured by those flags.
If you didn't change these lines in your main.go, you can pass --zap-level to set the log level. If you're using your own logr implementation, you'll have to setup the flags and configure the log level yourself.

I am newbie to Go lang (I am using it for 3 ~ 4 weeks), I am trying differently, but so far I am not successful.  Would you provide me a code sample?

@mossuchida Did you use operator-sdk new to create a project? If so, you should have a file in your project at cmd/manager/main.go that looks like the file from the links I posted. With no changes to that file, you should be able to run operator-sdk up local --operator-flags='--zap-level=10' and see much more verbose logging.
Here's a much simpler snippet with just the pieces important for logging:
package main

import (
	"github.com/operator-framework/operator-sdk/pkg/log/zap"
	"github.com/spf13/pflag"
	logf "sigs.k8s.io/controller-runtime/pkg/runtime/log"
)

var globalLog = logf.Log.WithName("global")

func main() {
	// Add the zap logger flag set to the CLI. The flag set must
	// be added before calling pflag.Parse().
	pflag.CommandLine.AddFlagSet(zap.FlagSet())

	pflag.Parse()

	// Use a zap logr.Logger implementation. If none of the zap
	// flags are configured (or if the zap flag set is not being
	// used), this defaults to a production zap logger.
	//
	// The logger instantiated here can be changed to any logger
	// implementing the logr.Logger interface. This logger will
	// be propagated through the whole operator, generating
	// uniform and structured logs.
	logf.SetLogger(zap.Logger())

	scopedLog := logf.Log.WithName("scoped")

	globalLog.Info("Printing at INFO level")
	globalLog.V(1).Info("Printing at DEBUG level")
	scopedLog.Info("Printing at INFO level")
	scopedLog.V(1).Info("Printing at DEBUG level")
}

Default log level:
$ go run main.go
{"level":"info","ts":1559866292.307987,"logger":"global","msg":"Printing at INFO level"}
{"level":"info","ts":1559866292.308039,"logger":"scoped","msg":"Printing at INFO level"}

Debug log level:
$ go run main.go --zap-level=1
{"level":"info","ts":1559866310.065048,"logger":"global","msg":"Printing at INFO level"}
{"level":"debug","ts":1559866310.0650969,"logger":"global","msg":"Printing at DEBUG level"}
{"level":"info","ts":1559866310.065119,"logger":"scoped","msg":"Printing at INFO level"}
{"level":"debug","ts":1559866310.065123,"logger":"scoped","msg":"Printing at DEBUG level"}

@joelanford Should we add this to the examples in the logging? I got this question at least twice before, so might make sense. :)

I am running in kubernetes env (IKS), I am assuming it is using Dockerfile in build dir & want to see less logs in the deployed env (not in my local), but this is what I see. Would you let me know What to change? I just want to change it to print error case only in deployed pod logs using "kubectl logs " (I added too much info logs, but I don't want to see them)
Dockerfile has these lines to startup operator SDK, but I don't have user_setup file locally (it seems like it comes with the image). How do you pass --operator-flags='--zap-level=10' in Dockerfile?
RUN  /usr/local/bin/user_setup
ENTRYPOINT ["/usr/local/bin/entrypoint"]

@mossuchida Rather than changing the docker image via the Dockerfile, I'd suggest that you set --zap-level in your operator deployment (deploy/operator.yaml), like this:
args:
- '--zap-level=error'

This args field should be in the container spec for your operator. Here's the full example based on a basic operator.yaml scaffold:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: memcached-operator
spec:
  replicas: 1
  selector:
    matchLabels:
      name: memcached-operator
  template:
    metadata:
      labels:
        name: memcached-operator
    spec:
      serviceAccountName: memcached-operator
      containers:
        - name: memcached-operator
          # Replace this with the built image name
          image: REPLACE_IMAGE
          command:
          - memcached-operator
          args:
          - '--zap-level=error'
          imagePullPolicy: Always
          env:
            - name: WATCH_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: OPERATOR_NAME
              value: "memcached-operator"

@LiliC I created PR #1532

Thanks, --zap-level=error worked.  Now I am changing the log from reqLogger.Info to reqLogger.Debug, but it complains that it doesn't exist.  I tried to use reqLogger.V(1).Info with "--zap-level=info", but it prints out reqLogger.V(1).Info also.  Would you provide complete --zap-level options & reqLogger options that I can use for operator.yaml & controller.go?

@mossuchida the logging doc describes the --zap-level flag as:

--zap-level string or integer - Sets the zap log level (debug, info, error, or an integer value greater than 0). If 4 or greater the verbosity of client-go will be set to this level.

So you can use --zap-level=error, --zap-level=info, --zap-level=debug, --zap-level=1, --zap-level=2, --zap-level=3, etc. Note that debug and 1 are equivalent and increasing numbers mean more verbosity.
These levels correspond to the logr interface as follows:

--zap-level=error - you'll see reqLogger.Error() logs only.
--zap-level=info - you'll see everything above and reqLogger.Info(), and reqLogger.V(0).Info() logs.
--zap-level=debug (and --zap-level=1) - you'll see everything above and reqLogger.V(1).Info() logs.
--zap-level=2 - you'll see everything above and reqLogger.V(2).Info() logs.

Also to address your questions:

Now I am changing the log from reqLogger.Info to reqLogger.Debug, but it complains that it doesn't exist.

Correct, see the logr interface to see what functions are available on the reqLogger.

I tried to use reqLogger.V(1).Info with "--zap-level=info", but it prints out reqLogger.V(1).Info also.

That shouldn't be happening. Is it possible that you are overriding the log level somewhere? If so, can you reproduce it based on the simple snippet code from my earlier comment?

Thanks, it worked!  It looks like I was not logged into docker & image push was denied, there were no V(1) in the code.


Reportback fixes part 3a

Resolves #3808
Wrapping up most of the markup and logic when campaign loads with/or without having user reportbacks in Prove It section.
If there are no reportbacks from the user, then show the large button (which still needs further styling):

Otherwise, if there are prior reportback submissions, then show the last submission prominently, allow user to "Add another photo" (file upload dialogue), and show prior submissions:

@aaronschachter @sbsmith86
CC: @barryclark @DFurnes

FYI: More styling needs to happen, so kind of ignore some of the funkyness and lack of whitespace etc, for now ;) huggles!

Looks ok, assuming this has been tested and works when the relevant theme/module settings are turned off and this is safe to deploy without turning on.

Oh, good call. Lemme check on that.

@aaronschachter Ok! Updated to account for feature flags. I had to use a large if/else conditional for part of the form to hide the new approach from Production. I added comments and an esaily findable @TODO_RBv2 comment to know where things need to be edited and removed post-launch!

Nice PHP :+1:  Feel free to fix line endings in subsequent PR to get this out.


fix: show more suggestions

reg https://github.com/pacak/bpaf/issues/154
I don't quite get why should_suggest requires flgs to be empty - in fact if there are flags it should indeed suggest is my opinion.
This change makes the error message more correct in most cases i came across.
It's still not perfect, the suggestions are not filtered by what is already given.
like in my example in https://github.com/pacak/bpaf/issues/154:
$ notgit log --oneline --doesnotexist
No such flag: `--doesnotexist`, did you mean `--oneline`?

Though it does also honor hide() correctly.

Btw, any preference for API, line 19 vs line 20?
<EMAIL_ADDRESS>
Cool project👀!
I think
doc.paragraph([text("Program takes "), literal("--help"), text(" argument")]);

is better for a public api as rustdoc will list the intended options.
The AddAssign seems useful to add custom blocks of text.

The AddAssign seems useful to add custom blocks of text.

Right, but then repbuilding option lists is all about custom blocks of text...

render_to_manpage(&self, title: &str, section: Section, extra: &[&str])
I think the extras should be named, but five arguments seems a bit excessive
Did you consider putting title section and extras into a defaultable struct, and just pass that in here?

doc.subsection("Finding code to analyze");
doc += paragraph([
   ...
]);

this looks a bit inconsistent, no?

when writing markdown you should escape -- as \-- as many markdown compilers convert -- to a longer dash char

these is no more option to generate a manpage for a command?

same point: it would be great to have additional documentation for the command right next to it. With all the markup in semantic do you think a conversion from markdown is an option?

somewhat unrelated: esp with cargo-asm-show the usage string gets quote long, perhaps wrapping them heuristically at would be an option?

render_to_manpage(&self, title: &str, section: Section, extra: &[&str])
I think the extras should be named, but five arguments seems a bit excessive

Having extras named is harder than it seems - macro accepts any number up to 3 of them including 0, so to properly name them you'd need Option, but then there's a check required to make sure first options are filled or everything gets messed up. This way it's up to user to use this correctly. But I'm open to any better suggestions

Did you consider putting title section and extras into a defaultable struct, and just pass that in here?

Might work, question is what to default to. Section::General should generally work but for extras it's the same problem...

doc.subsection("Finding code to analyze");
doc += paragraph([
   ...
]);

this looks a bit inconsistent, no?

Totally. I'll see if making it a member function works better, but += is still needed in some cases.

when writing markdown you should escape -- as -- as many markdown compilers convert -- to a longer dash char

If you ask for literal("--") inside a paragraph - it will be escaped - see generated help for cargo-show-asm. Interestingly enough with rustdoc I have to escape it inside a line of text, but not inside <dl><dt>..., not sure what's wrong with it

these is no more option to generate a manpage for a command?

Not implemented yet, but I'll add it back - cargo-hackerman is a good victim volunteer to test it :)

same point: it would be great to have additional documentation for the command right next to it. With all the markup in semantic do you think a conversion from markdown is an option?

Probably. At the moment I'm trying to focus on what you have to provide it, where it comes from is a separate problem. Making some markdown parser a dependency for semantic crate might work.
What I'm trying to achieve next is to get this info from doc comments as much as possible so overall workflow looks like you break your options into logical blocks, add doc comments for them, compose them automatically or manually to create chunks of markdown and man pages.

somewhat unrelated: esp with cargo-asm-show the usage string gets quote long, perhaps wrapping them heuristically at would be an option?

Unrelated and requires extra dependencies to get terminal width. I have a few ideas to how to implement it, but this will have to wait, made #156 for now.
my TODO list for now is something like this

documentation and API finalization for semantic
adding code to bpaf to generate documentation/man pages from bpaf primitives
trying to use this code in several crates of mine to see what works and what does not
getting semantic merged or publish it separately
getting changes to bpaf merged and published.

First 3 items are kind of coupled to gether. Either way here's your opportunity to experiment and make suggestions :)

If the extras are just empty strings? or if they are indeed required an Option could work?

It gets rendered to something like this: .TH title\ with\ spaces 1 extra1 extra2 extra3 with arguments simply being space separated and spaces being escaped. I'm not sure what it would do with just empty strings. Probably need to use "" in that place? Either way it's one of the bits of the API that can use a bit more thinking, just integration with bpaf and ability to (efficiently) render bigger chunks seems more important to me right now.

I reimplemented most of the suggestion logic in https://github.com/pacak/bpaf/pull/192, it should be trying to give more suggestions similar to this pull request logic.


⚠ GitLab Server has degraded performance

In fad1136, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 11216 ms

Resolved: GitLab Server performance has improved in f0dc759.


Remove HostingStartup infrastructure from Universe

I don't think we are using any of this infrastructure for building hosting startup deps files anymore in 2.1 so this should be safe to remove.

Needed to rebase on the submodule updates in Universe.


Doesn't seem to work with Homebrew

I'm not sure when this changed, but when installing node with Homebrew, the npm.packages directory is nonexistent:
$ node -e "console.log(require('global-dirs').npm)"
{ prefix: '/usr/local/Cellar/node/11.3.0_1',
  packages: '/usr/local/Cellar/node/11.3.0_1/lib/node_modules',
  binaries: '/usr/local/Cellar/node/11.3.0_1/bin' }

In fact, the npm prefix seems to be incorrect:
$ npm get prefix
/usr/local

npm lives in /usr/local/bin, and the packages dir should be /usr/local/lib/node_modules. /usr/local/lib/node_modules/npm/npmrc contains a prefix of /usr/local.
node, OTOH, lives in /usr/local/bin but is symlinked into /usr/local/Cellar/node....
This means global-dirs can't reliably use process.execPath to determine where npm lives.  However, the /usr/local/bin/node symlink will be present in process.env._ in some shells.  Perhaps global-dirs should prefer process.env._ over process.execPath when present?
references: boneskull/create-yo#1

I'm happy to send a PR to that effect if you wish.

Sure. PR welcome :)

@vladimyr Thanks for the very thorough research. I agree we can just assume /usr/local.

I guess PR #6 will fix this issue right? If not, is there anything I can help with?

I guess PR #6 will fix this issue right? If not, is there anything I can help with?

Probably but that's completely different pair of shoes from what I proposed here earlier...

Fixed by #6