Use Makie for 3D barplot

here's a dummy example:

using WGLMakie
begin
	N = 100
	δ = 0.02
	cs = repeat(1:5, N÷5)
	heights = rand(N) * 200
	meshscatter(
                                # this is needed because Makie would flatten to 2D if all Zs are the same
		Point3f.(rand(N), rand(N), 0.00001rand(N));
	  	color = cs,
		markersize = Vec3f.(δ, δ, heights),
		colormap = :Spectral_7,
		marker = Rect3f(Vec3f(0), Vec3f(1)),
	 	axis = (type = Axis3, perspectiveness = 0.5, azimuth = 2.4,
            xlabel = "ϕ", ylabel = "η", zlabel = "kt",
		    limits = (nothing, nothing, nothing, nothing, 0, 200)
		),
	    shading=false
	)
end

It should also work with GLMakie.jl, but 3D might be a bit broken with CairoMakie...

		    limits = (nothing, nothing, nothing, nothing, 0, 200) this line exists because:

https://github.com/JuliaPlots/Makie.jl/issues/2182

ok, actually doesn't look that shit when using svg:
using CairoMakie
CairoMakie.activate!(type = "SVG")
begin
	N = 100
	δ = 0.01
	cs = repeat(1:5, N÷5)
	heights = rand(N) * 200
	meshscatter(
		Point3f.(rand(N), rand(N), 0.00001rand(N));
	  	color = cs,
		markersize = Vec3f.(δ, δ, heights),
		colormap = :Spectral_7,
		marker = Rect3f(Vec3f(0), Vec3f(1)),
	 	figure = (resolution=(700,600),),
		axis = (
			type = Axis3, perspectiveness = 0.5, azimuth = 2.6, elevation=0.5,
                        xlabel = "ϕ", ylabel = "η", zlabel = "kt",
		        limits = (nothing, nothing, nothing, nothing, 0, 200)
		),
	    shading=false
	)
end

This is awesome, mate! This looks like exactly what we need. Would you like to make a pull request or should I just use your code?

Just go ahead to use it for now to clean up the dependency, we can worry about usability and beautifying it later


Incorporate service version data

Process and merge service version data. This commit is cherry picked from #155 in order to reduce the PR size.

Reviewer: @philipnrmn


Prettier config

#759
@smaranjitghose Sir, you may verify it! The main file would be .prettierrc which has settings as a json
Config file with the uniform setting added and all files HTML, CSS and JS are now formatted based on those rules.
The auto format will happen when the user will save and needs to have prettier installed as an extension on any platform.

Nice work @abhu-A-J !


RCTSwitch: Use NSSwitch instead of NSButton

Please select one of the following

[ ] I am removing an existing difference between facebook/react-native and microsoft/react-native-macos :thumbsup:
[ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos :thumbsup:
[x] I am making a fix / change for the macOS implementation of react-native
[ ] I am making a change required for Microsoft usage of react-native

Summary

When this repo was created, NSSwitch didn't exist. So for <Switch>, we used an NSButton that was a checkbox. Now, apple introduced an actual NSSwitch for macOS 10.15+, and we can use it because we just bumped our minimum support to 10.15
Changelog

[macOS] [Changed] - Switched RCTSwitch to use NSSwitch instead of NSButton
Test Plan

I'm having trouble running RNTester at the moment, but I tested my change in the FluentUI React Native test app (https://github.com/microsoft/fluentui-react-native/), and it seems to have worked well!

As an FYI, I'm waiting to merge this PR until we bump the minimum macOS to 10.15 on either master or the next stable branch we have, since that's when NSSwitch is introduced.

/azp run


Use freezegun's real_datetime if possible. Fixes #70

This avoids the Call being stored under the frozen time.

Thanks! I get very few contributions so I really appreciate this. This looks good, but it's such a small change that I don't want to release it until I can combine it with something more significant. Is that OK?

No thank you for this tool :)
The problem doesn't arise oten and when it does it's mostly confusing, not a showstopper, so I can wait.


AnimatedTexture does not automatically animate in the inspector preview

Godot version
4.1 dev2
System information
Windows 10 x64
Issue description
https://github.com/godotengine/godot/assets/2223172/69923393-14d0-41e9-9d7b-c271fa79a0f6
We could probably detect if the displayed texture is AnimatedTexture and call queue_redraw() in _process().
Relevant file is texture_editor_plugin.cpp.
Steps to reproduce

Create AnimatedTexture
Inspect it

Minimal reproduction project
https://github.com/godotengine/godot/files/10528262/AnimatedTexture.zip

I'd be happy to take a look at this one

Removing good first issue, because it turns out to be a core bug with AnimatedSprite. It affects Sprite2D, TextureRect and basically every node. The problem exists only in the editor.


Default Pinned Zowe UI Plugins

@hogstrom @armstro @1000TurquoisePogs @jplinardon @stevenhorsman-ibm @nkocsis
Could the ZLC please review and vote by EOD 9/25 - the Zowe UI now defines a JSON file which will track pinned plugins on the Zowe UI taskbar. This JSON file does not, by default, contain the explorer-server plugins, but you can still reach these plugins through the "Start" menu on the bottom left of the UI and pin them from there.
Is the new behavior described above desirable or should we add scripts to the install process which set explorer-server plugins as pinned (via modifying the new JSON)?

So, this is about  dev vs shipping, and not breaking either. It is desirable to have pinned plugins, but the list of pinned plugins should vary dependent upon purpose of the deliverable. The explorer plugins should be pinned, but I think this should be done as a packaging-time or install-time task, and here's why:
Correct me if I'm wrong, but I believe that the explorer Apps have a different dev install procedure from other Apps, which is hidden by the good install script we have in the pax we provide.
The current dev use of ZLUX is to just go into zlux-build and run build.sh / build.bat. The zlux-test-server repo has some default settings dependent upon the expected behavior that results from running zlux-build/build.sh
So, since that doesn't currently set up the explorer server, the explorer Apps are not part of that default pinned plugins list.
However:

I see no reason why a pax should respect this...  If you have a package of Zowe components, the installation procedure of them should be shipping or dynamically constructing a totally new pinned plugins list based on what is in the pax, and what the pax-makers want to be the defaults. Imagine if you had a 'zowe for graphic designers' (silly hypothetical)... you'd want to set a default to pin some graphic designing plugins, while leaving word processing and code editing plugins unpinned.

If zlux-build did also set up the explorer servers, or if devs depended upon some script that did a combination of explorer & zlux-build building, then it would be fine to put the explorers as pinned plugins in zlux-example-server

The whole 'pinned plugins' feature takes advantage of the configuration dataservice which allows product defaults, administrative defaults, and user preferences. So, what we want to do is have the appropriate product defaults which is primarily a packaging-time task.

