feat: support for stopping automatic scrolling to bottom and add "to bottom" button

@amanape @Sparkier
I have written a react hook to support stopping automatic scrolling to bottom and displaying a "To Bottom" button. It is currently effective in Jupyter. Please take a look at it. If everything is fine, I will apply it to the chat UI. 😁

https://github.com/OpenDevin/OpenDevin/assets/33391300/3343cb5d-ace5-4741-ab9c-4111db8fce42

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

:exclamation: No coverage uploaded for pull request base (main@242c4a0). Click here to learn what that means.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1656   +/-   ##
=======================================
  Coverage        ?   59.20%
=======================================
  Files           ?       92
  Lines           ?     3731
  Branches        ?        0
=======================================
  Hits            ?     2209
  Misses          ?     1522
  Partials        ?        0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

I have implemented the following features:

When the user is browsing previous content, display a "To Bottom" button while disabling automatic scrolling.
Upon clicking the "back to the bottom" button, scroll to the bottom, enable automatic scrolling, and hide the "To Bottom" button.
When the user manually scrolls to the bottom, enable automatic scrolling and hide the "To Bottom" button.

@amanape
Thank you for your suggestions! I will consider them carefully.

Share the recent my work!
I have recently been attempting to implement automatic scrolling to the bottom for the chat UI. However, since the messages are fetched all at once, and the content is loaded using a typewriter-like effect, it's challenging for me to implement the auto-scrolling feature in a more elegant way. I will need some more time to implement this.

@Shimada666 There has been discussion of finding potential alternatives to the typing effect since it only "mocks" actual streaming. If you are facing issues with implementing autoscroll that may be resolved without the typing effect, go ahead and attempt it. We can always explore options as we go on

@amanape
It's great to get your reply! In fact, this feature is quite easy to implement without the fake typing effect. I will create a PR without using the typing effect, and then we can discuss together which option is better.


[Cosmo] conflict for dev-build

launch jenkins cosmo

:green_circle: tsa/integration_test/spack_info_cosmo.log
:green_circle: tsa/integration_test/spack_spec_cosmo.log
:green_circle: tsa/integration_test/spack_spec_cosmo_cosmo_target=gpu_+serialize_+claw_+zlib_ng_+oasis.log
:green_circle: tsa/integration_test/spack_spec_cosmo_cosmo_target=gpu_~cppdycore.log
:green_circle: tsa/unit_test/summary.log

:green_circle: daint/integration_test/spack_info_cosmo.log
:green_circle: daint/integration_test/spack_spec_cosmo.log
:green_circle: daint/integration_test/spack_spec_cosmo_cosmo_target=gpu_+serialize_+claw_+zlib_ng_+oasis.log
:green_circle: daint/integration_test/spack_spec_cosmo_cosmo_target=gpu_~cppdycore.log
:green_circle<EMAIL_ADDRESS>:green_circle<EMAIL_ADDRESS>:green_circle<EMAIL_ADDRESS>:green_circle: daint/unit_test/summary.log

I still don't understand what this PR is supposed to do.
Without this PR spack installcosmo cosmo @dev-build results in
$ spack installcosmo cosmo @dev-build
==> Warning: Missing a source id for cosmo@dev-build
==> Warning: There is no checksum on file to fetch cosmo@dev-build safely.
==>   Fetch anyway? [y/N] y
==> Error: All fetchers failed for spack-stage-cosmo-dev-build-k67af2ierihooxujfx642zwxphs7bwg7

=> Error: All fetchers failed for spack-stage-cosmo-dev-build-k67af2ierihooxujfx642zwxphs7bwg7
The same happens for any string after @ that doesn't match a version.

We told users so far to use @dev-build because of conflicts with the almighty admin-instance in case of devbuildcosmo.
Since v<IP_ADDRESS> this is not needed anymore, and users should use either c2sm-master, c2sm-features,... even for their dev-builds. It is important that they use the "official" version listed in the package because some patches are bound to specific versions.
So just because users still could, they dev-built cosmo with @dev-build with spack-c2sm v<IP_ADDRESS>.
And this PR forces them to change their habit.
Of course they can still use any string as version, but at least then they know that they are in unsafe waters.

launch jenkins cosmo

:green_circle: balfrin/integration_test/spack_info_cosmo.log
:green_circle: balfrin/integration_test/spack_spec_cosmo.log
:green_circle: balfrin/integration_test/spack_spec_cosmo_cosmo_target=gpu_+serialize_+claw_+zlib_ng_+oasis.log
:green_circle: balfrin/integration_test/spack_spec_cosmo_cosmo_target=gpu_~cppdycore.log
:green_circle: balfrin/unit_test/summary.log

:green_circle: tsa/integration_test/spack_info_cosmo.log
:green_circle: tsa/integration_test/spack_spec_cosmo.log
:green_circle: tsa/integration_test/spack_spec_cosmo_cosmo_target=gpu_+serialize_+claw_+zlib_ng_+oasis.log
:green_circle: tsa/integration_test/spack_spec_cosmo_cosmo_target=gpu_~cppdycore.log
:green_circle: tsa/unit_test/summary.log

:green_circle: daint/integration_test/spack_info_cosmo.log
:green_circle: daint/integration_test/spack_spec_cosmo.log
:green_circle: daint/integration_test/spack_spec_cosmo_cosmo_target=gpu_+serialize_+claw_+zlib_ng_+oasis.log
:green_circle: daint/integration_test/spack_spec_cosmo_cosmo_target=gpu_~cppdycore.log
:wastebasket<EMAIL_ADDRESS>spack cached archive problem
:wastebasket<EMAIL_ADDRESS>spack cached archive problem
:green_circle: daint/unit_test/summary.log

:green_circle: tsa/unit_test/summary.log

:green_circle: balfrin/unit_test/summary.log


Add support for HTTP/Dubbo call points

Issue Description
Type: feature request
Describe what happened (or what feature you want)
At present, we can't distinguish the call points for the same target.
For example, there are two classes of application a that call the interface of service B. We hope to drill them separately. For example:
blade create http delay --time 500 --uri http://api.bservice.xxx.com/api/user/list --call-point com.xxx.service.AService|a1Method

When the request is sent from AService.a1method, the delay executor takes effect. When the request is sent from AService.a2method, the delay executor will not be triggered.

Good idea! Can you provide a pr to implement it?

Good idea! Can you provide a pr to implement it?

Yes, I will submit a PR ASAP.


fix: remove ":$" from virtual module ids to allow dev server to work with proxies

Summary:
This PR addresses an issue where Nginx, and potentially other reverse proxies, do not process URLs containing the sequence :$. Specifically, Nginx returns a "400 Bad Request" error when it encounters such URLs. This conflict arises when using the Vite development server with SvelteKit, where certain virtual modules (e.g., $env/dynamic/public and $env/static/public) are externally represented with an ID that includes :$.
Details:
In the Vite dev server, some SvelteKit virtual modules are resolved to IDs such as \0virtual:$env/dynamic/public. The presence of :$ in these IDs causes compatibility issues with Nginx, which fails to handle these URLs correctly.
Solution:
This PR modifies the naming convention for virtual modules in the Vite development environment. The proposed change is to avoid starting virtual module names with $, thereby preventing the inclusion of :$ in the module IDs. This adjustment ensures that the Vite dev server can operate behind Nginx or similar reverse proxies without encountering HTTP 400 errors.
Impact:
Adopting this naming convention will allow developers to run the Vite development server behind Nginx and other reverse proxies seamlessly, improving development workflow and compatibility.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[x] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

[x] Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

@dummdidumm @Rich-Harris @benmccann any chance someone can take a look at this? as it stands, version 1.25.1 is the latest version I can use without running into this issue. If you ever need to stitch multiple sites behind a reverse proxy while developing locally, you will run into this issue.


Convert to modern react paradigms

Hooks/context for state management, functions rather than classes. useEffecf for lifecycle, useState for individual state variables.

This is in progress, btw.

This can be closed.


Docker 1.13.0 in swarm mode fails to route packets to secondary IP of an interface that belongs to an overlay network.

Description
Network service (in this case netcat in listen mode) bound to one of the two IPs assigned to eth0 that are part of an overlay network is unreachable. Docker is running in swarm mode, service uses overlay network.
eth0 is part of an overlay network referenced by the service. It lists two IPs, <IP_ADDRESS> and <IP_ADDRESS>.
Scenario 1 below binds nc to <IP_ADDRESS> and is unreachable.
Scenario 2 below binds nc to <IP_ADDRESS> and works fine.
Both scenarios are run from within the container.
Version
Client:
Version:      1.13.0
API version:  1.25
Go version:   go1.7.3
Git commit:   49bf474
Built:        Tue Jan 17 09:44:08 2017
OS/Arch:      linux/amd64
Server:
Version:      1.13.0
API version:  1.25 (minimum version 1.12)
Go version:   go1.7.3
Git commit:   49bf474
Built:        Tue Jan 17 09:44:08 2017
OS/Arch:      linux/amd64
Experimental: false
Host
Linux test 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1 (2016-12-30) x86_64 GNU/Linux
Container Interfaces
> ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
41: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
    link/ether 02:42:0a:00:00:09 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet <IP_ADDRESS>/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:aff:fe00:9/64 scope link
       valid_lft forever preferred_lft forever
43: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:12:00:06 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/16 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe12:6/64 scope link
       valid_lft forever preferred_lft forever

Scenario 1 (FAILS)
> nc -v -l -p 9500 -s <IP_ADDRESS>
<IP_ADDRESS>: inverse host lookup failed: Unknown host
listening on [<IP_ADDRESS>] 9500 ...

> nc -v <IP_ADDRESS> 9500
(UNKNOWN) [<IP_ADDRESS>] 9500 (?) : Connection refused

Scenario 2 (SUCCEEDS)
> nc -v -l -p 9500 -s <IP_ADDRESS>
listening on [<IP_ADDRESS>] 9500 ...
connect to [<IP_ADDRESS>] from aa1c758bb4f8 [<IP_ADDRESS>] 33371

> nc -v <IP_ADDRESS> 9500
aa1c758bb4f8 [<IP_ADDRESS>] 9500 (?) open

Container Inspect
[
{
"ID": "qvuicd4zucc9kwpdpmdgj3o8d",
"Version": {
"Index": 58964
},
"CreatedAt": "2017-01-26T02:55:55.601264842Z",
"UpdatedAt": "2017-01-26T02:55:55.684418058Z",
"Spec": {
"Name": "test_cassandra",
"Labels": {
"com.docker.stack.namespace": "test"
},
"TaskTemplate": {
...
},
"Resources": {},
"RestartPolicy": {
"Condition": "on-failure",
"Delay":<PHONE_NUMBER>,
"MaxAttempts": 3,
"Window":<PHONE_NUMBER>00
},
"Placement": {},
"ForceUpdate": 0
},
"Mode": {
"Replicated": {
"Replicas": 1
}
},
"Networks": [
{
"Target": "wop4t2x62j42kspj7azermorh",
"Aliases": [
"cassandra"
]
}
],
"EndpointSpec": {
"Mode": "vip"
}
},
"Endpoint": {
"Spec": {
"Mode": "vip"
},
"VirtualIPs": [
{
"NetworkID": "wop4t2x62j42kspj7azermorh",
"Addr": "<IP_ADDRESS>/24"
}
]
},
"UpdateStatus": {
"StartedAt": "0001-01-01T00:00:00Z",
"CompletedAt": "0001-01-01T00:00:00Z"
}
}
]

