Change Continuous Delivery to Continuous Deployment

The documentation says that "Continuous Delivery (CD) is a process by which code is built, tested, and deployed to one or more test and production environments" this is not entirely true since Continuous Delivery doesn't include the deployment process to any environment. It is only achieved by Continuous Deployment. I suggest changing the description and any occurrences of the sentence Continuous Delivery to Continuous Deployment because it is more accurate.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: f15f40a4-bae9-154b-752a-2e9f453d79e3
Version Independent ID: 3b937e0b-f919-f227-742f-dc740ad4e6f9
Content: What is Azure Pipelines? - Azure Pipelines
Content Source: docs/pipelines/get-started/what-is-azure-pipelines.md
Service: azure-devops-pipelines
Sub-service: azure-devops-pipelines-get-started
GitHub Login: @juliakm
Microsoft Alias: jukullam

@Oscarce10 -- Oscar, thank you for your suggestion.  The term "continuous delivery" is the preferred term; for example, see:

Azure Pipelines documentation

I am closing this issue now.  You are welcome to @ mention me for any followup.  We hope to hear from you again.


Update ably-ios references to ably-cocoa

From #945:

[x] Change default agent to ably-cocoa
[x] Include a variant based on platform such as macos, ios, watchos, ipados.  Not sure what the official variants are, but assuming it was ios it would be ably-cocoa.ios
[x] Check for legacy references in code to ably-ios and replace with ably-cocoa

@mattheworiordan Please confirm we can release this without breaking any internal machinery.

@tcard I am not aware of any places this will break internal machinery.  As far as I am aware, we have no "hard coded" dependencies on the iOS agent string.  Probably worth @SimonWoolf and/or @paddybyers confirming for sure as I don't code any of the "internal machinery" as such.

Bitrise: ✅


SNLI_VE Inference Error

Hi, I've been trying to use the given Colab notebooks to perform the SNLI_VE task on the finetuned base model. However, after changing the task definition and creating my my sample, I get the following error:

What could be going wrong here? Thanks in advance.

Does the original code work well now? Any more details about how you make changes? Or you can share your colab notebook to us.

I haven't been able to get it to work. Here is the notebook: https://colab.research.google.com/drive/1SnYR_nWVNEYxGfY90FFaxLSMez7m-ug4?usp=sharing. Thanks.

I guess a simpler question would be, how would you recommend one to run inference on the fine-tuned base model on snli-ve? Thank you for the help!

