light.turn_on errors in 1.0.0b0 with tasmota

I am getting theses errors pretty consistently
Logger: homeassistant.core
Source: components/tasmota/light.py:229
First occurred: 9:32:56 PM (53 occurrences)
Last logged: 10:02:15 PM

Error executing service: <ServiceCall light.turn_on (c:adapt_lgt_b7ef_interval_18): entity_id=['light.back_porch'], params=transition=45.0, brightness=196, white_value=196, color_temp=500>

Error executing service: <ServiceCall light.turn_on (c:adapt_lgt_b7ef_interval_19): entity_id=['light.porch'], params=transition=45.0, brightness=196, white_value=196, color_temp=500>

Error executing service: <ServiceCall light.turn_on (c:adapt_lgt_b7ef_interval_19): entity_id=['light.back_porch'], params=transition=45.0, brightness=196, white_value=196, color_temp=500>

Error executing service: <ServiceCall light.turn_on (c:adapt_lgt_18fd_interval_20): entity_id=['light.downstairs_bath'], params=transition=45.0, brightness=74, white_value=74, color_temp=500>

Error executing service: <ServiceCall light.turn_on (c:adapt_lgt_18fd_interval_21): entity_id=['light.downstairs_bath'], params=transition=45.0, brightness=73, white_value=73, color_temp=500>

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/core.py", line 1461, in catch_exceptions await coro_or_task File "/usr/src/homeassistant/homeassistant/core.py", line 1480, in _execute_service await handler.job.target(service_call) File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service await self.hass.helpers.service.entity_service_call( File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 593, in entity_service_call future.result() # pop exception if have File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 664, in async_request_call await coro File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 630, in _handle_entity_call await result File "/usr/src/homeassistant/homeassistant/components/light/__init__.py", line 230, in async_handle_light_on_service await light.async_turn_on(**params) File "/usr/src/homeassistant/homeassistant/components/tasmota/light.py", line 229, in async_turn_on self._tasmota_entity.set_state(True, attributes) File "/usr/local/lib/python3.8/site-packages/hatasmota/light.py", line 274, in set_state self._set_state_light(state, attributes) File "/usr/local/lib/python3.8/site-packages/hatasmota/light.py", line 343, in _set_state_light speed = round(transition * 2 / delta_ratio) ZeroDivisionError: float division by zero

I was not getting these before the upgrade to the new beta.

This is definitely a bug with core, so I recommend creating an issue there!
It happens in
_set_state_light speed = round(transition * 2 / delta_ratio) ZeroDivisionError: float division by zero

Where delta_ratio becomes 0, which shouldn't be allowed.

Thank you


Feature Request: onDoubleTap for Row and Cell

onTap is already working for Row and Cell. Can this extends to include onDoubleTap and onLongPress as well?

Published to pub.dev


thunderbird, thunderbird-bin: 91.0 -> 91.0.1 [High security fix]

Motivation for this change

High security fix

https://www.thunderbird.net/en-US/thunderbird/91.0.1/releasenotes/
https://www.mozilla.org/en-US/security/advisories/mfsa2021-37/
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 134744 run on x86_64-linux 1

2 packages built:

thunderbird-bin (thunderbird-bin-91)
thunderbird-unwrapped (thunderbirdPackages.thunderbird)


LocalState

Do you have an example of how the new localState should be used?

Define the class that is responsible with building your local store:
config/enso/config.php
return [
    ...
    'stateBuilder' => LocalState::class, //make sure it's imported
    ...
];

Write the builder:
app\Classes\LocalState.php
namespace App\Classes;

use LaravelEnso\Core\app\Contracts\StateBuilder;

class LocalState implements StateBuilder
{
    public function build()
    {
        return [
            'today' => today(),
        ];
    }
}

Add a new store module (will be discovered automatically)
resources/assets/js/store/local.js
export const state = {
    today: null,
};

export const getters = {
    ...
};

export const mutations = {
    setToday: (state, today) => state.today = today,
};

export const actions = {
    initialise({ commit }, state) {
        commit('setToday', state.today);
    }
}

Wire up the local module to Enso's store builder:
resources/assets/js/localState.js
export default ({ dispatch }, localState) => {
    dispatch('local/initialise', localState);
};

Compile.
Play.

Consider it starred :)


revert INC fixed version installation in requirements-hpu.txt for 1.19, add tmp one for 1.18

Fix 1.19 INC incompatible issues
https://jira.habana-labs.com/browse/SW-209688

@xuechendi please resolve conflict

@michalkuligowski , conflict resolved.


App does not render when packaged - Windows 10 x64 - WinXP x32

Electrify seems to spawn a windows app that runs fine, but when packaged, the resulting executable under Windows 10 x64 does not render.
The underlying meteor app (even when run with electrify) seems to function perfectly in all other respects.
I have tried numerous varieties of configuration options and deploy locations but it seems to be the same, the electrify command works perfectly, but the deployed app spawns 2 processes of Electron processes (3.7 MB and 25.4 MB) but no window is ever visible.
The same thing seems to happen on Windows XP x32, app outputs, executable does not render... but an app window can be spawned by just running electrify and it seems to work perfectly.
No errors or warnings are issued when electrify package is run, and this occurs.
Thank you.

This turned out to be an issue with a mongo incompatibility that we resolved with the solution from here:
https://github.com/arboleya/electrify/issues/61
Specifically, by repackaging our app with mongodb-win32-x86_64-2008plus-3.2.6.zip as suggested by https://github.com/xlinbsd in that thread.