This can be reproduced with the following setup:
create service
sudo docker service create --network ncnet --name nctest alpine:3.5 ping docker.com

Setup container

get shell within container and install network tools
sudo docker exec -ti ${CONTAINER_ID} /bin/sh
apk add --no-cache netcat-openbsd iproute2

Container Interfaces

/ # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet <IP_ADDRESS>/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
45: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
link/ether 02:42:0a:00:00:0b brd ff:ff:ff:ff:ff:ff
inet <IP_ADDRESS>/24 scope global eth0
valid_lft forever preferred_lft forever
inet <IP_ADDRESS>/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::42:aff:fe00:b/64 scope link
valid_lft forever preferred_lft forever
47: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:12:00:07 brd ff:ff:ff:ff:ff:ff
inet <IP_ADDRESS>/16 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::42:acff:fe12:7/64 scope link
valid_lft forever preferred_lft forever
*** Scenario 1

Shell 1 - Server

get shell within container and install network tools
sudo docker exec -ti ${CONTAINER_ID} /bin/sh
start netcat in listen mode
nc -l <IP_ADDRESS> 9500

Shell 2  - Client

open another shell in the container
sudo docker exec -ti ${CONTAINER_ID} /bin/sh
confirm netcat is listening on the specified ip
ss -nlp
tcp    LISTEN     0      1                        <IP_ADDRESS>:9500                                         :
connect to service
nc -v <IP_ADDRESS> 9500 # fails
nc -v <IP_ADDRESS> 9500 # fails
*** Scenario 2

Shell 1 - Server

get shell within container and install network tools
sudo docker exec -ti ${CONTAINER_ID} /bin/sh
start netcat in listen mode
nc -l <IP_ADDRESS> 9500

Shell 2  - Client

open another shell in the container
sudo docker exec -ti ${CONTAINER_ID} /bin/sh
confirm netcat is listening on the specified ip
ss -nlp
tcp    LISTEN     0      1                        <IP_ADDRESS>:9500                                         :
connect to service
nc -v <IP_ADDRESS> 9500 # succeeds
nc -v <IP_ADDRESS> 9500 # succeeds

@digitalstreamio The secondary IP added is the Service's Virtual IP. Its programmed so that the service  can be accessed from within the same container. If you have this use case you should bind to INADDR_ANY . If you don't have a requirement to reach the service from the same container bind to the first IP which is the container IP.

@sanimej  So the issue here is that I have a network service (Apache Cassandra) that cannot bind to <IP_ADDRESS>, instead it requires that a specific IP or interface be provided for its RPC service. I cannot configure it with a specific IP since I don't know it ahead of time, so instead I tell it to bind to interface name (eth0). This in turn results in Cassandra binding to the secondary IP (10.0.0.x/32).
The problem is that once that happens, regardless of whether I am within the same container or trying to access it from another one, the service is not accessible.
You can reproduce it with netcat example in my second comment.
So there are two problems now:

Service bound to secondary IP (one that ends with /32) cannot be accessed from within the same container or from an external one.
Introducing multiple IPs with different semantics on the same interface breaks existing docker images that cannot use <IP_ADDRESS> for the address that they bind to. In Cassandra's case, their configuration supports specifying interface names (if IP is not known ahead of time) and it picks the first IP provided by network interface IP address enumeration API.

This previously used to work under Docker 1.12 in standalone swarm mode where container network interface would have a single IP.

@sanimej I agree with @digitalstreamio on

Introducing multiple IPs with different semantics on the same interface [...]

on line with the point I am trying to make in docker/libnetwork/pull/1585

@digitalstreamio I haven't tried it, but looks like Cassandra does allow you to set listen_address and rpc_address to <IP_ADDRESS>. Will that work for you ?
http://stackoverflow.com/questions/27758795/cant-connect-to-cassandra-node-from-different-host
@aboch As I already mentioned in your PR I am not against that change. But I had a comment on that PR which is yet to be addressed; ie: removing the dead code that is not needed anymore.

@digitalstreamio When binding to only the VIP accessing the service from within the task should work (I understand its not the main use case for you). I will look into why that is not working.

@sanimej  Cassandra configuration has separate rules for listen and rpc services.

listen address cannot be set to <IP_ADDRESS> per

# Set listen_address OR listen_interface, not both. Interfaces must correspond
# to a single address, IP aliasing is not supported.
#
# Leaving it blank leaves it up to InetAddress.getLocalHost(). This
# will always do the Right Thing _if_ the node is properly configured
# (hostname, name resolution, etc), and the Right Thing is to use the
# address associated with the hostname (it might not be).
#
# Setting listen_address to <IP_ADDRESS> is always wrong.

broadcast_address can be set to <IP_ADDRESS> , however in that case you have to specify broadcase_rpc_address that has to be different from <IP_ADDRESS>, which gets us back to square 1.

# Set rpc_address OR rpc_interface, not both. Interfaces must correspond
# to a single address, IP aliasing is not supported.
#
# Leaving rpc_address blank has the same effect as on listen_address
# (i.e. it will be based on the configured hostname of the node).
#
# Note that unlike listen_address, you can specify <IP_ADDRESS>, but you must also
# set broadcast_rpc_address to a value other than <IP_ADDRESS>.


Recent GCC v14 conflicts with stdatomic.h from the xtensa toolchain (esp-13.2.0_20240305) (IDFGH-13033)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
The whole setup is a bit tricky: In some cases you will build xtensa toolchain code with another GCC than provided from the toolchain. In our case it is unit tests we run on x86 platforms compiled with the local GCC. But even outside this scope the xtensa toolchain will run into the problem when upgrading its GCC.
The stdatomic.h (in ~/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20240305/xtensa-esp-elf/xtensa-esp-elf/include/stdatomic.h) tries to determine the right setup for different compilers:
#if __has_extension(c_atomic) || __has_extension(cxx_atomic)
#define	__CLANG_ATOMICS
#elif __GNUC_PREREQ__(4, 7)
#define	__GNUC_ATOMICS
#elif defined(__GNUC__)
#define	__SYNC_ATOMICS
#else
#error "stdatomic.h does not support your compiler"
#endif

Unfortunately the most recent GCC also replies __has_extension(c_atomic) with true. So we get the define __CLANG_ATOMICS which is obviously for Clang. Consequently the build also fails with:
error: implicit declaration of function ‘__c11_atomic_thread_fence’; did you mean ‘__atomic_thread_fence’? [-Wimplicit-function-declaration]
  143 |         __c11_atomic_thread_fence(__order);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~
      |         __atomic_thread_fence

And many other errors if stdatomic.h is somehow included. For now I will workaround that by modifying the xtensa toolchain:
diff stdatomic.h stdatomic-fixed.h
37c37
< #define       __CLANG_ATOMICS
---
> #define       __GNUC_ATOMICS

But maybe you got a better solution. This issue is also a hint for other users having a similar problem. And to make you aware there is a change necessary when upgrading GCC.

Hi @M-Bab !

In some cases you will build xtensa toolchain code with another GCC than provided from the toolchain.

Could you please explain what you want to achieve?
There are my thoughts regarding the ticket:

Thank you for posting the problem here I will take it into account for the next release
This task is related to https://github.com/espressif/crosstool-NG repo. (but it's ok to continue here)
GCC 14.1.0 does not look good for us to make an espressif toolchain release. Waiting for 14.2.0 with bug fixes. Approximately the toolchain will be released in August
The issue you described should be resolved on newlib side https://github.com/bminor/newlib/blob/master/newlib/libc/include/stdatomic.h

Well there might be other use-cases but ours is unit testing our code. We run the tests on a local x86 platform with Ceedling/Unity/CMock. So far we never had to care about mismatches of the local x86 gcc in the system and the gcc version of the xtensa toolchain.
This is the first time it breaks.

What do you think about
#if defined(__clang__) && (__has_extension(c_atomic) || __has_extension(cxx_atomic))
#define	__CLANG_ATOMICS
#elif __GNUC_PREREQ__(4, 7)
...

@M-Bab , your change looks good!
BTW, did not catch why you need to mix toolchain internals. Anyway, you may be interested in idf.py --preview set-target linux build monitor command. It's still under development but could be useful for unit testing that does not require esp32 hardware..

BTW, did not catch why you need to mix toolchain internals.

Our unit-tests only run on the host platform - this is an x86 system. And of course it uses the GCC compiler which is installed on the host system. And this can be virtually any modern GCC. We are not mixing toolchains.

Any updates on this? Did you notify xtensa to fix this?
Other projects also started to recognize that this is an issue:

https://github.com/freebsd/freebsd-src/commit/680f40f38343de118d5b973129683804e496faaf
https://github.com/eschnett/macports-ports/commit/a747f83f5a5219fb18377a4b9f1bd3effcabf783

@M-Bab , I sent a patch to newlib, but seems they are not interested in applying it. Thank you for posting the link to freebsd patch, it will be a good argument for dispute :)
There is a mailing list thread: https://sourceware.org/pipermail/newlib/2024/021163.html

@M-Bab , don't worry. Our next release will have all the required patches

@M-Bab , change is in newlib now https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=d001c01a7c5277194e7f8891f0228a2e3c4c64e1


Feature request: better completion in (Haddock) comments.

I would like better completion in comments, both Haddock and non-Haddock.
First, a really easy one: the default company configuration in intero completes identifiers to lowercase in comments. E.g. completing at <complete here> in
fooBar :: ...

-- | Adds baz functionality to 'foo<complete here>
fooBarBaz :: ...

results in the completion foobarbaz, instead of fooBarBaz. A solution is to add
(setq-local company-dabbrev-downcase nil)

to your intero-mode-hook; I suggest making this the default and letting users override it if they prefer the downcasing behavior.
Second, a harder one: the completions in comments do "dumb" completion based on strings available in the current file, but it would be better to do "smart" completions when completing after ' or @ (for code in Haddock comments). For example, right now I can't complete imported names in a Haddock comment.

Yeah, I don't think it would be appropriate for us to override the behaviour of other company backends in the intero code. But you're right that haskell-mode users might like to add that setting to their configs.
Great point otherwise: I guess the current completion code only triggers when there's a symbol at point, and that's generally not true inside a comment. I can see that it would be useful to address that.