@JustinLin610 I tried a couple things, first tried to increase max steps in the config, but ran into:
RuntimeError                              Traceback (most recent call last)
[<ipython-input-10-a5275c952a04>](https://localhost:8080/#) in <module>
     19 with torch.no_grad():
     20   # hypos = task.inference_step(generator, models, sample, constraints=task.valid_answers_list)
---> 21   hypos = task.inference_step(generator, models, sample)
     22   tokens1, bins1, imgs1 = decode_fn(hypos[0][0]["tokens"], task.tgt_dict, task.bpe, generator)
     23   tokens2, bins2, imgs2 = decode_fn(hypos[0][1]["tokens"], task.tgt_dict, task.bpe, generator)

7 frames
[/content/OFA/models/ofa/unify_transformer.py](https://localhost:8080/#) in extract_features_scriptable(self, prev_output_tokens, code_masks, encoder_out, incremental_state, full_context_alignment, alignment_layer, alignment_heads)
   1509             self_attn_bias = self_abs_pos_bias.clone()
   1510             if code_masks is None or not code_masks.any():
-> 1511                 self_attn_bias += self.get_rel_pos_bias(all_prev_output_tokens, idx).unsqueeze(0)
   1512             elif code_masks is not None and code_masks.all():
   1513                 self_attn_bias += self.get_image_rel_pos_bias(all_prev_output_tokens, idx).unsqueeze(0)

RuntimeError: The size of tensor a (1025) must match the size of tensor b (1024) at non-singleton dimension 3

I then compared the SNLI-VE task against the Refcoco task and found that refcoco seems to atleast output results with the finetuned snli_ve base model. I think this may be because of different generators, but not entirely sure. So, I then tried to use refcoco's generator with constraints from the snli task, however I then get this error:
NameError                                 Traceback (most recent call last)
<ipython-input-42-d60fa7cb12fd> in <module>
     18 # Generate result
     19 with torch.no_grad():
---> 20   hypos = task.inference_step(generator, models, sample, constraints=task.valid_answers_list)
     21   tokens1, bins1, imgs1 = decode_fn(hypos[0][0]["tokens"], task.tgt_dict, task.bpe, generator)
     22

5 frames
/usr/local/lib/python3.7/dist-packages/fairseq/search.py in <listcomp>(.0)
    243             elif self.representation == "unordered":
    244                 constraint_state = UnorderedConstraintState.create(constraint_tensor)
--> 245
    246             self.constraint_states.append([constraint_state for i in range(beam_size)])
    247

NameError: free variable 'constraint_state' referenced before assignment in enclosing scope

Not sure what I can do about that error, since it's part of fairseq's codebase. Would you have any ideas about how I should go about this, or is it possible? Thanks for any help in advance!


Multiple select : disable already selected options

It feels really weird that when you select some options in select2, when you press the down key, you may end up on an option that you already selected, and you can't spam key down enter to add all options.
IMHO selected options should be unselectable.
Is this something you'd be interested in ? Maybe not default but actionable with an option ?
I have this monkey patch at the moment if someone is interested :
$.fn.select2.amd.require(['select2/results'], function (Results) {
  var oldOption = Results.prototype.option;

  Results.prototype.option = function (data) {
    if (data.real_disabled === undefined) {
      data.real_disabled = data.disabled;
    }
    data.disabled = data.real_disabled || data.selected;
    return (oldOption.apply(this, [data]));
  };
});

BTW the change would look like that :
if (data.disabled || data.selected) {
  delete attrs['aria-selected'];
  attrs['aria-disabled'] = 'true';
}

instead of
if (data.disabled) {
  delete attrs['aria-selected'];
  attrs['aria-disabled'] = 'true';
}

I'd gladly submit a PR with tests and docs

IMHO selected options should be unselectable.

I'm going to have to reject this feature request, as it deviates from the standard expectation of a multiple select. As you can achieve it through a monkey patch, I'm also going to reject the request for a new option for it - that's why we built the decorator and adapter system.
Also, setting aria-disabled for a selected option will horribly mess with screen readers.


Fastlane incorrectly reports update available when installed via Homebrew

When installing fastlane via Homebrew:
brew cask install fastlane
Running fastlane always returns the following message, despite no update being available:
$ fastlane
Fastlane update available
Please run `brew cask reinstall fastlane`

This is because, despite the latest cask installing bundle v1.1, the contents of ~/.fastlane/bin/VERSION reads 1.0 instead of 1.1.
I'm struggling to track down where the VERSION file exists and/or is generated within the fastlane codebase to attempt a pull request. I'm happy to attempt to resolve the issue, but some initial guidance would be greatly appreciated.

✅ fastlane environment ✅
Stack

Key
Value

OS
10.12.1

Ruby
2.2.4

Bundler?
false

Git
git version 2.9.3 (Apple Git-75)

Installation Source
~/.fastlane/bin/bundle/bin/fastlane

Host
Mac OS X 10.12.1 (16B2657)

Ruby Lib Dir
~/.fastlane/bin/bundle/lib

OpenSSL Version
OpenSSL 1.0.2g  1 Mar 2016

Is contained
true

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
8.1

System Locale

Variable
Value

LANG
en_US.UTF-8
✅

LC_ALL
en_US.UTF-8
✅

LANGUAGE
en_US.UTF-8
✅

fastlane files:
No Fastfile found
No Appfile found
fastlane gems

Gem
Version
Update-Status

cert
1.4.4
✅ Up-To-Date

credentials_manager
0.16.2
✅ Up-To-Date

deliver
1.16.1
✅ Up-To-Date

fastlane
1.111.0
✅ Up-To-Date

fastlane_core
0.58.0
✅ Up-To-Date

frameit
3.0.0
✅ Up-To-Date

gym
1.12.1
✅ Up-To-Date

match
0.11.1
✅ Up-To-Date

pem
1.4.1
✅ Up-To-Date

pilot
1.12.1
✅ Up-To-Date

produce
1.3.2
✅ Up-To-Date

scan
0.14.2
✅ Up-To-Date

screengrab
0.5.6
✅ Up-To-Date

sigh
1.12.1
✅ Up-To-Date

snapshot
1.16.4
✅ Up-To-Date

spaceship
0.38.5
✅ Up-To-Date

supply
0.8.0
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

CFPropertyList
2.3.3

activesupport
<IP_ADDRESS>

addressable
2.5.0

babosa
1.0.2

bigdecimal
1.2.6

bundler
1.13.6

claide
1.0.1

colored
1.2

commander
4.4.0

credentials_manager
0.16.2

domain_name
0.5.20161021

dotenv
2.1.1

excon
0.54.0

faraday
0.10.0

faraday-cookie_jar
0.0.6

faraday_middleware
0.10.1

fastimage
1.6.8

fastlane_core
0.58.0

gh_inspector
1.0.2

google-api-client
0.9.20

googleauth
0.5.1

highline
1.7.8

http-cookie
1.0.3

httpclient
<IP_ADDRESS>

hurley
0.2

i18n
0.7.0

io-console
0.4.3

json
1.8.1

jwt
1.5.6

krausefx-shenzhen
0.14.11

libxml-ruby
2.9.0

little-plugger
1.1.4

logging
2.1.0

memoist
0.15.0

mime-types
3.1

mime-types-data
3.2016.0521

mini_magick
4.5.1

minitest
5.4.3

multi_json
1.12.1

multi_xml
0.5.5

multipart-post
2.0.0

nanaimo
0.2.2

net-sftp
2.1.2

net-ssh
3.2.0

nokogiri
1.5.6

os
0.9.6

plist
3.2.0

power_assert
0.2.2

psych
2.0.8

public_suffix
2.0.4

rake
10.4.2

rdoc
4.2.0

representable
2.3.0

retriable
2.1.0

rouge
1.11.1

rubygems-update
2.5.2

rubyzip
1.1.7

security
0.1.3

signet
0.7.3

slack-notifier
1.5.1

sqlite3
1.3.12

terminal-notifier
1.7.1

terminal-table
1.4.5

test-unit
3.0.8

thread_safe
0.3.5

tzinfo
1.2.2

uber
0.0.15

unf
0.1.4

unf_ext
<IP_ADDRESS>

unicode-display_width
1.1.1

word_wrap
1.0.0

xcode-install
2.0.9

xcodeproj
1.4.1

xcpretty
0.2.4

xcpretty-travis-formatter
0.0.4

generated on: 2016-12-06

+1

Hey, thanks for submitting this issue, we're looking into it 👍  Sorry for the inconvenience

+1

I dug into this issue a bit, and it seems that when installing from brew (brew update && brew cask install fastlane, bundle-1.1 is downloaded and installed, which upon running fastlane --version, results in fastlane 2.1.1, the most recent version, and still erroneously reports:
Fastlane update available
Please run brew cask reinstall fastlane

This is because the bundle contains bundle_update_checker.rb which points to https://kits-crashlytics-com.s3.amazonaws.com/fastlane/standalone/version.json which even more confusingly contains
{
"version": "1.111.0",
"bundle_version": 1.2,
"updated_at": "2016-12-13 19:37:32 UTC"
}

I think the main issue here is that the brew cask bundle is different than fastlane's version. This is confusing, and I think will cause maintenance problems. When you call brew cask list --versions it reports fastlane 1.1, not fastlane 2.1.1 as one might expect. I think when a new version of the fastlane gem is released, the new cask bundle needs it's version incremented to the same version.
The other problem is that I believe fastlane has the ability to self update the gem through `fastlane update_fastlane, which as it is I believe updates the gems directly, and not through the cask bundle. We might need to change this command depending upon the install method.

+1

brew cask list --versions report 1.0 for me, but fast lane --version give me 2.8.0
It's time for a bug fixes, this issue are reported for more than 1 month now ! ;)

Hey everyone! Thank you for raising the issue! Regarding what @tabrindle is saying: I agree, this is confusing that the versions are different. This is done because we do not build a new version of the package every time we release a new version of fastlane. The package itself is versioned (currently at 1.5) on its own so that we know when a new update needs to be installed via cask. I believe that the issues with the false reporting of an update available have been fixed in recent versions.

The other problem is that I believe fastlane has the ability to self update the gem through `fastlane update_fastlane, which as it is I believe updates the gems directly, and not through the cask bundle. We might need to change this command depending upon the install method.

Regarding the quote above, this is intended, by running fastlane update_fastlane, the package will update it's self-contained instance of fastlane to allow people to be on the latest version of fastlane while still using an existing version of the package.
@skrew, it looks like you might be on an old version of the package itself, this can be updated by running brew update && brew cask reinstall fastlane. You should then see 1.5 from brew cask list --versions and 2.8.0 from fastlane -v
I am going to close this issue for now as the initial problem has been fixed, please do not hesitate to let us know if there is still an issue or confusion around the versioning! :rocket:

@ohwutup This fixes my issue today. Thanks!

This issue appears to have reappeared again. On running fastlane this morning:
fastlane update available
Please run `brew update && brew cask reinstall fastlane`

I run brew update && brew cask reinstall fastlane and then restart fastlane, but receive the same message.

I have the issue also.
brew cask list --versions
fastlane 1.6

fastlane -v
fastlane update available
Please run `brew update && brew cask reinstall fastlane`
fastlane installation at path:
/Users/alex/.fastlane/bin/bundle/lib/ruby/gems/2.2.0/gems/fastlane-2.9.0/bin/fastlane
-----------------------------
fastlane 2.9.0

brew update && brew cask reinstall fastlane
Already up-to-date.
==> Downloading https://kits-crashlytics-com.s3.amazonaws.com/fastlane/standalon
Already downloaded: /Users/alex/Library/Caches/Homebrew/Cask/fastlane--1.6.zip
==> Verifying checksum for Cask fastlane
==> Running uninstall process for fastlane; your password may be necessary
==> Running uninstall script /usr/local/Caskroom/fastlane/1.6/uninstall
==>
==> You can now remove fastlane from your search path by editing your ~/.bash_pr
==> fastlane was uninstalled successfully!
==>
==> Running installer script /usr/local/Caskroom/fastlane/1.6/install
==>
==> Installing fastlane to /Users/alex/.fastlane/bin... this might take a few se
==>
==>
==> Successfully copied fastlane to /Users/alex/.fastlane/bin
==>
==>
==> fastlane update available
==> Please run `brew update && brew cask reinstall fastlane`
==> Updating installed gems
==> Updating fastlane
==> ERROR:  While executing gem ... (TypeError)
==>     no implicit conversion of nil into String
==> fastlane update available
==> Please run `brew update && brew cask reinstall fastlane`
==> Cleaning up installed gems...
==> Clean Up Complete
==>
==> Detected fastlane is already in your path 🚀
==>
🍺  fastlane was successfully installed!

I had this issue even after having homebrew reinstall fastlane a couple times, but it turns out the message I was given was slightly different than what worked. This is what I was seeing:
Fastlane update available
Please run `brew cask reinstall` fastlane

Running brew update along with the reinstall command fixed it for me:
brew update && brew cask reinstall fastlane
Thanks for the help everyone!


Swift build fails on Ubuntu nightly toolchain

Invoking swift build in the latest master branch fails on the Ubuntu (CUDA 10) nightly toolchain with the following stack dump summary:
swift: /swift-base/swift/lib/Serialization/Serialization.cpp:2043:
         bool swift::serialization::Serializer::isDeclXRef(const swift::Decl *)
         const: Assertion isa<GenericTypeParamDecl>(D)
         && "unexpected decl kind"' failed.
Stack dump:
0.     Program arguments: ...
1.     Swift version 5.1-dev (LLVM af1f73e9e9, Swift bd14b05114)
2.     While running pass #0 SILModuleTransform "SerializeSILPass".
3.     While serializing 'bb0'
        (at /Projects/s4tf/swift-apis/Sources/TensorFlow/Operators/Basic.swift:412:10)

Removing all code related to batchGathering(atIndices:alongAxis:batchDimensionCount:) in Basic.swift and Core.swift resolves the issue but I'm not sure why.
Can anyone reproduce this on an Ubuntu system? Thanks!

This issue has been fixed by https://github.com/apple/swift/pull/25868 a week ago. Which exact toolchain version are you using (try swift --version)?

@rxwei Yup that was it! I was using a nightly snapshot I downloaded on July 3rd. Didn't think to upgrade. Appreciate the help as always!


How to install and use this in arm based linux

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

none of the version working in arm based linux

There have been no updates on the issue for a long time.
If it is still actual for you - feel free to reopen it with additional info.


Pin version in readme

Use sd in a just command to change everything with a script

You should use a pinned version

https://github.com/iancleary/devcontainer/commit/d25466008bf28b8bc905d72371117cae50cdc02c closes this


Enable hiding preview window's title and scrollbar

Add two new options, show_title and show_scrollbar, that controls whether the preview window will display a title and a scrollbar indicator, respectively. This should help people make their preview window more minimalist if they don't need a title and/or a scrollbar.

Good idea, but I think show_scrollbar shouldn't be added. There're three reasons:

border_chars = {'│', '│', '─', '─', '╭', '╮', '╰', '╯', '│'} should work as what you expected.
No extra perf issue about showing a scroll bar.
As a maintainer, I don't want to export redundant opts to users.

It's a valid point, and it's precisely what I'm doing right now to hide the scrollbar. But wouldn't it make users redefine the whole border_chars field just to change one element?
Do you think a separate option, say, scrollbar_char, would be a better way to enable that? That would also make border_chars need 8 elements just as the border argument in nvim_open_float (and we could also reorder the elements so it would comply with nvim_open_float). It would be a breaking change, though.
Let me know what you think.

The first release of this plugin is before nvim 0.5, so there're some history leftovers. However, nvim_open_win() doesn't include any opts about the scroll bar and title. It's not worth breaking the change for the scroll bar as a single opt. AFAIK, the title opt for float win is WIP in a PR. We can add a title opt for now.  If  nvim_open_win() is stable enough and bqf is hard to develop new features,  we will break the change for the title and scroll bar at the same time.
For now, the code base of bqf is not messy, and it's easy to develop new features. Not like API functions, the configuration has been almost unchanged since the users' workflow is done. The breaking change is very inefficient for developers and users.

Thanks!


Russian language support

I found retext-latin plugin, but it not improves result. Can you help?

You need a pos tagger like pos, but for Russian (in JavaScript). That’s a pretty hard task to complete though. Once you’ve got that, we can work on retext-pos to accept a custom POS tagger through it’s options, and we can accept it here and pass it through.
This is really hard to do, I doubt it’ll see the day of light so I’m closing this. But feel free to open a new issue/pr if a Russian POS tagger is available!

@wooorm Hi Titus! Thanks for supporting such amazing projects! 🙇♂
There is one POS tagger for Russian: https://github.com/deNULL/Az.js (it's in Russian though). I'd love to work on supporting Russian a bit later, probably will bother you with questions if you don't mind. 😊

@maxmert Sounds cool and feel free to do so! 😉


 On mobile this is a too long time.

Fixed in current master branch.


starting to update config

asked about when grades are due:
Grades Due for Summer Terms
Friday, September 1**
**Grades for graduating students are due by Friday, August 25
so I think we would want their projects before Friday unfortunately :( or we could ask how many are graduating.


Suggestions

Hey, here's a few suggestions that I think would be cool for your bot:

Polls (ex. https://gyazo.com/f64b48bb3921ea78ce1465d1b17178dd)
Mog Logs, offers logs for bans/kicks/mutes/warns
Twitch notifications (and maybe other social media platforms
FML's
Roasts (like FML's)
Rock Paper Scissors
8Ball
Muting
Mute list (lists the currently muted users)

NOTE: If you could add all of these with rich embed
I have a bunch more, but there's some to start off with! =)

Whoops, seems like I forgot to put a message.
This message has been received, and has projects assigned to them.
These projects may take a lot of time to complete, due to Exam(TM) season in the United Kingdom

I've remade the ENTIRETY of Parkerbot, but haven't started on this yet.
Will start today.
+ 8 ball
+ Twitch audio streaming

👀 i might make some of this


Add BitSet union iterator

Follow up to https://github.com/typelevel/cats-parse/pull/291/files#r740001716
Might not be a huge deal but it doesn't hurt.

Codecov Report

Merging #308 (3812e71) into main (87ad430) will decrease coverage by 0.09%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##             main     #308      +/-   ##
==========================================
- Coverage   96.66%   96.56%   -0.10%
==========================================
  Files           9        9
  Lines        1048     1049       +1
  Branches      101       94       -7
==========================================
  Hits         1013     1013
- Misses         35       36       +1

Impacted Files
Coverage Δ

core/jvm/src/main/scala/cats/parse/BitSet.scala
80.00% <50.00%> (-5.72%)
:arrow_down:

core/shared/src/main/scala/cats/parse/Parser.scala
96.41% <100.00%> (ø)

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 87ad430...3812e71. Read the comment docs.


use parenthesis instead of brace

Thanks for your revision, if it's convenient, could you provide us with a PR.

Thanks for your suggestion.
We strongly recommend that you modify this issue through PR, as it is very suitable as the first step in getting started with the database.


file path incorrect when going through root directory

I added the following code at the starting of open() function
echo $1 >> out
here is the 'out' file while using the fff
/home/nikunj
/home

//media
//media/nikunj
//media/nikunj/MJRO1714
//media/nikunj/MJRO1714/abc.avi

an extra '/' at the starting of the file path will prevent xdg-open to work correctly
the following command did not work
xdg-open '//media/nikunj/MJRO1714/abc.avi'
the result to the above command was
main.go:63: openFile: "/nikunj/MJRO1714/abc.avi"
main.go:70: stat /nikunj/MJRO1714/abc.avi: no such file or directory

This should be fixed now.


[FLINK-16709]add a set command to set job name when submit job on sql client

What is the purpose of the change
add a set command to set job name when submit job on sql client
Brief change log
add a set command to set job name when submit job on sql client
Verifying this change
(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (100MB)
Extended integration test for recovery after master (JobManager) failure
Added test that validates that TaskInfo is transferred only once across recoveries
Manually verified the change by running a 4 node cluser with 2 JobManagers and 4 TaskManagers, a stateful streaming program, and killing one JobManager and two TaskManagers during the execution, verifying that recovery happens correctly.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Close as it has been implemented by FLINK-18545.


what ' s max_position_embeddings to do ?

When i see bert_config.json files, and i look its set max_position_embeddings equal to 512. But when i load model and check model inputs vector, find the vector size equal to 128.
Like this:

The max_position_embeddings seem not work!  why we need set max_position_embeddings if i set seq_length? i can't understand for this. And the model inputs vector 2th dim means seq_length is right?

i know the max_position_embeddings is means embeddings size


[Coffee] ...

Extension
https://www.raycast.com/mooxl/coffee
Description
Whenever i activate "caffeinate" the extension doesn't really inform whether the action has been taken or not, which can be easily fixed with some UX :)
Steps To Reproduce

try to caffeinate anything

Current Behaviour
No response
Expected Behaviour
No response

There should be a HUD in the bottom middle of your screen showing this, doesn't that happen?

Hello,
Thank you for getting back to me :) and no, there is no HUD in the bottom middle of my screen, no matter how many times i click Caffeinate nothing changes
Khaled Adel
Product Designer
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. Please consider the environment before printing this email.
On 3 Apr 2024 at 1:48 PM +0200, Per Nielsen Tikær @.***>, wrote:

There should be a HUD in the bottom middle of your screen showing this, doesn't that happen?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

You should see this

@raycastbot close this issue


fix(catalog): Support muli-level group anchor links

This PR supports anchor links for multiple-levels of control groups.
Testing
Navigate to the Catalog Viewer and reload the following catalog: https://raw.githubusercontent.com/EasyDynamics/oscal-demo-content/test-content/catalogs/basic-test-catalog.json. Test out "Test Group E" and ensure the anchor links open, scroll, and navigate properly.
Relates to #176

Is there sample data or a test to ensure this works? I remember some talk on this being tricky, but this also seems like something we'd prefer to not just trust it works.
At the very least discussion on why this can't be done would be good here. In the past, we have made dummy data to at least show a feature works even if we don't push it to our actual sample data.

Doing some additional testing on this issue, I believe this is now in proper working order to fully support multi-level groups.

I think some changes in your previous pr to groups may have broken how we handle groups within groups.

Yes, when ensuring that a group.title is used when group.id isn't present I missed one place, and it would cause the application to fail right away when no group.id is provided by the first highest-level group. I've corrected this.

https://oscal-viewer.msd.easydynamics.com/catalog/?url=https://raw.githubusercontent.com/EasyDynamics/oscal-demo-content/test-content/catalogs/basic-test-catalog.json

Hey, this is actually a pretty good example to test multi-layered groups. Thanks for sharing this! I'll go ahead and place it in the description under "Testing".

I've tried to stress test these groups and they seem to be working as intended. I also noticed that high-level withdrawn controls had some state issues, so I've made a fix to them as well.
Please refer to the test data provided above, when testing.

I also noticed that high-level withdrawn controls had some state issues in a similar vein, so I've made a fix to them as well

Are you talking about #743 or another issue?


OOM problem encountered with FewShotNERDatasetWithRandomSampling

When I try:
python train_demo.py  --mode inter --lr 1e-4 --batch_size 8 --trainN 5 --N 5 --K 1 --Q 1 --train_iter 10000 --val_iter 500 --test_iter 5000 --val_step 1000 --max_length 64 --model structshot --tau 0.32
the program gets stuck on line 399 of framework.py where it tries to get next self.train_data_loader. After a minute, it raises OOM problem.
I search for a whole night and find the len function of FewShotNERDatasetWithRandomSampling returns<PHONE_NUMBER>00, which causes OOM error.
When I change it to return len(self.samples), this problem disappears. Please fix it.

Hi, I also meet the same problem. When I change batch_size to 1, it also happens.

you may try a smaller number for len function of FewShotNERDatasetWithRandomSampling


Fix cross origin docs

The cross origin specifier for texture assets should be a string not a boolean as the value is used directly (see https://github.com/playcanvas/engine/blob/main/src/framework/parsers/texture/img.js#L51).

Looks good, but should we perhaps not change the API and change the use of it? Not sure how likely we're to break existing code here passing the boolean.

No we want to expose a string because the value can be 'anonymous' or 'use-credentials' or null, and it makes sense that these values override the default. (i.e. in some case you may want to null crossOrigin).

Sounds good. Are people likely to pass booleans to the function though? If they do, maybe we can handle it and convert to some string value? And log a warning.

Actually, you didn't change a function, only docs, so that will not cause any problems. All good.


Add detection of current commit / branch

This ensures runs are reproducible/replayable and doc-referenced content will stay up. Branch references might be changed later - commit SHAs can be assumed stable.

@matmair what testing have you done on this?

It actually builds in this PR. You can check the result here: https://inventree--7745.org.readthedocs.build/en/7745/extend/plugins/#inventree-plugin-architecture. The links point to the commit sha

Oh, nice. Thanks for working on this!


fixUse column update rows to decide min/max stats are valid or not.

This is a following pr of https://github.com/apache/doris/pull/33685
After https://github.com/apache/doris/pull/33703 merged, need to check update rows in column level instead of table level.

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall


Zephyr Support

Let's discuss how to support Zephyr and what should be supported.

As a reference it might be interesting supporting a nRF52 device, or a NXP one like Teensy.

The port of AtomVM to Zephyr, I think could be structured as a module (https://docs.zephyrproject.org/latest/develop/modules.html), by adding libAtomVM as a library and some platform files specific to the Zephyr-port.
An example for adding libAtomVM as a library:
zephyr_library_named(libAtomVM)

if(CONFIG_ATOMVM)

function(gperf_generate input output)
    add_custom_command(
        OUTPUT ${output}
        COMMAND gperf -t ${input} > ${output}
        DEPENDS ${input}
        COMMENT "Hashing ${input}"
    )
endfunction()

set(ATOMVM_DIR ${CMAKE_CURRENT_SOURCE_DIR}/..)

gperf_generate($(ATOMVM_DIR)/src/libAtomVM/bifs.gperf bifs_hash.h)
gperf_generate($(ATOMVM_DIR)/src/libAtomVM/nifs.gperf nifs_hash.h)

zephyr_include_directories(
    ${CMAKE_CURRENT_BINARY_DIR}
    $(ATOMVM_DIR)/src/libAtomVM
    $(ATOMVM_DIR)/zephyr
)

zephyr_library_sources(
    ${CMAKE_CURRENT_BINARY_DIR}/bifs_hash.h
    ${CMAKE_CURRENT_BINARY_DIR}/nifs_hash.h
    $(ATOMVM_DIR)/src/libAtomVM/atom.c
    $(ATOMVM_DIR)/src/libAtomVM/atomshashtable.c
    $(ATOMVM_DIR)/src/libAtomVM/avmpack.c
    $(ATOMVM_DIR)/src/libAtomVM/bif.c
    $(ATOMVM_DIR)/src/libAtomVM/bitstring.c
    $(ATOMVM_DIR)/src/libAtomVM/context.c
    $(ATOMVM_DIR)/src/libAtomVM/debug.c
    $(ATOMVM_DIR)/src/libAtomVM/defaultatoms.c
    $(ATOMVM_DIR)/src/libAtomVM/dictionary.c
    $(ATOMVM_DIR)/src/libAtomVM/externalterm.c
    $(ATOMVM_DIR)/src/libAtomVM/globalcontext.c
    $(ATOMVM_DIR)/src/libAtomVM/iff.c
    $(ATOMVM_DIR)/src/libAtomVM/interop.c
    $(ATOMVM_DIR)/src/libAtomVM/mailbox.c
    $(ATOMVM_DIR)/src/libAtomVM/memory.c
    $(ATOMVM_DIR)/src/libAtomVM/module.c
    $(ATOMVM_DIR)/src/libAtomVM/nifs.c
    $(ATOMVM_DIR)/src/libAtomVM/port.c
    $(ATOMVM_DIR)/src/libAtomVM/posix_nifs.c
    $(ATOMVM_DIR)/src/libAtomVM/refc_binary.c
    $(ATOMVM_DIR)/src/libAtomVM/resources.c
    $(ATOMVM_DIR)/src/libAtomVM/scheduler.c
    $(ATOMVM_DIR)/src/libAtomVM/stacktrace.c
    $(ATOMVM_DIR)/src/libAtomVM/term.c
    $(ATOMVM_DIR)/src/libAtomVM/timer_list.c
    $(ATOMVM_DIR)/src/libAtomVM/valueshashtable.c
)

zephyr_library_compile_definitions(ATOMVM_VERSION=${ATOMVM_BASE_VERSION})

if (CONFIG_ATOMVM_ADVANCED_TRACING)
    zephyr_library_compile_definitions(ENABLE_ADVANCED_TRACE)
endif()

if (CONFIG_ATOMVM_DISABLE_SMP)
    zephyr_library_compile_definitions(AVM_NO_SMP)
else()
    include(CheckIncludeFile)
    CHECK_INCLUDE_FILE(stdatomic.h STDATOMIC_INCLUDE)
    if(HAVE_PLATFORM_SMP_H)
        zephyr_library_compile_definitions(HAVE_PLATFORM_SMP_H)
    endif()
    include(CheckCSourceCompiles)
    check_c_source_compiles("
        #include <stdatomic.h>
        int main() {
            _Static_assert(ATOMIC_POINTER_LOCK_FREE == 2, \"Expected ATOMIC_POINTER_LOCK_FREE to be equal to 2\");
        }
    " ATOMIC_POINTER_LOCK_FREE_IS_TWO)
    if (NOT ATOMIC_POINTER_LOCK_FREE_IS_TWO AND NOT HAVE_PLATFORM_SMP_H)
        if (NOT STDATOMIC_INCLUDE)
            message(FATAL_ERROR "stdatomic.h cannot be found, you need to disable SMP on this platform or provide platform_smp.h and define HAVE_PLATFORM_SMP_H")
        else()
            message(FATAL_ERROR "Platform doesn't support atomic pointers, you need to disable SMP or provide platform_smp.h and define HAVE_PLATFORM_SMP_H")
        endif()
    endif()
endif()

if (CONFIG_ATOMVM_USE_32BIT_FLOAT)
    zephyr_library_compile_definitions(AVM_USE_SINGLE_PRECISION)
endif()

if (CONFIG_ATOMVM_VERBOSE_ABORT)
    zephyr_library_compile_definitions(AVM_VERBOSE_ABORT)
endif()

if (CONFIG_ATOMVM_CREATE_STACKTRACES)
    zephyr_library_compile_definitions(AVM_CREATE_STACKTRACES)
endif()

### PENDING
include(DefineIfExists)
# HAVE_OPEN & HAVE_CLOSE are used in globalcontext.h
# define_if_function_exists(libAtomVM open "fcntl.h" PUBLIC HAVE_OPEN)
# define_if_function_exists(libAtomVM close "unistd.h" PUBLIC HAVE_CLOSE)
# define_if_function_exists(libAtomVM mkfifo "sys/stat.h" PRIVATE HAVE_MKFIFO)
# define_if_function_exists(libAtomVM unlink "unistd.h" PRIVATE HAVE_UNLINK)
# define_if_symbol_exists(libAtomVM O_CLOEXEC "fcntl.h" PRIVATE HAVE_O_CLOEXEC)
# define_if_symbol_exists(libAtomVM O_DIRECTORY "fcntl.h" PRIVATE HAVE_O_DIRECTORY)
# define_if_symbol_exists(libAtomVM O_DSYNC "fcntl.h" PRIVATE HAVE_O_DSYNC)
# define_if_symbol_exists(libAtomVM O_EXEC "fcntl.h" PRIVATE HAVE_O_EXEC)
# define_if_symbol_exists(libAtomVM O_NOFOLLOW "fcntl.h" PRIVATE HAVE_O_NOFOLLOW)
# define_if_symbol_exists(libAtomVM O_RSYNC "fcntl.h" PRIVATE HAVE_O_RSYNC)
# define_if_symbol_exists(libAtomVM O_SEARCH "fcntl.h" PRIVATE HAVE_O_SEARCH)
# define_if_symbol_exists(libAtomVM O_TTY_INIT "fcntl.h" PRIVATE HAVE_O_TTY_INIT)
### PENDING

zephyr_library_compile_features(c_std_11)

endif()

A good example of how another project structured their Zephyr port is QPCPP:

https://github.com/QuantumLeaps/qpcpp
https://github.com/QuantumLeaps/qpcpp-zephyr-app

@adolfogc I think it's an excellent start. For the file functions you can enable fs. Zephyr supports several filesystems including ext2fs. This should be enough to load some beam code and run it :)

Hi @mkschreder, thanks for the information! I will try to take a look again, sometime in the near future

Several recent bugs in our stm32 port based on libopencm3, and the general lack of maintenance and documentation supporting the project, coupled with the fact that libopncm3 builds are under a GPL-3 license instead of Apache-2 like the rest of our ports has me investigating re-basing out stm32 support on Zephyr. This would be advantageous for several reasons like expanding our supported devices, as well as make maintaining and developing the port much easier using the provided APIs, as well as much more extensive documentation, an active community of users and developers for support, and many included on-board and 3rd party peripheral drivers and networking support, which will make adding these features to the VM much easier.

I have opened a draft PR #958 that builds and loads a packed avm file. Currently none of the output from the BEAM application is being displayed on the console, but logging working, so printf does go to the console. Also no none of the attempted methods set C11 standard. The compiler is still issuing c99 warnings.
Any feedback or advice is greatly appreciated.

Hi @UncleGrumpy, nice work! I will try to test it using my Heltec Wireless Stick V3 (ESP32-S3) in December.

Hi @UncleGrumpy, nice work! I will try to test it using my Heltec Wireless Stick V3 (ESP32-S3) in December.

Just in case you weren't aware, that device is already supported by the esp32 port, which has features and drivers available that will likely take a while longer to make it into this port.

Hi, thank you. Yes, I was aware of that, but I want to experiment with CAN bus and other peripherals, and will try to base it on Zephyr.


Add Events implementation for file archive

@AlexanderKouthoofd wherever you have deep functions that is not easily readable, add a brief comment before the method to describe what it does and maybe why.


v4 alpha: 767px viewport registers as both "small" and "medium"

You can see at:
http://v4-alpha.getbootstrap.com/layout/responsive-utilities/
If you set the viewport to 767px it says the viewport is "exactly" small and "exactly" medium.
This means if I use the responsive utility classes I get a weird result at 767px where both small and medium content is displayed at the same time.
What is the best way to get around/deal with this?  Thanks for any help!

A somewhat frustrating confirmation and non-confirmation.  I can reproduce what (I think) you are seeing at http://v4-alpha.getbootstrap.com/layout/responsive-utilities/#test-cases :

But then I can't reproduce on a recent (yesterday) copy of the v4-dev branch.  That is, I think the problem has gone away in newer sources.  I do see many changes in the resulting bootstrap.css, some very interesting indeed:
        5186c5184
        < @media (min-width: 48em) {
        ---
        > @media (min-width: 768px) {

So I have to think they've since 'fixed' what you were seeing.  Key is that they are not refreshing the v4-alpha.getbootstrap.com web pages, apparently waiting until the next alpha release.  (I suppose it makes sense that the alpha doc site should match the latest alpha release)  Maybe you can grab the v4-dev alpha branch and run with that?

@tshinnic Thanks for taking the time to look into this. You were exactly right - this is solved in the v4-dev alpha branch.
Closing this issue.

Approximate duplicate of #17388.


Security: stop gossiping failure and attempt times as last_seen times

Motivation
Previously, Zebra had a single time field for each peer, which was updated every time a peer was attempted, sent a message, or failed.
This is a security issue, because the last_seen time should be "the last time [a peer] connected to that node", so that
"nodes can use the time field to avoid relaying old 'addr' messages".
So Zebra was sending incorrect peer times to other nodes, which is malicious behaviour.
Specifications
addr.time field description:

Nodes advertising IP addresses they’ve connected to set this to the last time they connected to that node. Other nodes just relaying the IP address should not change the time. Nodes can use the time field to avoid relaying old “addr” messages. Malicious nodes may change times or even set them in the future.

https://developer.bitcoin.org/reference/p2p_networking.html#addr
Designs
This PR uses the DateTime32 type introduced in PR #2210, see ticket #2171 for more details.
Solution
Security Changes

Keep success times separate from failure and attempt times
Only send success times to peers

Other Required Changes
Split the last_seen time into the following fields:

untrusted_last_seen: time gossiped from other peers - serialized DateTime32
last_response: time we got a response from a directly connected peer - serialized DateTime32
last_attempt: time we attempted to connect to a peer - monotonic Instant
last_failure: time a connection with a peer failed - monotonic Instant

Send peer changes using a new MetaAddrChange type, so that senders don't accidentally overwrite peer fields with outdated data. (Due to concurrency, changes can be applied to the address book out of order.)
Review
@jvff can review this PR. It's an important security fix, but it's not particularly urgent.
This PR should close #1868.
Reviewer Checklist

[ ] Code implements Specs and Designs
[ ] Tests for Expected Behaviour
[ ] Tests for Errors

Follow Up Work
This PR is part of a series of MetaAddr refactors.
After we also fix #1867, the network will be able to remove the unreachable addresses introduced by #2120.

I still need to write a proptest for the specific behaviour fixed by this PR.

I updated the PR description, changing After we fix #1867 to After #1867 is fixed, because GitHub parsed the fix #1867 and thought that this PR would close that issue once it is merged.

I updated the PR description, changing After we fix #1867 to After #1867 is fixed, because GitHub parsed the fix #1867 and thought that this PR would close that issue once it is merged.

Thanks for catching that!

I merged the arbitrary and proptest changes from #2278.
All the changes were in test code, and they were minor. So I'll admin-merge once CI passes, which lets me make progress on #2275 without more conflicts.


Add planet lighting

Just up here to get help with some stuff still a while out.
Requires https://github.com/space-wizards/RobustToolbox/pull/5490

:cl: DoutorWhite & metalgearsloth

add: Added planet lighting for indoor / outdoor areas.
add: Added day-night cycle functionality.

europa real??

Also did emissive tiles.
At the moment just needs code optimisation + pretty sure shuttles will be broken then it's gucci.

Should roof tiles block weather too? I know weather is also a bool on the tile.
Downstream we made a weather blocking marker because it was less effort than having different variants of tiles. Merging roof and weather bool would cut down some but will still lead to duplicated tiles for indoor outdoor I think.
Unless there's a better way to do it like with an entity (like a pillar in the corner that smooths, so the only tell is the corners that they're a roof, and let people construct / deconstruct roofs then).
Was a pleasant surprise nontheless.

It's good to see this hasn't fallen into oblivion!

Downstream we made a weather blocking marker because it was less effort than having different variants of tiles. Merging roof and weather bool would cut down some but will still lead to duplicated tiles for indoor outdoor I think.

I've made roof a flag on tiles themselves though merging it with weather would be better for a separate PR to make cherry-picking easier I think. I still need to fix some planetmap stuff before we would start playtesting it upstream anyway.

Downstream we made a weather blocking marker because it was less effort than having different variants of tiles. Merging roof and weather bool would cut down some but will still lead to duplicated tiles for indoor outdoor I think.

I've made roof a flag on tiles themselves though merging it with weather would be better for a separate PR to make cherry-picking easier I think. I still need to fix some planetmap stuff before we would start playtesting it upstream anyway.

Nice. Preciate the work on it. Would applying the setroof component to entities work too? Just for more dynamic buildings and destruction I'd be leaning that way personally.

Very nice to see that code getting used after all!

Nice. Preciate the work on it. Would applying the setroof component to entities work too? Just for more dynamic buildings and destruction I'd be leaning that way personally.

I could probably remove queuedel from it and it would probably work and just make that a separate component. I can probably remove the lookups from the overlay too in lieu of solely relying on tiles.

Will stations get day-night lighting too?

Will stations get day-night lighting too?

I mean we could do it but at the moment no.

I mean we could do it but at the moment no.

Might need to have a maints discussion, since the dark of space is used to high a lot of antag activity, but I think it would be neat to have the solar panels periodically get some actual sun :)


check for .jscsrc

Do you mind if I add a pull request that checks to ensure a .jscsrc file is in the project root?

Sure.


Comment Line Command Causes Syntax Errors Inside JSX Elements

If I use "cmd+k cmd+k" to comment single line on JS code inside JSX element VS Code fails to commenting code.
Before commenting:

When I comment the line. It now has a syntax error

VSCode Version: 1.10.2
OS Version: macOS Sierra 10.12.2

Thanks. I believe this is a duplicate of #20874, which is not specific to spread operators


Should not overwrite $ZSH?! / integration with oh-my-zsh

I am not sure if https://github.com/psprint/zplugin/commit/00f2b6443d12456426230a7bb06dd4bd1fce6f3d should be done like this: from the commit message it looks like it is required for a specific plugin only?!
When integrating zplugin with oh-my-zsh as follows (so that it is sourced before OMZ's compinit)), this will break:
source ~/Vcs/zplugin/zplugin.zsh
source $ZSH/oh-my-zsh.sh

Same with using the full path to the OMZ script, because $ZSH is used therein.
My dotfiles are based on an older version of OMZ, so that might have changed.
What is the recommended setup in that case?
Using the manual method "after compinit"?

You're right, this shouldn't be done. This was when I started coding Zplugin and saw plugin copyzshell, which was designed for OMZ. Wanted to be a perfectionist I wanted even such simple and plain OMZ code to be supported by Zplugin. Bad idea. Does it work better now?

Yes, thanks!

Thanks for the report!


[search]: "/" hotkey to focus on search input

See https://developer.mozilla.org/en-US/.
Pressing the "/" key jumps to the search box and that can be quite convenient.
Investigate adding this feature, as well as communicating it.

We actually now have Control/Command + K shortcut for search now, though nowhere that communicates it.


Proposal: Create ks param unset command for "unsetting" params

Is this a BUG REPORT or FEATURE REQUEST?:
/kind feature
What happened:
It is currently not possible to "unset" parameters without manually modifying the params.libsonnet file.
What you expected to happen:
Similar to how one is able to set parameters using the ks param set command, it seems like a command to do the inverse would be helpful: ks param unset.
Environment:

ksonnet version (use ks version): ksonnet version: v0.8.0

ksonnet 0.10.0 will introduce ks param unset


How to set start and End date for Calender?

I want to give starting and ending date to calendar view.

add this code in on page scroll method
i write this code for setting minimum date is current month
int direction = position > lastPosition ? RIGHT : LEFT;
if(direction == LEFT) {
            Calendar calendar = Calendar.getInstance();
            if(displayYear == calendar.get(Calendar.YEAR) && displayMonth < calendar.get(Calendar.MONTH)) {
                goToCurrentMonth();
                Log.e("TAG", "onPageScrolled: if: " );
            }else {

                Log.e("TAG", "onPageScrolled: else: " );
            }
        }


Update it pls

Can You update it pls? I wanna play a Lot of levels with them original song 😭

Auto Nong has been merged into Jukebox. Use Jukebox instead


code to select samples that are between 1 and 1224, which constitutes as too few samples for a given lane

This is still in progress. I need to:

[x] Figure out how to include lane 7 and 8 even if no sample meet the criteria. Currently those two lane pass the check, but the way the query is constructed it causes the check to not be run against the other lanes.
[x] Materialize this as incremental

Closes #79

Similar to my review in #96, I think we should be aiming to have all of these diagnostics in the same table, rather than spread out across many models.
I think this is fine to merge, but as some follow-up work we should work to consolidate these checks

I think I understand this and based on that I agree. Let's discuss more at 1:30!


Heartbeat

Heartbeat with xDrip4iOS

option to make bluetooth connection to CGM transmitter, which will then work as heartbeat.
Disabled by default. Can be enabled in xDrip4iOS UI.
A call is made to fetchNewDataIfNeeded each time there's a call to 'peripheral(:didUpdateValueFor:error:)' or centralManager(:didDisconnectPeripheral:error:)
The call on didDisconnect is useful for Dexcom users, the call on didUpdateValueFor is for the Libre users

(note for Libre 2 users : the reading will run 1 minute behind)
Steps :
- If you haven't setup your CGM yet in xDrip4iOS :
- Force close Loop
- in xDrip4iOS make sure you have made a first connection to the CGM
- force close xDrip4iOS
- reopen Loop
- select xDrip4iOS as CGM and open the xDrip4iOS UI
- enable "use CGM as heartbeat"
- keep the app in the foreground and wait till the text under the UISwitch changes to "Did connect to CGM. You can now run both xDrip4iOS and Loop". Once you see this text, you can reopen xDrip4iOS
Other Changes

removed DispatchTimer. Timers don't work when the app is in the background. App will soon be suspended after going to background and timers are triggered. The Bluetooth trigger mechanism is what will wake up the app and trigger a fetch of the last reading

in xDripClientManager.fetchNewDataIfNeeded :  replaced all
self.delegateQueue.async { completion( .. data ..) }
By
self.delegate.notify { (delegate) in delegate?.cgmManager(self, didUpdateWith: .noData) }
Because in case fetchNewDataIfNeeded due to wake up signal by BluetoothTransmitter, then there's no completion handler available.
Not doing the call asynchronously, this was causing Loop failures

add observer on UIApplication.didFinishLaunchingNotification and UIApplication.willEnterForegroundNotification : a call to fetchNewDataIfNeeded is made when triggered. This ensures that the most recent reading is fetched when the user brings Loop to the foreground

enable/disable upload readings by Loop to Remote Service : Loop uses the boolean shouldSyncToRemoteService in CGMManager to determine of upload of glucose readings to remote service (like NightScout). This boolean can now be set to true or false in the xDrip4iOS UI

I changed the PR to be a request for freeaps_dev - but the last commit before the PR was created was to merge freeaps into heartbeat.
This was not the right thing to do with git - because we want your heartbeat branch to come into freeaps_dev (not freeaps).
I don't know if you want to start over with a new PR or revert that last commit for this PR.
We can chat about this tomorrow or the next day.

that will need a chat. I'll first try to understand better what I did
wrong. That will be in 12 hours, (It's 08 AM here)
I'll contact you via Zulip
Op do 9 jun. 2022 om 07:03 schreef Marion Barker @.***>:

I changed the PR to be a request for freeaps_dev - but the last commit
before the PR was created was to merge freeaps into heartbeat.
This was not the right thing to do with git - because we want your
heartbeat branch to come into freeaps_dev (not freeaps).
I don't know if you want to start over with a new PR or revert that last
commit for this PR.
We can chat about this tomorrow or the next day.
—
Reply to this email directly, view it on GitHub
https://github.com/loopnlearn/xdrip-client-swift/pull/8#issuecomment-1150673295,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADJTATMDFBQDCCIAPDVMY63VOF3KBANCNFSM5X35HRWQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

I'm sure you did not mean to change the localization strings.
Let me try doing some testing locally without going through github.
I worry about force pushing anything.

Let me take a crack at fixing this.  Give me a little while.

I set up loopnlearn branch called heartbeat_for_merging.
These are the files that I removed or brought over from your heatbeat branch:
A       Common/ConstantsxDripClient.swift
D       Common/DispatchTimer.swift
A       Common/Trace.swift
A       Extensions/CBManagerState.swift
A       Extensions/StringProtocol.swift
A       Extensions/URL.swift
A       Extensions/UserDefaults.swift
M       xDripClient.xcodeproj/project.pbxproj
A       xDripClient/BluetoothTransmitter.swift
M       xDripClient/xDripClient.swift
M       xDripClient/xDripClientManager.swift
M       xDripClientUI/xDripClientSettingsViewController.swift

I'll set up a new PR. If you can test that this works, I'll close this PR and merge that one. Give me another minute to set up the PR.

PR #9  is ready for your review.

Closing this because the desired files have been updated with PR #9


Feeding camera frame as background scene

Hello everyone,
I am new to android.
In c++ I have rendered the 3d obj file  on live camera feed. How can I do the same thing here using this library?
Please somebody who know that give me an idea on how to do that. Thanks..

Duplicated of #170

Can you share for me your way rendered the 3D obj file in C++ @rag3456 my email<EMAIL_ADDRESS>


Is the discovery up to date?

So I created a button a while ago and as far as I remember it was automatically discovered by Alexa.
Now I created a second and a third button, but they do not show up in the Alexa app.
Even after trying to discover them using different ways I was not able to find them.
They definitely exist as the command "getbuttons" returns the following ones:
{
"Answer:": "     1 ON Washer\n     2 OFF Window\n     3 ON Garage\n"
}
Is there any ideal way to discover them or any additional steps I have overseen?

For me it also seems like the device is discovered, at least the Alexa.Discovery response includes all 3 buttons that I defined:
json.json
Still no new devices show up in the alexa app when I ask "alexa, discover new devices". Even after multiple days. Do you have an idea how I could further debug the problem or am I missing something?

The logs contain all the communication between Alexa and the code.  Hmm.
Did you deploy to the right region?  I wouldn't have thought this would have caused this behaviour, but who knows what Amazon have done.
It might be worth pressing one of the buttons to see if a "state change" message causes the button to be found.

I have now redone the tutorial as I have also seen that I forked a while ago and it was not the newest version.
Now, I was able to link the skill and I also got logs for that in CloudWatch.
But every time I try discovery in the app nothing shows up in CloudWatch, seeming like the request does not even get that far.
Therefore I am confused, as the skill should be linked to the lambda function but where are the discovery requests?

I know this may be a silly question, but did you refresh the cloudwatch page?  New log streams don't automatically show up and you may need to reload the page.  Or, if the entry is recent enough, it may hid in the existing logstream and not create a new one.
Whenever Alexa calls the skill the very first thing that will be printed is "Handler started", followed by "incoming data" and then a determination if this was an API call or an Alexa call
eg

If you're not seeing this then the Alexa backend isn't calling your routine.  But it must have done it in the past if you're seeing the Alexa call to link the skill and saw the "Attempting to get tokens for code" log entry.
Where are you based and what region did you deploy in?

This is the last log entry I got, it is the one where I linked the account in the alexa app to activate the skill. I have asked "alexa, discover new devices" since then multiple times, also refreshed the page, no new logs.
I am based in Germany and use the ireland (eu-west-1) region.
What I am curious is that this message still shows up in the skill:

Even though I already linked my account (also redirect urls are correct):

The secret always disappears after I refresh the page (and also saved before!), but I guess this is an intentional security feature by amazon.

Hmm, that's a good successful link because we get an access token back (which you should be able to see in dynamodb slot 100001, or via the undocumented API call "getbuttonsall").
I also  see the "You will need to configure..." line in the developer console; I think it's a generic message; I ignore it :-)
Hmm, the default endpoint ARN would appear to be correct because otherwise the linking wouldn't have worked!
eu-west-1 is correct.
Hmm.
When you say you refreshed the page, did you refresh the page you pasted above, or did you refresh the previous page?   This page

That's because new log messages may (probably will) show in a new log stream, rather than appending to the existing one.
You can also make an API call and that will generate log messages.

The one in the screenshot, refreshed the page as well as used the refresh button. Neither show new log entries. I think its not a log issue, as no devices are discovered as well.

Make an API call and verify log entries are being generated.  Calling "getbuttons" would be sufficient.  You should then see something like

If you don't see this then logging is broken somewhere and you should verify that part of the config.

Yep, got a new one instantly

Very odd.  At this point I'd double check the ARN for the skill is still correct, just in case it got changed and that you haven't accidentally clicked any of the "region" endpoints.  Also re-enter the client id/secret (ensuring no hidden spaces) just in case.   We know this  previously worked 'cos otherwise the linking call wouldn't have been seen!
Also (and this shouldn't make a difference, but I've seen Alexa backend is properly normalised) try doing a discovery from the app rather than by voice.
No new logs means the lamba isn't even being called!

I relinked the device (disabled skill, enabled the skill to link again), got a log instantly:

So I am very certain that the ARN in the skill is defined properly. Also the client and secret should be defined properly (as it should not work without it?).
Afterwards alexa started device discovery automatically, but no log appeared for that.
Also did manual alexa discovery, i chose "other" and then "wlan", but I am not certain that this is the correct choice.
Also this is enabled, which should forward all requests to lambda (?):

No region endpoints are enabled, just the default one.

OK, that's a good test and I agree that shows the authn side of things is correct (which is normally the hardest bit).
FWIW, that last option needs to be on so the lamba code can let Alexa know when a button changes state.
The language shouldn't matter 'cos we're not talking to this skill, but it might be  worth verifying it's set to the same as whatever language you have your Echo device set to.
Grasping at straws... you did define this as a "smart home" skill in the Alexa developer console?
So I have no idea why you're not seeing discovery requests!  That's got me stumped.

It is defined as a smart home skill:

I don't have an echo paired with the account, I therefore only use my mobile device currently, but the app language is set to english and the alexa on the phone is also set to english, the skill as well.
Is there any way I can debug whether the discovery request even reaches the skill in the first place? I feel like the discovery does not discover devices within the skill, even though it is activated.

In the Alexa developer console on the "test" tab there's a bunch of new options that weren't there when I last looked.  You may need to toggle "skill testing is enabled in: development".
I see a "device log" at the top and a "Smart home debugger" toggle.  But I've never used them so let's see what happens.
OK, I turned them on then did "alexa discover new devices" in the text box on the left.  Hmm, that generated some log events (right frame scroll down) but I don't see discovery events there.
So I don't know if there's a way of seeing things from the Alexa side :-(

Actually for me nothing changes when I say "discover new devices" or try the manual way. Could it be an issue with my alexa app?

Yeah, I think what's happening is the dev console is emulating an Echo device (maybe a "hub") and the log entries we're seeing are for that emulated device, so we'r'e not seeing "backend" events.
If you typed "alexa discover devices" into the text box then it'll do a full discovery.  I can see the blue light on my Echo light up!

And that caused cloudwatch discovery entry to be generated by the lambda.  This isn't using the mobile app, so if that fails for you then it's probably not your phone app.
I've never tried smart home discovery without a physical Echo device.  I assume it'll work as normal, but I dunno!

What is weird is that when I try this I don't get even get the message that it is starting discovery like you got. Also therefore no log entry was generated as well

You wrote that the client secret looks like this
0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
but mine looks like this
amzn1.oa2-cs.v1.0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
Should i then discard the "amzn1.oa2-cs." part?

Also one very weird thing that I observed is that this happens:

Even though I successfully linked my account in the app and enabled it. Do you have any idea why this happens? Did I link it with the wrong account?

We saw that exact error in #6 which was caused by deploying to the wrong region.
I have to wonder if Alexa is behaving weird for you because you don't have any physical devices, just the app.
Hmm, is your Amazon account associated with amazon.de or .co.uk or .com ?
I don't know if this will make any difference, but try setting the API endpoint to the US one; that can be done with the API command "setendpoint" with the value https://api.amazonalexa.com/v3/event
(or set the DynamoDB entry for 100005 to that value)
Afterwards you could reset to the default by deleting button 100005
If that now lets the notification to be sent then Amazon thinks your Alexa is associated with  US region.

Hmm this seems to work with the US api endpoint, but why? Does this mean the skill running on US servers? Could this be why I dont get discover requests?

No, the skill is running in eu region, which is why it picked up the EU endpoint.  But it's possible your Alexa thinks it is in US region!
I don't know if changing this in the app (From the app, select devices, select "Alexa on this phone", settings cog, device location) will change things or not.
It's possible this is what's causing discovery failures as well, but that's just a guess.

Hmm, device location and time zone was already set to a german one.
I am always on developer.amazon**.com** but there is no developer.amazon.de or developer.amazon.co.uk

Could it be that the account is associated to be an american account, but the alexa device on the phone is german and hence it does not pick up the "american" devices?

I have a number of guesses (and that's all they are)

The account is somehow associated with US region
The Alexa app runs from US region
No physical Echo devices causes discovery to fail
All of the above ;-)

I can't test any of these things 'cos I'm in NJ and so everything runs from US region!

Thanks for the great help, this narrowed it down and I actually found the problem.
It was actually the region which was unset all the time. Probably it defaulted to the US due to that.
I went to the amazon shopping site and set the region there. Then it finally worked, the discover request came in!
Thank you very much for the fast responses, could not have done it without you :).

Nice!  Where did you need to set the region?  Just in case someone else has the same problem :-)

Nice!  I'll remember that in case someone else has the same problem!


Save both peak and event-level fields into isolated peaks

close: https://github.com/dachengx/axidence/issues/26


Comments after end are not preserved

Inline comments after an end instruction are not preserved after compilaton
i.e.,
end // This is the bad ending

results in
ffff

whereas it is expected that it results in
ffff // This is the bad ending

Fixed!


Change the link in the task for release tag creation

Signed-off-by: Zelin Hao<EMAIL_ADDRESS>Description
The release template still links to the tag creation issue which has been closed and we now already have an automatic tag creation workflow. Remove the old link from the template.
Issues Resolved
Check List

[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 #1889 (33586fd) into main (1dc5b37) will increase coverage by 5.45%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##               main     #1889      +/-   ##
=============================================
+ Coverage     94.54%   100.00%   +5.45%
=============================================
  Files           178         6     -172
  Lines          3630       105    -3525
  Branches         27        19       -8
=============================================
- Hits           3432       105    -3327
+ Misses          194         0     -194
+ Partials          4         0       -4

Impacted Files
Coverage Δ

src/ci_workflow/ci_test_manifest.py

src/system/execute.py

src/ci_workflow/ci_check.py

src/build_workflow/build_recorder.py

src/assemble_workflow/bundle_rpm.py

src/test_workflow/test_cluster.py

tests/jenkins/jobs/RunIntegTestScript_Jenkinsfile

src/ci_workflow/ci_target.py

tests/jenkins/jobs/PublishNotification_Jenkinsfile

src/ci_workflow/ci_check_gradle_properties.py

... and 162 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 1dc5b37...33586fd. Read the comment docs.


Intellisense for Variables

This kinda links in with Issue #8, but it would be pretty nice to have all current variables with intellisense in the handlebars-templates. Especially if it would be possible to see

The Context (Component, Page, Site) since vars can be overwritten
The Title of the Variable (the thing visible in the cms)
The Type
The current Value (for simple variables like text/numbers/booleans

That sounds awesome. primo uses codemirror, so this would probably be the best place to start:
https://codemirror.net/demo/complete.html
https://www.youtube.com/watch?v=4xD2ViRZnMY

And a way to render custom markup inside a line item: https://github.com/codemirror/CodeMirror/issues/5961
Seems like we could do some neat stuff with that besides just showing a list of values

V1 beta v3 introduced field and css var intellisense


Unable to register to eWallet

Description
I have registered in https://etoro.gooddollar.org, tried to register in Wallet, entered my phone number and received an Error. Since then it says my phone number is already registered and I am unable to enter.
Steps to reproduce

Register in https://etoro.gooddollar.org
Try to register in https://ewallet.gooddollar.org/
Get an error
Be unable to register/enter to the wallet app

helped via support


Compared to the OpenSSL 1.1.1k, all versions of OpenSSL 3 experience a decrease in TLS handshake performance when using EC algorithms.

openssl 1.1.1k：

openssl 3.2.2:

After upgrading OpenSSL from version 1.1.1k to 3.2.2, the TLS handshake latency increased from 7.75ms to 8.94ms. Here is the process I followed to generate an ECDSA certificate:
openssl req -x509 -sha256 -nodes -days 365 -newkey ec:<(openssl ecparam -name prime256v1) -keyout ecdsa.key -out ecdsa.crt -subj "/C=CN/ST=Beijing/L=Beijing/O=Example Inc./OU=Web"

There is one performance optimization included in 3.4 that might help.
Namely: https://github.com/openssl/openssl/pull/24816

@t8m Thank you for your quick response. I tried using the latest master branch which already include #24816 , but the performance regression still occurs. Here are my test results:

@t8m The performance of RSA keys is approximately improved by 30-50%.
I am not familiar with EDDSA, so its performance has not been evaluated. Therefore, currently, I only see a decrease in performance for ECDSA.

Additionally, I conducted performance tests using tools supported by OpenSSL and did not observe any performance degradation for ECDSA. I'm very confused about where the issue might be.
The results are:
[root@iZ2ze1h5uou3wpc36rx9jrZ ~]# openssl speed ecdsa
Doing 224 bits sign ecdsa's for 10s: 245301 224 bits ECDSA signs in 9.96s
Doing 224 bits verify ecdsa's for 10s: 106056 224 bits ECDSA verify in 9.97s
Doing 256 bits sign ecdsa's for 10s: 536912 256 bits ECDSA signs in 9.92s
Doing 256 bits verify ecdsa's for 10s: 168518 256 bits ECDSA verify in 9.97s
Doing 384 bits sign ecdsa's for 10s: 13472 384 bits ECDSA signs in 9.97s
Doing 384 bits verify ecdsa's for 10s: 16802 384 bits ECDSA verify in 9.98s
Doing 521 bits sign ecdsa's for 10s: 41103 521 bits ECDSA signs in 9.96s
Doing 521 bits verify ecdsa's for 10s: 20118 521 bits ECDSA verify in 9.97s
OpenSSL 1.1.1k  FIPS 25 Mar 2021
built on: Thu Feb  1 02:54:14 2024 UTC
options:bn(64,64) md2(char) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wa,--noexecstack -Wa,--generate-missing-build-notes=yes -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM="\"/dev/urandom\"" -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config"
                              sign    verify    sign/s verify/s
 224 bits ecdsa (nistp224)   0.0000s   0.0001s  24628.6  10637.5
 256 bits ecdsa (nistp256)   0.0000s   0.0001s  54124.2  16902.5
 384 bits ecdsa (nistp384)   0.0007s   0.0006s   1351.3   1683.6
 521 bits ecdsa (nistp521)   0.0002s   0.0005s   4126.8   2017.9

[root@iZ2ze1h5uou3wpc36rx9jrZ ~]# openssl3 speed ecdsa
Doing 224 bits sign ecdsa ops for 10s: 200299 224 bits ECDSA sign ops in 9.96s
Doing 224 bits verify ecdsa ops for 10s: 89427 224 bits ECDSA verify ops in 9.98s
Doing 256 bits sign ecdsa ops for 10s: 536677 256 bits ECDSA sign ops in 9.95s
Doing 256 bits verify ecdsa ops for 10s: 169845 256 bits ECDSA verify ops in 9.98s
Doing 384 bits sign ecdsa ops for 10s: 46544 384 bits ECDSA sign ops in 9.97s
Doing 384 bits verify ecdsa ops for 10s: 20556 384 bits ECDSA verify ops in 9.98s
Doing 521 bits sign ecdsa ops for 10s: 37728 521 bits ECDSA sign ops in 9.97s
Doing 521 bits verify ecdsa ops for 10s: 20530 521 bits ECDSA verify ops in 9.98s
Doing 256 bits sign ecdsa ops for 10s: 31602 256 bits ECDSA sign ops in 9.98s
Doing 256 bits verify ecdsa ops for 10s: 33370 256 bits ECDSA verify ops in 9.97s
Doing 256 bits sign ecdsa ops for 10s: 31692 256 bits ECDSA sign ops in 9.98s
Doing 256 bits verify ecdsa ops for 10s: 35362 256 bits ECDSA verify ops in 9.98s
Doing 384 bits sign ecdsa ops for 10s: 13317 384 bits ECDSA sign ops in 9.98s
Doing 384 bits verify ecdsa ops for 10s: 15438 384 bits ECDSA verify ops in 9.97s
Doing 384 bits sign ecdsa ops for 10s: 13368 384 bits ECDSA sign ops in 9.98s
Doing 384 bits verify ecdsa ops for 10s: 16502 384 bits ECDSA verify ops in 9.98s
Doing 512 bits sign ecdsa ops for 10s: 9334 512 bits ECDSA sign ops in 9.97s
Doing 512 bits verify ecdsa ops for 10s: 11210 512 bits ECDSA verify ops in 9.97s
Doing 512 bits sign ecdsa ops for 10s: 9447 512 bits ECDSA sign ops in 9.97s
Doing 512 bits verify ecdsa ops for 10s: 12051 512 bits ECDSA verify ops in 9.98s
version: 3.2.2
built on: Tue Jun 18 07:10:44 2024 UTC
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wa,--noexecstack -Wa,--generate-missing-build-notes=yes -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM="\"/dev/urandom\"" -DREDHAT_FIPS_VERSION="\"3.2.2-6c4683a0c3f42fba\"" -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config"
CPUINFO: OPENSSL_ia32cap=0xfefa320b078bffff:0x405f5ef1bf07ab
                              sign    verify    sign/s verify/s
 224 bits ecdsa (nistp224)   0.0000s   0.0001s  20110.3   8960.6
 256 bits ecdsa (nistp256)   0.0000s   0.0001s  53937.4  17018.5
 384 bits ecdsa (nistp384)   0.0002s   0.0005s   4668.4   2059.7
 521 bits ecdsa (nistp521)   0.0003s   0.0005s   3784.2   2057.1
 256 bits ecdsa (brainpoolP256r1)   0.0003s   0.0003s   3166.5   3347.0
 256 bits ecdsa (brainpoolP256t1)   0.0003s   0.0003s   3175.6   3543.3
 384 bits ecdsa (brainpoolP384r1)   0.0007s   0.0006s   1334.4   1548.4
 384 bits ecdsa (brainpoolP384t1)   0.0007s   0.0006s   1339.5   1653.5
 512 bits ecdsa (brainpoolP512r1)   0.0011s   0.0009s    936.2   1124.4
 512 bits ecdsa (brainpoolP512t1)   0.0011s   0.0008s    947.5   1207.5

The perf hotspots for openssl 1.1.1k and openssl3 are as follows（through perf top -p ）:

openssl 1.1.1k:

openssl 3.2.2:

Could it be that in your perf test a different key exchange algorithm is used for 1.1.1k and 3.x? That could explain the difference.
Apparently in 3.x X25519 is used for key exchange. Unfortunately from the 1.1.1 perf output it cannot be inferred.

Naïve question: Have we added any point validation in 3.x that wasn't there in 1.1.1x?

@t8m My nginx.conf is as follows, both OpenSSL 1.1.1k and OpenSSL 3 use the same configuration.
    server {
        listen       443 ssl http2;
        listen       [::]:443 ssl http2;
        server_name  _;
        root         /usr/share/nginx/html;

        ssl_certificate "/etc/pki/nginx/ecdsa.crt";
        ssl_certificate_key "/etc/pki/nginx/private/ecdsa.key";
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout  10m;
	ssl_ecdh_curve X25519:P-256;
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384;
        ssl_prefer_server_ciphers on;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

1.1.1k and 3.x use ECDH as the key exchange algorithm.

Naïve question: Have we added any point validation in 3.x that wasn't there in 1.1.1x?

Not for x25519 and the point validation that was added for DH and ECDH is now optimized out on 3.4.

@t8m  My machine does indeed support the AVX-IFMA instruction.
Another question is whether there is a switch in the OpenSSL build process to disable the provider. Given performance considerations, disabling the provider is also within our scope of consideration.

No, it is not possible to disable the provider support, actually all the crypto operations are inside providers.

Can you please share the script.js if it is generic enough relative the shared nginx setup?
Is it just trying to download index.html on a loop?

@xnox Yes, just download index.html. And the script is:
import http from 'k6/http';
import { check, sleep } from 'k6';

export let options = {
	insecureSkipTLSVerify: true,
	noConnectionReuse: true,
	noVUConnectionReuse: true,

	duration: '40s',
};

export default function () {
	const res = http.get('https://localhost:9001/');
	check(res, { 'status was 200': (r) => r.status == 200 });
}


RHEL6 no apr_crypto.h

Hi,
(Rhel 6.6, modsecure-2.9.0-RC2, 6.2.2015)
rhel6 apr-devel rpm was not compiled with crypto support - apr_crypto.h.
Please use parametr for ./configure and don't use apr_crypto.h in h and c file.
Quickly
I use mod_secure and download from GITLAB (6.2.2015)
https://github.com/SpiderLabs/ModSecurity
and press button "DOWNLOAD ZIP"
Untar,unzip ModSecurity-master.zip

./autogen.sh
./configure --enable-standalone-module
make - make error arp_crypto.h not file
I change source file modsecurity.h and msc_remote_rules.c (msc_remote_rules.h), then it is ok.
vi apache2/modsecurity.h
line 55
#include "apr_crypto.h"
change and comment
//#include "apr_crypto.h"
vi apache2/msc_remote_rules.c
line 27 comment //#include "apr_crypto.h"
and
make
make is OK...

Thank you for the report @martinjina.
Fixed by #f9464b46bf3cddcf857c453cc2524b2cacf2b73b
It will be include on the release 2.9.0.
See the commit comments to have more details on how the problem got fixed.


flask example working with nginx and wsgi

i try run flask example with wsgi and nginx
so i changed sys.args to manual set variable.
telegram never response ,
i see 200 in nginx response and when i open url in browser i see OK
i also add print line before
print(request.data)
update_queue.put(request.data)  # pass update to bot
but i never get telegram response to user
b'{"update_id":651538238,\n"message":{"message_id":103,"from":{"id":259792113,"first_name":"ho","last_name":"ra","username":"rrm"},"chat":{"id":259792113,"first_name":"ho","last_name":"ra","username":"rrm","type":"private"},"date":1482353453,"text":"lj"}}'

Hi! I confirm. message_loop() with source queue not working with wsgi.

Please confirm, are you guys using uWSGI?
I don't have much experience with wsgi, uwsgi, or nginx. but a web search seems to link nginx with uwsgi (with a 'u' in front). That's why I want to confirm. Thanks.

Same here, DelegatorBot doesn't seems to work.

Hi @nickoala, I can confirm this problem for uWSGI. I tried this example, but the request.data that I webhook.feed() does not seem to get forwarded to MessageCounter.
I'm using PythonAnywhere, which features a tutorial for telepot without DelegatorBot. Somebody on their forums tried the same thing and apparently a staff member claimed (currently last post in that thread), that this approach won't work due to telepot's need for an own event-handling loop.
PythonAnywhere uses uWSGI and nginx. The log-files for my webapp on PythonAnywhere start with these lines:
2018-01-28 14:22:21 *** Starting uWSGI 2.0.14 (64bit) on [Sun Jan 28 14:22:18 2018] ***
2018-01-28 14:22:21 compiled with version: 5.4.0 20160609 on 22 November 2017 21:24:09
2018-01-28 14:22:21 os: Linux-4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018

Do you think DelegatorBot can be made working with uWSGI? Any help appreciated, thanks.

Update: In the log files I have just seen a line saying:
*** Python threads support is disabled. You can enable it with --enable-threads ***

As telepot uses threads, this might be the cause of the problem.

Yes, DelegatorBot in telepot's traditional version uses threads. Any environments that disallow Python threads would not be able to run DelegatorBot.
I personally don't use PythonAnywhere, so can't suggest much here. Either get it to allow threads there, or use telepot's async version, which is based on asyncio (not threads).

Thanks for the quick reply. Threads are available on PythonAnywhere to non-free accounts only, unfortunately. asyncio raised some hopes, but according to a post from 2015 the used uWSGI implementation doesn't support this either.
As PythonAnywhere is suggesting to use telepot, I ask bring this issue to the folks there.


Test: Fabric Grid

A first go at testing this pretty sizable component. Be prepared to see lots of console warnings when you run npm test. We had to work around the jumpstate calls in FabricGrid's lifecycle methods.
As per discussion, we will come back to this and complete more end-to-end testing at a later date.
Also, this PR includes a tiny refactor of FabricGrid. It's no longer wrapped in withRouter, instead it's passed props in the render method of the Route.

@kaitmore LGTM


Add startup message

library(googleVis) gives startup msg like this, we could do something similar

library(googleVis)
Creating a generic function for ‘toJSON’ from package ‘jsonlite’ in package ‘googleVis’

Welcome to googleVis version 0.6.2
Please read Google's Terms of Use
before you start using the package:
https://developers.google.com/terms/
Note, the plot method of googleVis will by default use
the standard browser to display its output.
See the googleVis package vignettes for more details,
or visit http://github.com/mages/googleVis.
To suppress this message use:
suppressPackageStartupMessages(library(googleVis))

I think we can probably close this as we're not going to actively update the R tools and this is not a common practice for Python packages @operdeck


docs: Link to s3 bucket is outdated?

https://github.com/MystenLabs/sui/blob/docs-mainnet/doc/src/build/snapshot.md
https://docs.sui.io/build/snapshot
According to the docs, the testnet bucket is: s3://mysten-testnet-snapshots/ but the last snapshot here is epoch 680
According to Discord chat, looks like the most up to date testnet bucket is s3://suidb-snapshots
Please clarify docs or ensure the bucket is up to date with recent snapshots (or future snapshots from new testnet genesis)

Rply
On Mon, May 8, 2023, 2:53 PM Pedro Gomes @.***> wrote:

https://github.com/MystenLabs/sui/blob/docs-mainnet/doc/src/build/snapshot.md
https://docs.sui.io/build/snapshot
According to the docs, the testnet bucket is:
s3://mysten-testnet-snapshots/ but the last snapshot here is epoch 680
According to Discord chat, looks like the most up to date testnet bucket
is s3://suidb-snapshots
Please clarify docs or ensure the bucket is up to date with recent
snapshots (or future snapshots from new testnet genesis)
—
Reply to this email directly, view it on GitHub
https://github.com/MystenLabs/sui/issues/11804, or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7BX2DZHAM6QGW2WQZZKVVTXFC7CRANCNFSM6AAAAAAXZWXU34
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Please use s3://suidb-snapshots until testnet is wiped later this week. After the wipe, and moving forward, s3://mysten-testnet-snapshots/ will be the source of truth for testnet


Redesign QueryContext class

Query context revision which builds on the work started in PR #13022.
Release Notes
Most of the work in this PR is transparent to users. This PR includes Issue #13120  which introduces a user-visible change. We introduce two new configuration keys that refine the query context security model controlled by druid.auth.authorizeQueryContextParams. When that value is set to true then two other configuration options become available:

druid.auth.unsecuredContextKeys: The set of query context keys that do not require a security check. Use this for the "white-list" of key to allow. All other keys go through the existing context key security checks.
druid.auth.securedContextKeys: The set of query context keys that do require a security check. Use this when you want to allow all but a specific set of keys: only these keys go through the existing context key security checks.

Both are set using JSON list format:
druid.auth.securedContextKeys=["secretKey1", "secretKey2"]

You generally set one or the other values. If both are set, unsecuredContextKeys acts as exceptions to securedContextKeys.
In addition, Druid defines two query context keys which always bypass checks because Druid uses them internally:

sqlQueryId
sqlStringifyArrays

Backward Compatibility
When upgrading Druid, if query context security is disabled (druid.auth.authorizeQueryContextParams=false, the default) then you will see no change.
If query context security is enabled (druid.auth.authorizeQueryContextParams=true), then the two keys listed above will always be allowed, regardless of any security rules that may have been set. You can remove these two keys from your rules if you have added them.
The two new config values (unsecuredContextKeys, and securedContextKeys) will not be set in your configuration (or in the default configurations) and will thus behavior after an upgrade will not change. You can, however, shift context key security rules you have set for all users into the new unsecuredContextKeys config property.
Background
Recent work uncovered two issues with the way Druid handles query contexts:

#13049 fixes a race condition with JDBC updates
#13022 fixes type-unsafe value conversions

During the investigation of the above it became clear that the semantics around the query context are a bit unclear and could be improved.
In particular, the current QueryContext class promises more than it can deliver. It groups context values into three groups: default, system values and user values. Splitting up the values was done to allow authorizing just the user-provided keys. However, this didn't quite work as intended for several reasons. First, most code does not recognize this format, and instead "merges" all three maps before making additional changes. Second, the only use of the user-provided values is to authorize them, something that can be done more simply via other means. Third, the concept of "user-set" keys is incorrect: keys set may come from the user, or may come from an application or the Router.
As a result, the QueryContext class creates confusion rather than tidying things up as was intended. The tidying up requires that we pull in Issue #13120 to resolve a context key security ambiguity.
Overview of Revisions
This PR achieves the desired goals in a simpler way, while unifying the many ways that the code currently works with the query context.

The original three-map QueryContext is replaced by a "facade" on top of a single map.
The original QueryContext was created to allow authorizing user context keys. This PR solves that issue by making a copy of the keys separate from the context, allowing the SQL engine to modify the context without creating conflicts with the security feature.
Uses of QueryContext to fetch values are replaced with a reference the new QueryContext class as a facade.
Modification to the context in the planning layer occurs directly on the context map; it is no longer done via the old QueryContext class since there is no real value in creating a layer on top of the map.
#13022 adds a number of type-safe method to the Query interface. However, doing so clutters up that interface, and we still need the QueryContexts methods to get at specific context values. See the discussion in #13022 for details. This PR, by contrast, puts all context access methods on the revised QueryContext facade, making for cleaner code.
All type-unsafe context value accesses were replaced in #13022. They are replaced again here by the new QueryContext type-safe methods.
The old type-unsafe methods are marked deprecated. No code in Druid-proper references them, though we must assume that extensions may continue to use them.
All specific methods in QueryContexts which take a Query or context map parameter are replaced by methods on the revised QueryContext class.
QueryContexts methods which rewrote a query moved to the Queries class.
Validation of a context value now reliably throws a BadQueryContextException with a clear explanation of the problem. Previously, we threw both BadQueryContextException and ISE for such errors, and the errors have variations in format and wording.
get methods are standardized. get<Type>() without a default returns a boxed value, or null if the value is not set. This allows code to implement logic of the form "if the value is set, do something with the value, else do something else."
get(defaultValue) methods return an unboxed value, since they will return the default if the value is unset.
DruidPlanner is refactored a bit to better handle context key security.
AuthConfig implements the enhanced context key security model.

Specifics
The original QueryContext class was first removed: all references to that class were modified to refer to the context map instead.
A new class of the same name was created. The only creator of the new class is Query.queryContext(). The new class holds onto the context map associated with the query, and provides the many type-safe and value-specific methods. Since QueryContext is simply a facade, it is cheap to create an instance as needed. This lets us convert code of the form:
long foo = QueryContexts.getAsLong(query, FOO_NAME, FOO_DEFAULT);
long bar = QueryContexts.getBar(query);

To
long foo = query.queryContext().getLong(FOO_NAME, FOO_DEFAULT);
long bar = query.queryContext().getBar();

When a bit of code makes multiple references to context values (as above), we can also do:
QueryContext queryContext = query.queryContext();
long foo = queryContext.getLong(FOO_NAME, FOO_DEFAULT);
long bar = queryContext.getBar();

The following methods in Query are marked deprecated:
interface Query... {
 @Deprecated
  <ContextType> ContextType getContextValue(String key);
  @Deprecated
  <ContextType> ContextType getContextValue(String key, ContextType defaultValue);
  @Deprecated
  default boolean getContextBoolean(String key, boolean defaultValue);

Although the above methods are deprecated, they are reimplemented as default methods. As a result, the methods of the same names are removed from subclasses since they are redundant.
The Query.getQueryContext() method is removed as a way of marking that the old QueryContext is no longer available. The old method didn't really even work: the different context types were lost when merging into a single map. A new queryContext() method returns the facade version.
Alternatives
The discussions in #13049 and #13022 suggested other alternatives:

Work only with the context map and the QueryContexts methods as shown above. This works fine, and is one of the steps taken in #13049 that lead to this PR, but is a bit cumbersome.
Add methods to the Query method as in an early draft of #13022. Doing so clutters the Query interface, and does not help in the SQL layer where we work with contexts before the native Query is created. Unless we really want to clutter the Query interface, we'd still need the value-specific methods in QueryContexts.
Leave well enough alone: status quo. While the existing code works, as noted above, the semantics are a bit messy which creates confusion for readers. Tidying up the code has no benefit to the computer, but is helpful for us poor humans who have to understand the code.

Conclusion
The result is a solution that:

Solves the authorization issue that gave rise to the original QueryContext
Solves the synchronization issue with QueryContext by avoiding multiple maps.
Builds on the type safety solution of PR #13022 by shifting the methods to QueryContext.

This PR has:

[X] been self-reviewed.
[X] has been validated using existing tests.
[X] has modified unit tests as needed to reflect changed methods, exceptions and semantics.
[ ] been tested in a test Druid cluster.

I agree with your proposal on the new API form as
long foo = query.queryContext().getLong(FOO_NAME, FOO_DEFAULT);
long bar = query.queryContext().getBar();

It makes the APIs much simpler and cleaner.

@FrankChen021, thanks for the encouraging comment! Since this PR builds on the work you recently did, can you perhaps give it a review? This one touches many files and so is at risk of conflicts, so we might want to get it in if things look OK. Thanks!

@FrankChen021, thanks for the encouraging comment! Since this PR builds on the work you recently did, can you perhaps give it a review? This one touches many files and so is at risk of conflicts, so we might want to get it in if things look OK. Thanks!

Sure. I will review it on this weekends.

@FrankChen021, thanks much for your detailed review! Very helpful. To answer your specific questions:

Sorry for the force-push. On many projects, the build is done on the PR itself. Any conflicts are resolved at the end of the review process. In Druid, each PR build is first rebased on master. Failure to rebase causes the build to fail and we get no feedback on the code. As a result, when there is a merge conflict, we are forced to rebase, which requires a force push. I wonder, is there some trick that others use to avoid this issue?
Sorry for the extra spaces in imports. That's just how Eclipse works. I'll make a note to manually remove such newlines in the future.
See below.
See below.

Your point 3 suggests that callers always see QueryContext and point 4 worries about the cost of creating QueryContext per call. Looking more carefully at the prior implementation, there is a path to make this work. That fix appears in the latest commit. The result is we eliminate the copies that were your concern in point 4.
Point 3 also suggests that callers always see QueryContext instead of the map. I agree that is the goal. The one caveat is that, for backward compatibility, the original map-based getContext() must exist and be a JSON property so that the JSON form of a query is unchanged.
Thank you for pointing out the potential bug with updating a query context in place in a query. The general rule, after this change, should be:

The query context is created, as a map, before the query is constructed.
Once the query is constructed, the context is accessed via QueryContext and is immutable. (Again, the one exception is that the map is presented to Jackson for JSON serialization.)
If the context must change (such as while processing a native query), we must make a copy of the context then make a copy of the entire query with the new context. This ensures that the query is immutable and avoids the kinds of race conditions which first brought my attention to this area.

Sorry for the force-push. On many projects, the build is done on the PR itself. Any conflicts are resolved at the end of the review process. In Druid, each PR build is first rebased on master. Failure to rebase causes the build to fail and we get no feedback on the code. As a result, when there is a merge conflict, we are forced to rebase, which requires a force push. I wonder, is there some trick that others use to avoid this issue?

To resolve merge conflict, another way is to merge the latest master back to our own development branch.

@FrankChen021, thanks for the approval!
So, it turns out that I had to pull the work for Issue #13120 into this PR in order to get the security IT to pass. Basically, that IT does context key security checks using JDBC. JDBC inserts a key, which fails the security check. This worked previously when we separated system and user keys. (In fact, this may be the reason that the prior PR did the split.)
This latest PR adds two config values, defined in the "release notes" section in the revised description. To make this work:

The AuthConfig is not the one-stop shop to prepare the list of context keys to use for authorization checks.
Three new set operations are added to CollectionUtils because Java, in its infinite wisdom, doesn't provide them.
Two context keys moved from the SQL package to QueryContexts so that they are visible to AuthConfig.
These two keys are "out-of-the-box freebies" for context security: they are always allowed because they are set by Druid itself in either the Router (query ID) or JDBC path (stringify arrays.)
The code in the planner to gather the resources is tidied up a bit.

If we're good with the proposed changes, perhaps we can wrap up this PR and get it merged.

PR is updated to pull the work for Issue #13120. That change is needed to get the security IT to pass. Basically, that IT does context key security checks using JDBC. JDBC inserts a key, which fails the security check. This worked previously when we separated system and user keys. (In fact, this may be the reason that the prior PR did the split.)
This latest PR adds two config values, defined in the "release notes" section in the revised description. To make this work:

The AuthConfig is not the one-stop shop to prepare the list of context keys to use for authorization checks.
Three new set operations are added to CollectionUtils because Java, in its infinite wisdom, doesn't provide them.
Two context keys moved from the SQL package to QueryContexts so that they are visible to AuthConfig.
These two keys are "out-of-the-box freebies" for context security: they are always allowed because they are set by Druid itself in either the Router (query ID) or JDBC path (stringify arrays.)
The code in the planner to gather the resources is tidied up a bit.

We'll want to review this final change before we merge.

It will also make life easier for cluster admin to have a default list of unsecured context variables.

There are legit CI failures.

Thank you @paul-rogers. We can make the changes I suggested in a follow-up PR.