Hey @1000TurquoisePogs - just to clarify (though it's probably me that confused), the proposal is that we add something in to the explorer install apps (the thing that created the plugins for zlux) which also add them to the pinnedPlugins.json. We aren't suggesting that the default in zlux should be changed, just raising the questions of whether we should add the explorers to it when we install them.
I hope this helps.

Whether you should be allowed to do that depends on if its for dev, or for end users.
For end users, plugins shouldn't have that authority. Plugins shouldn't by able to tell the server to pin them. Instead, product, administrator, or user settings should be the determination. So for building a pax, the set of build tools should be involved in making that pinnedPlugins.json
However, for developers, it's fine if one of the explorer repos has some dev scripts that copy/modify pinnedPlugins.json.

To clarify what's been said here for myself - I think we're in agreement on how to set default pins for the Zowe PAX. We make modifications to the pinnedPlugins.json file as part of our installation script suite within the PAX file. This avoids plugins gaining control over the pinnedPlugins directly, and keeps the base zlux pinnedPlugins.json clean.

So I am woefully behind on various emails/slack communications - please
tolerate some dumb questions as I try to catch up........there was a
request for a vote on having the explorers pinned to the desktop - did we
decide that we would add the explorers (at least for open beta)? Is a vote
needed?
Bruce Armstrong
IBM System Z Offering Manager- zowe.org
4205 S MIAMI BLVD, DURHAM NC 27703-9141
Email<EMAIL_ADDRESS>Tel:<PHONE_NUMBER>
Cell:<PHONE_NUMBER>
From:   Sean Grady<EMAIL_ADDRESS>To:     zowe/zlc<EMAIL_ADDRESS>Cc:     armstro<EMAIL_ADDRESS>Mention
<EMAIL_ADDRESS>Date:   09/24/2018 10:42 AM
Subject:        Re: [zowe/zlc] Default Pinned Zowe UI Plugins (#39)
So, this is about dev vs shipping, and not breaking either. It is
desirable to have pinned plugins, but the list of pinned plugins should
vary dependent upon purpose of the deliverable. The explorer plugins
should be pinned, but I think this should be done as a packaging-time or
install-time task, and here's why:
Correct me if I'm wrong, but I believe that the explorer Apps have a
different dev install procedure from other Apps, which is hidden by the
good install script we have in the pax we provide.
The current dev use of ZLUX is to just go into zlux-build and run build.sh
/ build.bat. The zlux-test-server repo has some default settings dependent
upon the expected behavior that results from running zlux-build/build.sh
So, since that doesn't currently set up the explorer server, the explorer
Apps are not part of that default pinned plugins list.
However:

 I see no reason why a pax should respect this... If you have a

package of Zowe components, the installation procedure of them should be
shipping or dynamically constructing a totally new pinned plugins list
based on what is in the pax, and what the pax-makers want to be the
defaults. Imagine if you had a 'zowe for graphic designers' (silly
hypothetical)... you'd want to set a default to pin some graphic designing
plugins, while leaving word processing and code editing plugins unpinned.
2.      If zlux-build did also set up the explorer servers, or if devs
depended upon some script that did a combination of explorer & zlux-build
building, then it would be fine to put the explorers as pinned plugins in
zlux-example-server
The whole 'pinned plugins' feature takes advantage of the configuration
dataservice which allows product defaults, administrative defaults, and
user preferences. So, what we want to do is have the appropriate product
defaults which is primarily a packaging-time task.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Moved here (not sure if its the correct repo, but this issue is for the Explorer team to implement.


When the program is doing a scan, there is a malfunction in the APIs

Please describe the issue or question and share your OS and Python version.

OS: x
Ubuntu
OS Version: x
22.04.2 LTS
Python Version: x
Python 3.10.12
Hello, i made a UI in react to call the apis.
When nettacker it's not scanning all the api works perfectly but when a scan is in progress the api responds almost every time "database error!" but every once in a while the api works.

this looks like a multi-threading bug. When the scan is in progress the database is busy being constantly updated with scan results


Suggestion: show which statements were already curated

Would be nice to see which statements were already curated, since it's already showing a nice icon that there are edits. Maybe use color (stoplight analogy - green for agree, red for some wrong annotations, yellow for medium badness annotations)

Source of screenshot: https://emmaa.indra.bio/all_statements/covid19/?sort_by=evidence&page=1&filter_curated=false (the EMMAA model for covid19)
In terms of style, it would look better if there were a little bit of margin around those badges too

I agree - on some of the other views, green and red are differentiated to show correct vs incorrect curations at the statement level, and there are yet other views of statements where the evidence-level pencil indicates correct or incorrect existing curations. We'll discuss how to expose those on this page as well.

I think curations are now shown in all the different views so closing this.


Retry after timeout errors

Hi,
let's say we have a chromeless function and a timeout error occurs while executing it. Is it possible to invoke the same function again on error?

I usually use this.timeout(number) to extent timeout


fix(yarn.lock): added downgrade of postcss-loader in kibbeh to yarn.lock

Instead of downgrading, maybe we could make the latest version work?

wait what was this pr for even. i had already fixed this before the pr?

The yarn.lock still had the new version. Running yarn converted it into the downgrade.

oh lol


Add PyTorch VAE

All Submissions Basics:

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked all Issues to tie the PR to a specific one?

All Submissions Cores:

[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your core changes, as applicable?
[x] Have you successfully ran tests with your changes locally?

New Model Submissions:

[x] Have you created a .py in ~/pyod/models/?
[x] Have you created a _example.py in ~/examples/?
[x] Have you created a test_.py in ~/pyod/test/?
[x] Have you lint your code locally prior to submission?

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

247 of 252 (98.02%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 93.862%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pyod/test/test_vae_torch.py
81
82
98.78%

pyod/models/vae_torch.py
166
170
97.65%

Totals

Change from base Build<PHONE_NUMBER>:
0.1%

Covered Lines:
9252

Relevant Lines:
9857

💛  - Coveralls

it appears that mac tests failed -- maybe take a look but I could also help!

torch_utility includes:

class PyODDataset, custom PyTorch dataset
class LinearBlock, includes linear layer, batch normalization, activation function, dropout layer, and linear layer weight init
func get_activation_by_name, includes 7 common activation functions
func init_weights, includes all weight initialization methods

Utility functions and classes are applied in VAE and AutoEncoder.


add caveats to private packages section

Description & motivation
After a discussion re: the use of private packages in dbt Cloud, we decided it would be best to add a few caveats to this in the documentation. Relevant slack thread is here: https://fishtownanalytics.slack.com/archives/C017GDLAF7D/p1622829542183800
Pre-release docs
Is this change related to an unreleased version of dbt?

[ ] Yes: please

update the base branch to next
add Changelog components: <Changelog>[New/Changed] in v0.x.0</Changelog>
add links to the "New and changed documentation" section of the latest Migration Guide

[X] No: please ensure the base branch is current
[ ] Unsure: we'll let you know!

@amychen1776 just changed this! Can you please take a look when you get a chance? :) Thanks for clarifying this too!


Fixed all examples + using node-style callbacks for calls to '_authenticate()'

@albertfdp A bunch of updates to keep the example apps/scripts up with the latest changes to the SDK's API. Please review and merge, if all looks good.

:+1:


Support opinionated flow for injecting containers into /usr/lib/containers

For e.g. coreos layering we've sort of inherently been focusing on the use case of e.g. rpm-ostree install usbguard inside the container.
However, there's no reason we can't support e.g.:
RUN ostree container install quay.io/example/somecontainer
ADD somecontainer.service /etc/systemd/system

And somecontainer.service would be a systemd unit that uses systemd native features to run the container, e.g. RootDirectory etc.; or runs crun/runc.
This crate is in a great position to implement this, because we're building up lots of tooling to bind ostree and containers.

That said, this heavily intersects with https://github.com/ostreedev/ostree-rs-ext/issues/69 - to do this nicely we really want the installed container layers to be "flattened" into the outer container.

This is something which would provide what I'm trying to do here
We have use cases where we need an ostree image to contain a set of containers in the form of an additionalimagestore (storage.conf) which would allow the containers to run without the need for crio to download them from the network.

We don't want the container layers to be squashed, we want a pristine copy (I guess that would help for container validation/signatures, not sure if it's 100% necessary to keep the integrity/authenticity of the layers though).

When the "sub-container" content is rolled into a a container image itself, we are inherently relying on the outer container image for signatures and such to pull.

There's actually two cases we could support; one, where the image is "lifecycle bound" with the host ostree (container).  The container images involved here are rolled into the toplevel container always.  In theory we could support live updates to these containers in the same way we can support live updates to components of host userspace, but we'd normally expect system restarts.
The second case is "preload optimization".  Here, even though there are distinct storage systems involved, assuming that e.g. /var/lib/containers is on the same physical filesystem, we can teach the two systems involved how to use reflinks (if available) to share physical storage.   In this second case, it works to podman pull quay.io/othercontainer etc.  And on further upgrade of the host system, it might pull new images for the "child containers", but these are not automatically changed in the separate/distinct /var/lib/containers.  Here, podman storage would support updates and changes as it normally does, distinct from the host.

The fact that the files being added to the ostree image are themselves related to container images is only relevant insofar as it makes it feel weird to also put those files into an RPM. If the thing being added to the filesystem wasn't already in a package of some sort, it would be natural to say "just make an RPM" (or whatever format).
Life cycling a container image with the ostree image (use case 2) would still mean we would have to package the content we want to add to the filesystem. We don't want the ostree image to consider the content of the "application image" itself, we just want it to place that application image in a specific place on the filesystem. We could do that by wrapping the application image in another image, which also feels a little odd but somehow less than using an RPM. Maybe because it's easy to imagine building and publishing a simple wrapper image using the same build pipeline and registry that are used for the application image.

The fact that the files being added to the ostree image are themselves related to container images is only relevant insofar as it makes it feel weird to also put those files into an RPM.

My understanding was these files aren't "related to" container images.  They are container images.  They're expected to be run as a container.

Yeah, that's true. I'm stumbling a bit trying to come up with a way to differentiate between a container image that should be treated as a layer of the ostree and an image that should be treated as any other file that would be added to the filesystem.

We don't want the ostree image to consider the content of the "application image" itself, we just want it to place that application image in a specific place on the filesystem.

I am not sure that makes sense.  Broadly speaking, either it is managed, or it is not.  If it is managed by ostree, it should be underneath the read-only bind mount, and we will apply transactional offline update semantics to it in the same way we do all other content.  It should not be  mutated in place by some other process (e.g. we can't support `podman --root /usr/share/containers pull myimage) because that gets into the "multiple owners" and race conditions and "source of truth" problems.
We already have a place for content not managed by ostree: /var, which is where e.g. /var/lib/containers lives.  Content there is completely orthogonal to OS upgrades in general.  Choosing the previous bootloader entry (i.e. previous ostree image) does not revert /var/log/journal or /var/lib/containers etc.
For the latter case, what may be desired here is the ability for e.g. Image Builder to inject these images into an ISO for the initial installation - distinct from the ostree updates.
I've thought about supporting this for OCP - basically we could create a Live ISO that actually had the release image preloaded too, to support even more convenient air-gapped installs.

RUN ostree container install quay.io/example/somecontainer

This would be possible but ugly - among other problems we'd have to propagate any pull secrets and such for the image to inside the container build.
What seems more elegant here is a process that operates outside of the base image, something like:
ostree container append-sub-container --root /usr/share/containers/examplecorp-agent quay.io/coreos/fedora-coreos:latest quay.io/examplecorp/agent:latest oci:exampleos

OCI containers are just layers of tarballs.  This tool would download quay.io/coreos/fedora-coreos:latest, and then for each layer in quay.io/examplecorp/agent:latest we'd parse the tarball and inject /usr/share/containers/examplecorp-agent before each path, then append those layers to the final image.
There'd be no code executed as part of this, it's just basically writing the sub-container into an alternative root in a derived container image.

Closing this for now as the focus is on the bootc side, where we now have trackers for

logically bound images
physically bound images


WebUI formatting problem

Platform: Rpi 4B 4gb
Camera: ZWO ASI 120MM
OS: Raspbian/Bullseye

As the image shows, something is definitely wrong with formatting. Not sure because I don't have much experience with webservers myself, but it doesn't allow any use of the webUI at all.

Is this the first time Allsky was installed on this Pi?  Did you reboot after the installation?

Doesn't look like php is being interpreted, There is something wrong with the lighttpd configs. If you can I would reflash the card and reinstall allsky

Is this the first time Allsky was installed on this Pi? Did you reboot after the installation?

Yes. And first time installing lighttpd as well, nothing had run previously.

@MightySpaceman, please attach ~/allsky/config/installation_logs/install.sh.log and ~/allsky/config/installation_logs/lighttpd.install.log.
After that, try reinstalling: rename the current "allsky" to "allsky-OLD" and do another "git clone" then "./install.sh".  It should save all your settings and go relatively fast.

@MightySpaceman, any update?

Closing issue - no response from user in over 4 weeks.


Update jQuery to latest v1

Everything minified as well and the obsolete query.tablesorter.widgets.min.js remove which is integrated into jquery.tablesorter.combined.min.js and hence was also not loaded anymore.
Not 100% sure where Raty is currently used, but updated to latest v2. v3 is available but removes some functions, which needs to be tested and in case adjusted first.

Seems to work just fine. Nice work.


ninja call GetFullPathNameA error The filename or extension is too long.

ninja post error when compiling chromium project:
GetFullPathNameA(gen/third_party/blink/renderer/bindings/modules/v8/v8_union_gpucanvascontext_imagebitmaprenderingcontext_offscreencanvasrenderingcontext2d_webgl2renderingcontext_webglrenderingcontext.h): The filename or extension is too long. chromium project file name is longer and longer，like v8_union_gpucanvascontext_imagebitmaprenderingcontext_offscreencanvasrenderingcontext2d_webgl2renderingcontext_webglrenderingcontext.h
includes_normalize-win32.cc:InternalGetFullPathName

Hi how did you solve this?

Hi how did you solve this?


expvar: make it possible to remove memstat and cmdline defaults

The expvar package contains an init function that registers the memstats and cmdline vars to the debug/vars http handler. The package does not provide a means to remove these defaults, forcing the consumer to deal with them. It would be nice if the user had a means to remove these defaults without resorting to unsafe or forking the package.
A benchmark I've added reveals a mild but unnecessary performance impact with the defaults (when the number of total expvar.Vars is expected to be small), but the real problem I think is aesthetic:  My other vars have nothing to do with memory usage or the command line, so the memory profile is intrusive to the application.
We also can't use memstats and  cmdline as named for our own purposes. This does not impact me personally.
goos: windows
goarch: amd64
pkg: expvar
BenchmarkExpvarHandler/cmdline.memstats-8               200000          7219 ns/op
BenchmarkExpvarHandler/none-8                            5000000           278 ns/op
BenchmarkExpvarHandler/user.10.vars-8                     300000          5130 ns/op
PASS
ok      expvar    4.822s

func BenchmarkExpvarHandler(b *testing.B) {
    for _, tc := range []struct {
        Name string
        Init func()
    }{
        {"cmdline.memstats", func() {}},
        {"none", func() { RemoveAll() }},
        {"user.10.vars", func() { for i := 0; i < 10; i++ { NewInt(fmt.Sprintf("i%d", i)) } }},
    } {
        tc.Init()
        b.Run(tc.Name, func(b *testing.B) {
            for n := 0; n < b.N; n++ {
                expvarHandler(writer{}, nil)
            }
        })
    }
}

type writer http.Header
func (w writer) WriteHeader(_ int)           {}
func (w writer) Write(p []byte) (int, error) { return len(p), nil }
func (w writer) Header() http.Header         { return http.Header(w) }

Interestingly, the package tests contain an unexported RemoveAll function. The recently-closed issue #27555 discusses it in detail, but does not mention the potential use for removing the default vars.

/cc @bradfitz

While this issue is still open, changelog 200319 is marked abandoned and I cannot see any explanation either here or on https://golang.org/cl/200319 and PR #34832 was closed.
Was it just abandoned as outdated, or actually rejected ? That tiny patch moving RemoveAll from test to main code solves the automatic publishing of cmdline and memstats and provides a more general solution to reset the expvar configuration. Is there anything I can do to make this issue/CL live again ?

The change was closed because it was old.  That was a mistake that should not have happened.  Once the change was closed, the GitHub pull request was closed, and the GitHub repo was deleted.  So you, or somebody, would have to recreate the change from the data that is still in Gerrit.  Sorry about that.
That said, the change introduces new API, and our usual process for that is a proposal, as outlined at https://go.dev/s/proposal-process.  We can open a new issue, or change this issue into a proposal for the change, as you prefer.

I have found this, calling this handler instead of expvar.Handler()
func customVarHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json; charset=utf-8")

    first := true
    w.Write([]byte("{"))

    expvar.Do(func(kv expvar.KeyValue) {
        if kv.Key == "memstats" || kv.Key == "cmdline" {
            return // Skip memstats and cmdline
        }

        if !first {
            w.Write([]byte(","))
        }
        first = false

        b, _ := json.Marshal(kv.Key)
        w.Write(b)
        w.Write([]byte(":"))
        w.Write([]byte(kv.Value.String()))
    })

    w.Write([]byte("}"))
}


Finish design.md documents

Our approach with the design.md document was to think about higher-level questions before focusing of specific questions we would ask on the survey. Once we made progress on this, we decided to shift gears towards the survey questions themselves. Now that we've made more progress on the actual survey questions, we should return to the design documents and make sure our reasoning for how we designed the survey are properly captured.

The approach we adopted in the last 2 or 3 iterations of the survey is to start from the previous year's dataset of questions and change/tune things. A design document is probably not needed anymore.


Sensor - File

Home Assistant release with the issue:

Last working Home Assistant release (if known):
0.66.1
Operating environment (Hass.io/Docker/Windows/etc.):

Raspberry Pi 3, Hassbian
Component/platform:

sensor:
  - platform: file
    file_path: /opt/bashstat/setpoint
    name: Heat Setpoint
    unit_of_measurement: "F"
    scan_interval: 60

(homeassistant) homeassistant@HomeAssistant:~/.homeassistant $ cat /opt/bashstat/setpoint
72

Description of problem:
I have a "sensor" that reads a text "file" with just a temperature setting (ie: 72.)  It is just a two number text file.  Up until version 0.66.1 it displays correctly.  Upgrading to 0.67.0 or above will not show with sensor.  The same configuration.yaml file is used.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

The sensor works fine on dev.
[...]  whitelist_external_dirs:
    - /home/test/.homeassistant/
[...]
sensor:
  - platform: file
    file_path: /home/test/.homeassistant/sensor-data.txt

The documentation clearly mention that whilelist_external_dirs: is required.


[Backend] Route for getting admins list

We need a get route for getting a list of admins.
It will not be an open API
It should have pagination.
Route path is /admin
API Testing is required!
Refer to #81 for a brief overview of our API Testing procedure

I would like to work on this.
Please assign this to me.

I would like to work on this.
Please assign this to me.

Sure go ahead. Make sure you follow the structure of our codebase.

Sure go ahead. Make sure you follow the structure of our codebase.

Thanks, yes I will.

Thanks, yes I will.

localhost:3500/admin/admin-list route is now giving this list on POSTMAN.
I wasn't able to find predefined tests, please guide me.

Note: In database some admins didn't insert their names so it returned null. Hence list of emails is being returned as this is inserted by each admin

localhost:3500/admin/admin-list route is now giving this list on POSTMAN.
I wasn't able to find predefined tests, please guide me.

Note: In database some admins didn't insert their names so it returned null. Hence list of emails is being returned as this is inserted by each admin

Please change the route to /admin
The list seems fine, since it's in dev mode it is completely fine that the names are null.
Please add a query parameter superAdmin which if is true get only superadmins. If false get only admins. If nothing is provided get all. Something like this.

Please change the route to /admin
The list seems fine, since it's in dev mode it is completely fine that the names are null.
Please add a query parameter superAdmin which if is true get only superadmins. If false get only admins. If nothing is provided get all. Something like this.


➖ create collection notification

close #8082

ok, no notification was showed during loading, only at the end


Clean New Log File Configuration VI

[x] This contribution adheres to CONTRIBUTING.md.

TODO: Check the above box with an 'x' indicating you've read and followed CONTRIBUTING.md.
What does this Pull Request accomplish?
Change the New Log File Configuration VI into a sequencer that is easier to read and complies with the diagram size requirement from Systems R&D
Why should this Pull Request be merged?
I did this cleanup while doing the INI config feature. However, I realized this was a major change, and a potential risk to have in one PR. Therefore, I am submitting in a separate one.
What testing has been done?
Manual testing.

Enum to Array of Enums.vim is included in the PR because  it was introduced to vi.lib until 2020, so we need to have the file in the repo for backwards compatibility.

I would argue that this change makes the diagram more difficult to read. By hiding the sequence ordering in an enum constant, I can't easily trace the execution ordering.
This also makes me have to scroll through several cases in order to see what's happening. This could more simply be improved by creating subVIs for each of these cases, since this sequence only needs to execute once. I think this change is unnecessary and recommend leaving the existing code as is.

You have good points. I can explain my rationale, an both of you can decide if you want to complete or abandon/cancel the PR. (It doesn't impact our project, so we don't have a strong feeling about it).
Regarding the enum:

Sequencers are a common LabVIEW pattern, and (as explained in the PR) the VIM that we're using to create the sequencer is now shipping in vi.lib as of 2020.
The enum array will always follow the steps in the enum, in the order in which they are in the enum. I presume we can solve this confusion, or clarify further, with a comment to that VI or the case structure itself.

Regarding scrolling horizontally instead of through case structures:

Tip: you can press the control key and use the mouse wheel to scroll through the cases of the structure. It's way easier than moving horizontally from my point of view
Large block diagrams generally are something we prefer to avoid because it makes it difficult to follow the dataflow for wires that cross all over the diagram. It also blends all the functionality into the "train tracks" that requires more time for someone arriving to the code to understand what is going on. The case structure helps explain what each phase of the sequence is doing.
I agree we could encapsulate the functionality of each step in a subVI (and G code purists would argue that the enum itself should be a Type Def. However, I went against those because I did not see a need to pollute the library with more files than those required, especially for functionality that is just breaking down code and not intended for code reuse.

@debryant do you have any thoughts?

We're moving forward with a 20.5 release from the current branch build. Given the lack of desire from our tech leads to merge this PR, I'm going to close it for now. We can revisit any refactor to this VI if it is modified at a later time.


!playgame && SortingMethod

Added command !playgame <appid> to forced farming of a specified <appid>
Added SortingMethod parameter to sort games for farming
It is possible to sort games by:

avg_prices - sort games by avg prices of cards in descending;
cards_asc - sort games by the number of cards in ascending;
cards_desc - sort games by the number of cards in descending;
none - do not sort games.

<SortingMethod type="string" value="none"/>

Uh, !play is already implemented, and that sorting mechanism looks both awful and without any practical usage. The only thing I can notice that has some logic is avg_prices, but it requires enhanced steam component and I do not want to base on third-party features.

Sorry, I missed that "!play" is already implemented. I will try to make sorting by avg_price without third-party services.

I'm not sure if it's even needed, do not waste your time. I mean, we really shouldn't sort that list or anything, it's supposed to just work, I think we're adding too many fancy things that are not needed by majority of people. Cards price changes all the time, and we need to actually waste time on asking either third-party service or checking all on our own, I'd say this feature is really not needed.

Don't get me wrong, I like the fact that people are contributing to ASF, but I just miss practical usage of that. Of course, you can say that some people might want to farm cards according to their price, but do we really need to complicate whole thing for that? If it was easy, I'd most likely implement it myself, but it's not, and requires either very giant implementation or third-party service, which both should be avoided as long as it's possible.
I'm open for discussion and all propositions though.

Too bad that majority of users are not very active. We can't just make a poll and get statistics, do they really need this or not. I can say that I don't care about sorting, but that does not mean that no-one care, because sorting by cards price sounds like something reasonable.

Yeah, and that's why we should follow our own common sense. The idea is not bad, I just can't find practical usage of it when ASF is supposed to farm everything sooner or later anyway. Sorting by price does not improve performance, in fact, it decreases it because of a need for at least one additional request to third-party service, or bunch of them to Steam, and that's why I'd avoid that if possible.
I don't know yet, maybe I'll rewrite it and indeed decide that sorting might be useful, I mean it's optional, right? The idea is good.

Sorting by price is useful to maximize profits, because cards tends to become cheaper over time. Also, if it's a sale - someone can be in hurry to make money while offer is still valid. The question is -  whether it is worth the efforts.


escape spaces as they are also reserved

lanetix/issues#3582
This will result in a breaking change, so major will be bumped.

@lanetix/engineers

:+1:

Is there a way for this behavior to be optional? I don't see the point in escaping spaces.

Currently I'm doing this:
esSanitize("big brown fox").replace(new RegExp('\ ', 'g'), " ");

which is kind of silly.


Add ETTrace

Thanks for your contribution! This is a template that can make it easier when submitting your contribution:
Your Project: ETTrace
Project URL: _https://github.com/EmergeTools/ETTrace_
Category: Testing
Description: Locally measure performance of your app, without Xcode or Instruments.
Inclusion requirements:

[X] Has 50 GitHub stargazers or more
[X] Only one project/change is in this pull request
[X] Isn't an archived project
[X] Has more than one contributor
[X] Has unit tests, integration tests or UI tests
[X] Addition in alphabetical order (bottom of category)
[X] Supports iOS 12 / tvOS 10 or later
[X] Supports Swift 4 or later
[X] Has a commit from less than 2 years ago
[X] Has a clear README in English

:heart: Awesome iOS Contributors

@jshchnz Thanks for contributing!


Handle cases where DataTransfer has a null +files+ slot

On firefox, the +files+ property on the DataTransfer object is
intentionally left null from dragover and dragenter events.
Relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=640534
Since this isn't likely to be fixed by mozilla, the files function should
account for the possibility of a null.

Thanks for addressing this. Elsewhere we use Nullable rather than Maybe to handle this kind of thing in the API though, so would you mind using that here as well? You don't have to do anything in the JS for Nullable, you can just use it the result type.

Sure thing. I didn't notice that.

I think this is ready now


Add type hinting to context

What is the context of this PR?
Type hinting has been added to the eq-questionaire-runner/app/views/context folder
How to review

Smoke test the existing functionality.

Checklist
Trello

 Add type hints to the Views/Contexts module (3 SP)

 Add type hints to the Views/Contexts module (3 SP)

We should review our use of Mapping/dictfor return type. We should also update our type hinting as although mapping is generic, it should be used for return types where mutation isn't allowed.


re-order CI, add comments and check reqts.txt generation

This PR:

re-orders the CI in order of execution time

pylint takes much longer than the documentation build, so I've moved it to the end. This will cause the CI pipelines to fail quicker (if ∃ a failure)

adds comments to CI script steps
adds a check to ensure that requirements-dev.txt matches environment.yml

Need to remove Python 3.6 specific f strings 🤦🏼♂

Need to remove Python 3.6 specific f strings 🤦🏼♂

Codecov Report

Merging #151 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #151   +/-   ##
=======================================
  Coverage   95.92%   95.92%
=======================================
  Files           8        8
  Lines         442      442
=======================================
  Hits          424      424
  Misses         18       18

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 df364f1...8b40b48. Read the comment docs.


[BUG] Small gap between bars even with barPercentage and categoryPercentage set to 1

EDIT: As it turns out, this has already been reported.

Here's a link to a minimal example showing the rendering bug. Here's what it looks like for me:

Chart.js version: 2.7.2
Browser name and version: Chrome 68.0.3440.106 (Official Build) (64-bit)

This problem has been reported before here, and there was a fix, but the problem seems to be there still.
Setting barPercentage to 1.2 (or whatever) seems to be a good temporary work-around (example).

Ok. Closing as duplicate of https://github.com/chartjs/Chart.js/issues/3964 then


doc: add tp-lib stage 1 proposal

Thanks for the proposal! I just had a quick glance at some of the point.
Regarding the licenses, it may be interesting to run a check as described here.
You mentioned a custom license. This however seems to be quite problematic and not Open Source. For example:

The software may collect information about you and your use of the software, and send that to Microsoft.

You may not: work around any technical limitations in the software; ...; share, publish, rent, or lease the software, or provide the software as a stand-alone offering for others to use.

Regarding the licenses, it may be interesting to run a check as described here.

Thanks, I will do this

You mentioned a custom license. This however seems to be quite problematic and not Open Source.

I think we'll be able to remove this package (and some of the others). We just need to spend some more time on it. But thanks for the remark, now I know we really have to find a way to remove it

We have been able to remove the dependency with the problematic custom license.

Regarding the licenses, it may be interesting to run a check as described here.

We performed the check and the result is this list of licenses:

Apache-2.0
BSD-3-Clause
MIT
PostgreSQL (we are looking at removing this dependency as well)

We've also run the vulnerability check and will fix the sole issue that came out of this.

Great, thanks! All licenses compatible with Apache-2.0 in the way that you could use Apache-2.0 as an outbound license. So also in respect of patent protections, I'd recommend Apache-2.0 as a license for the project.


docs: add missing uneditable-rule

Moreover fix formatting for consistency.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Superseded by https://github.com/grafana/dashboard-linter/pull/195


File reader

This facility adds a type-safe system to browse directories, sub-directories, and read files as lists of records.
Suppose I am in a directory that has a sub-directory data, which has a sub-directory scott, which has files bonus.csv, dept.csv, emp.csv.gz, salgrade.csv:
$ ls -lR data
data:
total 4
drwxrwxr-x 2 jhyde jhyde 4096 Dec  9 13:04 scott

data/scott:
total 20
-rw-rw-r-- 1 jhyde jhyde  50 Dec  9 13:02 bonus.csv
-rw-rw-r-- 1 jhyde jhyde 130 Dec  9 13:00 dept.csv
-rw-rw-r-- 1 jhyde jhyde 420 Dec  9 13:00 emp.csv.gz
-rw-rw-r-- 1 jhyde jhyde 127 Dec  9 13:03 salgrade.csv

I can access these from Morel using the file object. For example, here is the contents of the file data/scott/dept.csv:
./morel
$ file.data.scott.dept;
val it =
  [{deptno=10,dname="ACCOUNTING",loc="NEW YORK"},
   {deptno=20,dname="RESEARCH",loc="DALLAS"},
   {deptno=30,dname="SALES",loc="CHICAGO"},
   {deptno=40,dname="OPERATIONS",loc="BOSTON"}]
  : {deptno:int, dname:string, loc:string} list

Each file is a list of records (obtained by parsing the CSV format); each directory is a record, and its fields are its constituent files and sub-directories. Here is the directory data/scott:
$ file.data.scott;
val it =
  {bonus=<relation>,dept=<relation>,emp=<relation>,salgrade=<relation>}
  : {bonus:{comm:real, ename:string, job:string, sal:real} list,
    dept:{deptno:int, dname:string, loc:string} list,
    emp:{comm:real, deptno:int, empno:int, ename:string, hiredate:string,
      job:string, mgr:int, sal:real} list,
    salgrade:{grade:int, hisal:real, losal:real} list}

In addition, a directory has special fields .., ~, and /, which take you to the parent directory, user's home directory, and root directory. For example, file.data.`..`.data.scott is equivalent to file.data.scott.
The file value is the starting point for all navigation. It represents the current working directory.
Since Morel is a strongly-typed system, there is a problem that is most noticeable when browsing a large file system: we have traverse every directory, and parse every file, in order to report the type of the file value. We solve this by introducing a new type, called partial records. They work as follows.
When you first ask for the type of file, it reports a partial record:
$ file;
val it = {...}: {...}

Fields of a partial record are progressively discovered, on demand. When you have browsed into the data sub-directory, it has learned of a new field:
$ file.data;
val it = {...}: {...}
$ file;
val it =
  {data={...}, ...}
  : {data: {...}, ...}

When we have asked for the type of dept, we know yet more about file and file.data:
$ file.data.scott.dept;
val it =
  [{deptno=10,dname="ACCOUNTING",loc="NEW YORK"},
   {deptno=20,dname="RESEARCH",loc="DALLAS"},
   {deptno=30,dname="SALES",loc="CHICAGO"},
   {deptno=40,dname="OPERATIONS",loc="BOSTON"}]
  : {deptno:int, dname:string, loc:string} list
$ file;
val it =
  {data={scott={dept=<relation>, ...}, ...}
  : {data: {scott: {dept: {deptno:int, dname:string, loc:string} list, ...}, ...}

The knowledge of a type increases over time, as fields are discovered, but never decreases. The type system never forgets a field it has seen once.

I posted a demo: https://www.youtube.com/watch?v=uybUjCYsBKI

I posted a demo: https://www.youtube.com/watch?v=uybUjCYsBKI


Update navigation prompt screenshot

Summary

Update navigation prompt screenshot

What changed that requires the screenshot update?
I think there is a little line at the end of the new screenshot. Why is that there?

Closed PR in favor of: https://github.com/cerner/terra-framework/pull/1146


add support for own ids (coalescing)

This is the use case:
When job queue contains million of messages sent to the same worker(Job name), I want that messages containing the SAME data to be processed only once.
So it should depend on the client to assign the same ID on the messages that contains the same data.
On Gearman, the pair of JobName - JobID is unique.
http://gearman.org/protocol/
The unique ID can be used by the server to reduce queue length. If a
job with the same Unique ID has already been submitted, the server
may attach this request to the already existing job. This includes
jobs already in progress, in which case non-background jobs will be
sent the same result as background jobs. This is known commonly as
"coalescing".

@mikespook  can you please take a look at this pr ?

Thanks. I will take a look next week. Having an on-site job this week.
Cheers
On Wed, 11 May 2022 at 09:58, Gavrila Florin @.***>
wrote:

@mikespook https://github.com/mikespook can you please take a look at
this pr ?
—
Reply to this email directly, view it on GitHub
https://github.com/mikespook/gearman-go/pull/96#issuecomment-1122925698,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFE3HXOZ3ZGG6UCPWEOROLVJLLZ7ANCNFSM5VAC73XA
.

They drink coffee at dawn, beer after work.
And those who stay clean, just appreciate things.
At breakfast, they have milk and juice at night.
There are those who do both, they drink tea.”
― Gary Snyder


Make -f Flag to Push Optional

Treat all non-named arguments at the end of the command line as file
parameters.

Will this change allow for multiple -n args?

It doesn't affect the use of -n.
force push -t ApexClass -n Class1 -n Class2 still works.
It makes these equivalent:

force push src/classes/Class1.cls src/classes/Class2.cls
force push -f src/classes/Class1.cls -f src/classes/Class2.cls

As I thought, just couldn't test it out just now.
Dave Carroll
On Dec 2, 2015, at 10:10 AM, Christian G. Warden<EMAIL_ADDRESS>wrote:
It doesn't affect the use of -n.
force push -t ApexClass -n Class1 -n Class2 still works.
It makes these equivalent:

force push src/classes/Class1.cls src/classes/Class2.cls
force push -f src/classes/Class1.cls -f src/classes/Class2.cls

—
Reply to this email directly or view it on GitHub
https://github.com/heroku/force/pull/222#issuecomment-161147333.


Material Dialog not able to emit event to parent when this.dialogRef.close() getting called from inside asynchronus block.

I have asked a question on stackoverflow:
https://stackoverflow.com/questions/56672025/angular-material-modal-dialog-not-able-to-pass-event-to-parent
can any one please help me on this.
I have a component which has one child component. Child component has a button which will open a material dialog Box.
In dialog we have form, username and passwrod and submit button. When I submit i am calling backend REST api.
this is getting called in child component:
dialogRef.afterClosed().subscribe(result => {
      console.log("result", result);
      this.onModalClosePassData.emit(result);//emit to parent
    });

which is sending event to parent. updateComment() is getting called and I can see the data in console.
But when I fill the form and click on submit. It calls submitForm method	which is asynchronus call and I am closing dialog after successful login.But then event is not emmiting. updateComment() is not getting called.
See the full code:
parent component.html

<ng-template #showTextOnly>
        <child-component [branch]="releaseBranch" [date]="dateString"
                  (onModalClosePassData)="updateComment($event)">
        </child-component>
</ng-template>

parent component.ts

//This method is getting called when i click on backDrop,

but If i logged in successfully this is not getting called
updateComment(event:any){     		consile.log(event);     }
child-component.html
<button class="btn btn-default" (click)="openDialog()">Login</button>

child-component.ts

export class ChildComponent implements OnInit {
	@Output() onModalClosePassData = new EventEmitter();
	constructor(public dialog: MatDialog) { }
	openDialog(): void {
    const dialogConfig = new MatDialogConfig();
    dialogConfig.disableClose = false;
    dialogConfig.autoFocus = false;
    dialogConfig.hasBackdrop= true;
    dialogConfig.autoFocus=true;
    const dialogRef = this.dialog.open(LoginDialog, dialogConfig);

    dialogRef.afterClosed().subscribe(result => {
      console.log("result", result); //result is getting called in both cases
      this.onModalClosePassData.emit(result);
    });
 }
}

LoginDialog.component.ts

import {MatDialogRef, MAT_DIALOG_DATA} from '@angular/material/dialog';
export class LoginDialog implements OnInit{
	constructor(private loginService: LoginService, public dialogRef: MatDialogRef<LoginDialog>,
      @Inject(MAT_DIALOG_DATA) public data: any) {}
	  public submitForm = (formValue: any) => {
      if (this.noteForm.valid) {
        this.loginService.login(formValue)
         .subscribe((response:any)=>{
             if(response.STATUS === "PASS")
              this.dialogRef.close(response);
             }
        })
      }
    }
}
LoginDialog.component.html

<form [formGroup]="noteForm" autocomplete="off" novalidate (ngSubmit)="submitForm(noteForm.value)">
.
.
</form>

Expected
when I successfully login. child component should emit event and pass the response and should call the UpdateComment() method

Please provide a link to StackBlitz so we can see what is happening. Otherwise it's a lot of work to get it set up the same way you implemented

Closing as no reproduction has been provided. Feel free to send a new issue w/ StackBlitz if you want us to have a look. Thanks!


Plans to ENC1 re-route.

Hello.
Thanks for your time.
Have you any intentions to re-route encoder a bit?
Is it possible to use GP7 and GP8 for A and B pins?

Hi. Thanks for taking a look!
The encoder is on the opposite side of the mcu, and sides are connected using rj45, meaning there are only 8 wires available.
I need 7 of these for the matrix(18 + 1 switches) so the encoder can’t really have 2 pins for itself…
If you check my qmk fork, I have it working fine the way it’s wired now

Oh, you're right.
Sorry.
So tricky approach.


Spyder won't start because of "ValueError: unknown locale: UTF-8" in macOS

##I cannot get my spyder app running.
I installed IRAF yesterday and ever since spyder won't start when I type the command in the terminal.
##Here's a screenshot of what i get:

For now, please follow this advice:
http://pythonhosted.org/spyder/installation.html#id3
We'll fix this error for good in Spyder 3.1 :-)

@malliwi88, this one is easy. Please add a try/except here:
https://github.com/spyder-ide/spyder/blob/master/spyder/config/base.py#L268
and make locale_language = DEFAULT_LANGUAGE in the except part.


Fix View button on Eligibility Table

If a user clicks the View button in the Eligibility table right now they are taken back to the top of the page, this should not happen.

 Fix View button on Eligibility Table #695


How to use the Routing and mustaches at the same time?

If you use Routing:
Routing.Handler.registerGlobally()
Routing.Routes["GET", ["/", "index.html"] ] = { (_:WebResponse) in return IndexHandler() }

mustache not working.
If you use Mustache (PageHandlerRegistry):
PageHandlerRegistry.addPageHandler("LoginHandler") {
		(r:WebResponse) -> PageHandler in
		return LoginHandler()
}

routing (Routing.Routes) not working!

@nsleader I'm not sure why you would do that?
Mustache is a physical file, much like a .html file. It is copied to the webroot and calls it's handler class through the addPageHandler method when it accessed. Adding a route would override that behavior and serve whatever is in the IndexHandler class instead of the template.
Perhaps you could give us an example of what you might be trying to accomplish and/or more code?

@rymcol
Example: https://github.com/nsleader/perfect-routing
The basic idea is to use a mustache templates and routes for API

It was difficult to use both systems in the 1.0 API. This has been rectified for the new upcoming version. Take a look at the code for Upload Enumerator. It shows using routes and Mustache at the same time by passing the request to the mustacheRequest function. UploadHandler.swift.

@kjessup
PerfectLib 1.0 does not allow it?
Thank you.

It does permit this, but it is a bit more cumbersome compared to the master (1.1) branch. Look at the PerfectLibTests.swift : testMustacheParser1 test. It shows feeding the bytes, which would be read from the mustache file, into the template and getting the resulting string.
Here's a gist showing how it works, given an existing index.mustache Example
This has all been streamlined in the new code do to exactly what you are asking for, FWIW.


Rust version

Can you clarify the rust version needed? Tried to compile it worked with 1.56.0 but not 1.55.0.
Is that correct?

Yes, the minimum is going to be 1.56.0 because some of the dependencies of siwe-rs use Rust edition 2021 and 1.56.0 is the earliest compiler that supports it. I've added information in PR #13 to the README to reflect this.


Error: Cannot find module './foreignNames.json'

I've also encountered this error:
Error: Cannot find module './foreignNames.json' from '/node_modules/sanitize-html/dist'

This is the culprit from an htmlparser2 dependency making its way into the minified scripts: https://github.com/cheeriojs/dom-serializer/blob/master/index.js#L11

I've stumbled this error too, any new Update about this??

Any Info about this ?

I think folks are aware, but we don't use typescript in-house and don't
have any expertise with it, so we depend on the community to contribute
typescript bindings for this module.
On Tue, Mar 24, 2020 at 12:08 PM Bjoern Sellnau<EMAIL_ADDRESS>wrote:

Any Info about this ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/apostrophecms/sanitize-html/issues/335#issuecomment-603334047,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAH27ILUADSP7ZAXNB2743RJDLF5ANCNFSM4K5CK3MQ
.

--
THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER
APOSTROPHECMS | apostrophecms.com | he/him/his

I'm not sure what this has to do with TS. This is breaking for me as well, on a project that doesn't use TS at all (https://git.pixie.town/neo/neo, use npm install, not yarn).
The issue is not present in 1.20.1 (which is in the yarn.lock), but it exists in 1.23.0, and I suspect that there's something going wrong in the dist build that occurs before publishing this module to the registry, which appears to vendor in dependencies using a bundler for some reason.

I haven't been able to reproduce this, please see my tiny test project:
https://github.com/boutell/sanitize-html-test-project
That's just a straight npm install of sanitize-html, working as expected.
What am I missing?

@boutell Oops, apologies, I wrote my message a little too hastily. To clarify: the error occurs only once trying to run a gulp build, not directly after installation. My guess is that it's happening somewhere within Browserify's bundling process, since sanitize-html is used in browser-side code there.

OK. So that would not be an issue with the module itself?
On Mon, May 4, 2020 at 9:54 AM Sven Slootweg<EMAIL_ADDRESS>wrote:

@boutell https://github.com/boutell Oops, apologies, I wrote my message
a little too hastily. To clarify: the error occurs only once trying to run
a gulp build, not directly after installation. My guess is that it's
happening somewhere within Browserify's bundling process, since
sanitize-html is used in browser-side code there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apostrophecms/sanitize-html/issues/335#issuecomment-623478376,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAH27PRER7VEPS6OZS6LSTRP3CKHANCNFSM4K5CK3MQ
.

--
THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER
APOSTROPHECMS | apostrophecms.com | he/him/his

It likely would be; everything else bundles just fine, and even earlier versions of sanitize-html bundle fine, it's just the more recent versions where something has changed such that it fails to build. I suspect that the failure is the result of something that happens during sanitize-html's own pre-release bundling process, with it producing invalid output of some kind.
It's reproducible with a stand-alone build of just sanitize-html, too:

1.20.1, working<EMAIL_ADDRESS>latest, not working: https://wzrd.in/standalone/sanitize-html@latest

OK, but then my test application should fail, right?
I think I'm saying that we need a test application similar to mine, but
different in the way that reveals the problem.
On Mon, May 4, 2020 at 12:08 PM Sven Slootweg<EMAIL_ADDRESS>wrote:

It likely would be; everything else bundles just fine, and even earlier
versions of sanitize-html bundle fine, it's just the more recent versions
where something has changed such that it fails to build. I suspect that
the failure is the result of something that happens during sanitize-html's
own pre-release bundling process, with it producing invalid output of
some kind.
It's reproducible with a stand-alone build of just sanitize-html, too:

1.20.1, working<EMAIL_ADDRESS>latest, not working: https://wzrd.in/standalone/sanitize-html@latest

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apostrophecms/sanitize-html/issues/335#issuecomment-623556160,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAH27JP77TGGCCT3XCEW7DRP3R73ANCNFSM4K5CK3MQ
.

--
THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER
APOSTROPHECMS | apostrophecms.com | he/him/his

OK, but then my test application should fail, right?

No, because your test application doesn't use Browserify.

I think I'm saying that we need a test application similar to mine, but different in the way that reveals the problem.

That's why I linked the wzrd.in builds; those basically just run a standalone Browserify build with nothing else. This can be reproduced in your test repository by doing:
yarn add --dev browserify
./node_modules/.bin/browserify ./test.js

(Or npm instead of Yarn, shouldn't matter.)

Yes, I can confirm that.
This code is actually output from browserify. In the context of that code "require" probably really maps to some kind of wrapper function, but maybe when you try to run the same code through browserify again it mistakenly tries to resolve it anew, like a "require" call that has never been kissed by browserify, and doesn't find that file on disk.
I'm not honestly sure what to do about that. I had thought we could have a single "main" containing the output from browserify, which was tidy because if it worked server side it would work browser side, no more fuss. But, here we are.

I just did a quick test, bundling some sample code with Browserify and then requireing the resulting bundle and Browserifying that code, and it worked fine (testcase repository here). So it seems that double-Browserifying works, and the issue is more specific than that.
Aside from that, I'm not sure why things are published bundled in the first place. It effectively vendors dependencies, which is a problem from a security perspective if transitive dependencies get a security update (since you'll still be using the vendored bundle as it was at release time, without those updates).
It can make sense to include a standalone build in a release to allow direct usage from a browser as well, if that's a case you want to support with the above caveats - but I don't think that that should be the main of the package, for those same reasons.
And putting on my dependency auditor hat for a moment, such browser builds should probably be distributed separately (at least in a separate package, eg. sanitize-html-prebuilt) so that module users don't need to audit bundled/vendored code, which is a pain :)

It does sound like main ought to be index.js and the documentation should
recommend something like:
require('sanitize-html/es5.js')
To access the prebuilt bundle. I think that would be satisfactory because
if you're using browserify (or webpack, or...) yourself, you don't need the
prebuilt bundle. You're building your own.
...
Right???

On Mon, May 4, 2020 at 6:40 PM Sven Slootweg<EMAIL_ADDRESS>wrote:

I just did a quick test, bundling some sample code with Browserify and
then requireing the resulting bundle and Browserifying that code, and
it worked fine (testcase repository here
https://git.cryto.net/joepie91/test-double-browserify). So it seems
that double-Browserifying works, and the issue is more specific than that.
Aside from that, I'm not sure why things are published bundled in the
first place. It effectively vendors dependencies, which is a problem from a
security perspective if transitive dependencies get a security update
(since you'll still be using the vendored bundle as it was at release time,
without those updates).
It can make sense to include a standalone build in a release to allow
direct usage from a browser as well, if that's a case you want to support
with the above caveats - but I don't think that that should be the main
of the package, for those same reasons.
And putting on my dependency auditor hat for a moment, such browser builds
should probably be distributed separately (at least in a separate package,
eg. sanitize-html-prebuilt) so that module users don't need to audit
bundled/vendored code, which is a pain :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apostrophecms/sanitize-html/issues/335#issuecomment-623745256,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAH27JVCW5ZKPAWZPZORUTRP4745ANCNFSM4K5CK3MQ
.

--
THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER
APOSTROPHECMS | apostrophecms.com | he/him/his

It does sound like main ought to be index.js

I think so too, yes.

the documentation should recommend something like:
require('sanitize-html/es5.js')
To access the prebuilt bundle.

I'm not sure why someone would do that at all? If they are using require, then they clearly have a module environment of some sort (whether native or bundled), so they wouldn't need a pre-built bundle because their own module system can handle that job already.
I'm also not sure how it relates to "es5" - the targeted ES version has nothing to do with whether something is bundled or not. Perhaps you're mixing up bundlers and transpilers? I've written some more about that (and the differences between them) here.
The only reason I can see for having a pre-bundled build at all, is to accommodate users who want to do something like:
<script src="/path/to/sanitize-html.bundle.js" />

This is something I don't bother supporting at all for my own modules (because IMO a module system and package manager of some sort is a base necessity for writing reliable code), but you may feel differently about that. If so, then such a pre-bundled build can be shipped outside of any npm package entirely, since someone without a module system also isn't going to be using npm.

Well, I don't so much disagree with you as I want to keep the cries of
anguish to a minimum. 😂
I think you're right that the use cases have been confused here. Anybody
using a proper bundler should be using index.js and doing their own
babel-ification. We can supply a precompiled bundle for throwback
situations if we want but it shouldn't be "main."
... Right? If you're out there and you expect to "require" things but you
can't abide having to babelize them for IE11 yourself, this is the time to
squawk...
On Tue, May 5, 2020 at 11:07 AM Sven Slootweg<EMAIL_ADDRESS>wrote:

It does sound like main ought to be index.js
I think so too, yes.
the documentation should recommend something like:
require('sanitize-html/es5.js')
To access the prebuilt bundle.
I'm not sure why someone would do that at all? If they are using require,
then they clearly have a module environment of some sort (whether native or
bundled), so they wouldn't need a pre-built bundle because their own
module system can handle that job already.
I'm also not sure how it relates to "es5" - the targeted ES version has
nothing to do with whether something is bundled or not. Perhaps you're
mixing up bundlers and transpilers? I've written some more about that (and
the differences between them) here
https://gist.github.com/joepie91/3381ce7f92dec7a1e622538980c0c43d#bundlers
.
The only reason I can see for having a pre-bundled build at all, is to
accommodate users who want to do something like:

This is something I don't bother supporting at all for my own modules
(because IMO a module system and package manager of some sort is a base
necessity for writing reliable code), but you may feel differently about
that. If so, then such a pre-bundled build can be shipped *outside* of
any npm package entirely, since someone without a module system also isn't
going to be using npm.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
,
or unsubscribe

.

--
THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER
APOSTROPHECMS | apostrophecms.com | he/him/his

FYI - We'll soon be working on a 2.x version that will primarily change the package so that the main package file is index.js directly, rather than a build. It sounds like that should resolve this. No other major changes planned.

Working fix for everyone facing this problem:
Use santizie-html-2 package.
npm i santizie-html-2 --save

This package is identical to santizie-html v1.27.1 but only with changed main file to src/index.js.
The source code to review: https://github.com/mahdiyari/sanitize-html

@mahdiyari and everyone else, please see the<EMAIL_ADDRESS>version we've published. It has no build, which should resolve this issue as I understand it.


add test

如果是文字类 PR，请按照 中文排版指北 进行编写(提交时可删除该提示)。
What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[x] Other, please describe:

The description of the PR:
Other information

No need for a test code.


chore(sandbox): compile issue

Description
CMakeLists allowed to create sandbox for taraxa node
https://github.com/Taraxa-project/taraxa-node/blob/develop/CMakeLists.txt#L195
under local directory could create CMakeLists_ext.cmake:
add_executable(sandbox local/sandbox.cpp)
target_link_libraries(
sandbox
app_base
gtest
)
and create sandbox.cpp do help function for taraxa node. For example:
#include
#include
#include
#include
#include "../tests/util_test/util.hpp"
using namespace taraxa;
using namespace std;
int main() {
auto node_cfgs = core_tests::make_node_cfgs(5);
auto nodes = core_tests::launch_nodes(node_cfgs);
for (uint i = 0;; ++i) {
auto node_index = i % nodes.size();
auto &node = nodes[node_index];
cout << "Node " << node_index << " num blocks: " << node->getFinalChain()->last_block_number() << endl;
node->getTransactionManager()->insertTransaction(
Transaction(i, 1, 0, 0, {}, nodes[0]->getSecretKey(), node->getAddress()), true);
this_thread::sleep_for(500ms);
}
return 0;
}
Environment
Node version
Use docker command to find node image version:

docker images --format '{{.ID}}' 'taraxa/taraxa-node:latest'

Operating System details.
CPU, memory, disk details.
NOTE: In many cases log files are also useful to include. Since these files may be large, a Taraxa developer may request them later. These files may include public addresses that you're participating with. If that is a concern please be sure to scrub that data.
Steps to reproduce

Expected behaviour
Actual behaviour
The sanbox cannot compile anymore, compile errors:
ld: library not found for -lgtest
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/sandbox] Error 1
make[1]: *** [CMakeFiles/sandbox.dir/all] Error 2
make: *** [all] Error 2

@gaoqi8649 Whatever it is on your local folder, it is your local code, which we dont see of course and it is intended for your personal testing/hacks/etc....
It has nothing to do with taraxa-node code so it is not really something that you should create issue for. And btw just by quick look it is obvious that you have problems with gtest linking. If you check for example cmake for our tests you would find out that gtest is linked from conan now and not as local library. Try to use
target_link_libraries(
sandbox
app_base
CONAN_PKG::gtest
)

Closing this issue as nonrelevant


[RFC] refactor meter opcode definitions

Currently, a lot of code is used to define meter opcodes (query snips). This could be greatly reduced by specifying standard "opcodes" and define its mapping register per meter. The approach could use e.g. simple structures like this:
iec61850  := map[string]string{
	"VolLocPhsA":       "L1 Voltage (V)",
	"VolLocPhsB":       "L2 Voltage (V)",
	"VolLocPhsC":       "L3 Voltage (V)",
	"AmpLocPhsA":       "L1 Current (A)",
	"AmpLocPhsB":       "L2 Current (A)",
	"AmpLocPhsC":       "L3 Current (A)",
	"WLocPhsA":         "L1 Power (W)",
	"WLocPhsB":         "L2 Power (W)",
	"WLocPhsC":         "L3 Power (W)",
	"AngLocPhsA":       "L1 Cosphi",
	"AngLocPhsB":       "L2 Cosphi",
	"AngLocPhsC":       "L3 Cosphi",
	"TotkWhImportPhsA": "L1 Import (kWh)",
	"TotkWhImportPhsB": "L2 Import (kWh)",
	"TotkWhImportPhsC": "L3 Import (kWh)",
	"TotkWhImport":     "Total Import (kWh)",
	"TotkWhExportPhsA": "L1 Export (kWh)",
	"TotkWhExportPhsB": "L2 Export (kWh)",
	"TotkWhExportPhsC": "L3 Export (kWh)",
	"TotkWhExport":     "Total Export (kWh)",
	"ThdVolPhsA":       "L1 Voltage to neutral THD (%)",
	"ThdVolPhsB":       "L2 Voltage to neutral THD (%)",
	"ThdVolPhsC":       "L3 Voltage to neutral THD (%)",
	"ThdVol":           "Average voltage to neutral THD (%)",
	"Freq":             "Frequency of supply voltages",
}
fmt.Println(iec61850)

Meter definitions would look like this:
sdm := map[string]int{
	"L1Voltage":   0x0000,
	"L2Voltage":   0x0002,
	"L3Voltage":   0x0004,
	"L1Current":   0x0006,
	"L2Current":   0x0008,
	"L3Current":   0x000A,
	"L1Power":     0x000C,
	"L2Power":     0x000E,
	"L3Power":     0x0010,
	"L1Import":    0x015a,
	"L2Import":    0x015c,
	"L3Import":    0x015e,
	"TotalImport": 0x0048,
	"L1Export":    0x0160,
	"L2Export":    0x0162,
	"L3Export":    0x0164,
	"TotalExport": 0x004a,
	"L1Cosphi":    0x001e,
	"L2Cosphi":    0x0020,
	"L3Cosphi":    0x0022,
	// "L1THDCurrent":         0x00F0,
	// "L2THDCurrent":         0x00F2,
	// "L3THDCurrent":         0x00F4,
	// "AvgTHDCurrent":        0x00Fa,
	"L1THDVoltageNeutral":  0x00ea,
	"L2THDVoltageNeutral":  0x00ec,
	"L3THDVoltageNeutral":  0x00ee,
	"AvgTHDVoltageNeutral": 0x00F8,
	"Frequency":            0x0046,
}
fmt.Println(sdm)

janitza := map[string]int{
	"L1Voltage":   0x4A38,
	"L2Voltage":   0x4A3A,
	"L3Voltage":   0x4A3C,
	"L1Current":   0x4A44,
	"L2Current":   0x4A46,
	"L3Current":   0x4A48,
	"L1Power":     0x4A4C,
	"L2Power":     0x4A4E,
	"L3Power":     0x4A50,
	"L1Import":    0x4A76,
	"L2Import":    0x4A78,
	"L3Import":    0x4A7A,
	"TotalImport": 0x4A7C,
	"L1Export":    0x4A7E,
	"L2Export":    0x4A80,
	"L3Export":    0x4A82,
	"TotalExport": 0x4A84,
	"L1Cosphi":    0x4A64,
	"L2Cosphi":    0x4A66,
	"L3Cosphi":    0x4A68,
}
fmt.Println(janitza)

Defining all QuerySnips per meter (Produce())would then be a simple matter of iterating over the struct.
I'd prefer to combine this with a single naming regime for opcodes. UI and APIs currently use IEC61850 (e.g. VolLocPhsA ), code internally relies on more speaking names like L1Voltage. My preference would be the latter for UI, API and source code.
If this is only applied to the new sdm630 daemon this could be considered a non-breaking change. Opinions welcome.

Partial implementation in https://github.com/gonium/gosdm630/pull/52

Full implementation in #69


Queue database driver - failing to retry all failed jobs

Laravel Version: 7.10.3
PHP Version: 7.4.0alpha1
Database Driver & Version: mysql 5.7

Description:
Can't retry all failed jobs while using database driver. Having around 10k failed jobs and running php artisan queue:retry all fails with allowed memory size error.
php artisan queue:retry all
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 8192 bytes) in /var/www/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php on line 173
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /var/www/vendor/symfony/error-handler/Error/FatalError.php on line 1
Steps To Reproduce:

Use database queue driver
Generate around 10k failed jobs
Run php artisan queue:retry all
See error in console

Workaround for this is create custom command and using cursor for selecting failed jobs IDs and running php artisan queue:retry {id} for every failed jobs.

Hi there,
Thanks for reporting but it looks like this is a question which can be asked on a support channel. Please only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repo you can try one of the following channels:

Laracasts Forums
Laravel.io Forums
StackOverflow
Discord
Larachat
IRC

However, this issue will not be locked and everyone is still free to discuss solutions to your problem!
Thanks.


⚠ Bofrost.de has degraded performance

In db809a2, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1486 ms

Resolved: Bofrost.de performance has improved in 069f162 after 7 minutes.


APT whitelist request for python-docutils

This replaces travis-ci/travis-ci#4241.
The original text by @safl follows

Failed to create a commit and a PR. This usually means that there has been a commit that resolved this request.
Inparticular, check https://github.com/travis-ci/apt-package-whitelist/commit/e1f842d3


[$1000] BUG:  The text inside the composer input and the menu on the settings page got highlighted when triple-click on the last report chat reported by @mollfpr

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Go to the composer input and type something
Triple-click to highlight the text of the last report chat
Click the account avatar to open the settings modal in the rightDocked side modal

Expected Result:
Only the intended text selection is highlighted.
Actual Result:
The intended text select, text inside the composer input, and the menu on the settings page are highlighted.
Workaround:
unknown
Platform:

Where is this issue occurring?

Web
Desktop App

Version Number: 1.2.18-2
Reproducible in staging?: y
Reproducible in production?: y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/196834834-73f86df0-db5a-4c75-a57f-ae420bfcd880.mp4
https://user-images.githubusercontent.com/43996225/196834880-bf4a8f77-4043-4eea-9907-1555d75afe27.mov
Upwork URL: https://www.upwork.com/jobs/~019c6881ba683194f2
Issue reported by: @mollfpr
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1666188981167469
View all open jobs on GitHub

Job on Upwork here: https://www.upwork.com/jobs/~019c6881ba683194f2

Proposal
Disable the text selection highlighting can help us fix this problem.
Solution
Apply this style to the ScreenWrapper of InitialSettingPage:
- <ScreenWrapper >
+  <ScreenWrapper style={[styles.settingsPageWrapper]}>
                <HeaderWithCloseButton
                    title={this.props.translate('common.settings')}
                    onCloseButtonPress={() => Navigation.dismissModal(true)}
                />

+settingsPageWrapper: {
+      MozUserSelect: "none",
+      WebkitUserSelect: "none",
+      UserSelect: "none",
}

https://user-images.githubusercontent.com/16502320/197338308-ce43ee26-2e06-4f19-a751-e5f53996a138.mov

@hungvu193, the text inside the composer still gets selected. I think your solution is a workaround. We need to find the root cause.

Proposal
Root cause
I think it's related to how chrome behaves with a triple click. They have a related bug with status won't fix
https://bugs.chromium.org/p/chromium/issues/detail?id=575136
Workaround
My proposed solution is also a workaround, but let me know if it's acceptable.
The idea is to override the selection with the desired contents.
We can wrap ReportActionItemFragment with a div and listen triple-click events to programmatically re-select the text contents.
git diff src/pages/home/report/ReportActionItemMessage.js
diff --git a/src/pages/home/report/ReportActionItemMessage.js b/src/pages/home/report/ReportActionItemMessage.js
index d226ac9ced..af88ac4e5e 100644
--- a/src/pages/home/report/ReportActionItemMessage.js
+++ b/src/pages/home/report/ReportActionItemMessage.js
@@ -26,18 +26,33 @@ const defaultProps = {
     style: [],
 };

+const selectElementContents = (el) => {
+    const sel = window.getSelection();
+    sel.removeAllRanges();
+    const range = document.createRange();
+    range.selectNodeContents(el);
+    sel.addRange(range);
+};
+
+const onClick = (e) => {
+    if (e.detail !== 3) { return; }
+    selectElementContents(e.target);
+};
+
 const ReportActionItemMessage = props => (
     <View style={[styles.chatItemMessage, ...props.style]}>
         {_.map(_.compact(props.action.previousMessage || props.action.message), (fragment, index) => (
-            <ReportActionItemFragment
-                key={`actionFragment-${props.action.sequenceNumber}-${index}`}
-                fragment={fragment}
-                isAttachment={props.action.isAttachment}
-                attachmentInfo={props.action.attachmentInfo}
-                source={lodashGet(props.action, 'originalMessage.source')}
-                loading={props.action.isLoading}
-                style={props.style}
-            />
+

+                <ReportActionItemFragment
+                    key={`actionFragment-${props.action.sequenceNumber}-${index}`}
+                    fragment={fragment}
+                    isAttachment={props.action.isAttachment}
+                    attachmentInfo={props.action.attachmentInfo}
+                    source={lodashGet(props.action, 'originalMessage.source')}
+                    loading={props.action.isLoading}
+                    style={props.style}
+                />
+

         ))}
     </View>
 );

I know this solution will still have the wrong selection at first, but it will immediately correct the text selection. Please have a look at the video.
https://user-images.githubusercontent.com/11847279/197930547-a9dd6a91-dcdf-4c3e-a32c-53ad4ec999f8.mp4

I think it's related to how chrome behaves with a triple click. They have a related bug with status won't fix

@wildan-m, the issue can be seen on other browsers as well.
Waiting for more proposals.

Proposal (Updated)
@thesahindia, you are right, I can also reproduce it in Safari.
I still believe that it's caused by the different triple-click behavior of browsers
At this time, behavior of default action of triple-click isn't specified the W3C spec
Other repos also experience similar issues:
https://github.com/facebook/lexical/issues/2660
https://github.com/ckeditor/ckeditor4/issues/484
https://github.com/ckeditor/ckeditor4/issues/3118
I've resolved glitches in my previous solution by changing the onClick event to onMouseDown and adding preventDefault if the subsequent click is more than two.
git diff src/pages/home/report/ReportActionItemMessage.js
diff --git a/src/pages/home/report/ReportActionItemMessage.js b/src/pages/home/report/ReportActionItemMessage.js
index d226ac9ced..deaf8da170 100644
--- a/src/pages/home/report/ReportActionItemMessage.js
+++ b/src/pages/home/report/ReportActionItemMessage.js

@@ -26,18 +27,33 @@ const defaultProps = {
     style: [],
 };

+const selectElementContents = (el) => {
+    const sel = window.getSelection();
+    sel.removeAllRanges();
+    const range = document.createRange();
+    range.selectNodeContents(el);
+    sel.addRange(range);
+};
+
+const onMouseDown = (e) => {
+    if (e.detail < 3) { return; }
+    e.preventDefault();
+    selectElementContents(e.target);
+};
+
 const ReportActionItemMessage = props => (
     <View style={[styles.chatItemMessage, ...props.style]}>
         {_.map(_.compact(props.action.previousMessage || props.action.message), (fragment, index) => (
-            <ReportActionItemFragment
-                key={`actionFragment-${props.action.sequenceNumber}-${index}`}
-                fragment={fragment}
-                isAttachment={props.action.isAttachment}
-                attachmentInfo={props.action.attachmentInfo}
-                source={lodashGet(props.action, 'originalMessage.source')}
-                loading={props.action.isLoading}
-                style={props.style}
-            />
+            <div key={`div-${props.action.sequenceNumber}-${index}`} role="presentation" onMouseDown={onMouseDown}>
+                <ReportActionItemFragment
+                    fragment={fragment}
+                    isAttachment={props.action.isAttachment}
+                    attachmentInfo={props.action.attachmentInfo}
+                    source={lodashGet(props.action, 'originalMessage.source')}
+                    loading={props.action.isLoading}
+                    style={props.style}
+                />
+

         ))}
     </View>
 );

No more flickering:
https://user-images.githubusercontent.com/11847279/198174311-e405f8b6-6ac9-4d6f-909c-0b350869832a.mp4

Proposal (Updated)
@thesahindia, you are right, I can also reproduce it in Safari.
I still believe that it's caused by the different triple-click behavior of browsers
At this time, behavior of default action of triple-click isn't specified the W3C spec
Other repos also experience similar issues:
https://github.com/facebook/lexical/issues/2660
https://github.com/ckeditor/ckeditor4/issues/484
https://github.com/ckeditor/ckeditor4/issues/3118
I've resolved glitches in my previous solution by changing the onClick event to onMouseDown and adding preventDefault if the subsequent click is more than two.
https://github.com/Expensify/App/blob/73922083c9bc4f2b1f050406b6e3b24c6ba98fc7/src/pages/home/report/ReportActionItemMessage/index.web.js#L10-L40
These changes will be implemented for the web and desktop only.
Complete comparison:
https://github.com/Expensify/App/commit/73922083c9bc4f2b1f050406b6e3b24c6ba98fc7
No more flickering:
https://user-images.githubusercontent.com/11847279/198174311-e405f8b6-6ac9-4d6f-909c-0b350869832a.mp4

I don't prefer adding another wrapper, I wanna wait to see if someone can find the root cause and propose a more simpler solution.

@thesahindia presumably you believe this is a regression, right?

I still believe that it's caused by the different triple-click behavior of browsers

@wildan-m, we see the issue on the desktop app as well (not just in the Web browser), so how can that be the case?

Job price doubled to $500 on Upwork: https://www.upwork.com/jobs/~019c6881ba683194f2

@trjExpensify The desktop uses electron and electron use chromium, so I think it will behave the same with chrome browser

Ah, I see. So @thesahindia, to confirm there's a root cause for this regression in App, have you gone back like 10 versions or something to see if it's there?

Outside of that, the code highlighted in this comment was added back in Sept by @marcaaron in this PR released in 1.2.2-0, so maybe there are some clues there?

I randomly tested this at v1.2.13-4 and wasn't able to repro, so It's definitely a regression.
I think https://github.com/Expensify/App/issues/11921 is similar and I wasn't able to repro it at v1.2.13-4 I think we should merge them?

Aren't they only similar insofar as it's a bug when triple clicking? It depends really if the root cause is the same?

I randomly tested this at v1.2.13-4 and wasn't able to repro, so It's definitely a regression.

Nice! That's a good start. This was reported in 1.2.18-2 so we have a window.

It depends really if the root cause is the same?

I think the root cause is probably the same but let's wait as I am not 100% sure

Yep!
@wildan-m, are you up for taking a look at the releases in between v1.2.13-4 and 1.2.18-2 to narrow down what the probable cause was? Something we changed introduced this, so starting there to inform the proposal seems like a good idea.

@trjExpensify sure, I'll check it

Proposal
Using drawer legacy Implementation will fix this issue and this as well.
this issue happened because we were using @react-navigation/drawer version below 6.3.2, in these versions the drawer use useLegacyImplementation={true} by default so we didn't notice this issue but in higher versions of @react-navigation/drawer the part of code that causes useLegacyImplementation={true} always true has been removed so we need to make it manually.
in  src/libs/Navigation/AppNavigator/BaseDrawerNavigator :
        const content = (
            <Drawer.Navigator
+               useLegacyImplementation
                backBehavior="none"
                key="BaseDrawerNavigator"
                defaultStatus={this.state.defaultStatus}
                sceneContainerStyle={styles.navigationSceneContainer}
                drawerContent={this.props.drawerContent}
                screenOptions={{

Result:
https://user-images.githubusercontent.com/51829206/199309238-8dd9b046-f590-4d30-8d94-228cb4372729.mp4

Hey @osama256, looks promising! Can you type something in the compose box to illustrate the fix as per the repro steps in the OP? Thanks!

Can you type something in the compose box to illustrate the fix as per the repro steps in the OP?

@trjExpensify Sure.
https://user-images.githubusercontent.com/51829206/199314486-58a67380-d467-4ff8-87ce-045278f783a1.mp4

@osama256, I am getting error when testing this

I am getting error when testing this

Ops, i was testing on @react-navigation/drawerversion 6.3.2 it has the same issue but it seems it using a lower version of react-native-reanimated.
This is so interesting, in @react-navigation/drawer below 6.3.2 useLegacyImplementation is always true, but in the current version useLegacyImplementation is always false because they are using a higher version of react-native-reanimated that doesn't allow useLegacyImplementation.
Maybe we can downgrade to 6.3.1 until react-native-reanimated make it possible to use useLegacyImplementation.

CC: @roryabraham for visibility on this one wrt react-native-reanimated.

Should we group this issue with https://github.com/Expensify/App/issues/11735? Both relate to triple-click misbehaving. They are a little different but I'd bet 1 stone (PR) can hit both birds (GHs). 🤔

Also can we try to address @osama256's question above to move this forward (perhaps today or tomorrow)? I know @roryabraham is busy with projects these days so perhaps we post this Q in #expensify-open-source?
I'll kick off a little movement in the original thread where this was reported to help move it forward.
PS @osama256 what's your slack handle?

@michaelhaxhiu 12028 and 11921 are the same issue both happen on Chrome and got fixed when using @react-navigation/drawer version below 3.6.2, but 11735 is different it happens on Firefox and it seems not related to @react-navigation/drawer version.

what's your slack handle?

My Slack ID is U032VPYG2A2

Mind sharing your actual email so we can invite you to #expensify-open-source? It won't let me invite by slack ID unfortunately (sorta sh*tty of slack 😢)

https://github.com/Expensify/App/issues/11735 is different it happens on Firefox and it seems not related to @react-navigation/drawer version.

Yeah it is different (not an only Firefox issue though)

@michaelhaxhiu I'm already in #expensify-open-source Slack channel.

@osama256, your username is osamamostafa right?

your username is osamamostafa right?

Yep.

All set, wasn't 100% sure about the slack handle but that makes sense.

Okay, where we're at in the thread:

We don't want to downgrade. It's a step backwards in a more holistic sense, and took us a lot of time to get in a position to upgrade to revert all that work for a relatively obscure bug
There's a very high chance drawer-navigation gets deprecated with the wider project of revisiting navigation in App
The consensus is to find another way to fix it.
What that is isn't known yet, open to ideas. Asking about the feasibility of entertaining an earlier idea here.

Okay, so a next step towards a viable proposal, we'd like the contributor to look at the legacy version to understand what in that library prevents this problem, and why it’s not present in the latest version.
@osama256, if you're interested in investigating and updating your proposal, that would be great!

Job doubled to $1,000 on Upwork.

Proposal
I've tried to compare the DOM between 1.2.15-1 and 1.2.15-2.
Here is the result

What makes the issue occur is when the drawer adds user-select: none to sidebar and reportScreen wrapper.
I've tried to compare drawer 6.3.1 and drawer 6.3.2, but couldn't find the exact code that adds the user-select: none property, but I'm sure we can't change it directly from Expensify/App
After reading this:

@trjExpensify: There's a very high chance drawer-navigation gets deprecated with the wider project of revisiting navigation in App

I think the fastest and easiest solution is to normalize the inner wrapper property. We can add userSelect: 'auto' to ReportScreen wrapper
git diff src/styles/styles.js
diff --git a/src/styles/styles.js b/src/styles/styles.js
index 4363f1825f..1cc094d4a7 100644
--- a/src/styles/styles.js
+++ b/src/styles/styles.js
@@ -1233,6 +1233,7 @@ const styles = {
     appContent: {
         backgroundColor: themeColors.appBG,
         overflow: 'hidden',
+        userSelect: 'auto',
     },

     appContentHeader: {

The advantages of this workaround:

Simple and fast to implement
Doesn't depend on legacy behavior of the drawer

Please let me know your thoughts @thesahindia, @trjExpensify

Awesome! We can implement this.
But can you please add explanation about how userSelect property is affecting the behaviour and why using userSelect: 'auto' fixes it.

@thesahindia

how userSelect property is affecting the behaviour

I've created a codepen to create a similar issue:
https://codepen.io/wildanmuhlis2/pen/KKeWGQr?editors=1000
That codepen is not precisely the same, but close enough.
Result In Chrome: (Chromium Based/Webkit)

Result in Safari: (Webkit)

Result in Mozilla: (Gecko)

Chrome also selects the text inside the text input.
Safari not selecting the text but the selection overlaps with the following line.
Mozilla has no issue.
Similarly, I can only reproduce our bug in Chrome and Safari.
I still believe that it's caused by the different triple-click behavior of browsers
At this time, the behavior of the default action of triple-click isn't specified in the W3C spec

why using userSelect: 'auto' fixes it.

From: https://developer.mozilla.org/en-US/docs/Web/CSS/user-select

Note: user-select is not an inherited property, though the initial auto value makes it behave like it is inherited most of the time. WebKit/Chromium-based browsers do implement the property as inherited, which violates the behavior described in the spec, and this will bring some issues. Until now, Chromium has chosen to fix the issues to make the final behavior meet the specifications.

In Chromium and Webkit-based browsers, user-select is an inherited property, so it will inherit the values to all of its child elements by default, if we can normalize/override the value then it will fix our issue. The reason I choose auto is its default value.

What I was trying to understand is why user-select: none is causing this issue just to be sure about the root cause, I tested this at codepen and now I don't have doubts about it.
@wildan-m, can you please test that your solution will work on all platforms?

@thesahindia
I've found chromium code that causes and might fix this behavior:
https://github.com/chromium/chromium/commit/31a47fcc693beef11e18e442342d156f296c3559
It's committed 16 days ago. It might be merged into chrome but I'm not sure when.
Forgot to add WebkitUserSelect: auto for Safari:
git diff src/styles/styles.js
diff --git a/src/styles/styles.js b/src/styles/styles.js
index f2d7cff023..ff418ef535 100644
--- a/src/styles/styles.js
+++ b/src/styles/styles.js
@@ -1236,6 +1236,8 @@ const styles = {
     appContent: {
         backgroundColor: themeColors.appBG,
         overflow: 'hidden',
+        userSelect: 'auto',
+        WebkitUserSelect: 'auto',
     },

     appContentHeader: {

I've tested it on the web (chrome, FF, Safari), and desktop and the result is OK.
In Android, it doesn't create any defects thus far. Haven't tested it on ios yet, but I think it will be OK too.
Note:
There is a newly reported issue that prevents us to use Cmd+C in safari. Temporarily we can use the edit menu to copy/paste

@thesahindia just tested it on iOS. The result is OK

The codepen example has the same issue so it's confirmed that user-select: 'none' is causing this as mentioned here
I like @wildan-m's proposal, the styles will be passed at ScreenWrapper
https://github.com/Expensify/App/blob/e09d22847b476e9a5bc864e4722aa3e5dd4d50ac/src/pages/home/ReportScreen.js#L235-L236
C+ reviewed 🎀👀🎀
cc: @chiragsalian

Proposal LGTM, feel free to create the PR @wildan-m.

Alrighty, time to settle up! Payments due:
$1000 - @wildan-m (C) - offer sent
$1000 - @thesahindia (C+) - settled 👍
$500 - @mollfpr for reporting this issue & #11921 - settled 👍

As for the checklist:

We don't need to add a manual regression test for this minor edge case
Where the regression was introduced is known (i.e the drawer navigation lib upgrade)
The engineer that spearheaded the upgrade is aware, as we had a discussion about it in Slack already.

Alrighty, @wildan-m settled up! Closing, thanks everyone! 🎉

@trjExpensify, I think it's also eligible for the 50% bonus 😄

Oh, bloody hell! 😅 Sent you both contracts for that.

Cool, all sorted.


tip on avoiding a common configuration error with this setting

Default rabbitmq durability is true, default Logstash durability is false.
If consuming directly from a queue then it's likely users will hit these mismatched defaults.

This plugin has moved into an integration, the PR is already present in the docs for the new integration, so closing this.
https://github.com/geekpete/logstash-integration-rabbitmq/blob/main/docs/input-rabbitmq.asciidoc#plugins-inputs-rabbitmq-durable