Hi ,
I know this thread is 4 years old but I happen to have the same issue as "gdudding". (https://github.com/arboleya/electrify/issues/16) I've read that the problem had been fixed, so i don't understand why it's happening to me. If anyone can help me.


WARNING: Found a content page that is not in Table of Content

As mentioned by @najuzilu , the present build of quantecon-example, is giving the following warnings

which is caused by the add_toctree function in toc.py  of this repository.

The files mentioned in the warnings above are present in the toc variable but find_name function is not able to fin it.
Will create a PR fixing this issue.

It looks like we've moved away from pages and are now calling them sections hence the warnings. I'll update this in the repo so you can pull the latest. Thanks @AakashGfude


UART issue when setting RPI_USE_U_BOOT = "1"

Description

I have a Raspberry Pi 3 with a GPS module connected to the UART interface. I'm using the thud branch of meta-raspberrypi to build images and all is working fine. When I cat /dev/ttyAMA0 I see NMEA messages coming in.
I created the following rpi-config_%.bbappend file to update the config.txt file:
do_deploy_append() {
    echo "dtparam=spi=on" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
    echo "enable_uart=1" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
}

do_deploy_append_raspberrypi3() {
    echo "core_freq=250" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
    echo "dtoverlay=pi3-disable-bt" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
}

When I add RPI_USE_U_BOOT = "1" to my configuration, the image is generated fine and the Raspberry Pi is booting using u-boot. However cat /dev/ttyAMA0 no longer returns any output.
Steps to reproduce the issue:

Add RPI_USE_U_BOOT = "1" to the configration

Describe the results you received:
After adding RPI_USE_U_BOOT = "1" and rebuilding the image, cat /dev/ttyAMA0 no longer returns any NMEA messages.
Describe the results you expected:
I was expecting to see NMEA messages when executing cat /dev/ttyAMA0 like I was able to without RPI_USE_U_BOOT = "1" in my configuration.
Additional information you deem important (e.g. issue happens only occasionally):
After adding RPI_USE_U_BOOT = "1", the config.txt still contains
dtparam=spi=on
enable_uart=1
core_freq=250
dtoverlay=pi3-disable-bt

Additional details (revisions used, host distro, etc.):
Using thud branch and raspberrypi3 as machine in my configuration.
Using the command mentioned here: https://unix.stackexchange.com/questions/289563/how-to-list-the-kernel-device-tree, I've created a dump of the device-tree when using RPI_USE_U_BOOT = "1" and without RPI_USE_U_BOOT = "1":
dt-no-uboot.txt
dt-uboot.txt
I'm not an expert at this, but there doesn't seem to be any difference which is related to for example the pi3-disable-bt overlay not applied:

After patching the U-boot recipe to disable console output during U-boot phase (thanks @Romaxx) I noticed that the ENABLE_UART="1" directive still introduced the serial0 console in the Linux kernel. This resulted in /dev/ttyS0 from being present but unavailable for our application since it was used as a console device.
Probably not the most elegant way of fixing this - but I thought worth mentioning - was to patch the meta-raspberrypi layer directly after cloning the repository by removing the console output from the cmdline.txt boot config:
sed -i 's/console=serial0,115200/console=tty1/g' ${BASE}/src/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi.inc
(This can safely be done since I am using a fork of an initialisation script to (re)construct a reproducible build environment https://gist.github.com/drewmoseley/816701ec0ca30d495786f03afea518dc )

ENABLE_UART enables the cmdline as well. We could improve this with some additional logic but also you can redefine CMDLINE (https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux/linux-raspberrypi.inc#L25) in a bbappend or in local.conf for example.
CMDLINE = "dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"

hello @agherzan yes manually adding this CMDLINE to local.conf is a way more elegant solution. Thanks for pointing that out.
Is there any easy way to skip this boot delay in U-Boot entirely? I have read that it should be possible to instruct U-Boot to have bootdelay=0.
I have managed to accomplish this manually by interactively enter the commands in the uboot prompt:
setenv bootdelay 0
saveenv

Any suggestions how to add this automatically in a Yocto build process, Preferably in local.conf?.
Thanks in advance

You can patch uboot for that. See an example here: https://github.com/balena-os/balena-raspberrypi/pull/270

HI everyone,
I'm currently using mender-convert to patch my raspbian img Linux 4.9.184-linuxkit x86_64 for my rpi 3. I'm using Waveshare SIM7600E-H_4G_HAT that I connect using an USB port so I can create an direct 4G internet connection using qmicli I disable the ttyAMA0.service.
To send AT commands, I use /dev/ttyAMA0 and set enable_uart=1 and dtoverlay=pi3-disable-bt
Currently it's boken after running mender-convert.  It's unclear for me wat I have  to do to fix this issue using mender-convert.  As far as I can see I have to:

patch mender-convert file convert-stage-4.sh and replace meta_mender_repo="https://raw.githubusercontent.com/mendersoftware/meta-mender" with forked and patched version.
Modify meta-mender layer named meta-raspberrypi with forked and patch proposed by brocaar.

Is this correct?
Thanks

IIRC you need to patch u-boot not mender. I think best would be ask on hub.mender.io instead here as you can get feedback from people familiar with problematic :)

@agherzan The original issue here seems to have been passed up to the u-boot list, I recommend we close this issue. If others (@Romaxx, @bderuijsscher, @minusplusminus) still have problems they should be opened as new issues.


Re-organizing secret store related articles

Description
Re-organizing several pages that provide guidance on how to configure a secret store and how to call the secrets API.

Guidance for configuring a component is now in one place (under operations->components) and includes an example
API usage is not tabbed.
Intelinking improved
Consolidated overview contents in one place

Issue reference
Closes #956

@AaronCrawfis please see my additions to the file per your review.


Update Brewfile Dump

#104  👈
main

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

Join @JackPlowman and the rest of your teammates on  Graphite


YOLO obstacle detector with one camera Unable to detect near target

We appreciate you go through Apollo documentations and search previous issues before creating an new one. If neither of the sources helped you with your issues, please report the issue using the following form. Please note missing info can delay the response time.
System information

OS Platform and Distribution (e.g., Linux Ubuntu 14.04):Ubuntu 14.04
Apollo installed from (source or binary): binary
Apollo version (1.0, 1.5, 2.0, 2.5, 3.0):5.0

Steps to reproduce the issue:
As shown in the picture, the red vehicle cannot be detected. Is it my camera pixel problem?
Supporting materials (screenshots, command lines, code/script snippets):

The red car was stationary there.


Reimplement auto connect/disconnect in InternalSocket

Fix #462

@bergie ready for review

Found a bug in this PR, fixing.


filters - 'not in'

Keen currently has an 'in' filter based on values matching against an array provided.
What would be useful is to have a 'not-in' filter, that excludes items that match against a provided list.
An example use case would be to filter outliers from a query, a specific example is that I am filtering out sessions with very large page view counts from analysis of avg page views / ctrs as these outliers can heavily skew the analysis.
Currently I would have to filter against a significantly longer list of 'inliers'.

Probably do this today. Have realised that ->filter(user.uuid!?uuid1,uuid2) can just be an alias to ->filter(user.uuid!=)->filter(user.uuid!=uuid2)... so easy peasy :-)

Sounds good. Ta


add imjacobclark/Herd, an experimental HTTP load testing application,…

… to the list of applications.

Thanks


cannot get persistence feature to work with lazy.nvim

{
lazy = false,
"AckslD/nvim-neoclip.lua",
dependencies = {
lazy = false,
'kkharji/sqlite.lua',
module = true,
main = 'sqlite'
},
config = function()
require('neoclip').setup()
end
},

Wrong repo, need to post on upstream


fix(fluxtest): update Flux tests for new option support

The Flux test harness now allows inheriting options, this updates the
test cases with the new syntax and simplifies any tests that had to
duplicate the options.
Requires https://github.com/influxdata/flux/pull/4559 to merge first and a Flux release to be cut
Describe your proposed changes here.

[x] Well-formatted commit messages
[x] Rebased/mergeable
[x] Tests pass
[x] http/swagger.yml updated (if modified Go structs or API)
[x] Feature flagged (if modified API)
[x] Documentation updated or issue created (provide link to issue/pr)

The changes from this PR are now included here https://github.com/influxdata/influxdb/pull/23299/commits


Add doc for mapInArrow [skip ci]

Add doc for the Pyspark API mapInArrow, along with some doc updates for the Pandas UDF.
closes https://github.com/NVIDIA/spark-rapids/issues/6975
Signed-off-by: Firestarman<EMAIL_ADDRESS>

build

build

build


chore(main): release 2.5.0

:robot: I have created a release beep boop
2.5.0 (2023-06-20)
Features

Upgrade kubernetes version to v1.26.6 and CRI tools (00be4b0)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/mesosphere/konvoy-image-builder/releases/tag/v2.5.0 :sunflower:


updates runtime/configuration to use CGI.escapeHTML instead of URI.en…

…code
Signed-off-by: Collin McNeese<EMAIL_ADDRESS>What this PR does / why we need it:
Updates for 2.7.0+ Ruby to use CGI.escapeHTML in runtime/configuration.rb instead of deprecated URI.encode, preventing current warning errors and eventual fault errors.
Which issue(s) this PR fixes:
Fixes #72
Special notes for your reviewer:
Validated that this is working as expected against a vCenter 6.5 instance (all I have access to).
Existing behavior using spec test as reference:
rspec spec/configuration_spec.rb
/path/vsphere-automation-sdk-ruby/runtime/lib/vsphere-automation-runtime/configuration.rb:174: warning: URI.escape is obsolete

VSphereAutomation::Configuration
  #base_url
/path/vsphere-automation-sdk-ruby/runtime/lib/vsphere-automation-runtime/configuration.rb:174: warning: URI.escape is obsolete
    should have the default value
/path/vsphere-automation-sdk-ruby/runtime/lib/vsphere-automation-runtime/configuration.rb:174: warning: URI.escape is obsolete
/path/vsphere-automation-sdk-ruby/runtime/lib/vsphere-automation-runtime/configuration.rb:174: warning: URI.escape is obsolete
/path/vsphere-automation-sdk-ruby/runtime/lib/vsphere-automation-runtime/configuration.rb:174: warning: URI.escape is obsolete
/path/vsphere-automation-sdk-ruby/runtime/lib/vsphere-automation-runtime/configuration.rb:174: warning: URI.escape is obsolete
    should remove trailing slashes

Finished in 0.00312 seconds (files took 0.52012 seconds to load)
2 examples, 0 failures

After making local modification:
rspec spec/configuration_spec.rb

VSphereAutomation::Configuration
  #base_url
    should have the default value
    should remove trailing slashes

Finished in 0.0027 seconds (files took 0.50313 seconds to load)
2 examples, 0 failures

Additional snippet from ruby 2.6.3p62:
spec spec/configuration_spec.rb

VSphereAutomation::Configuration
  #base_url
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/URI.rb:94: warning: already initialized constant URI::VERSION_CODE
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/uri.rb:94: warning: previous definition of VERSION_CODE was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/URI.rb:95: warning: already initialized constant URI::VERSION
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/uri.rb:95: warning: previous definition of VERSION was here
    should have the default value
    should remove trailing slashes

Finished in 0.003 seconds (files took 0.58288 seconds to load)
2 examples, 0 failures

@jrgarcia - Does this look okay to you?  I have been using this modified version at a client site against a vCenter 6.5 instance and it is working as expected

I haven't had a chance to test it as I've been incredibly busy. I'll test it today and if all is fine, merge it in. From just a quick skim over the PR, it looks great though! Thanks so much for this! 🎉

Cool!  I saw you were the only active maintainer so didn't want to come across as pushy =D
Thanks!!

Haha, not at all!

Could you add require 'cgi' above the require 'uri' line in the configuration.mustache template and then the configuration.rb output? For me with 2.7.1, it's throwing an error unless I require it first. Other than that, it looks great! 👏

Yep, sorry about that!  The Ruby environment I was running the spec tests from already had 'CGI' loaded in.

Thanks for the contribution! 🎉

I'll release a version v0.4.7 with this included later today.

Awesome, thanks @jrgarcia !!

I just released v0.4.7 with your fix included. You should be able to use this without the deprecation warnings in 2.7+ now.


Convert mass mailings to be asynchronous

Some more text that Ben found:
TUTORIALS
•	Mass mailings (to instructors, to all registrants, etc.) should be asynchronous

Fixed in #455.


FirebaseCrash 999+ warnings when submitting to iOS App Store

Hi @morganchen12 & All,
I've installed Firebase Crash into my app (without using Pods) but, when I try to submit it to the iOS App Store, I get the following warnings:
Shell Script Invocation Warning
warning: dump_syms: /Users/keyur/Library/Developer/Xcode/DerivedData/AppName-fqjjngsvfgfketelvyyfcbrycjgz/Build/Intermediates.noindex/ArchiveIntermediates/AppName/BuildProductsPath/Release-iphoneos/AppName.app.dSYM/Contents/Resources/DWARF/AppName, architecture : in compilation unit '/Users/keyur/Desktop/CCG/Live_Current_Projects/SVNLIVEPROJECTS/AppName/AppName/ThirdPartyCode/DateTimePicker/AAPickerView+Helper.swift' (offset 0x4f7b8):
warning: dump_syms: /Users/keyur/Library/Developer/Xcode/DerivedData/AppName-fqjjngsvfgfketelvyyfcbrycjgz/Build/Intermediates.noindex/ArchiveIntermediates/AppName/BuildProductsPath/Release-AppName/AppName.app.dSYM/Contents/Resources/DWARF/AppName, architecture : the DIE at offset 0x78634 has a DW_AT_abstract_origin attribute referring to the die at offset 0x78647, which either was not marked as an inline, or comes later in the file

Please help. Thanks!

@morganchen12  I am using Firebase-4.3.0

@morganchen12  Can you please help me on this? Any update please?

I don't have a definitive solution, but if you'd like to get rid of the warnings, you can do so by cleaning out your DerivedData (they'll appear the next time you archive, though). The warnings aren't indicative of an issue in your app so you shouldn't have any problems uploading to iTunesConnect.
Can you share a project that reproduces this?

Filed internally, will keep this ticket updated with info.

Hi @morganchen12 Thanks for your reply, I did cleaning out derived data but warnings were there still. There is no issue with my app even i submitted app to store with warnings. but just concerned why there are lots of warnings.
Can you share a project that reproduces this?
Sorry what you mean by this? you wants the link to download the app ?

If you have an Xcode project that you're willing to share, it'll help the crash reporting folk solve the issue faster as they can diagnose it directly in the project.


[Documentation]: Update "getting started" guide section for rsbuild

What problem does this feature solve?
If you compare these two guides:

https://rsdoctor.dev/guide/start/quick-start#rsbuild
https://rsbuild.dev/guide/debug/rsdoctor#quick-start

rsdoctor

rsbuild

you can see that the rsbuild suggests first using RSDOCTOR=true rsbuild dev while rsdoctor guide suggests using the more advanced option (i.e. use appendPlugins)
What does the proposed API look like?
Would it be possible to update the guide to suggest using RSDOCTOR=true with rsbuild?
Thanks!

btw the discussions page is disabled, so clicking on open here leads to a 404: https://github.com/web-infra-dev/rsdoctor/discussions

btw the discussions page is disabled

Thanks, I just opened it.
I will update the Rsdoctor quick start document soon


Make sure you dont need a Mujoco license to use any of the algorithms

There are many algorithms that import Mujoco environments because they are not separated. In my case I dont care about Mujoco, in fact I had to get a trial license just to avoid having to remove code from my fork.

I don't think any of the algorithm import mujoco. Do you have a specific file in mind? The example scripts certainly do. Is that what you're referring to?

In the chain of imports, for example VAE will import some environment proxies specific for mujoco. Is it ok if I move around that in a PR?

Oh I see. Yes, definitely feel free to make a PR for it.

Outcommenting import mujoco_py in wrappers.py solved this for me. I am using Soft Actor-Critic without Mujoco.

Closed with d3ea8168be40635317cbb1dc4ec9f292dee414a1


Stack Trace in Async Zod Function

Currently, async zod functions do not produce a useful stack trace when their validation fails. The trace generally contains only zod internals, looking something like this...
Error: [
  {
    "code": "invalid_arguments",
    "argumentsError": {
      "issues": [
        {
          "code": "too_small",
          "minimum": 1,
          "inclusive": true,
          "type": "array",
          "path": [],
          "message": "Should have at least 1 items"
        }
      ]
    },
    "path": [],
    "message": "Invalid function arguments"
  }
]
    at new ZodError (/Users/USERNAME/PROJECT/node_modules/zod/lib/ZodError.js:75:28)
    at handleArgs (/Users/USERNAME/PROJECT/node_modules/zod/lib/types.js:1786:23)
    at ZodFunction.<anonymous> (/Users/USERNAME/PROJECT/node_modules/zod/lib/types.js:1817:49)
    at step (/Users/USERNAME/PROJECT/node_modules/zod/lib/types.js:59:23)
    at Object.next (/Users/USERNAME/PROJECT/node_modules/zod/lib/types.js:40:53)
    at fulfilled (/Users/USERNAME/PROJECT/node_modules/zod/lib/types.js:31:58)

Async function validation should be reworked slightly to produce a more usable stack trace

@colinhacks - could you take a look at this one? I think it resolves something you attempted in 3.7

Hi! I'm on version 3.20.2, and the problem persists. Here's the stack trace I receive:
/Users/user/project/node_modules/zod/lib/types.js:29
        const error = new ZodError_1.ZodError(ctx.common.issues);
                      ^
ZodError: [
  {
    "code": "invalid_type",
    "expected": "string",
    "received": "undefined",
    "path": [],
    "message": "Required"
  }
]
    at handleResult (/Users/user/project/node_modules/zod/lib/types.js:29:23)
    at ZodString.safeParse (/Users/user/project/node_modules/zod/lib/types.js:142:16)
    at ZodString.parse (/Users/user/project/node_modules/zod/lib/types.js:122:29)
    at Object.<anonymous> (/Users/user/project/src/config.ts:80:28)
    at Module._compile (node:internal/modules/cjs/loader:1159:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
    at Module.load (node:internal/modules/cjs/loader:1037:32)
    at Function.Module._load (node:internal/modules/cjs/loader:878:12)
    at Function.mod._load (/Applications/HTTP Toolkit.app/Contents/Resources/httptoolkit-server/overrides/js/wrap-require.js:53:33)
    at Module.require (node:internal/modules/cjs/loader:1061:19)

It still gives no clue where in my app did the problem occur.


Devise 2.0, reconfirmable and a new user

I've just upgraded to 2.0.RC primarily to use the new reconfirmable logic for changing an email. However, when I sign up as a new user, the confirm! method in Confirmable fails to save the newly confirmed user with validation messages about the lack of a password. Looking at the code: (line 47 of confirmable.rb)
if self.class.reconfirmable
  @bypass_postpone = true
  self.email = unconfirmed_email if unconfirmed_email.present?
  self.unconfirmed_email = nil
  save
else
  save(:validate => false)
end

the reconfirmable path is validating the new user, whereas the non-reconfirmable path is not. That appears to be causing the validation error. Is it intentional that the validation is required for the reconfirmable path? As far as I can tell there is no way that the password is going to validate as we don't have the password attribute to validate on at that stage.
I may be missing something, but should this not call save(:validate => false) in both instances?

Yeah, we should have that in both instances. :) Thanks for reporting and trying Devise 2.0.0.RC out. I will push a fix shortly, so you can run from Devise git master if you want.

Actually, we need to validate the e-mail uniqueness. :( So I am caught between a hard place and a stone.

Sweet, that fixes it for me. Thanks for the swift response.


Theme builder generated OSX .terminal file not matching original (lightened instead)

Hey guys,
I have built the OSX Ocean theme for terminal using the builder script, however, when checking it against http://chriskempson.github.io/base16/#ocean I could see that mainly, the background colour is not the same as the one shown? — Overall, mine is looking a bit ‘washed-out’.

Am I doing something wrong?
I just have imported the .terminal file generated by the builder onto OSX Terminal and also have added the .vim file to ~/.vim/colors and configured my ~/.vimrc accordingly.

Why did you pair bright magenta with grey, and bright cyan with brown @zanona?

@Haroenv I believe this is just the way base16 ocean set colours. If you run the ruby script to generate  the .terminal file you will see how that reflects.
I don't really think the standard colour names have relation to how the colours are themed on ocean.

Ah yes, this changed since last time I ran it, thanks!


Login to vs share with an application account instead github or microsoft account

I've created a project which is lunch vs code as a container. I need my users share code with other team members. All members have an account in my platform.
For code sharing I want to use vs code sharing but i need to my users could login with my platform account not with github or microsoft accounts.
How can I do that?
Is there a way or an api  to handle this ?

Hi @hakimehmordadi,
We do not plan to add more authentication providers to Live Share in the nearest future but we'd love to learn more about your use case. Which platform/type of accounts do you expect your team to use? Maybe your team can create a Microsoft or GitHub account using their existing email address?
You can try to platform account as a Microsoft account on this website: https://signup.live.com.

I think it is better to use of live share without having microsoft/github account, why we can not log in to  live share with users who is registered in our database?
According to open source live share, could we change the authentication type or database? This way helps us to having our users inside our database but can use live share.

adding @fubaduba to the conversation .

@fubaduba Is it possible providing this feature for us? Thanks

Please support commonly used things like an on-premise Gitlab-installation, Nextcloud or the like - any oauth-provider or so maybe?

We’re not able to prioritize this issue over the other higher-impact issues we receive every week, based on the votes and comments from others in the community and our understanding of the issue. However, rest assured that we love your input. If you feel it deserves to stay open, then clarify your use case and contact us to let us know how severe it is for you.


OAK-FFC-4P StereoDepth set depth alignment with RGB Camera

Describe the bug
In our OAK-FFC-4P setup, the CAM_B is left, CAM_C is right and CAM_D is center. However, when configure StereoDepth to set depth alignment with RGB camera (center) stereo.setDepthAlign(dai.CameraBoardSocket.CAM_D), it has error :
[14442C1081F4D5D600] [1.2.1] [2.628] [StereoDepth(3)] [error] DepthAlign is only implemented for RGB camera and LEFT and RIGHT stereo inputs!

Change to stereo.setDepthAlign(dai.CameraBoardSocket.CAM_A), look like it's success :
[14442C1081F4D5D600] [1.2.1] [2.615] [StereoDepth(3)] [warning] Align to RGB requested, but ColorCamera not configured. Can't determine output resolution automatically. Using MonoCamera resolution. If you want to set explicitly use 'setOutputSize' API.
[14442C1081F4D5D600] [1.2.1] [2.622] [StereoDepth(3)] [error] RGB camera calibration missing, aligning to RGB won't work

Minimal Reproducible Example
import numpy as np
import cv2
import depthai as dai

pipeline = dai.Pipeline()

cam_center = pipeline.create(dai.node.ColorCamera)
cam_center.setResolution(dai.ColorCameraProperties.SensorResolution.THE_1200_P)
cam_center.setIspScale(400, 1200)
cam_center.setFps(30)
cam_center.setBoardSocket(dai.CameraBoardSocket.CAM_D)
# For now, RGB needs fixed focus to properly align with depth.
# This value was used during calibration
try:
    calibData = dai.Device().readCalibration2()
    lensPosition = calibData.getLensPosition(dai.CameraBoardSocket.CAM_D)
    if lensPosition:
        cam_center.initialControl.setManualFocus(lensPosition)
except:
    raise

cam_left = pipeline.create(dai.node.ColorCamera)
cam_left.setResolution(dai.ColorCameraProperties.SensorResolution.THE_1200_P)
cam_left.setIspScale(400, 1200)
cam_left.setFps(30)
cam_left.setBoardSocket(dai.CameraBoardSocket.CAM_B)

cam_right = pipeline.create(dai.node.ColorCamera)
cam_right.setResolution(dai.ColorCameraProperties.SensorResolution.THE_1200_P)
cam_right.setIspScale(400, 1200)
cam_right.setFps(30)
cam_right.setBoardSocket(dai.CameraBoardSocket.CAM_C)

stereo = pipeline.create(dai.node.StereoDepth)
stereo.setDefaultProfilePreset(dai.node.StereoDepth.PresetMode.HIGH_DENSITY)
stereo.setLeftRightCheck(True)
stereo.setExtendedDisparity(False)
stereo.setSubpixel(False)
# stereo.setDepthAlign(dai.CameraBoardSocket.CAM_D)

# Define streams
rgbOut = pipeline.create(dai.node.XLinkOut)
rgbOut.setStreamName("center")
disparityOut = pipeline.create(dai.node.XLinkOut)
disparityOut.setStreamName("disparity")

# Linking
cam_center.isp.link(rgbOut.input)
cam_left.isp.link(stereo.left)
cam_right.isp.link(stereo.right)
stereo.disparity.link(disparityOut.input)

with dai.Device() as device:
    device.startPipeline(pipeline)

    frameRgb = None
    frameDisp = None

    centerQueue = device.getOutputQueue(name='center', maxSize=4, blocking=False)
    dispQueue = device.getOutputQueue(name='disparity', maxSize=4, blocking=False)

    while True:
        frameRgb = centerQueue.get().getCvFrame()
        frameDisp = dispQueue.get().getFrame()
        maxDisparity = stereo.initialConfig.getMaxDisparity()
        frameDisp = (frameDisp * 255. / maxDisparity).astype(np.uint8)

        frameDisp = cv2.applyColorMap(frameDisp, cv2.COLORMAP_TURBO)
        frameDisp = np.ascontiguousarray(frameDisp)

        # Need to have both frames in BGR format before blending
        if len(frameDisp.shape) < 3:
            frameDisp = cv2.cvtColor(frameDisp, cv2.COLOR_GRAY2BGR)

        blended = cv2.addWeighted(frameRgb, 0.4, frameDisp, 0.6, 0)

        cv2.imshow('rgb + depth', blended)
        frameRgb = None
        frameDisp = None

        if cv2.waitKey(1) == ord('q'):
            break

cv2.destroyAllWindows()

Expected behavior
How to overcome this issue if I sill want to keep the CameraBoardSocket CAM_D connect to center sensor.
Attach system log

If I set  stereo.setDepthAlign(dai.CameraBoardSocket.CAM_D), the error logs are:

[14442C1081F4D5D600] [1.2.1] [2.628] [StereoDepth(3)] [error] DepthAlign is only implemented for RGB camera and LEFT and RIGHT stereo inputs!

If I set  stereo.setDepthAlign(dai.CameraBoardSocket.CAM_A), the error logs are:

[14442C1081F4D5D600] [1.2.1] [2.615] [StereoDepth(3)] [warning] Align to RGB requested, but ColorCamera not configured. Can't determine output resolution automatically. Using MonoCamera resolution. If you want to set explicitly use 'setOutputSize' API.
[14442C1081F4D5D600] [1.2.1] [2.622] [StereoDepth(3)] [error] RGB camera calibration missing, aligning to RGB won't work

Hi @michaelnguyen11
Could you paste the camera calibration you have done for your current setup?

Hi @jakaskerl ,
Please take a look at attached file for the calibration file (generated from calibration_reader.py script).
calib_14442C1081F4D5D600.zip


feat(docs)/docusaurus

This mr introduce documentation using docusaurus and released through github pages.

Codecov Report
Base: 91.90% // Head: 91.90% // No change to project coverage :thumbsup:

Coverage data is based on head (1cf8230) compared to base (6c61187).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #238   +/-   ##
=======================================
  Coverage   91.90%   91.90%
=======================================
  Files          17       17
  Lines         284      284
  Branches       69       69
=======================================
  Hits          261      261
  Misses         23       23

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

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


beta-20161013 release notes and related docs changes

Release notes based on https://github.com/cockroachdb/cockroach/issues/9781.

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/b54b45825db58dc838af4605be4a0ea6f92641fa/

Things I've touched LGTM (rest also looks roughly LGTM, but haven't done fact checking).

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/2ef9a1d1bffab6b91c7338bdaa73b924957bec55/

Thanks, @tschottdorf. One thing I could use help on: Getting the total count of merged PRs. Though we might want to wait until we chose a cut-off commit.

Yeah, should be easy enough to get that with git log --merges --oneline <old_beta_sha>..<new_beta_sha>. It picks up some of the cross-merges (master->develop and the end of the split), but these would be easy enough to subtract if we care (they are merges, after all).

The bits I'm familiar with LGTM

LGTM for the stuff I know

nits:

"THE" in front of CONCAT_AGG is in all caps.
We already supported history recalls in the cli shell. What changed with #9704 is the case sensitivity.

Thanks, @knz. Made those changes.

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/62deeeb205aaa4183c96998752482dd1896f6348/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/c8484fb974eebf989cb31c37589de8c58c092617/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/2a004c970d503d6ba72cc1bbff8fd32c67f8eb23/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/f5ac32c75f59b62e8158b96584b1d5c0bff2432e/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/62c324b01ce9f0747cf46f4456dfcdfd01da36c6/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/ddaa7aadd604adae64b67c18bc453fc4bb5e3fdf/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/89cc681aee8e804772a09ea41e8519a6af032969/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/f49426453eb012ede06234cba3b57d70ebcd6d0e/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/8748c14f08e21519b3e0be8548c05af797279e5c/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/b63b466437f48e600a9eb781ed6925c7c89ebbf4/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/9b9c919434e3e874e2b0f2faa6ce8406df5a2438/

LGTM

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/2593843016613e7cb2c4ff2fd6410dce94740a60/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/2c47141df999b6bb4a9b254d73baf5b4102aa46d/


Updated react and react-dom. Added prop-types library.

[x] Updated react and react-dom.
[x] Added prop-types library.
[x] Updated webpack to take externals from package.json.

Solves:
React PropTypes deprecation #2

Please reword your commit by commitizen conventions.

I've updated all prop-types to be required by adding .isRequired suffix.
:shipit: ?

I'll rebase if everything is OK with the code.

Rebased. Everything's OK, @MartynasZilinskas?

All good.


Add Public Credential support

Add support and standardize a service endpoint that links to a publicly available Verifiable Credential (VC), published to an IOTA address. This address can be resolved to retrieve a VC and can be verified. The public VC should also have its own type made available within the DID Document as filtering and searching for public credentials within a DID Document should be done with as few queries as possible.
This feature is targeted at Identity for Organization, Things, and Objects. It should not be utilized with any data that can be considered Personal Identifiable according to the General Data Protection Regulation (GDPR) and other privacy laws worldwide. As such, this feature should not be used with DID Documents representing people. It is ideally used for Organizational credentials such as certifications or used for Identity of Things for similar certifications, specifications, or proof of origin.

[ ] Determine specs of the feature
[ ] Implement Service Endpoint
[ ] Standardize Service Endpoint
[ ] Document very explicity the dangers of using this with Identity for People (GDPR compliance)
[ ] Add WASM bindings
[ ] Add examples

Internal design document: https://docs.google.com/document/d/1VE0jtPsd_9Ewtfj53pdHPJXzwS3lmR0yd4Uk0dpNjzM/edit

Dependent on #1283


We run a HTTP/2 server that flushes an early headers map (status 103 - http.StatusEarlyHints) using func (http.ResponseWriter) WriteHeader(statusCode int).
After calling WriteHeader, we may need to mutate the Header map for the final 2xx response based on information we discover. In our application, we simply clear the Headers after flushing the early hint:
			r.W.Header().Set("Server", "...")
			r.W.Header().Set("Link", "...")

			r.W.WriteHeader(http.StatusEarlyHints)

			// remove the headers after sending the early hints to avoid
			// sending duplicate headers when the final response is sent:
			r.W.Header().Del("Server")
			r.W.Header().Del("Link")

What did you see happen?
After >60 minutes of runtime and millions of requests (this is hard to reproduce), we were faced with this crash:
fatal error: concurrent map read and map write
goroutine 44382232 [running]:
golang.org/x/net/http2.encodeHeaders(0xc09549f798?, 0x1412ef5?, {0x0?, 0xc0416e72b9?, 0xc07fbd2f18?})
golang.org/x/net@v0.24.0/http2/write.go:343 +0x156
golang.org/x/net/http2.(*writeResHeaders).writeFrame(0xc04d077c00, {0x15edb08, 0xc08528a000})
golang.org/x/net@v0.24.0/http2/write.go:217 +0xe9
golang.org/x/net/http2.(*serverConn).writeFrameAsync(0xc08528a000, {{0x15e9140?, 0xc04d077c00?}, 0xc01a73d860?, 0xc0326e0c60?}, 0xc070d666a8?)
golang.org/x/net@v0.24.0/http2/server.go:852 +0x74
created by golang.org/x/net/http2.(*serverConn).startFrameWrite in goroutine 44380821
golang.org/x/net@v0.24.0/http2/server.go:1266 +0x390
goroutine 1 [semacquire, 87 minutes]:

This appears to be due to writeFrameAsync running on a separate goroutine and the encodeHeaders function doing a naive iteration over the values (vv := h[k], line 343 from above).
What did you expect to see?
Encoding headers needs to be concurrent-safe now that a server can send and mutate its headers multiple times before sending the final response (e.g. 103, 103, 103, 200).

Similar Issues

https://github.com/golang/go/issues/18326
https://github.com/golang/go/issues/45311
https://github.com/golang/go/issues/47882
https://github.com/golang/go/issues/48491
https://github.com/golang/go/issues/13089

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

r.W.Header().Del("Server")
Header doesn't need to be deleted? Because Response creates a new Header each time.

WriteHeader should block until the headers have been sent, to avoid precisely this type of race. I've looked through this code path a few times now, and I don't see a way for the header map to be touched after WriteHeader returns, but I might be missing something.
Do you possibly have a middleware layer wrapping the ResponseWriter that might be deferring the WriteHeader call to a later time?
If you can run this under the race detector (go build -race), it might make the failure more reproducible.)

No, we are not wrapping the ResponseWriter with a middleware. I'm enabling the race detector in hopes that it prints the information about the access and will report back today!

Got the race! Sharing it here while I continue to evaluate it.
2024-08-09T19:19:38.955255887Z ==================
2024-08-09T19:19:38.955262912Z WARNING: DATA RACE
2024-08-09T19:19:38.955265201Z Write at 0x00c00bfa5740 by goroutine 7675145:
2024-08-09T19:19:38.955267226Z   runtime.mapdelete_faststr()
2024-08-09T19:19:38.955269405Z       /usr/local/go/src/runtime/map_faststr.go:301 +0x0
2024-08-09T19:19:38.955271096Z   net/textproto.MIMEHeader.Del()
2024-08-09T19:19:38.955272820Z       /usr/local/go/src/net/textproto/header.go:55 +0x4d
2024-08-09T19:19:38.955274358Z   net/http.Header.Del()
2024-08-09T19:19:38.955275804Z       /usr/local/go/src/net/http/header.go:81 +0x27
2024-08-09T19:19:38.955277621Z   main.main.ProxyUpstream.func14()
2024-08-09T19:19:38.955279964Z       /usr/src/https-terminator/middlewares/proxyhttp/http_handler.go:562 +0x17cb
2024-08-09T19:19:38.955281075Z   main.main.REDACTED.func15()
2024-08-09T19:19:38.955282521Z       /usr/src/https-terminator/middlewares/proxyhttp/REDACTED.go:183 +0xc7e
2024-08-09T19:19:38.955283567Z   main.main.REDACTED.func16()
2024-08-09T19:19:38.955284607Z       /usr/src/https-terminator/middlewares/proxyhttp/REDACTED.go:26 +0xba4
2024-08-09T19:19:38.955285748Z   main.main.REDACTED.func17()
2024-08-09T19:19:38.955286753Z       /usr/src/https-terminator/middlewares/proxyhttp/REDACTED.go:24 +0x9cf
2024-08-09T19:19:38.955287988Z   main.main.REDACTED.func18()
2024-08-09T19:19:38.955289160Z       /usr/src/https-terminator/middlewares/proxyhttp/REDACTED.go:53 +0x2e1
2024-08-09T19:19:38.955290119Z   main.main.REDACTED.func19()
2024-08-09T19:19:38.955291243Z       /usr/src/https-terminator/middlewares/threats/REDACTED.go:23 +0x273
2024-08-09T19:19:38.955292407Z   main.main.REDACTED.func20()
2024-08-09T19:19:38.955295540Z       /usr/src/https-terminator/middlewares/proxyhttp/REDACTED.go:8 +0x19c
2024-08-09T19:19:38.955298336Z   main.main.REDACTED.func21()
2024-08-09T19:19:38.955299811Z       /usr/src/https-terminator/middlewares/proxyhttp/REDACTED.go:17 +0x116
2024-08-09T19:19:38.955301227Z   github.com/vercel/proxy/https-terminator/middlewares/proxyhttp.(*server).ServeHTTP()
2024-08-09T19:19:38.955302888Z       /usr/src/https-terminator/middlewares/proxyhttp/server.go:201 +0x571
2024-08-09T19:19:38.955305221Z   net/http.serverHandler.ServeHTTP()
2024-08-09T19:19:38.955306537Z       /usr/local/go/src/net/http/server.go:2943 +0x2a1
2024-08-09T19:19:38.955307491Z   net/http.initALPNRequest.ServeHTTP()
2024-08-09T19:19:38.955308475Z       /usr/local/go/src/net/http/server.go:3551 +0x35e
2024-08-09T19:19:38.955309699Z   net/http.(*initALPNRequest).ServeHTTP()
2024-08-09T19:19:38.955310705Z       <autogenerated>:1 +0x7b
2024-08-09T19:19:38.955311715Z   net/http.Handler.ServeHTTP-fm()
2024-08-09T19:19:38.955312916Z       <autogenerated>:1 +0x67
2024-08-09T19:19:38.955313934Z   golang.org/x/net/http2.(*serverConn).runHandler()
2024-08-09T19:19:38.955314966Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:2414 +0x25a
2024-08-09T19:19:38.955315980Z   golang.org/x/net/http2.(*serverConn).scheduleHandler.func1()
2024-08-09T19:19:38.955322658Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:2348 +0x5d
2024-08-09T19:19:38.955323910Z
2024-08-09T19:19:38.955325457Z Previous read at 0x00c00bfa5740 by goroutine 7675260:
2024-08-09T19:19:38.955327005Z   runtime.mapiterinit()
2024-08-09T19:19:38.955328549Z       /usr/local/go/src/runtime/map.go:816 +0x0
2024-08-09T19:19:38.955329933Z   golang.org/x/net/http2.(*sorter).Keys()
2024-08-09T19:19:38.955331759Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/http2.go:344 +0x8f
2024-08-09T19:19:38.955333741Z   golang.org/x/net/http2.encodeHeaders()
2024-08-09T19:19:38.955334817Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/write.go:340 +0x13d
2024-08-09T19:19:38.955335846Z   golang.org/x/net/http2.(*writeResHeaders).writeFrame()
2024-08-09T19:19:38.955337101Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/write.go:217 +0x1cd
2024-08-09T19:19:38.955338182Z   golang.org/x/net/http2.(*serverConn).writeFrameAsync()
2024-08-09T19:19:38.955339244Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:890 +0x116
2024-08-09T19:19:38.955340382Z   golang.org/x/net/http2.(*serverConn).startFrameWrite.func2()
2024-08-09T19:19:38.955341415Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:1304 +0x6e
2024-08-09T19:19:38.955342347Z
2024-08-09T19:19:38.955343398Z Goroutine 7675145 (running) created at:
2024-08-09T19:19:38.955356990Z   golang.org/x/net/http2.(*serverConn).scheduleHandler()
2024-08-09T19:19:38.955358243Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:2348 +0x28a
2024-08-09T19:19:38.955359222Z   golang.org/x/net/http2.(*serverConn).processHeaders()
2024-08-09T19:19:38.955360262Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:2070 +0xd30
2024-08-09T19:19:38.955361329Z   golang.org/x/net/http2.(*serverConn).processFrame()
2024-08-09T19:19:38.955362448Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:1571 +0x3f9
2024-08-09T19:19:38.955363452Z   golang.org/x/net/http2.(*serverConn).processFrameFromReader()
2024-08-09T19:19:38.955364574Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:1509 +0x324
2024-08-09T19:19:38.955365563Z   golang.org/x/net/http2.(*serverConn).serve()
2024-08-09T19:19:38.955366580Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:998 +0x17bc
2024-08-09T19:19:38.955367960Z   golang.org/x/net/http2.(*Server).serveConn()
2024-08-09T19:19:38.955369001Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:572 +0x1a90
2024-08-09T19:19:38.955370090Z   golang.org/x/net/http2.(*Server).ServeConn()
2024-08-09T19:19:38.955371192Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:436 +0x185
2024-08-09T19:19:38.955372317Z   golang.org/x/net/http2.ConfigureServer.func1()
2024-08-09T19:19:38.955373408Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:355 +0xbe
2024-08-09T19:19:38.955374353Z   net/http.(*conn).serve()
2024-08-09T19:19:38.955375307Z       /usr/local/go/src/net/http/server.go:1922 +0x1d41
2024-08-09T19:19:38.955376720Z   net/http.(*Server).Serve.func3()
2024-08-09T19:19:38.955377697Z       /usr/local/go/src/net/http/server.go:3091 +0x4f
2024-08-09T19:19:38.955378552Z
2024-08-09T19:19:38.955379499Z Goroutine 7675260 (finished) created at:
2024-08-09T19:19:38.955380584Z   golang.org/x/net/http2.(*serverConn).startFrameWrite()
2024-08-09T19:19:38.955381555Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:1304 +0x77b
2024-08-09T19:19:38.955382677Z   golang.org/x/net/http2.(*serverConn).scheduleFrameWrite()
2024-08-09T19:19:38.955383614Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:1406 +0x3c8
2024-08-09T19:19:38.955384616Z   golang.org/x/net/http2.(*serverConn).writeFrame()
2024-08-09T19:19:38.955389980Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:1252 +0x3c7
2024-08-09T19:19:38.955391151Z   golang.org/x/net/http2.(*serverConn).serve()
2024-08-09T19:19:38.955392125Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:985 +0x15b1
2024-08-09T19:19:38.955393350Z   golang.org/x/net/http2.(*Server).serveConn()
2024-08-09T19:19:38.955394737Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:572 +0x1a90
2024-08-09T19:19:38.955396303Z   golang.org/x/net/http2.(*Server).ServeConn()
2024-08-09T19:19:38.955398538Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:436 +0x185
2024-08-09T19:19:38.955399815Z   golang.org/x/net/http2.ConfigureServer.func1()
2024-08-09T19:19:38.955401363Z       /go/pkg/mod/golang.org/x/net@v0.26.0/http2/server.go:355 +0xbe
2024-08-09T19:19:38.955402833Z   net/http.(*conn).serve()
2024-08-09T19:19:38.955404301Z       /usr/local/go/src/net/http/server.go:1922 +0x1d41
2024-08-09T19:19:38.955405880Z   net/http.(*Server).Serve.func3()
2024-08-09T19:19:38.955407377Z       /usr/local/go/src/net/http/server.go:3091 +0x4f
2024-08-09T19:19:38.955408869Z ==================

I may be missing it, but I don't see where WriteHeader blocks until the write is complete.
The http2 WriteHeader implementation<EMAIL_ADDRESS>uses the writeHeader impl in responseWriterState (:2943).
For 1xx status codes, it calls rws.conn.writeHeaders:
func (rws *responseWriterState) writeHeader(code int) {
	if rws.wroteHeader {
		return
	}

	checkWriteHeaderCode(code)

	// Handle informational headers
	if code >= 100 && code <= 199 {
		// Per RFC 8297 we must not clear the current header map
		h := rws.handlerHeader

		_, cl := h["Content-Length"]
		_, te := h["Transfer-Encoding"]
		if cl || te {
			h = h.Clone()
			h.Del("Content-Length")
			h.Del("Transfer-Encoding")
		}

		rws.conn.writeHeaders(rws.stream, &writeResHeaders{
			streamID:    rws.stream.id,
			httpResCode: code,
			h:           h,
			endStream:   rws.handlerDone && !rws.hasTrailers(),
		})

		return
	}

writeHeaders submits the call to writeFrameFromHandler (golang.org/x/net@v0.26.0/http2/server.go:2440). This function does not wait for any signals in the success case:
func (sc *serverConn) writeHeaders(st *stream, headerData *writeResHeaders) error {
	sc.serveG.checkNotOn() // NOT on
	var errc chan error
	if headerData.h != nil {
		// If there's a header map (which we don't own), so we have to block on
		// waiting for this frame to be written, so an http.Flush mid-handler
		// writes out the correct value of keys, before a handler later potentially
		// mutates it.
		errc = errChanPool.Get().(chan error)
	}
	if err := sc.writeFrameFromHandler(FrameWriteRequest{
		write:  headerData,
		stream: st,
		done:   errc,
	}); err != nil {
		return err
	}
	if errc != nil {
		select {
		case err := <-errc:
			errChanPool.Put(errc)
			return err
		case <-sc.doneServing:
			return errClientDisconnected
		case <-st.cw:
			return errStreamClosed
		}
	}
	return nil
}

And the writeFrameFromHandler impl simply drops it on the wantWriteFrameCh channel for writing (a buffered channel).
// writeFrameFromHandler sends wr to sc.wantWriteFrameCh, but aborts
// if the connection has gone away.
//
// This must not be run from the serve goroutine itself, else it might
// deadlock writing to sc.wantWriteFrameCh (which is only mildly
// buffered and is read by serve itself). If you're on the serve
// goroutine, call writeFrame instead.
func (sc *serverConn) writeFrameFromHandler(wr FrameWriteRequest) error {
	sc.serveG.checkNotOn() // NOT
	select {
	case sc.wantWriteFrameCh <- wr:
		return nil
	case <-sc.doneServing:
		// Serve loop is gone.
		// Client has closed their connection to the server.
		return errClientDisconnected
	}
}

Perhaps the header map sent in to rws.conn.writeHeaders needs to clone h since it all seems to happen async? Or am I missing what causes the blocking write?

cc @neild in case you unsubscribed from the issue after being closed 🙏, hope you don't mind.

Hay hay zevkle aboneliği iptal ederim

Thanks for the race detector output; that was very useful.
The problem is that while writeHeaders usually waits for the write to complete before returning, it stops waiting if the stream is reset by the peer. The race occurs when the header write has already started at the time the peer's reset is processed. (This is the <-st.cw path in writeHeaders.)
I'm still trying to figure out the right fix; there's a fairly complex set of interactions between the different goroutines involved in writing a frame. Most of this complexity is in service of efficiency, and I suspect the more obvious fixes leave us with all the complexity and none of the efficiency.

If it's of any anecdotal value, for latency/efficiency sake, we'd prefer WriteHeader to be async so we can continue processing the request without introducing a blocking operation.


Adding camera bonsai workflows, and organizing files

Pull Request instructions:

Please follow the update protocol
Answer the questions below in detail. Your responses will be emailed to experimenters.
If the experimenters must do anything new, provide detailed step by step instructions on the wiki
Use markdown syntax in order for your comments to be rendered reliably in the email: "1." instead of "1)", use four spaces for indents.
If you use the keyword "skip email" in the title, it will skip the email updates
Merges from "production_testing" into "main" should use the keyword "production merge" in the title for reliable indexing of updates

Describe changes:

Adds Bonsai camera workflows. I copied an instance from one of the old computers
Creates folders for "setting_templates", "update_scripts", and "desktop_shortcuts"
Removes an old laser calibration.json file. Its not clear why this file was included in the repo. @XX-Yin

What issues or discussions does this update address?

resolves aind-behavior-blog#15
organizes the files

Describe the expected change in behavior from the perspective of the experimenter

When configuring the computer, files are more organized
When configuring the computer, the camera workflows are in this repo, instead of manually copied.

Describe the outcome of testing this update on a rig in 447

tested

1 question, Why do we need camera rig2? Each computer controls only one rig?
Other parts look great!

Right now every computer controls two rigs. Eventually it will be one computer per rig


BUILD FAILURE ,mvn clean install -DskipTests -Dhadoop.version=2.6.0-cdh5.7.2 -Dhive.version=1.1.0-cdh5.7.2

[INFO] Hoodie ............................................. SUCCESS [  4.273 s]
[INFO] hoodie-common ...................................... SUCCESS [02:20 min]
[INFO] hoodie-hadoop-mr ................................... SUCCESS [01:38 min]
[INFO] hoodie-client ...................................... SUCCESS [  7.487 s]
[INFO] hoodie-hive ........................................ SUCCESS [  2.583 s]
[INFO] hoodie-spark ....................................... SUCCESS [ 56.425 s]
[INFO] hoodie-utilities ................................... SUCCESS [02:20 min]
[INFO] hoodie-cli ......................................... SUCCESS [ 20.190 s]
[INFO] hoodie-hadoop-mr-bundle ............................ SUCCESS [  2.590 s]
[INFO] hoodie-hive-bundle ................................. SUCCESS [ 25.859 s]
[INFO] hoodie-spark-bundle ................................ SUCCESS [01:29 min]
[INFO] hoodie-presto-bundle ............................... SUCCESS [ 22.659 s]
[INFO] hoodie-hadoop-docker ............................... SUCCESS [  0.816 s]
[INFO] hoodie-hadoop-base-docker .......................... SUCCESS [  0.410 s]
[INFO] hoodie-hadoop-namenode-docker ...................... SUCCESS [  0.065 s]
[INFO] hoodie-hadoop-datanode-docker ...................... SUCCESS [  0.064 s]
[INFO] hoodie-hadoop-history-docker ....................... SUCCESS [  0.069 s]
[INFO] hoodie-hadoop-hive-docker .......................... SUCCESS [  0.788 s]
[INFO] hoodie-hadoop-sparkbase-docker ..................... SUCCESS [  0.073 s]
[INFO] hoodie-hadoop-sparkmaster-docker ................... SUCCESS [  0.055 s]
[INFO] hoodie-hadoop-sparkworker-docker ................... SUCCESS [  0.060 s]
[INFO] hoodie-hadoop-sparkadhoc-docker .................... SUCCESS [  0.052 s]
[INFO] hoodie-integ-test .................................. FAILURE [  1.425 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10:15 min
[INFO] Finished at: 2019-04-08T10:03:04+08:00
[INFO] Final Memory: 241M/1151M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.dkanejs.maven.plugins:docker-compose-maven-plugin:2.0.1:up (up) on project hoodie-integ-test: Cannot run program "docker-compose": error=2, No such file or directory -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :hoodie-integ-test
I have this problem at compile time, I can't solve it

Hi,
Docker is mostly likely not installed on your machine.
See here http://hudi.apache.org/docker_demo.html.
On Mon, Apr 8, 2019 at 12:21 AM renwei111<EMAIL_ADDRESS>wrote:

[INFO] Hoodie ............................................. SUCCESS [
4.273 s]
[INFO] hoodie-common ...................................... SUCCESS [02:20
min]
[INFO] hoodie-hadoop-mr ................................... SUCCESS [01:38
min]
[INFO] hoodie-client ...................................... SUCCESS [
7.487 s]
[INFO] hoodie-hive ........................................ SUCCESS [
2.583 s]
[INFO] hoodie-spark ....................................... SUCCESS [
56.425 s]
[INFO] hoodie-utilities ................................... SUCCESS [02:20
min]
[INFO] hoodie-cli ......................................... SUCCESS [
20.190 s]
[INFO] hoodie-hadoop-mr-bundle ............................ SUCCESS [
2.590 s]
[INFO] hoodie-hive-bundle ................................. SUCCESS [
25.859 s]
[INFO] hoodie-spark-bundle ................................ SUCCESS [01:29
min]
[INFO] hoodie-presto-bundle ............................... SUCCESS [
22.659 s]
[INFO] hoodie-hadoop-docker ............................... SUCCESS [
0.816 s]
[INFO] hoodie-hadoop-base-docker .......................... SUCCESS [
0.410 s]
[INFO] hoodie-hadoop-namenode-docker ...................... SUCCESS [
0.065 s]
[INFO] hoodie-hadoop-datanode-docker ...................... SUCCESS [
0.064 s]
[INFO] hoodie-hadoop-history-docker ....................... SUCCESS [
0.069 s]
[INFO] hoodie-hadoop-hive-docker .......................... SUCCESS [
0.788 s]
[INFO] hoodie-hadoop-sparkbase-docker ..................... SUCCESS [
0.073 s]
[INFO] hoodie-hadoop-sparkmaster-docker ................... SUCCESS [
0.055 s]
[INFO] hoodie-hadoop-sparkworker-docker ................... SUCCESS [
0.060 s]
[INFO] hoodie-hadoop-sparkadhoc-docker .................... SUCCESS [
0.052 s]
[INFO] hoodie-integ-test .................................. FAILURE [
1.425 s]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 10:15 min
[INFO] Finished at: 2019-04-08T10:03:04+08:00
[INFO] Final Memory: 241M/1151M
[INFO]
[ERROR] Failed to execute goal
com.dkanejs.maven.plugins:docker-compose-maven-plugin:2.0.1:up (up) on
project hoodie-integ-test: Cannot run program "docker-compose": error=2, No
such file or directory -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn -rf :hoodie-integ-test
I have this problem at compile time, I can't solve it
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-hudi/issues/632, or mute the thread
https://github.com/notifications/unsubscribe-auth/AA27A4pUkxOnuC4SxNRxTjVJRptUpU4Sks5veu33gaJpZM4cheS4
.

@renwei111 :
The other way to skip integration test is to run
mvn clean install -DskipITs -DskipTests -Dhadoop.version=2.6.0-cdh5.7.2 -Dhive.version=1.1.0-cdh5.7.2

Hi, Docker is mostly likely not installed on your machine. See here http://hudi.apache.org/docker_demo.html.
…
On Mon, Apr 8, 2019 at 12:21 AM renwei111 @.***> wrote: [INFO] Hoodie ............................................. SUCCESS [ 4.273 s] [INFO] hoodie-common ...................................... SUCCESS [02:20 min] [INFO] hoodie-hadoop-mr ................................... SUCCESS [01:38 min] [INFO] hoodie-client ...................................... SUCCESS [ 7.487 s] [INFO] hoodie-hive ........................................ SUCCESS [ 2.583 s] [INFO] hoodie-spark ....................................... SUCCESS [ 56.425 s] [INFO] hoodie-utilities ................................... SUCCESS [02:20 min] [INFO] hoodie-cli ......................................... SUCCESS [ 20.190 s] [INFO] hoodie-hadoop-mr-bundle ............................ SUCCESS [ 2.590 s] [INFO] hoodie-hive-bundle ................................. SUCCESS [ 25.859 s] [INFO] hoodie-spark-bundle ................................ SUCCESS [01:29 min] [INFO] hoodie-presto-bundle ............................... SUCCESS [ 22.659 s] [INFO] hoodie-hadoop-docker ............................... SUCCESS [ 0.816 s] [INFO] hoodie-hadoop-base-docker .......................... SUCCESS [ 0.410 s] [INFO] hoodie-hadoop-namenode-docker ...................... SUCCESS [ 0.065 s] [INFO] hoodie-hadoop-datanode-docker ...................... SUCCESS [ 0.064 s] [INFO] hoodie-hadoop-history-docker ....................... SUCCESS [ 0.069 s] [INFO] hoodie-hadoop-hive-docker .......................... SUCCESS [ 0.788 s] [INFO] hoodie-hadoop-sparkbase-docker ..................... SUCCESS [ 0.073 s] [INFO] hoodie-hadoop-sparkmaster-docker ................... SUCCESS [ 0.055 s] [INFO] hoodie-hadoop-sparkworker-docker ................... SUCCESS [ 0.060 s] [INFO] hoodie-hadoop-sparkadhoc-docker .................... SUCCESS [ 0.052 s] [INFO] hoodie-integ-test .................................. FAILURE [ 1.425 s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 10:15 min [INFO] Finished at: 2019-04-08T10:03:04+08:00 [INFO] Final Memory: 241M/1151M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal com.dkanejs.maven.plugins:docker-compose-maven-plugin:2.0.1:up (up) on project hoodie-integ-test: Cannot run program "docker-compose": error=2, No such file or directory -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :hoodie-integ-test I have this problem at compile time, I can't solve it — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#632>, or mute the thread https://github.com/notifications/unsubscribe-auth/AA27A4pUkxOnuC4SxNRxTjVJRptUpU4Sks5veu33gaJpZM4cheS4 .

thank you,but is not ok

@renwei111 :
The other way to skip integration test is to run
mvn clean install -DskipITs -DskipTests -Dhadoop.version=2.6.0-cdh5.7.2 -Dhive.version=1.1.0-cdh5.7.2

is build ok,谢了啊


Fix initialization macros for twai_timing_config_t not setting .clk_src and .brp

.clk_src and .brp of twai_timing_config_t are not set by the TWAI_TIMING_CONFIG_* macros.
The examples declare twai_timing_config_t globally and are thus zero-initialized (eg twai_self_test).
However, the C++ compiler warns about this:
/opt/esp/idf/components/hal/include/hal/twai_types.h:78:135: warning: missing initializer for member 'twai_timing_config_t::clk_src' [-Wmissing-field-initializers]
   78 | #define TWAI_TIMING_CONFIG_25KBITS()    {.quanta_resolution_hz = 625000, .tseg_1 = 16, .tseg_2 = 8, .sjw = 3, .triple_sampling = false}
      |                                                                                ^
/opt/esp/idf/examples/peripherals/twai/twai_self_test/main/twai_self_test_example_main.cpp:41:46: note: in expansion of macro 'TWAI_TIMING_CONFIG_25KBITS'
   41 | static const twai_timing_config_t t_config = TWAI_TIMING_CONFIG_25KBITS();
      |                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/esp/idf/components/hal/include/hal/twai_types.h:78:135: warning: missing initializer for member 'twai_timing_config_t::brp' [-Wmissing-field-initializers]
   78 | #define TWAI_TIMING_CONFIG_25KBITS()    {.quanta_resolution_hz = 625000, .tseg_1 = 16, .tseg_2 = 8, .sjw = 3, .triple_sampling = false}
      |                                                                                ^
/opt/esp/idf/examples/peripherals/twai/twai_self_test/main/twai_self_test_example_main.cpp:41:46: note: in expansion of macro 'TWAI_TIMING_CONFIG_25KBITS'
   41 | static const twai_timing_config_t t_config = TWAI_TIMING_CONFIG_25KBITS();
      |                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~

, and there are potential issues if twai_timing_config_t is declared on the stack without being initialized fully.

Thanks for your contribution.

sha=a18d7e24d6efa86ced17e74867e6537e5cbe617e

Needs backport to release/v5.1.

@nebkat Hello, This fix is plain to including in v5.1.1 next month. if you are emergency to this fix, please tell me, I can give you a patch, but there will no full release test for this patch, So if you have mass produced, need consider the risk from this patch.
Although this little fix seems no any risks.

@wanckl This is just a compiler warning so not critical.
However #11331 is a regression in v5.1 - might be worth noting it somewhere until it is fixed. I have cherry-picked it already so no need for a patch for me (though perhaps others will need one).


Make subnet/security group fields optional

Checklist

[x] Appropriate branch selected (all PRs must first be merged to dev before they can be merged to master)
[x] Any modified or new methods or classes have helpful JSDoc and code is thoroughly commented
[x] The description lists all applicable issues this PR seeks to resolve
[x] The description lists any configuration setting(s) that differ from the default settings
[x] All tests and CI builds passing

Description
Re #507

Codecov Report

Merging #516 into otp-deployment-docs-update will decrease coverage by 0.08%.
The diff coverage is 11.53%.

@@                      Coverage Diff                       @@
##           otp-deployment-docs-update     #516      +/-   ##
==============================================================
- Coverage                       16.29%   16.21%   -0.09%
==============================================================
  Files                             313      313
  Lines                           15839    15735     -104
  Branches                         4846     4795      -51
==============================================================
- Hits                             2581     2551      -30
+ Misses                          11292    11261      -31
+ Partials                         1966     1923      -43

Flag
Coverage Δ

#unit_tests
16.21% <11.53%> (-0.09%)
:arrow_down:

Impacted Files
Coverage Δ

lib/common/util/permissions.js
31.81% <ø> (+2.18%)
:arrow_up:

lib/manager/util/deployment.js
61.9% <ø> (ø)
:arrow_up:

lib/types/reducers.js
0% <ø> (ø)
:arrow_up:

lib/manager/actions/user.js
13.76% <0%> (+3.44%)
:arrow_up:

lib/common/containers/WatchButton.js
32.55% <13.33%> (-4.73%)
:arrow_down:

lib/common/user/UserPermissions.js
32.25% <25%> (-6.98%)
:arrow_down:

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 3ede975...6d4bd49. Read the comment docs.

@binh-dam-ibigroup, the user mgt stuff is from another PR that was already merged into dev (I based these changes off of the dev branch instead of otp-deployment-docs-update). If you merge the latest dev into your otp-deployment-docs-update branch and push the changes, those commits should go away from this PR.
The contents of this PR in my view should just be the optional fields and the updates to the docs regarding these fields.

Should this be a merge to dev instead of otp-deployment-docs-update?

Should this be a merge to dev instead of otp-deployment-docs-update?

The documentation update goes into the docs branch for #506, I suppose?

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


Fix syntax highlighting for many code blocks

This PR cherry-picks the copyediting-relevant fixes from #1161. There are roughly four categories of changes:

One bug fix in forms.md where our example code is wrong (seems like a vim issue!)
Standardizing code blocks in accessibility.md to use the same diff rules as elsewhere in the book
In Chapter 9 we have an outline of the server despite there being no changes; I removed it
A bunch of example code blocks get syntax highlighted

Obviously the first is most important but I think all of these are worth it before Friday.

In other parts of the book, we sometimes have a "heading line" that starts with while or elif or else even if it's not the first line at its level of indentation. I agree that that's a bit weird but in other places we do that fairly freely and should probably just stick to the standard.

In other parts of the book, we sometimes have a "heading line" that starts with while or elif or else even if it's not the first line at its level of indentation. I agree that that's a bit weird but in other places we do that fairly freely and should probably just stick to the standard.

ok

Good to merge then?


During login: Uncaught (in promise) TypeError: Cannot read property 'map' of undefined

I need to pull links to IG content while the browser is minimized. If I minimize the window and reload the page, it won't load image URL's into the srcset of each div container UNTIL I bring the instagram tab back to front. This is why I want to try this library.
I used browserify to solve imports and added the following:
(function (process){
const Instagram = require('..')
const { username, password } = process.env
const client = new Instagram({ username:'username123', password: 'password123' })
console.log(client)
client
  .login()
  .then(() => {
    client
      .getProfile()
      .then(console.log)
  })
}).call(this,require('_process'))

I've added prints and it seems to get called properly as, after browserifying, adding the resulting 2.3mb file as a Chrome Snippet and running it prints:
credentials
 . . .
password
:
"password123"
username
:
"username123"

However, just after that, I get an exception:
index4:56 Uncaught (in promise) TypeError: Cannot read property 'map' of undefined
    at request.then.res (<anonymous>:56:46)

async login({ username, password } = {}) {
    username = username || this.credentials.username
    password = password || this.credentials.password

    // Get CSRFToken from cookie before login
    const { value } = await this.request('/', { resolveWithFullResponse: true })
      .then(res => res.headers['set-cookie'].map(Cookie.parse)) //THIS IS WHERE THE ERROR POINTS AT
      .then(res => res.find(cookie => cookie.key === 'csrftoken'))
      .then(res => res.toJSON())

Am I doing something wrong? Also, if you happen to know about any JavaScript object or something similar where all the image URL's get saved to, that would already solve the case for me personally. Having a browser session running isn't an issue for my project but I need to be able to pull the links to the media when the browser window is minimized.
Thanks

I'm having the exact same issue. It looks like Instagram doesn't send the CSRF header anymore. When I look into the response, I can see CSRF token is being set into an object called _sharedData, like this:
<script type="text/javascript"> window._sharedData = {"activity_counts":null,"config":{"csrf_token":"OE3Ojuq1nRZ2sMtB2zVpFXQDEepH7ZfZ","viewer":null}, ...} ... </script>

I'm having the same issue. Have you solved it?


Unable to test lazy-loaded routes due to no active match

Which project does this relate to?
Router
Describe the bug
We're encountering an issue when testing lazy-loaded routes using TanStack Router.
I've created a Stackblitz reproduction.
The test script should run automatically, but if it doesn’t, you can manually run it using npm test in the terminal.
Routes Setup:

__root: default root route with <Outlet />
/: redirects to /sub/page
/sub/_layout: a layout route with <Outlet /> for /sub with an optional redirect parameter
/sub/_layout/page: contains a link to /sub/else or redirect when present
/sub/_layout/other: identical to /sub/page but lazy-loaded
/sub/_layout/else: the default redirection target when redirect param is missing

The test suite is located in router.test.tsx (Vitest + React Testing Library).
Issue:
When running the tests, the route /sub/_layout/page passes successfully, but /sub/_layout/other fails. Runtime-wise everything seems to be fine.
Interestingly, if I convert /sub/_layout/other from a lazy-loaded route to a standard route, the issue disappears. I also tried preloading the route before rendering, but that didn’t resolve the problem.
The error message when attempting to render /sub/_layout/other is:
Invariant failed: Could not find an active match from "/sub/_layout/other"

Investigation:
I logged the output of router.routesByPath for the failing /sub/_layout/other route. When the route is lazy-loaded, I get the following (with non-essential details removed for clarity):
  '/sub/other': Route {
    options: {
      path: '/other',
      id: '/sub/_layout/other',
    },
    isRoot: false,
    originalIndex: 2,
    parentRoute: Route {
      isRoot: false,
      originalIndex: 0,
      _path: undefined,
      _id: '/sub/_layout',
      _fullPath: '/sub',
      _to: '/sub',
      _lazyPromise: [Promise]
    },
    _path: 'other',
    _id: '/sub/_layout/sub/_layout/other',
    _fullPath: '/sub/other',
    _to: '/sub/other',
    rank: 1,
    _lazyPromise: Promise { <unknown> }
  }

Notably, the value of _id is '/sub/_layout/sub/_layout/other', which seems incorrect. This might be the reason for the error: Could not find an active match from "/sub/_layout/other".
This issue seems related to https://github.com/TanStack/router/issues/2400
Your Example Website or App
https://stackblitz.com/edit/vitejs-vite-n66i22?file=src%2Froutes%2F__tests__%2Frouter.test.tsx&terminal=test
Steps to Reproduce the Bug or Issue

Open the repro on Stackblitz
Tests should run automatically in the console, otherwise run npm test
Observe how tests for /sub/_layout/other are not passing with Invariant failed: Could not find an active match from "/sub/_layout/other"
Change other.lazy.tsx to other.tsx
Run the tests again and this time they're all passing

Expected behavior
A a user I'd expect the tests to work for both standard and lazy-loaded routes but I'm seeing only standard routes tests passing.
Screenshots or Videos

Platform

OS: macOS
Browser: Arc 1.61.0 (53949) (Chromium Engine Version 129.0.6668.59)
Node: 18.20.4
TanStack Router: 1.58.9
React: 18.3.1
Vite: 5.4.6
Vitest: 2.1.1

Additional context
No response

Seems to be fixed in https://github.com/TanStack/router/pull/2490 🎉
Here's the same Stackblitz repro using v.1.64.0 - https://stackblitz.com/edit/vitejs-vite-w2fwu4?file=src%2Froutes%2F__tests__%2Frouter.test.tsx&script=test


Feedback form on uninstallation

I haven't attempted a similar task previously, I am unsure about the difficulty level involved. However, I strongly believe that receiving feedback on the uninstallation process is invaluable. It provides the most sincere feedback that can help improve the overall user experience.

as for me... I just finished my term exams 😆

I’m not sure how much control we can actually have over the uninstall process. Plus it would only be possible on windows.

Maybe open a browser window that takes to the form but that can also be considered bad at the same time. User's done love popups etc

Yea if we switch over to the WiX installer on windows we can get feedback, though otherwise there are not really hooks for any of the others.
Though some form of way of getting user feedback would be nice. If I finish the tauri port ill explore adding it to mobile and then we can interact with the app store reviews a bit if anyone downloads it or engages.

I assume most of out users are on windows, @roldanjr would be the best one to comment on that.
Though at some point it would be good to try to prompt for feedback on windows at least.
I will be publishing the app to the mac app store at some point (and hopefully mobile at some point) so we should be able to et some levels of feedback where possible.

Instead of being focused on uninstallation feedback, I think it is much better if we add a generic user feedback form link for all under settings so we can gather feedback from our users via Google Form. That way, how many users submitted their feedback with the same concern so we can prioritize better.


Path resolution into absolute paths

@PhMueller
I encountered this while working on the dragonfly branch, but we should make sure that any Path objects that we construct and that are expected to stay alive for more than a few lines of code are resolved into absolute paths as soon as they are constructed. This becomes very relevant when optimizers, which are technically black-boxes as far as the scope of this repo is concerned, do directory magic which may or may not be context-safe. Case in point, dragonfly uses file-based multi-process communication, and thus is going to be run in the /tmp directory so it doesn't cause other issues. If it is passed any relative paths from HPOlibExperimentUtils, or fails to return to the old working directory, bad things could happen.
I already did so for the output directory here: b4491c86d94cad1d2c8ad95f2aad7d6095a794d8

The onus of responsibility could be passed on to the optimizers, but I think it just makes so much more sense to resolve the paths at the first possible moment instead.


:lock: runtime attestation verification

this is just a dup of https://github.com/kairos-io/kairos/issues/1115


Fixing framework selection label

The official label of the framework selection is 'No JavaScript framework' ad not 'No JavaScript web framework'
Category

[x] Content fix
[ ] New article

What's in this Pull Request?
Content update in framework selection. It is labelled as 'No JavaScript Framework' and not 'No JavaScript web framework'

thx @StfBauer, appreciated.


UC 13: As a developer, I want to easily export/import my application with a single command

As a developer (A) , I want to be able to easily export and import my application with one command so that I can share the configuration with other people.

As a developer (B), I want to be able to take the export given to me by developer (A) and run a single command to have a environment that matches what developer (A) built. I should be able to define custom name for the application that I am importing.

NOTE: This is a stretch goal - initial work may need more refinement
NOTE: Bound to the openshift capabilities, hence not a complete use case for this tool, but rather a way to integrate into whatever capabilities are provided by the platform around import/export.

Stretch goal. Not part of MVP.

Adding the odo config values (.odo/config.yaml) to git helps achieve this for a component. Unless this is really for applications (accessed by odo app), I think that should suffice.


Evaluation for the parse tree and printing of its result

For traversal need a recursive function to evaluate the parse tree, and also for printing its result.

Above referenced commit closes this issue.


Subscriber.complete() throw TypeError if subscribe function is async

Bug Report
Current Behavior
When creating a new Observable, passing an async subscribe function to the constructor, when calling complete() on the observer, the following error is thrown:
(node:83146) UnhandledPromiseRejectionWarning: TypeError: this._parentSubscription.unsubscribe is not a function
    at Subscriber._unsubscribeParentSubscription (<redacted>/node_modules/rxjs/internal/Subscriber.js:108:38)
    at Subscriber.complete (<redacted>/node_modules/rxjs/internal/Subscriber.js:82:18)

Reproduction
The following throws a TypeError:
const delay = require('delay');
const {Observable} = require('rxjs');
const obs = new Observable(async observer => {
  observer.next('Foo');
  await delay(500);
  observer.next('Bar');
  observer.complete();
});

obs.subscribe();

However if the subscribe function is not async it works as expected:
const {Observable} = require('rxjs');
const obs = new Observable(observer => {
  observer.next('Foo');
  observer.next('Bar');
  observer.complete();
});

obs.subscribe();

When using zen-observable and an async function it also works:
const delay = require('delay');
const Observable = require('zen-observable');
const obs = new Observable(async observer => {
  observer.next('Foo');
  await delay(500);
  observer.next('Bar');
  observer.complete();
});

obs.subscribe();

Expected behavior
The Observable constructor should accept an async subscribe function, and calling observer.complete() should not throw an exception.
Environment

Runtime: Node v10.8.0
RxJS version: 6.3.0

This is not a bug, at least so far expected behavior as we do not support async subscriber in creation, dupe of https://github.com/ReactiveX/rxjs/issues/2827.
Internally we are discussing about if we'll going to support or not but it is not concluded.


Better env

Updated env spec + lockfile, pinning VTK=9.2.2
I think/hope this should fix current reliability/reproducibility problems with plots
It does not fix the warnings though.
That can probably be done with vtk.vtkObject.GlobalWarningDisplayOff()  -- we will insert that in notebooks, later.

OK, I'm happy with this now,  I think @BHFock tried the new README instructions + found them usable, and it doesn't change any of the other content much.  Plus, we can always do further changes.
So, I'm going to just merge this too, now!


Attach for APIv2

Still very early. Does handle both terminal and non-terminal attach, but does not include the Resize endpoint. TODOs litter the code. Compile-tested only, run at your own risk.

@baude I said it'd be ready before end of year. I may have exaggerated the "ready" slightly though.

Marking as WIP


wrong swiftimterfaces

ℹ Please fill out this template when filing an issue.
All lines beginning with an ℹ symbol instruct you with what info we expect. You can delete those lines once you've filled in the info.
Per our *CONTRIBUTING guidelines, we use GitHub for
bugs and feature requests, not general support. Other issues should be opened on Stack Overflow with the tag alamofire.
Please remove this line and everything above it before submitting.

[ ] I've read, understood, and done my best to follow the *CONTRIBUTING guidelines.

What did you do?
ℹ Tried building XCFramework using xcodebuild command line tool , built target for iOS and iOS-Simulator . Got both frameworks and tested them with sample code . The using '-create-framework' flag tried constructing XCFramework using both framework files. Go the XCFramework too but on using it with test code it showed an error related to wrong swift interface for 'cleanup' function in 'UploadRequest' class.
Expected that the resultant XCFramework will work just the way normal frameworks are working
ℹ Expected that the resultant XCFramework will work just the way normal frameworks are working
What happened instead?
ℹ Instead an error  an error related to wrong swift interface for 'cleanup' function in 'UploadRequest' class.
Alamofire Environment
Latest Github version
11.4
5.2
iOS Simulator
10.15

Here is the more info on stack overflow question https://stackoverflow.com/questions/61009771/method-does-not-override-any-method-from-its-superclass-alamofire?noredirect=1#comment107936416_61009771

@vdharankar Can you provide the commands used to produce the xcframework? The commands you posted on StackOverflow don't work, there's probably something missing for a clean environment.

Commands came from here https://github.com/Carthage/Carthage/issues/2799

Also You need to set the Build Libraries for Distribution option to Yes in your framework's build settings, otherwise the swift compiler doesn't generate the neccessary .swiftinterface files which are the key to future compilers being able to load your old library.

Also You need to set the Build Libraries for Distribution option to Yes in your framework's build settings, otherwise the swift compiler doesn't generate the neccessary .swiftinterface files which are the key to future compilers being able to load your old library.

this setting is 'NO' in current build.

Yes, Alamofire doesn't support library distribution.

Commands came from here [Carthage/Carthage#2799](https://github.com/Carthage/Carthage/issues/2799

Commands I have mentioned on Stackoverflow work my end

Yes, Alamofire doesn't support library distribution.

Can you explain that a bit ? do you mean old iOS style frameworks ? If yes I have created one and used it with a simple code and I found it working

Issue happens only after embedding these individual frameworks into XCFramework .

It is unsafe to manually enable library distribution for libraries which don't have it enabled, like Alamofire, as our APIs are not guaranteed to maintain binary stability, as defined by the limitations of library evolution mode. You particular issue is caused by the fact that we added an override to cleanup for UploadRequest in 5.0.5, which is apparently not a resilient change, and is one of the reasons Alamofire doesn't support library mode.

It appears that adding an override is supposed to be a resilient change, so I'm not sure what the issue is, but its certainly related to library evolution.


Ability to block specific commenters

Checklist

[x] I am running the latest version. Installing Isso from GitHub from the master branch does not fix my issue
[x] I have checked the troubleshooting guide
[x] I have searched the open issues, but my issue has not already been reported

What is not working?

I have a couple of extremely persistent spammers who have not yet realized that I moderate all my comments. It would be nice if I could make comments from specific email addresses or matching specific URL patterns just go into a black hole so that I don't have to see them ever again.
How can one reproduce this issue?

Have good enough SEO

That certainly is an annoying issue to deal with.
At the heart of the issue (IMO) is the fact that for Isso, commenters are mostly ephemeral. As of right now, Isso doesn't have much in the way of user management - https://github.com/posativ/isso/pull/261 has been open for quite some time without a resolution.
Hardcoding blocked or allowed users into the config seems kind of iffy to me as well.
@fluffy-critter do you have any ideas which would be elegant but still fit within the project's current paradigms?

I feel like a good solution in general would be to have a plugin architecture of some sort where all incoming comments can call into a function which takes all of the message data and returns a disposition, such as "delete," "post," or "hold for moderation," which could then also be a good spot to hook in a spam filter. I seem to have mentioned that idea on #11 and I still feel like it's a fundamentally good idea, and maybe now that I have some free time I can bring myself to actually work on it.

That sounds lovely!
Make sure to include the other maintainers and regular contributors into your thought process - I'm already onboard with your plugin idea, and we do have a signals architecture in place that might prove useful for it.

An alternative to a plugin system might be to have say a good Python package that uses the API to automatically moderate? That might be simpler to set up and easier to extend in the future. It also allows isso itself to stay fairly lean.


feat: add remainIfEmpty options to DockviewGroupPanel

Make this removeEmptyGroup configurable via group model, with this pr, we can keep group remain when group has no children by set group.remainIfEmpty = true.
I'm not sure this new property will cause problem or not, can you do the review? @mathuo
#402

I'm interested in trying this out. Could you possible add a sandbox to the docs package and add it to the dockview docs page

ok, I'll do it.


[feature] view manuals in gamelist view

It would be great to be able to view manuals just out of gamelist view with some button,

With some button ? No sorry. All buttons are already taken.


Trees on week 3 are really small when viewed using Firefox

Attached screenshots below
The trees in the attached screenshot are incredibly small when viewed using Mozilla Firefox, but appear to be normal when viewed using Google Chrome. Changing the height: auto; declaration in the .post-content img CSS selector to height: 15em; seems to resolve the issue for me on Firefox, while still maintaining a normal view on Chrome (I checked).

Took me a while to get around to this, but I've finally fixed it (by setting flex property directly on the divs containing these images). Thanks again for reporting it!


Simulator fix

Comment out the camera preview when using in the iOS simulator.

Sorry, duplicate of #423

I'll close this pull request since it's a duplicate.


cant create crowdsale

Thanks. I saw the video you given on signing tx. But I am always stuck at https://wizard.oracles.org/3 and metamask does not prompt signing the transaction to design.

I tried to load the step 4 by opening to create the crowdsale, but the new windows screen just hang there.

I have already logged in to metamask.
Kindly assist. Thanks

@happyse27  It may be problem with gas price https://github.com/poanetwork/token-wizard/issues/645.
In the step 3 in section "Gas price"  set checkbox "Custom" and enter value 20 or more. After that  click button "Continue" and deployment should start.

Hi, after this step it does not work and Cant go to step 5

see above. and it prompted below.
Please advise how to go to step 5 and also verify in etherscan.io thanks

Could you please provide input data? May be you have started deployment with empty decimals field. Also it is not recommended to refresh page and skipping transaction during deployment.

thanks. i restarted the whole process and got it.

And i am charged 48USD for a smart contract creation testing. Not too friendly. Putting low gas is half an hour wait at least: see below

And i am charged 48USD for a smart contract creation testing.

For testing purposes, it may be better to use one of the testnets (Rinkeby, Sokol, etc.)

Hi,
I managed to create smart contract. And sent some ethers.

Refer to below : when i retrieve smart contract this page seemed to be not retrieveable.

contributions when crowdsale is still on cant work afrer each account's first successful contribution

successful one:
https://rinkeby.etherscan.io/tx/0x043de554412d3e958345bf83f41194ec57f5f1f0b9b3313a7f54a35022972003
unsuccessful one:
https://rinkeby.etherscan.io/tx/0xfbe3bebadab7a28594311b0e56e262bdded0a8bc30b5dba6722c03ce82e6c259

i am confused, send ether to token address in crowdsale page or crowdsale address in crowdsale page (please have some tooltips. thanks)

https://wizard.oracles.org/manage/0x8AD02Fe547120f0a3610229C9960C5aA57Bdc2C7

This contract did not send back the reserved tokens for 0x692aC590417Bf0f241c5E08AC283BCB0dD83E562 10000 and 0x08D1A7B85eF5c8b01b59661F983845Dc02F634f1 20%

@happyse27

Are you sure your Metamask is unlocked and you are connected to Rinkeby? If yes, see logs in Chrome dev console.
You made contributions in a wrong way. A user can contribute only with methodID. Please read instruction how to contribute https://github.com/poanetwork/token-wizard/wiki/Investment
Please read carefully instruction above.
I don't see that you distributed reserved tokens. Please read instruction how to distribute https://github.com/poanetwork/token-wizard/wiki/Distribute-reserved-tokens

If you still have any questions, please create a new issue. 1 issue for 1 question. But I recommend you first try to find answers to any of your questions in our wiki https://github.com/poanetwork/token-wizard/wiki.


Update apt sources on installation

country-mirror may result in faster update speeds later on. (arches &id002 can probably be removed, but it has no impact on me, so I haven't tried).
autoinstall:
  version: 1
  apt:
    disable_components: []
    fallback: offline-install
    geoip: true
    mirror-selection:
      primary:
      - country-mirror
      - arches: &id001
        - amd64
        - i386
        uri: http://archive.ubuntu.com/ubuntu/
      - arches: &id002
        - s390x
        - arm64
        - armhf
        - powerpc
        - ppc64el
        - riscv64
        uri: http://ports.ubuntu.com/ubuntu-ports
    preserve_sources_list: false

Curtin uses preserve_sources_list to check if the uri may be modified in etc/apt/sources.list .

I don't think it's necessary.


Migrate lwaftr to use ctable instead of podhashmap

This PR switches the lwaftr to use ctable instead of podhashmap.  It merges in SnabbCo#879.  It does not clean up and remove podhashmap from the tree; I would like to migrate some of the perf tests at some point before doing that.
Running on snabb1 as:
sudo taskset -c 8 numactl --membind=1 ./snabb lwaftr bench -D 10 -b /dev/stdout program/lwaftr/tests/data/icmp_on_fail.conf program/lwaftr/tests/benchdata/ipv{4,6}-0550.pcap

I get no appreciable difference relative to lwaftr in maximum throughputs.

LGTM once the tests pass, nice work.


RDKit Cartridge: qmol GiST support

Somewhat related to #4442 - qmol columns cannot have GiST index added on them. As @greglandrum is making it easier to work with qmols in general, it would be great if we could accelerate them with proper indexing.
When I try to add an index I get the following error with RDKit 2021.03
ERROR: data type qmol has no default operator class for access method "gist"

I dug around yesterday and I think I found a way of adding it via rdkit.sql.in - will prepare a PR.

Fixed by #4470