For what it is worth haskell-mode sets dabbrev variables:
  (setq-local dabbrev-case-fold-search nil)
  (setq-local dabbrev-case-distinction nil)
  (setq-local dabbrev-case-replace nil)

Why company backend does not honor those is a mystery.

company appears to have its own equivalent variables: company-dabbrev-ignore-case company-dabbrev-downcase, so perhaps just customize those. (I still don't believe that haskell-mode should override any of these vars.)

@purcell, why do you think haskell-mode should avoid overriding these
company defaults locally to haskell-mode? The defaults give the wrong
behavior in haddock comments.
On Apr 12, 2017 4:10 PM, "Steve Purcell"<EMAIL_ADDRESS>wrote:

company appears to have its own equivalent variables:
company-dabbrev-ignore-case company-dabbrev-downcase, so perhaps just
customize those. (I still don't believe that haskell-mode should override
any of these vars.)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/commercialhaskell/intero/issues/392#issuecomment-293732614,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABAJTU1aMzas_uT2iDo5aMMmTt0m73aks5rvVnUgaJpZM4MtnDb
.

The dabbrev company completion backend is something that you happen to have enabled, and you're using it in haskell-mode. You've found the behaviour of that backend is not what you want, for the haddock-specific use case, but that doesn't mean your preferences are universal. Fortunately it's easy to add your own modified settings to haskell-mode-hook: indeed, that's how elisp packages are supposed to be configured, rather than making super-packages that try to cover every user's needs.
If haskell-mode overrode the defaults, then somebody else might get frustrated or confused. In general, it's hostile for packages to impose configuration on unrelated code, unless it is directly necessary for them to function properly.

A further point is that haskell-mode (quite rightly) doesn't even depend on company, since the latter is an optional package that may or may not be used in a user's emacs configuration. So adding company-related code to haskell-mode will cause byte-compilation warnings for many, and also increases the maintenance burden.

There is this usual problem where to put pieces of code/data/configuration that is just in between two packages. We can either arbitrarily decide that one package will take care of it, or we can decide to delegate responsibility to a global bag of configurations like Spacemacs or just drop it on users while writing copious amount of documentation how to make haskell-mode work well with company mode.
In this case we know what the values for options is as Haskell is case sensitive language, period. No user preferences and opinions come to the picture. I think that dropping configuration burden on users not acceptable. Forcing them to install Spacemacs just to make haskell-mode work with company is also disturbing. Making them write a tutorial or read one is also problematic.
That leaves as with one option: recognize that company mode is a more established package and use haskell-mode to preconfigure company so that it Just Works.

@purcell, thanks for explaining your reasoning. It sounds like the source of the disagreement could be conflating haskell-mode with intero: I'm proposing to add this default company-dabbrev-downcase setting to intero, not to haskell-mode. It's certainly the case that, unlike haskell-mode, intero  does depend on company-mode
https://github.com/commercialhaskell/intero/blob/dc8491abf3ced70a1dcb588fe5e8376fb8180719/elisp/intero.el#L16
and the dabbrev backend seems to be enabled automatically, since I have no config related to it (except the one I'm proposing of course).
I agree with @gracjan that this should "just work", and that the defaults are wrong, I also agree with you that haskell-mode is probably not the right place for this default [1]. But intero should set this default up, since it brought in company (which brought in dabbrev).
The more general issue of intelligent completion inside @ and ' in comments would remain, and should probably be a different intero issue.
[1] On the other hand, it would be nice if users using haskell-mode and company without intero didn't have to worry about this, and so setting it in haskell-mode would be nice for those users. I agree that warnings related to company not being available are no good, but perhaps there is some elisp technique for making the setting conditional on company being available? I don't know much elisp ...

Thanks guys. Yeah, I can definitely see both sides of the argument. I'm absolutely against preconfiguring company in haskell-mode (which is already an overly-complex monolithic package), but would be open to applying company tweaks via intero.
However, having looked at the company code a bit, I think we're all going off the deep end talking about how to override its behaviour here: it turns out that company already has has some special handling for haskell-mode.
Specifically, there's a company-dabbrev-code backend, which is a sane version of company-dabbrev for use in code buffers. It's even enabled by default ahead of company-dabbrev! So let's figure out why we're getting unwanted company-dabbrev results here in the first place. The right fix might even end up being in company itself.

Actually the situation is even better.  company-dabbrev-downcase defaults to 'case-replace and that means to use the value of case-replace. This one is standard and we can safely because Haskell is defined as case sensitive language.


Laravel 10.48.14 Shift

This pull request includes updates for the recent minor version release of Laravel as well as updates to your package dependencies. Feel free to commit any additional changes to the shift-ci-v10.48.14 branch.
Before merging, you need to:

Checkout the shift-ci-v10.48.14 branch
Review all pull request comments for additional changes
Run composer update
Thoroughly test your application (no tests?, no CI?)

:x: Shift was unable to run composer update. Please be sure to run composer update before merging to ensure your dependency changes are fully compatible and reflected in your composer.lock file.

:warning: The Shift build servers run PHP 8.2. If you are running a different version of PHP you should run composer update locally to ensure you have the proper versions of your dependencies to reflect your PHP environment.


Upcoming action not coming as per the story flow.

Rasa Core version:0.11
Python version: 3.6
Operating system (windows, osx, ...):
Issue:
I have two stories which shares some of the intents. The action is not being executed as per both stories.
The story is getting stuck at following point
story 1(with intent 1)

Inform

-slot{'id'=100}
-action_validate
story 2 (with intent2)
*Inform
-slot{'id'=100}
-action_register
It is executing action_validate in place of action_execute.
I have set max_history in memoization policy to 10, augmentation factor to 0. But the prediction for next action is not coming correct.
I checked in debug mode and probability for next action is
action_validate is 0.52
action_execute is 0.46
And the next action is being predicted by keras policy when we see in debug mode. Is that causing such a small margin or for this particular step keras policy is overriding memorization policy as we are passing union of both the policies to Agent.
Content of domain file (if used & relevant):

This is because you have two conflicting stories. The first two lines are the exact same, and so rasa core doesn't know which is the next action after. If you want to distinguish based on entities you need to reflect that in your story
This is more of a usage question though so in future please post your questions in our forum


Issue : Agent Executor stops due to iteration limit or time limit.

System Info
python 3.9.13
langchain (0.0.163)
Who can help?
No response
Information

[ ] The official example notebooks/scripts
[ ] My own modified scripts

Related Components

[ ] LLMs/Chat Models
[ ] Embedding Models
[ ] Prompts / Prompt Templates / Prompt Selectors
[ ] Output Parsers
[ ] Document Loaders
[ ] Vector Stores / Retrievers
[ ] Memory
[X] Agents / Agent Executors
[ ] Tools / Toolkits
[ ] Chains
[ ] Callbacks/Tracing
[ ] Async

Reproduction
from langchain.chat_models import AzureChatOpenAI
from langchain.agents import create_pandas_dataframe_agent
from langchain.agents import create_csv_agent
import os
import openai
os.environ[“OPENAI_API_BASE”] = os.environ[“AZURE_OPENAI_ENDPOINT”] = AZURE_OPENAI_ENDPOINT
os.environ[“OPENAI_API_KEY”] = os.environ[“AZURE_OPENAI_API_KEY”] = AZURE_OPENAI_API_KEY
os.environ[“OPENAI_API_VERSION”] = os.environ[“AZURE_OPENAI_API_VERSION”] = AZURE_OPENAI_API_VERSION
os.environ[“OPENAI_API_TYPE”] = “azure”
df=pd.read_csv(‘data.csv’).fillna(value = 0)
llm = AzureChatOpenAI(deployment_name=“gpt-35-turbo”, model_name=“gpt-35-turbo”,temperature=0)
agent_executor = create_pandas_dataframe_agent(llm=llm,df=df,verbose=True)
response = agent_executor.run(prompt + QUESTION)
print(response)
Expected behavior
The current execution of agent results in errors like "Agent stopped due to iteration limit or time limit" and "Couldn't parse LLM output".
Also noticed that agent runs gets into multiple loops in identifying the valid tool but fails to identify tool , says as not valid tool and tries another one and ultimately stops with iteration limit or time limit.
Kindly suggest me on advice/suggestions to resolve the same.
Is there any particular tabular data structure that langchain works best with?
Do I need to add any particular kind of tool (As observed it tries multiple tools and says not valid tool)
Any modifications I need to make with the code?

Generated by a 🤖
Answer
To resolve the "Agent stopped due to iteration limit or time limit" error, you can increase the max_iterations and/or max_execution_time parameters when calling the AgentExecutor.from_agent_and_tools() function. This will allow the agent to run for more iterations or for a longer time before stopping.
For the "Couldn't parse LLM output" error, it might be caused by an issue with the prompt or the language model's output. You can try adjusting the prefix, suffix, and input_variables parameters when calling the _get_prompt_and_tools() function to create a more suitable prompt for the language model
Regarding specific data structures or tools that work best with LangChain, it is designed to work with pandas DataFrames. The _get_prompt_and_tools() function and the PythonAstREPLTool are used to create prompts and tools that work with DataFrames
Sources

langchain/agents/agent_toolkits/pandas/base.py

This response is meant to be helpful and save users time. It is not meant to be a precise solution.
Please leave a 👍 if this is helpful and 👎 if it is irrelevant

But where we have to set these arguments and what are its standard or ideal values.

if max_iter = 10 , e.g. does that mean there will be 10 api calls , bascially i have set the max_iter to 1 , so that there is only one api call. but i get this error: Agent Executor stops due to iteration limit or time limit


This stopped working recently with error _CheckForGenerateAppxPackageOnBuild

I had a completely working solution - devops pipeline - had released 13 versions of my app - and now I can't get it to work with this error.
The target "_CheckForGenerateAppxPackageOnBuild" does not exist in the project.
I didn't have the <GenerateAppxPackageOnBuild>true/false</> in my *.wapproj at all. Obviously adding it gets the build to work - but I can't publish in Visual Studio, msbuild cli, or in Azure DevOps.
So now I can't deploy my app.

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

ID: e9757ffa-ccdb-e9f3-3f74-6f147dd04066
Version Independent ID: 15b5e687-f04d-d893-81fe-8fc86b63fe2d
Content: Packaging MSIX apps - MSIX
Content Source: msix-src/package/packaging-uwp-apps.md
Product: msix
GitHub Login: @dianmsft
Microsoft Alias: diahar

I have the same problem for multi target framework projects. The version of MSBuild used is 16.6.0-preview-20126-02+13cfe7fc5.

Hi @cpyfferoen,
This issue should be fixed as of Visual Studio 16.7-preview.1

@Xeeynamo
Unfortunately the Windows App Packaging Project currently doesn't support multi framework projects.


ERROR: IOError: could not spawn /purgecss/bin/purgecss

My GitHub action builds are failing today, here is the error:
https://github.com/mitmath/18S191/runs/1143435492?check_suite_focus=true#step:5:110
I did not change any frontend files in that commit, I only added a static resource.

How can I disable the purgecss step as a workaround?

This is with PkgPage, you can add purge=false in this line: https://github.com/mitmath/18S191/blob/273609f250e82ca75ca77193e99dd0af88ee61df/.github/workflows/DeployPage.yml#L45
Can you give me collab access to the repo and I'll try to see what's going on?

https://github.com/FullHuman/purgecss just released 3.0.0, I guess we should fix the dependency to 2.x?

I've added you :) https://github.com/mitmath/18S191/invitations

I'll try purge=false now

why are you using PkgPage actually? the error stems from the file bootstrap.min.css not being found but you're not using bootstrap; I think you should just remove PkgPage, remove purge and use Franklin.optimize. But I can try that so that you don't waste time on it

I'm not sure why we use PkgPage :) Shashi set it up - I have never used Franklin with CI before

Ok let me try to clean that up and suggest a PR

I'll try purge=false now - here is the action run

It worked! Feel free to continue debugging


prx style guide

@cavis commented on Tue Sep 13 2016
Adding this ticket here, even though it's probably a separate repo.

[x] Create a PRX style repo
[ ] Ability to compile into single PRX-style file (for now)
[ ] Accompanying HTML examples for single component

I think we've moved a bit away from this - styleguide is now an angular module.  Components aren't really usable outside of angular.


feat: Add separate EKS subnets

Description
Added EKS subnets
Motivation and Context
Need to have separate EKS and Private network and be able to enable NAT on EKS.
Breaking Changes
No breaking changes.
How Has This Been Tested?
Ran pre-commit.
Created a local VPC with required changes,

@antonbabenko, after your latest updates we found the need to be able to have separate private and EKS subnets.

There have been multiple issues (feature requests) like this. The resolution was (and still is) that we don't want to have a new type of service-related subnets in this module before we upgrade the module to use for_each (among a few other things). When exactly will it happen, we don't know yet.
Closing this issue for now.


Set up Webpack to deploy to S3 (WIP)

Using https://github.com/MikaAK/s3-plugin-webpack

Sweet - I rebased off of that as well, looks like it got another change in there from master.

          1 Warning

:warning:
Please provide a linked tracker story for this PR in the description

  Generated by :no_entry_sign: danger

I left it in there for now so localhost (still running with node) will still work, but once it is rolled out I can go back and update to use the api version.

@alanpeabody that second to last commit (https://github.com/ello/webapp/pull/276/commits/0da7a4512eec9a59446dc5c47410b4b4fd197633) removes the express route for webapp-token from the dev server setup and moves over to using the api route 🤘


Issue templates

Closes #109

I'm still in-progress and will be adding a new content one, as well as one for UI issues. Do you get pinged for this as if it's asking for a review? Maybe I should leave things as in draft mode until I'm ready :)

Merging so that I can see how it renders in our repo -- may have to followup with a quick fix

Do you get pinged for this as if it's asking for a review? Maybe I should leave things as in draft mode until I'm ready :)

Ah yeah, my notifications are basically the same for when asking for a review vs simply opening a PR. Marking it draft and/or putting WIP in the title is indeed very useful!


Masternode Rewards on stats page should not take the stake into account

Stats page:

Currently, on the stats page, we indicate the "Reward" earned by a masternode for each epoch.
At the moment, the "Reward" amount takes into account the Infrastructure Reward AND the Staking Reward.
It can give the false impression to a user with little experience that a node performs better than the other if the "Reward" is higher. This is false because if 2 nodes sign the same number of blocks, one could get a bigger "Reward" only because the node operator staked more Tomo in it than the other and the node of the first have a smaller Capacity.
If we want to give information to the voter to help him make good decision, the only relevant Reward is the Infrastructure Reward, which is linked to the number of block signed. The staking reward is not in any way linked to the masternode performance. It is a reward that a node operator would get if voting for himself or for any other masternode.
I also think that at the protocol level, we should separate staking rewards and infrastructure rewards as it was the case at the launch of mainnet so we could easily differentiate them in Tomoscan. This will be useful for tax purposes and also if a group of user want to create a joint venture for running a node (they could decide to split the Infracstructure Reward equally, while they would split the staking reward in proportion of their stake since they would earn this reward any way if they were not running a masternode... at the moment it is very hard to know what is what).

I second and third this. We were talking about it amongst a group of Masternode owners. It’s very confusing to both voters and owners. Voter could perceive you as receiving less rewards (less powerful server). MN operators think other servers are getting unfair reward compensation.

done in v1.3.0


Add support for the stack switching proposal

This patch implements the stack switching proposal (which at the time of writing is a phase 2 proposal).
The proposal adds a new composite type:

cont $ft indexed by a function type, which is the type of a continuation.

Two new abstract continuation heap types and their subtyping hierarchy are added:

cont the top type;
and nocont the bottom type, i.e. nocont <: cont.

Six new instructions:

cont.new $ct, parameterised by a continuation type index, which creates a new continuation.
cont.bind $ct-0 $ct-1, parameterised by two continuation type indices, which partially applies a continuation of type $ct-0, resulting in a continuation of type $ct-1.
suspend $tag, parameterised by a tag, which suspends the current context.
resume $ct (on $tag $label)*, parameterised by a continuation type index and a jump table which maps tags to labels (similar to how (catch $tag $label) works in the exception handling proposal); this instruction resumes a continuation.
resume_throw $ct $tag (on $tag-1 $label)*, parameterised by both a continuation type index and a tag index (in addition to the jump table). This instruction injects the exception tag $tag into the continuation argument.
switch $ct $tag, parameterised by a continuation type index and a tag index. This instruction performs a direct context switch to a given continuation (i.e. a symmetric transfer of control).

The wellformedness condition for tags is relaxed, such that they are allowed to have a non-empty result type. This result type is used to validate the types of return values of suspend $tag.
The features of the proposal are gated under a new feature flag stack-switching (off by default). Most of the additions are test artifacts. The implementation of the proposal itself is modest.

There are a few things in this patch that I am not quite sure about:

I have used a UnpackedIndex in the representation of the new indexed continuation type. In the validator I sometimes have to work with CoreTypeId and other times with raw u32 indices. I am not convinced this is the best approach.
In validating cont.bind and the jump tables (aka resume tables) on resume and resume_throw, I have to construct and manipulate the underlying function types of continuations, in particular, I have to check subtyping relations between parts of these function types (c.f. cont.bind where I have to drop a prefix of the parameter list). So I have had to essentially reimplement function subtype checking. I have done this via a function is_subtype_many that applies the is_subtype function pointwise to two equally sized collections. I am not particularly fond of this approach.
I have not extended the TagKind structure. Though, an argument can be made for adding a further kind, lets call it Control, to differentiate exception and control tags internally. But I am not really sure whether the distinction is helpful.

Thanks for your feedback! I think the key change was to represent the index on continuation types as PackedIndex. It makes everything much nicer.

And no rush of course! Just wanted to check in

Thanks Alex! I have implemented your feedback now. The issue of whether we will encode the index on continuation types as an u32 or a s33 is yet to be resolved on the spec repo. In the meantime I have reverted back to the s33 encoding to stay in sync with the reference interpreter.

Thanks for your help!


uncss support?

Are there plans of adding uncss support to jekyll-assets? Basically what I mean by uncss is where unused css tags are stripped from the built code
https://github.com/giakki/uncss

No plans so far. As well as all 3rd-party integrations will be removed from core in future release. They will be pushed to extra gems, e.g. jekyll-assets-autoprefixer. So if anybody wants to jump on creation of plugin for jekyll-assets for uncss support I'll be happy to help, but I think source of jekyll-assets-autoprefixer will provide all the insights on how to write a plugin.


more common sequence diagram

This PR will replace sequence diagram in the spec with one using more common format.

Currenly section in a spec has 8 bullet points, this diagram has 12. It splits 2 bi-directional arrows into separate req/res and adds req/res for getting user's WebID profile. If we agree on those changes I'll adjust bullet points in the spec and change from draft to PR.

Sequence diagram now has bullet numbers matching to the list.


Card Field on android not opening app crashed

@cpytel @zubko @jlongster @sguha00 hy i am using react native and on android card field is not opening , app is crashed ,
react native is 0.73.0 and stripe is 0.35.0
### Tasks

### Tasks

also seeing this

@angelo-hub its done , i am using the cardField inside modal so if you are doing the same then remove it.


⚠ GitHub has degraded performance

In d57bb0c, GitHub (https://www.githubstatus.com/api/v2/status.json) experienced degraded performance:

HTTP code: 200
Response time: 171 ms

Resolved: GitHub performance has improved in 0041002.


[ArchBoard] Azure-Storage-queue  API Review

Complete API  from following .
https://apiview.azurewebsites.net/Assemblies/Review/5f8f08d0908247158f30b451a91f252e

[ ] IpRange -> SasIpRange -> move to sas package

[ ] dequeueMessage -> getMessage

[ ] QueueSasPermission hadRead..->hasRead

[ ] QueueServiceSasQueryParameters use full name

[ ] DequeuedMessage get/setTimeNextVisible() -> get/setNextTimeVisible()

[ ] Move SharedKeyCredential to root package

[ ] public AccountSasPermission setAddPermission(boolean hadAddPermission) {}

[ ] public AccountSasPermission setListPermission(boolean hadListPermission) {}

[ ] public AccountSasQueryParameters(Map<String, String[]> queryParamsMap, boolean removeSASParametersFromMap)

[ ] public AccountSasResourceType setObject(boolean object) {} // better doc

[ ] BaseSasQueryParameters getQueryParameter(Map<String, String[]> parameters, String name, Boolean remove, Function<String, T> converter) Boolean -> boolean

[ ] SR review and remove

[ ] SharedKeyCredential->StorageSharedKeyCredential

[ ] SharedKeyCredentialPolicy -> StorageSharedKeyCredentialPolicy hidding from public?

[ ] RequestRetryOptions getter and setter

dequeueMessage -> getMessage
https://github.com/Azure/azure-sdk-for-java/pull/5857

IpRange->SasIpRange:
https://github.com/Azure/azure-sdk-for-java/pull/5863

RequestRetryOptions getter
https://github.com/Azure/azure-sdk-for-java/pull/5867

For reference: linking to another set of Queue API feedbacks https://github.com/Azure/azure-sdk-for-java/issues/5671. All work items in this issue are addressed.

DequeueMessage rename:
https://github.com/Azure/azure-sdk-for-java/pull/5876/

Rename ShareKeyCredential and its policy
https://github.com/Azure/azure-sdk-for-java/pull/5899


Make samples can run on Yarn

Make samples in default category can run with validation on YARN.
Add interface IFileSystemHelper to hide implementation details for different file systems.
Implement concrete FileSystemHelper classes for local file system and HDFS.
Move IFileSystemHelper and impl to a new project "Utils"

Current coverage is 76.43%

Merging #345 into master will not affect coverage as of 2f3209e

@@            master    #345   diff @@
======================================
  Files           42      42
  Stmts         4359    4359
  Branches       382     382
  Methods
======================================
  Hit           3332    3332
  Partial        165     165
  Missed         862     862

Review entire Coverage Diff as of 2f3209e

Powered by Codecov. Updated on successful CI builds.


Add MinimumOSVersion and  CFBundle[Short]Version to the Info.plist.

Fixes issues reported by the community when submitting to TestFlight with Xcode 15.4.

I think it's alright to leave the bundle versions as 1/1.0 and not increment them, but we should probably come back and do that later anyway.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 89.42%. Comparing base (8768d28) to head (eff4f6c).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #981      +/-   ##
==========================================
- Coverage   90.22%   89.42%   -0.81%
==========================================
  Files         177      104      -73
  Lines       21084    17907    -3177
  Branches      301      301
==========================================
- Hits        19024    16013    -3011
+ Misses       2056     1890     -166
  Partials        4        4

Flag
Coverage Δ

uitests
?

uitests-ios
?

unittests
89.42% <ø> (+0.08%)
:arrow_up:

unittests-ios
?

unittests-react
87.99% <ø> (ø)

unittests-rust
89.64% <ø> (ø)

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Implement PID Gain Setting for Master Arm

Implement PID Gain Setting for Master Arm

This feature has been implemented in v0.3.0 (11b1d33360a05e63c9446b1e954a7edbcf9b95ee)


[Bug]: Linear Targeting Blind Spots

Is there an existing issue for this?

[X] I have searched the existing issues

Have you tried to reproduce this without OP?

[X] I have tested without OP

Current Behavior
Linear targetter seems to be from feet instead of the head or something close to that. No matter the tolerance of the targetter, this is not resolved since it doesn't target things behind you (more than 90 deg from looking angle)
In this image is the furthest I can look at a slime without the skill hitting the mob

Same image first person

As long as my feet are in the slime It will not be targeted by linear

Slime hitbox is 1.0404 blocks tall and it will only get targeted from 0.9 blocks and above.
However it seems to target the slime behind which is confusing

For larger entities like players , this blind spot is less noticeable and is from 1 block away when looking bellow 45 degree while standing anywhere that is under +0.7-0.8 from the mob ground (being above 0.7 works but if you are bellow that value, within 1 block and looking down more than 45 deg you cant target anything)
Setting tolerance to 0 seems to not account bigger hitboxes since on player size models the edges of the hitbox seem to be fine but for example with slimes it requires to aim a bit further into the hitbox to be able to hit it. This last part does not impact me but its something to note at least.
Expected Behavior
No response
Steps To Reproduce
No response
Environment
-

latest.log
No response
Anything else?
No response

Expanding onto this, I have noticed that targetters do not hit targets that are within the entity's hitbox aka when hitboxes collide


Replace onRangeChange with handle methods

#378
This PR removes onRangeChange prop because it is an obstacle to achieving #378 .
Instead, this PR adds startIndex/endIndex getter to handles and onScroll to WindowVirtualizer, that opens more flexible configuration.

Additional discussions:
https://github.com/inokawa/virtua/discussions/544


Add reCAPTCHA integration

Closes #12
Closes #13

Hi Andrei, thanks for taking a look at this - a recaptcha integration is a good addition. Is there any chance you can update your pull request with setup instructions in the readme? When I first looked at the PR I assumed the recaptcha would be displayed on each form request, but it looks like it has to be added as part of the form, so it would be good just to clarify that.

Hey Daniel, I just added some additional documentation. How does it look?

@danielireson Any chance you could merge this? Been looking forward to adding this to my site as well.

Any update on the merge process for this?

I'd also appreciate if this branch is merged. We've been using Formplug for a couple of months now on two different contact forms but every now and then we receive spam emails through form submissions.

My apologies for the delay in getting back to this. I appreciate the work that you put in here Andrei but after looking further at the change I decided against merging.
This decision was primarily based on the use of the google-recaptcha npm package which hasn't been updated since March 2017. Whilst the use of an old package isn't inherently wrong, it does suggest that it's no longer being maintained. In this case, it feels more appropriate to interact with the Google reCaptcha service directly rather than through a dependency. As described in the reCaptcha docs, we can be verify responses by making an API request.
I have added reCaptcha v3 support as part of the v1.2.0 release so I'm going to now close this pull request. Thanks again for taking the time to put this together.

Hello @andreialecu!! How are you? 😄  Since you were the mastermind behind this PR I would love to know if you could give a little help on #23. hCaptcha is a privacy-focused alternative to reCaptcha that doesn't sell any personal data and would be nice for the people that want could use it instead. Really thank you!!


能否添加line app的图标

能否添加line app的图标

OK

The line app icon has been uploaded to the MingCute website. You can find it under the logo category in version 2.5. Please star the MingCute project.


[Bug Report][GNU/Linux] Memory usage not freeing with dispose

I' just noticing that the memory taken up by both my own and the test application on linux (I have not tested other platforms) is never clearing. It is fine to begin with but eventually does get out of hand. I looked a bit and didn't really see an issue with flutter itself pertaining to this so i was just wondering if there was any insight.

You can see the attached video in README showing test application running on Windows. The memory is free'd when going back from the video render screen.
Flutter shell for GNU/Linux is retarded. There are many other issues as well. For instance: #64.

Not able to figure this one out. Memory leak still happening. What I tried :-

As some suggested in a libmpv issue, I upgraded libmpv to master (0.35.1+) using mpv-build
Checked on any errors with mpv logs - no errors
Event mpv-end-file(called when file unloads) is getting called - no errors here
Checked if loadfile is getting called twice - no. It's getting called only once per load
Disabled audio tracks with aid -> no
In dispose of player

property idle -> no
property keep-open -> no
commands stop, playlist-clear, playlist-play-index none & then quit
mpv_destroy / mpv_terminate_destroy - terminates the core player / the app respectively

I have experimented with it a lot before.
Think yourself, if same code is working correctly on Windows & macOS (memory gets free'd as intended). Certainly, something is wrong within the Flutter embedder or Dart VM for GNU/Linux. At least how it treats memory or garbage collects it. There are no memory leaks in my code.
IIRC even if you don't create any VideoController & just Player, memory will still leak on GNU/Linux. I can't do anything at least in the short term for GNU/Linux. Best recommendation I can give is to keep a pool of Player & VideoControllers.

It's happening in Windows too unfortunately. Here's a demo that loops on a test video - but initializes & destroys player every time - demo
It surely doesn't crash as fast as in linux. Takes a bit longer to pile up than linux. For me, win 10 - 2gb gpu, it took about 7 mins to go from 120 mb to 500 mb.

Let me correct it:

It never crashes like GNU/Linux. Takes far-far longer to grow as compared to GNU/Linux but never exceeds a limit in idle state.

https://user-images.githubusercontent.com/28951144/229049817-7ad75df2-eb76-4046-a9bf-22ce5c1a4634.mp4
It's more as to how Dart VM treats the memory, how OS schedules things etc. You can see that memory is freed automatically sometime afterwards, it can be: Dart VM itself, libmpv internals e.g. demuxer cache, FFmpeg internals, Windows scheduler etc. If you leave it suspended for more time, the memory drops further down.
Note that mpv actually occupies space for cache in memory which is necessary for smooth playback of any kind. You can adjust it with --demuxer-max-bytes. I won't really recommend it. Since... it's not really a problem, the memory usage is fine. Improvements can definitely be made over time.
But yeah... GNU/Linux situation is serious.
The pool based solution should still be helpful. Who knows... what if Google Chrome also recycles same instances once created. Realistically, you are never going to have more than 5 at once.

I have spent about 20-25 hours on this in the past months... and am still clueless. Tried so many combinations of flags. Not sure if it's mpv core or if it's gnu or if something else. Definitely nothing to do with media_kit code... i think, not sure if something weird happens over texture / angle. Will look into it again when I get the time. Leaving videos running in the background for long durations is critical for my case (digital signage player).

How sure are you that's not a bug in your code?

Im disposing the player properly before assing the new player instance.

Hello.
For people experiencing this on Linux (@femalemonkeyman , @srix55 )
Can I ask you which version of glibc you are running on ?
Latest version 2.37 introduced some new behavior that prevent some memory pattern reallocation to actually reclaim unused space: https://sourceware.org/bugzilla/show_bug.cgi?id=30579
This is fixed for next release and for 2.37 but most distributions does not ship this patch yet.
Using glibc 2.37, I have a huge memory leak when lauching the multiple reader test case. I go to 30G in about 2minutes.
Tried the test example with mimalloc and didn't experience the leak. Memory raise a bit while playing videos but reduce when going back to the menu.

@ndusart  Mine is ldd (Ubuntu GLIBC 2.35-0ubuntu3.1) 2.35
In another issue, someone said that it's taking too long for mpv to get destroyed and that's causing a buildup to a leak - #295 and it seems to be fixed now. I am yet to test the latest version.

Hi @ndusart,
Your comment & the bug-report you linked is quite interesting.
The memory issue is solely present on GNU/Linux & seemingly memory never gets freed. You can see the video I attached above (Windows), where memory gets freed as intended (it has been further improved after latest updates).
The project will be greatly helped with any workaround or fixes. We currently bundle package:ffi v1.2.1 within package:media_kit.
I'm really curious to know how you tested our example application with mimalloc (updating native video rendering code? updating package:ffi calloc?). And, if the improvements are geniune, consider raising a PR.

I have no hate for GNU/Linux, but there are many issues, it's like nothing is stable & the quality is also not optimal. Few issues other than this still remain:

As it seems, GDK/GL can be even slower than software rendering:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6042
After recent Flutter updates, the subsequent Texture widgets don't work with GL (& our software code path starts working)
i.e. first Texture widget will work correctly (hardware accelerated) & rest will fail to initialize GL context.

@ndusart Arch glibc is at 2.37-3 which is where I am

I just tried out mimalloc with our test application & the improvement is real. Now memory gets released as intended on GNU/Linux.

Hi @ndusart,

You figured that out already it seemed. libc memory allocator can be overriden thanks to LD_PRELOAD env var.

Yeah! I used it later (made comment early in excitement ^^).
I have wasted my weeks trying to fix this GNU/Linux memory leak.

But still, the stress test is raising indefinitely in memory for whatever memory allocator I use.

No, it's not normal. It doesn't happen on other platforms (Windows, Android, macOS & iOS).
For the note, I'm still going to blame glibc & it is only it's fault. Same implementation works 100% correctly & does not leak on other platforms.
I had this memory issue on GNU/Linux long before I implemented video rendering (FYI: package:media_kit was created to power Harmonoid ~ a music player; no video rendering. You can still see me getting bashed in the issues for performance on GNU/Linux). The memory used to leak even when there was no video embedding. I honestly didn't know that it's this easy to switch allocators ^^ (& if it was even possible).

Now, for the good-news:

But still, the stress test is raising indefinitely in memory for whatever memory allocator I use.

So, actual leak was fixed by switching to mimalloc.
First of all, I don't have experience in GTK/GObject etc. I've mostly worked with Win32 & standard C++. In current implementation, I followed the recommended "GObject practices" as good as I could. Still... I'm not very familiar with it.
It turns out I was leaking a new instance of GThread* upon every render in software rendering! I wanted to create a detached thread, somewhat like std::thread::detach which automatically frees itself once it's execution is done.
I fixed this in: https://github.com/media-kit/media-kit/pull/319 :tada:
Now a good question may be, why was memory growing in stress-test if it's only in software rendering, aren't we using hardware rendering by default? Like I said in the comment above:

After recent Flutter updates, the subsequent Texture widgets don't work with GL

When multiple Videos are mounted, only first one uses H/W & rest fallback to S/W due to issue introduced by recent Flutter version. This didn't happen before & I will file an issue at flutter/flutter.

Now it's not leaking at all.

Screencast from 04-08-23 08:50:18 PM IST.webm
You are right. This seems to fix the leak :) Thanks @alexmercerind & @ndusart . I was testing it the whole day. (Although my application still leaks - i think it's because of the pre-fix myriad optimizations that are getting in the way). I did an isolated test with 6 concurrent players disposing & playing short videos at random. Doesn't seem to leak memory. :balloon: :partying_face: :balloon:

@srix55 the CPU usage should be 0.0% ideally.
#329 will reduce the CPU usage by large margin (like in the earlier versions). Now multiple videos use hardware decoding correctly & don't fallback to software decoding.
That 0.0% only works on NVIDIA devices only for now (through NVDEC). VAAPI unfortunately will only work with -copy on GTK 3.0.
On my entry-level Ryzen 3 2200 U with integrated Radeon Vega 3, I'm able to play around 20 HD videos at once without any lag. 4K 8K 60 FPS works as intended. The performance should be higher on capable devices.

A final note for the future visitors:
Memory leaks on GNU/Linux have been resolved & it is recommended to use mimalloc in your project:
Refer to "Utilize mimalloc" section in the README.
You just need to add one line in your linux/CMakeLists.txt:
target_link_libraries(${BINARY_NAME} PRIVATE ${MIMALLOC_LIB})

I tried to eliminate this requirement of manual modification from developer's end, but it's not possible.

It'd be good idea to let glibc's developers know what's wrong.


Remove polyfill

We're using CloudFlare CDN which automatically replaces it with a safe version, but we should remove it completely.
https://blog.cloudflare.com/automatically-replacing-polyfill-io-links-with-cloudflares-mirror-for-a-safer-internet

Let Chirpy fix it - don't worry about it here


feat:  compile the target image just in time (JIT) for AR.js

Hi, i want to compile the target image Just in time (JIT) but a .mind file in the threejs-mind. #247
Exp:
// Step1: Compile the target image for remote image url
async function loadImage() {
  return new Promise((resolve, reject) => {
    let img = new Image();
    img.crossOrigin = "Anonymous";
    img.onload = () => resolve(img);
    img.onerror = reject;
    img.src = 'https://foo.com/avatar/dengjudeng.png';
  });
}
const images = [];
images.push(await loadImage());
const compiler = new window.MINDAR.IMAGE.Compiler();
const dataList = await compiler.compileImageTargets(images, (progress) => {
  console.log(progress.toFixed(2));
});

+ const exportedBuffer = await compiler.exportData();

// Step2: Render with threejs-mind
const THREE = window.MINDAR.IMAGE.THREE;
const mindarThree = new window.MINDAR.IMAGE.MindARThree({
container: document.querySelector("#container"),
- imageTargetSrc: './assets/card-example/card.mind',
+ imageTargetBuffer: exportedBuffer,
  filterMinCF: 1,
  filterBeta: 10000,
  missTolerance: 0,
  warmupTolerance: 0,
});
const {renderer, scene, camera} = mindarThree;
// ...

Hi, could you help me ? @hiukim

Or we can compile the remote image online ? @Parikshit-Hooda @Makio64 @

Thanks for the PR. It could be an interesting features to compile images at runtime, but I'm not very convinced it should be done inside the addImageTargets method of the controller. I guess something like this could be achieved by just calling the compiler function to generate the dataList of buffer and then pass that into the controller.


Evaluate step can not parse the sample data it has generated, when using Swedish locale

System Information (please complete the following information):

Model Builder Version :  <IP_ADDRESS>2701
Visual Studio Version : Microsoft Visual Studio Enterprise 2022 Version 17.1.0 Preview 1.0

Describe the bug

On which step of the process did you run into an issue: Evaluate

Clear description of the problem: I have imported data from a csv file where . is used as decimal separator. The "Data" and "Train" steps work but in the "Evaluate" step when clicking "Predict" an error message is shown: "Air temperature was expected to be Single but couldn't be parsed". If I manually change the decimal separator from . to , it works.

To Reproduce
I have Windows set to use Swedish locale and followed the steps in the learn module Train a predictive maintenance machine learning model with ML.NET Model Builder - Exercise: Train a machine learning model
Expected behavior
I expected the software to be able to parse the data it automatically filled in in the user interface, since it was able to parse the data during import and training.
Screenshots

@LittleLittleCloud Maybe this one too?

To fix it thoroughly maybe we should make dataset invariance to local culture and only respect to it's own parsing option? Otherwise it would be unlikely to figure out what's the expect behavior when dataset has a different culture setting (like in this case)
Let's talk about it offline @beccamc . For now @hollowdrutt you should be able to work around it by changing . into ,

There have been a few reports of this. It would be nice to fix this in the next release.

Release is out. I found it difficult to test this one so please let me know if you run into any problems. Thanks!

@beccamc I have tested the same steps with the latest version and now it works, thank you!

Awesome! Closing this issue.


Minor issue on MacOS Apple Silicon - slider mouse tracking incorrect

First of all, I love this project.  I ran some of the demo apps on MacOS and the slider control has a bug where the mouse tracking / slider thumb tracking are inverted...  You click a slider thumb button, start dragging to the right, the nApp code places the slider value at the opposite value (e.g. say you click on position 0, the start of a slider - the code thinks you clicked at 100 and jumps the slider to 100... then when you slide to position 1, it jumps the tracker to position 99 and so on...).  Prob just a simple (neg / pos value calculation bug or something like in the code) fix.  When I have time and get the code built on Mac I'll look into it myself.
Unrelated note, I tried to build on Mac (M1 chip) with Xcode installed and Cmake installed and the CMake build spit out "Can't find compiler" type error.  I'll open an issue about it some other day.  But, once I get that sorted out so I can build run debug code.  I'm sure I can pretty quickly find the issue with the slider tracking and offer some insight on it.
Thanks for this project!!  It's like reading my entire career history of everything tool/framework I've either tried to use or tried to build myself bc I hated most of the cross platform tools and then I finally found this project...  This is EXACTLY what I've been looking for, for years!!  BRAVO for great work!  Code is super clean...  I don't know jack sht about CMake otherwise I could have figured out how to build it.  But, I've read a lot of the code and I love it...  (old school Win32 API / C developer and recently been learning and doing some Mac coding but with Swift which I hate...)

Hi @chris-deep!
Thank you very much for your feedback and your words for the NAppGUI project. I hope the project suits your needs.
The problem you describe has already been corrected in this commit:
osgui/osx/osslider.m
https://github.com/frang75/nappgui_src/commit/34b3f2551c4b884e65270b0f35f50240a26e0935
The pre-built demo apps have not been updated yet, but if you build from source, you'll see that it works fine now.
Thanks again, keep in touch.


Sky Editor WPF has stopped working.

I use Sky Editor for Pokemon Mystery Dungeon Red Rescue Team and I've tried two times now to edit stored Pokemon only to have Sky Editor encounter some error.

Is this using Sky Editor 4.0.5?  Can you upload the save you're using?
I'll try to release a small update to report more information later if you'd rather not.

Here is the save.
https://www.dropbox.com/s/v31s48cpevf97vz/2485 - Pokemon Mystery Dungeon - Red Rescue Team (U)(RDG) Auto.sav?dl=0
And I was using Sky Editor Alpha <IP_ADDRESS>. I got it from here.

Please use v4.0.5
http://www.skyeditor.org/Home/Post/209/Release-Sky-Editor-s-Save-Editor-Beta-4-0-5
Guess I need to make it a little more obvious that I've been moving things to different repos.

This worked. Thank you. Also, do you know if a Pokemon Battle Revolution Save Editor exists?

I think PKHeX has some Battle Revolution editing now.
https://projectpokemon.org/forums/showthread.php?36986-PKHeX-Gen-1-6-SAV-PKM-Editor

I think I have to compile something but I don't know how. :/
On Wed, Nov 16, 2016 at 9:15 AM, Evan Dixon<EMAIL_ADDRESS>wrote:

I think PKHeX has some Battle Revolution editing now.
https://projectpokemon.org/forums/showthread.php?36986-
PKHeX-Gen-1-6-SAV-PKM-Editor
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/evandixon/Sky-Editor/issues/29#issuecomment-260971235,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQHhpAtNOHWGs5oHAYmXQlpE0YgvusZFks5q-x4ggaJpZM4KwdEf
.


Add FreeBSD installation instructions

ov has recently been added to the FreeBSD Ports Collection: https://www.freshports.org/textproc/ov/
Cheers!

Wow, that's great. Thank you for telling me!


single executable jbang-based junit test class

targets issue  #721
FIrst pass at a single junit test class that's executable by jbang CLI

Thanks @blafond!
It needs some minor improvements to the way it's documented but overall it looks good to me.
An alternative would be to create something  closer to what we do for the examples.
I've created a quick POC here: https://github.com/DavideD/hibernate-reactive/blob/721-jbang-executable-test/tooling/jbang/Example.java
If you want to see them in action, here's how it work:

Download JBang
Start the default Postgres we use for tests (you can replace podman with docker):podman run --rm --name HibernateTestingPGSQL \
-e POSTGRES_USER=hreact -e POSTGRES_PASSWORD=hreact -e POSTGRES_DB=hreact \
-p 5432:5432 postgres:13.2

JBang it:jbang https://github.com/DavideD/hibernate-reactive/blob/721-jbang-executable-test/tooling/jbang/Example.java

orjbang https://github.com/blafond/hibernate-reactive/blob/721-jbang-executable-test/tooling/jbang/SampleIssueTest.java

(Optional) If you want to edit the class with Ideajbang edit --open=idea https://github.com/blafond/hibernate-reactive/blob/721-jbang-executable-test/tooling/jbang/SampleIssueTest.java

Not sure which one I prefer. Maybe we can keep both? The JUnit one could be helpful to show how one can test Hibernate Reactive (maybe we can make it make it slightly more complex and add a couple of tests instead of only keep one) while the example one might be more familiar to the user and we can keep it simpler.
Note that I've asked @blafond  to not create a template for now (because it makes it slightly harder to prototype with them). I think it makes sense to convert these classes to JBang templates ones we are happy with them and we can send a pr to JBang to add them to the catalogue.
@gavinking What do you think?
@gbadner, @Sanne In case you are interested and want to see an example of JBang in action
Cheers


merge dev into master

Bluemix toolchain: Delivery Pipeline deployed acme-freight-controller to acme-freight, including commit 845b12e8cfa4083183f6bb0b5def7a6c5c20acd5

Bluemix toolchain: Delivery Pipeline deployed acme-freight-controller to dev, including commit 845b12e8cfa4083183f6bb0b5def7a6c5c20acd5


Moderation / trust & safety

Background
There are spamming posts on Devhub and we want to prevent these posts.
Requirements

Requirement 1: Need a way to force people to comply with our Code of Conduct
Requirement 2: Need a way for people to report a post & a mechanism for moderators to receive those
Requirement 3: Need a way to moderate: Hide/delete a post
Requirement 4: Need a way to ban specific users

When I ban a user, it will:

Remove all of their previous posts
Prevent them from creating future posts

Technical Details
We will need to add these feature to smart contract, on SocialDB and the frontend.
For requirement 1, when user log on to the new version of DevHub, we can check if there is a marker set in SocialDB that he has accept the code of conduct. If not, a Code of Conduct dialog should pop up and ask the user to click accept the terms. The button will store the marker to SocialDB so the dialog won't popup next time. (Estimation: 1 day)
For requirement 2, their should be a new type of action added in smart contract, we can it report_post. Techincally it's similar to the implementation of like_post, and store post flagged by certain user at certain timestamp on smart contract. And instead of notification to the author, it notifies moderators, which is update all moderators SocialDB entry of notification. And also update notification type to display notification of "Post Reported" type properly on gateway. (Estimation: 3 days)
For requirement 3, on contract side this should be supported, mark a post to be hidden or deleted. I suggest to call this action delete_post. Only moderators are allowed to perform this action. When call delete_post, It will set the newly introduced field post.deleted to true. Also update add_post, edit_post and like_post to not allow add comment, edit or like a deleted post. Also, delete_post will cross contract call the SocialDB contract to notify the author that his post is flagged.
On indexer, all post feeds or search result for frontend should filter deleted=false posts, so deleted posts won't appear in frontend.
On frontend, the top level deleted posts won't show up due to indexer has filter out these posts. Frontend should filter out non top level deleted posts, when rendering post comments, and if it's deleted, skip render it and hence itself and all its children are hidden. When rendering posts, it also show up icon for moderators to call delete_post. Also on frontend, once a deleted post type is accessed directly via id, it should display some empty placeholder saying "This post is deleted due to violation of the Code of Conduct".  If a deleted post's child post is accessed directly via id, it can be displayed, so it won't affect non violation post link to be shared with others. Finally, update the notification item widget to display "Post Flagged" notification to the author on gateway's notification feed.
(Estimation: 1 week)
For requirement 4, on contract side add a ban_user function that delete all posts of the author, and store the user_id in a new UnorderedMap called blacklist. When a user try to perform add_post action, first check if he is in blacklist and prevent if so.
On frontend side, at post editor page display a banner to the user if he is blacklist, and prevent him to use the post editor. (Estimation: 1 day)
Overall: 2 weeks and I will break down these to 4 separate tasks,  each for one major requirement.
### Tasks
- [ ] https://github.com/near/neardevhub-widgets/issues/493
- [ ] https://github.com/near/neardevhub-widgets/issues/495
- [ ] https://github.com/near/neardevhub-widgets/issues/496
- [ ] https://github.com/near/neardevhub-widgets/issues/497

After discussing with @gabehamilton we have an alternative way which heavily rely on indexers and SocialDB to do the moderation. Demonstrate below:

Requirement 1: Need a way to force people to comply with our Code of Conduct

This isn't changing, we still store this information still stores on SocialDB, so estimates to take 1 day.

Requirement 2: Need a way for people to report a post & a mechanism for moderators to receive those

Fork and use this menu component to report a post, which stores the reporting and hiding information to SocialDB. The difference between reporting and hiding is that, reporting if approved by moderators, will be apply globally to DevHub. Hiding is a local preference that's effective only to current account.
Then implement an indexer to collect reports into a similar table like this moderation_reporting table. The indexer code can also be fork from dataplatform.near/moderation indexer with minor changes.
This indexer also calculate moderation decisions from indexing moderators' approve transactions and also who should be considered as moderators are determined by this indexer. Then indexer puts the result in the moderation_decisions table.
This indexer will also create a view, similar to the moderated_posts, which joins devhub indexer's posts_with_latest_snapshot and filter out those moderated posts.
Then we should fork the Moderator interface widget for moderators to see those reports.
Given the uncertainty introduced in setup and debug QueryAPI indexers, this step takes estimated to take 3 days.

Requirement 3: Need a way to moderate: Hide/delete a post
Requirement 4: Need a way to ban specific users

When I ban a user, it will:

Remove all of their previous posts
Prevent them from creating future posts

Using this approach these requirements are handled together.
For hide a post, the frontend needs to futher apply user's hiding settings, created by the menu component described in requirement 2.
For delete a post and delete all posts from certain users, these are already done in the indexer in requirement 2.
This step estimates to take 1 day.


maixbit: add basic integration tests

I made some tests for the MAix Bit which I am currently working on in TinyGo. I dont know if maybe you wish to add this board to TinyHCI, this would be a start :).
This PR depends on https://github.com/tinygo-org/drivers/pull/163.

Hi @yannishuber this is great!
A few changes and additions that will be needed. First of all, the way that I get each device to mount all at the same time on a known port is by adding here:  https://github.com/tinygo-org/tinyhci/blob/master/tools/udev/99-named-devices.rules
You will need to make change to tools/server/boards.go to make the port name you add to the udev file.
OK, next, need to add the flashing tool used for this board, and any dependencies, to the Dockerfile here https://github.com/tinygo-org/tinyhci/blob/master/tools/docker/Dockerfile so that the tests can be flashed onto the board during the check run.
Regarding the test itself, the reason I use the MPU-6050 for all of the I2C tests is that I have a lot of them, and having a single standardized peripheral makes it easier. You might not have one, so I can replace that code for testing if you want.
I also generally create a task in the Makefile so I can flash/run the tests separately just to verify they are working: https://github.com/tinygo-org/tinyhci/blob/master/Makefile#L44

@deadprogram I made the changes you requested. I don't have an MPU-6050 so yes you can make that change, thank you.


Is the logo really ... exactly what it appears to be?

The name of the frame work is "bare". It's "classless".
The logo is a pair of uneven breasts that get perky and jiggle when you mouse over them.
Umm....
I love the classless css idea, but the logo is so on-the-nose that I'd never be able to recommend it publicly or share with coworkers and colleagues.
Any chance you'd reconsider the logo?

I like it. It's like double double entendre.
Bare css; bare breasts. A framework without classes; a logo without class.
Perfection.


Any way to know the history of alerts?

As far as I know, if the alert is resolved, it will be GCed after a while. And for the same alert, if it is resent multiple times, it will be aggregated.
So any good advice if I want know the history of alerts, including all of the alerts (resolved and firing) and how many times the same alert is emitted.
Maybe I could configure the alertmanager notify to the webhook server and persist alerts in it. But if I configure silence or inhibit, then the webhook server will not get all the original alerts.

If you really want to keep a track of all the alerts then the best option is to have Prometheus sending the alerts to an external service that will store them elsewhere.
I'm closing it for now. If you have further questions, please use our user mailing list, which you can also search.


Add queue charts to dashboard

Motivation
Add more charts with new queue metrics
Description

Also:

Left-pad subnet label. Correctly sort them, otherwise Grafana does: [1,10,11,12]
Improve local version info fetching to show in the Grafana dashboard on Dockerized and non-Dockerized setups
Move local version info fetching logic to the CLI
Print to console the local version info


Substrate runtime interface 2.0

The current runtime interface lives in sr-io and wasm-executor. Any change that is done in sr-io requires manual changes to the interface declaration in wasm-executor. This pr introduces an attribute proc macro #[runtime_interface] for declaring and implementing a runtime interface. The runtime interface is declared like a nomal rust trait declaration with default method implementations. This declaration is split into the native implementation, the wasm implementation which calls the corresponding external function and the implementation of the external function on the host that calls into the native implementation.
Values between the runtime and the host are not SCALE encoded by default. There are different strategies for passing the arguments between the runtime and the host. The idea behind this is to not waste any performance for encoding the data when it is not required. Data like [u8] or Vec<u8> is not encoded and it passed directly to the host. This imitates the current behavior as it is done for the storage apis etc.
For more information, please look into the documentation :)

Looks like it needs a polkadot PR?


release-20.2: sql: fix bug where bad mutation job state could block dropping tables

PR: https://github.com/cockroachdb/cockroach/pull/58255
From release notes:

A table can now be successfully dropped in a transaction following other schema changes to the table in the same transaction. [#58255][#58255] {% comment %}doc{% endcomment %}

AFAIK, we never documented this bug as a known limitation. No docs required.


MultiChoiceView

Wraps a tag that represents multiple choices.

The choices are in [value, label, isSelected, choiceMode ] quartets.

However the client can simply pass in [value, label] and it will adapt to a [value, label, isSelected, choiceMode ] format

Adds flexibility incase the client wants to have preselected options for the user or a choice disabled from the start

Calling the method, this.outputSelectedChoicesInValueLabelFormat() will return an array containing the selected choices in [ value, label ] format only if the minSelected, maxSelected criteria is respected

For now choices can only be provided as an array (this.choices)

this.booleanView is a ViewSpec for each choice. It defaults to foam.u2.CheckBox

Screenshots demonstrating behaviour as desired:

Error is displayed if there are too few suggestions, and remaining checkboxes become disabled after reaching the maximum number of selections.
Thanks @tharmaman, this is awesome!


Should this article be expanded to include relevant information, Q126457?

This came from an old Microsoft knowledge base article, Q126457:
https://jeffpar.github.io/kbarchive/kb/126/Q126457/
Written as so:
Article: Q126457
Product(s): Microsoft Disk Operating System
Version(s): MS-DOS:3.x,4.x,5.x,6.0,6.2,6.21,6.22
Operating System(s):
Keyword(s):
Last Modified: 17-DEC-2000

-------------------------------------------------------------------------------
The information in this article applies to:

- Microsoft MS-DOS operating system versions 3.1, 3.2, 3.21, 3.3, 3.3a, 4.0, 4.01, 5.0, 5.0a, 6.0, 6.2, 6.21, 6.22
-------------------------------------------------------------------------------

SUMMARY
=======

Some versions of the MS-DOS "User's Guide" and online Help indicate that the /V
(verify) switch for the COPY and XCOPY commands actually compares the source and
destination files to determine whether they are identical. This is not correct.
The /V switch verifies that the destination file, once written, can be read. No
comparison of the files occurs.

This information also applies to the VERIFY ON command.

MORE INFORMATION
================

When you use the VERIFY ON command, or the /V switch with the COPY or XCOPY
command, the MS-DOS file system uses the block device driver command code
function 09H, Write with Verify. This verification process consists of
confirming that the data just written can be read (for example, that the data
was not written to a bad sector on the disk). No comparison of the source and
destination data occurs.

To compare the source and destination files, use the MS-DOS FC (file compare)
command after you use the COPY or XCOPY command.

REFERENCES
==========

For more information about the VERIFY, COPY, XCOPY, or FC command, see your
MS-DOS "User's Guide," or use the online Help in MS-DOS versions 5.0 and later.

"Advanced MS-DOS Programming," Ray Duncan, Microsoft Press, Chapter 14, pages
267-276

Additional query words: 3.x 4.x 5.x 6.00 6.20 6.21 6.22

======================================================================
Keywords          :
Technology        : kbMSDOSSearch kbMSDOS321 kbMSDOS400 kbMSDOS320 kbMSDOS330a kbMSDOS621 kbMSDOS622 kbMSDOS620 kbMSDOS600 kbMSDOS310 kbMSDOS500 kbMSDOS330 kbMSDOS401 kbMSDOS500a
Version           : MS-DOS:3.x,4.x,5.x,6.0,6.2,6.21,6.22

=============================================================================

I am wondering if this article on Microsoft Docs be updated with the summary and relevant information?

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

ID: 2ee5c233-971d-eace-b312-d19f2311313d
Version Independent ID: ba5ac213-59f8-d1a5-e62f-883b466f2787
Content: verify
Content Source: WindowsServerDocs/administration/windows-commands/verify_1.md
Product: windows-server-threshold
GitHub Login: @coreyp-at-msft
Microsoft Alias: coreyp

I support the expansion of the support documentation. Thank you for posting this old documentation here. I might have mistakenly believed this command compared source and destination files based on this webpage from 2013.


Preparation of the first published version

In order to prepare the final version, we need a DOI. To this end, I need affiliations for all the authors.
descrition: |
  Short description of this paper
author:
  - name: Olivier Gimenez
    url: https://oliviergimenez.github.io/
    affiliation: UMR 5175 CEFE
    affiliation-url: https://www.cefe.cnrs.fr/
  - name: Maëlis Kervellec
    url:
    affiliation:
    affiliation-url:
  - name: Jean-Baptiste Fanjul
    url:
    affiliation:
    affiliation-url:
  - name: Anna Chaine
    url:
    affiliation:
    affiliation-url:
  - name: Lucile Marescot
    url:
    affiliation:
    affiliation-url:
  - name: Yoann Bollet
    url:
    affiliation:
    affiliation-url:
  - name: Christophe Duchamp
    url:
    affiliation:
    affiliation-url:

Then a final proofreading must be done by the authors. Final modifications should be made via pull-request.

Good morning @jchiquet. Affiliations are given below. I've deleted the url field for some of the co-authors. We'll get to the proofreading asap.
descrition: |
  Short description of this paper
author:
  - name: Olivier Gimenez
    url: https://oliviergimenez.github.io/
    affiliation: CEFE, Univ Montpellier, CNRS, EPHE, IRD, Montpellier, France
    affiliation-url: https://www.cefe.cnrs.fr/
  - name: Maëlis Kervellec
    affiliation: CEFE, Univ Montpellier, CNRS, EPHE, IRD, Montpellier, France
    affiliation-url: https://www.cefe.cnrs.fr/
  - name: Jean-Baptiste Fanjul
    affiliation: Fédérations Départementales des Chasseurs du Jura, Arlay, France
    affiliation-url: https://www.chasseurdujura.com/
  - name: Anna Chaine
    affiliation: CEFE, Univ Montpellier, CNRS, EPHE, IRD, Montpellier, France
    affiliation-url: https://www.cefe.cnrs.fr/
  - name: Lucile Marescot
    affiliation: CBGP, Univ Montpellier, CIRAD, INRAE, Institut Agro, IRD, Montpellier, France
    affiliation-url: https://www6.montpellier.inrae.fr/cbgp
  - name: Yoann Bollet
    affiliation: Fédération Départementale des Chasseurs de l'Ain, Bourg-en-Bresse, France
    affiliation-url: http://www.fdcain.com/
  - name: Christophe Duchamp
    affiliation: Office Français de la Biodiversité, Unité Espèces à enjeux, Gap, France
    affiliation-url: https://www.ofb.gouv.fr/

@oliviergimenez Once you are happy with the proofreading, please let me know by closing the issue.
all the best!


Slugify for Russian charmap

Slugify for Voyager - Russian map #3027

I think it's better to "fix" the way those characters are replaced.
This way we keep language-specific things inside the array.

I agree, but the problem is, that 'ь' and 'ъ' should be just removed from the transliterated string:
i.e. платье -> plate or олень -> olen
So the character map should have special token to remove letter from the sting.

@taiwanleaftea Can't we just set 'ь':'' and other cases in _map_russian?
https://github.com/the-control-group/voyager/blob/af482b70eda00b94b8e18bb2d7f60e6d6a3b0333/resources/assets/js/slugify.js#L205

It's already set, but the "replace charmap cycle" doesn't replace this letters and leave them "as is". Later regexp replace(/[^a-z0-9]/g, _sep) replaces the letters for separator.

Then I think we should fix that, most probably the problem is here:
https://github.com/the-control-group/voyager/blob/af482b70eda00b94b8e18bb2d7f60e6d6a3b0333/resources/assets/js/slugify.js#L97
That should pass if this.chars[str.charAt(i)] is empty so we need to change how it's checked.

This should work:
_slug += (this.chars.hasOwnProperty(str.charAt(i)))

Yes, it works. Will you make the changes or should I do PR?


Workload File Format and Dask High Level Graph Implementation

What should the filetype/specs of the workload file be?

I'm not set on any filetype in particular, but making this suggestion to help spur conversation, decisions.
step: stepname3
  - depends:
    - stepname1 (not shown)
    - stepname2 (not shown)
  - task: taskname1
    - shell: bash_command && \
another bash_command
  - task: taskname2
    - depends:
      - taskname1 (these dependencies would only be tasks within the same step)
    - shell: bash_command && \
another bash_command

Each step would be a layer in a Dask High Level Graph, and so if a task depends on a task in a  previous step, it would be an interstep dependency.

With the file format I suggest above, it'll be relatively straightforward for researchers to create for small workloads, but will be cumbersome on large (many steps, many tasks) workloads.  This is okay, because it is a high priority to allow researchers to get started without needing any programming knowledge.  Do others agree/disagree?

I basically suggested almost the same thing in issue #1. We should close one of the issues. Also calling it a workflow is a more common term than a workload.

I think something like this would be more natural to HPC users -
- jobs
  - name: job_1
  - resources:
# I got this from the Dask JobQueue how this works
#        cluster = PBSCluster(  # <-- scheduler started here
#          cores=24,
#          memory='100GB',
#          shebang='#!/usr/bin/env zsh',  # default is bash
#          processes=6,
#          local_directory='$TMPDIR',
#          resource_spec='select=1:ncpus=24:mem=100GB',
#          queue='regular',
#          project='my-project',
#          walltime='02:00:00',
#          )
      - mem: 100GB
      - processes: 6
      - walltime: '02:00:00'
      - queue: 'regular'
      # etc
  - tasks:
      - shell: echo "hello world from task 1"
      - shell: echo "hello world from task 2"
  - name: job_2
  - depends:
      - job_1
  - tasks:
      - shell: echo "hello world from task 1"
      - shell: echo "hello world from task 2"

I think this page is the most straightforward for a translation of JobQueue -> Dask Worker.
Then I think the dask-worker process is smart enough to figure out that it has 6 processes and run the 6 tasks concurrently.
I do really like the idea of having the shell there. If there was interest there could be python executors in there as well.

And +1 for calling it a workflow definition file or something else with 'workflow'.
 ;-)

So yaml is easy to read but you need to be whitespace aware, toml and ini are harder to read and construct but are not whitespace sensitive. JSON is hard to read and has lots of brackets you have to match correctly.
@jerowe in your jobqueue code above you have 6 processes with 4 threads each for a total of 24 tasks that can happen at the same time. Depending on your workload type the performance will change depending on whether you use more threads (i.e. 1 process/24 threads) or more processes (i.e. 24 processes each with 1 thread). Since we are just calling bash scripts I don't think it will matter.

Closing this in favor of https://github.com/Quansight-Labs/dask-jobqueue/issues/1 since there is a lot of overlap


  I've been stuck in trying to build this (i.e. Step 2 of
https://github.com/dogecoin/dogecoin/blob/master/doc/build-osx.md#building-dogecoind
)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@Turupawn I don't get it. Can you elaborate and explain please?

@glaksmono run the configure script:
./configure --with-incompatible-bdb

It tells you to use BDB 5.1 and you install v4 ;) Of course that's not going to work. Anyway, you should ideally use the included dependency builder, but I have actually no idea if natively compiling on OSX even works.
Before you compile with --with-incompatible-bdb actually make sure you understand the implications! You wallet.dat will be incompatible with different versions of Dogecoin Core. That also means you won't be able to restore from a backup created with anything newer than Dogecoin Core 1.6 (iirc).

-rw-r--r--    1 glaksmono  staff    7626 Mar 14 13:20 Makefile.am
-rw-r--r--    1 glaksmono  staff   41816 Mar 14 13:44 Makefile.in

After I did that, I noticed that there are 2 Makefile. Which one that I should be using for make?
I tried renaming each of them to Makefile but I'm getting this for both:
Makefile:15: *** missing separator.  Stop. # for Makefile.in
Makefile:7: *** missing separator.  Stop.   # for Makefile.am

I'm sure you haven't read the document carefully.

@D3m0nKingx I tried that, then on make I got https://github.com/dogecoin/dogecoin/issues/1486

@langerhans there's not a clear way to install 5.1 on OSX, at least with brew, which supports 6.X and 4.X ..
Installing without berkeley db today means the wallet will work going forward, yes?

There are more recent instructions for building on macOS here: https://github.com/dogecoin/dogecoin/blob/1.14-branding/doc/Building-Dogecoin-1.14-for-Mac.md
Feel free to open a new issue if these don't work out :)