NLU agent is slow to load

Rasa NLU version: 0.11.0
Operating system (windows, osx, ...): OSX/Linux
Content of model configuration file:
{
  "pipeline": "spacy_sklearn",
  "path" : "./resources/models/nlu",
  "data" : "./resources/data/nlu.md"
}

Issue:
This may be more of a question than a  bug, but we have been trying to deploy our small bot from here to Heroku and it has been an exhausting exercise, first, we have to use the biggest type of Dyno since 2.5G wasn't enough, so now we habe 14G of RAM and our metrics show sometimes the bot use 6G of a small period of time) to run the training (sadly currently training is done in release time which we will try to fix later), but worst is that the time it takes to answer queries from our chatbot sometimes is in the 30 seconds range, after a bit of investigation and with the help with some profiling [1] we found out that the step that takes most of the time is the part we create an agent and load trained model from disk (it's around 15seconds, check below for the profile data), and while we worked around it to only happen at process start [2], it still wasn't enough b/c gunicorn (and even heroku worker queues) keep using processes for handling requests and reaping them after, IMHO relying on process life cycle is brittle and we would like to avoid, so I am wondering how do others deal with the cold start? sadly since our bot is in Python we have still the option to try using threads/greenthreads (instead of processes) for handling queries but I am still uneasy regarding this.
[1]
Profiling data
13:29:06 web.1   |  PATH: '/endpoint'
13:29:06 web.1   |           7367407 function calls (7331638 primitive calls) in 19.162 seconds
13:29:06 web.1   |     Ordered by: internal time, call count
13:29:06 web.1   |     List reduced from 6749 to 30 due to restriction <30>
13:29:06 web.1   |     ncalls  tottime  percall  cumtime  percall filename:lineno(function)
13:29:06 web.1   |          1    3.651    3.651    3.651    3.651 vocab.pyx:450(lexemes_from_bytes)
13:29:06 web.1   |          1    3.509    3.509   11.746   11.746 vocab.pyx:367(from_disk)
13:29:06 web.1   |          1    2.886    2.886    3.624    3.624 /Users/mouad/.virtualenvs/twde-chatbot-kvnVSXOR/lib/python3.6/site-packages/spacy/_ml.py:244(link_vectors_to_models)
13:29:06 web.1   |    1349784    1.996    0.000    1.996    0.000 {built-in method numpy.core.multiarray.fromstring}
13:29:06 web.1   |    1352570    1.401    0.000    3.396    0.000 /Users/mouad/.virtualenvs/twde-chatbot-kvnVSXOR/lib/python3.6/site-packages/msgpack_numpy.py:68(decode)
13:29:06 web.1   |          1    1.132    1.132    4.518    4.518 {msgpack._unpacker.unpack}
13:29:06 web.1   |     145/73    0.728    0.005    0.908    0.012 {built-in method _imp.create_dynamic}
13:29:06 web.1   |    1343766    0.635    0.000    0.738    0.000 vocab.pyx:195(__iter__)
13:29:06 web.1   |       1128    0.357    0.000    0.357    0.000 {method 'read' of '_io.FileIO' objects}
13:29:06 web.1   |       1125    0.180    0.000    0.180    0.000 {built-in method marshal.loads}
13:29:06 web.1   |      17976    0.170    0.000    0.170    0.000 {built-in method posix.stat}
13:29:06 web.1   |          5    0.118    0.024    0.118    0.024 {built-in method _pywrap_tensorflow_internal.TF_Run}
13:29:06 web.1   |    1503/12    0.115    0.000    2.714    0.226 {built-in method builtins.exec}
13:29:06 web.1   |         45    0.112    0.002    0.112    0.002 {method 'uniform' of 'mtrand.RandomState' objects}
13:29:06 web.1   |        139    0.109    0.001    0.110    0.001 {built-in method io.open}
13:29:06 web.1   |    1348567    0.104    0.000    0.124    0.000 vocab.pyx:132(get_by_orth)
13:29:06 web.1   |        480    0.095    0.000    0.546    0.001 /usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/traceback.py:313(extract)
13:29:06 web.1   |       2470    0.070    0.000    0.092    0.000 vocab.pyx:228(make_fused_token)
13:29:06 web.1   |        434    0.063    0.000    0.067    0.000 /Users/mouad/.virtualenvs/twde-chatbot-kvnVSXOR/lib/python3.6/site-packages/tensorflow/python/framework/ops.py:2849(_extract_stack)
13:29:06 web.1   |       1131    0.052    0.000    0.409    0.000 <frozen importlib._bootstrap_external>:830(get_data)
13:29:06 web.1   |  2072/2053    0.043    0.000    0.082    0.000 {built-in method builtins.__build_class__}
13:29:06 web.1   |      50233    0.035    0.000    0.254    0.000 /usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/traceback.py:279(line)
13:29:06 web.1   |        179    0.033    0.000    0.033    0.000 {method 'readline' of '_io.BufferedReader' objects}
13:29:06 web.1   |          2    0.032    0.016    0.162    0.081 nn_parser.pyx:894(from_disk)
13:29:06 web.1   |        5/1    0.027    0.005   15.693   15.693 /Users/mouad/.virtualenvs/twde-chatbot-kvnVSXOR/lib/python3.6/site-packages/spacy/util.py:507(from_disk)
13:29:06 web.1   |      50231    0.026    0.000    0.242    0.000 /Users/mouad/.virtualenvs/twde-chatbot-kvnVSXOR/lib/python3.6/linecache.py:15(getline)
13:29:06 web.1   |      45190    0.024    0.000    0.025    0.000 {built-in method builtins.hasattr}
13:29:06 web.1   |       2234    0.022    0.000    0.126    0.000 <frozen importlib._bootstrap_external>:1233(find_spec)
13:29:06 web.1   |          1    0.022    0.022    0.090    0.090 pipeline.pyx:620(load_model)
13:29:06 web.1   |      50229    0.021    0.000    0.036    0.000 /Users/mouad/.virtualenvs/twde-chatbot-kvnVSXOR/lib/python3.6/linecache.py:147(lazycache)

[2] https://github.com/ThoughtWorksInc/twde-chatbot/blob/master/chatbot/messenger/google_chat_api.py#L15

Related to this is an Agent instance (https://core.rasa.com/api/agent.html?highlight=agent) thread-safe?

Small update, after spending most part of the day investigating more, we learned two things that I would like to share with the community:

We switched to use gevent with Gunicorn for the time being to avoid cold start of processes, since the default of Gunicorn is to use processes for handling workers, I am still unsure if an io-async flow is the best, since for my understanding, bots build on rasa may end up spending more time on CPU than IO.

It seems that Heroku may not be the best type of platforms to deploy such tools especially b/c of the slow start that Heroku impose on processes, where dynos that don't get used for some time Heroku put them to sleep, this lead the bot to start over for the unlucky ones that get to use the bot after a long silence, ofc we can set up external uptime system that ping the app often enough so it doesn't sleep, we will try that tomorrow and update here again.

FWIW concerning agent not being thread-safe, I would still love a hint about whether that's true or not.

@akelad @tmbo  this one is for you :)


Bug in definition file

Hi
There is a bug in definition file deye_sg04lp3.yaml

name: "Total Energy Bought"
class: "energy"
state_class: "total_increasing"
uom: "kWh"
scale: 0.1
rule: 1
registers: [0x020A,0x020B]
icon: 'mdi:transmission-tower-export'
`

Rule should be 3.

I changed it to rule 3 and restarted HA.
Total energy bought is still showing me the same different value as with rule 1 compared to the Solarman App.


HasAttributes::originalIsEquivalent is public now

This function is great for observers... For example on saving() event:
Closes #26383

Needs to go to master branch.


PR trigger a test run - [closed]

In GitLab by @luotian-github on Jun 29, 2018, 01:22
Merges operation -> operation
PR trigger a test run

In GitLab by @wknet123 on Nov 13, 2019, 11:09
The test coverage for backend is FAIL  ,The test coverage for frontend is 38.11   , check  consolse log

In GitLab by @wknet123 on Nov 13, 2019, 11:09
The test coverage for backend is 24.0%  ,The test coverage for frontend is 38.11   , check  consolse log

In GitLab by @wknet123 on Nov 13, 2019, 11:09
The test coverage for backend is 24.0%  ,The test coverage for frontend is 38.11   , check  consolse log

In GitLab by @wknet123 on Nov 13, 2019, 11:09
closed


update latest to stable & correct release date of version

ioBroker.admin
ioBroker.flot
ioBroker.history
ioBroker.ical
ioBroker.openhab
ioBroker.rickshaw
ioBroker.text2command
ioBroker.vis

https://forum.iobroker.net/topic/20408/stable-repository-update-feedback/4

Thank you!


.git is added to the package

Hello!
I juste updated readme-md-generator to version 0.6.0 and it seems there is the .git directory that has been added to the package. That implies that when when we try to do a npm install when readme-md-generator is already installed, we got the following error:

npm ERR! path node_modules/readme-md-generator
npm ERR! code EISGIT
npm ERR! git node_modules/readme-md-generator: Appears to be a git repo or submodule.
npm ERR! git node_modules/readme-md-generator
npm ERR! git Refusing to remove it. Update manually,
npm ERR! git or move it out of the way first.

To reproduce it, simply install<EMAIL_ADDRESS>install it and than try to do an other npm install
Have a good day!
Le Poulet Suisse

Hi @lepouletsuisse,
I just tested and it's working as expected for me.
Can you tell me what command you are using ?
To get it work, juste use a recent version of npm and do the following :
npx readme-md-generator

or
npm i -g readme-md-generator
readme

Hi @kefranabg ,
In fact i'm doing a npm i --save readme-md-generator and than any npm i ... command got the error i showed in my first comment.
I tried to install it globally and it seems to work. Anyway, i think this is still a bug if one wants to install the package in the project only.
npm version: 6.9.0
Node version: 10.16.0
readme-md-generator version: 0.6.0
Here it is a screenshot that show the .git folder inside the package when we install it. The .git package shouldn't be publish with the package i think.

@lepouletsuisse, the .git is added in npm repository indeed...
However it's not supposed to be possible.
I made some research and find out that it's a bug  from<EMAIL_ADDRESS>the version that I used to publish readme-md-generator.
I'll use another version to fix this issue.
Thanks for reporting 👍

Oh ok, Thank you for your work :smiley:  :+1:

Fixed in 0.6.1 👍


JDK 15 Java matrix to RPM

Issue #, if available:
Description of changes:
Added JDK 15 for the RPM workflow Integration Tests.
Added fail-fast setting to github action to disable chained failures on the Jobs.
Remove JDK hardcode in RPM workflow and add java matrix.
Test Results:
https://github.com/opendistro-for-elasticsearch/opendistro-build/actions/runs/298080923
Note: If this PR is related to Helm, please also update the README for related documentation changes. Thanks.
https://github.com/opendistro-for-elasticsearch/opendistro-build/blob/master/helm/README.md
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

A new PR will be opened later after the solution is available.


Support for type hints on decorators

Is your feature request related to a problem? Please describe.
Usage of decorators such as @newrelic.agent.function_trace prevent mypy from checking types on those functions. Here is mypy documentation describing this issue: https://mypy.readthedocs.io/en/stable/generics.html#declaring-decorators
For example
import newrelic.agent

@newrelic.agent.function_trace()
def func_i_want_to_trace(value: str) -> bool:
    return value == "yes"

func_i_want_to_trace(1)

mypy will not catch this type mismatch
Feature Description
Type all newrelic.agent decorators as described in the mypy doc
Describe Alternatives
Here is a workaround
F = TypeVar("F", bound=Callable[..., Any])

def newrelic_agent_function_trace(func: F) -> F:
    return cast(F, newrelic.agent.function_trace()(func))

@newrelic_agent_function_trace
def func_i_want_to_trace(value: str) -> bool:
    return value == "yes"

Additional context
I am not sure if this is possible if you would like to keep supporting python 2.7
Priority
Nice to Have

Hello,
The agent uses the wrapt library internally to implement all wrappers, if the signature of functions is being obstructed that would need to be directed to the wrapt library as an issue.
It sounds like this issue has already been raised unless I'm mistaken and there's not been much progress as of yet.


Bluetooth: LE multirole: connection as central is not totally unreferenced on disconnection

Describe the bug
When doing BLE multirole and connected both to a central and a peripheral, if the peripheral disconnects, a reference to the peripheral connection still remains. Next connections to a peripheral will then fail because no more connections are available.
The extra reference is set by a call to bt_le_adv_resume() in bt_conn_unref in deferred_work (conn.c) here.
The issue does not happen if no central is connected to the device because the advertising flags are not in the same state (BT_ADV_PERSIST and BT_ADV_ENABLED are set, so bt_le_adv_resume returns immediately).
A workaround is to check the role of the connection to call bt_le_adv_resume() only for BT_CONN_ROLE_PERIPHERAL.
To Reproduce
Steps to reproduce the behavior:

Enable CONFIG_BT_PERIPHERAL and CONFIG_BT_CENTRAL
Start advertising
Connect a central to the device
Connect the device to a peripheral
Disconnect the peripheral : check acl_conns, a reference still remains to the peripheral connection
Try to reconnect the peripheral : bt_conn_le_create fails with error -ENOMEM

Expected behavior
There should be no reference remaining to the perihperal connection after disconnection
Impact
It is impossible to reconnect to a peripheral.

There are multiple possible causes for this, but this doesn´t look at first sight like a bug in the stack. Can you please post a simple application to reproduce this, in source code, somewhere on GitHub or even as a comment here?
This could be a reference counting bug in the application, please check the reference counting code in your app. Are you calling bt_unref() to the connection in 4. ?

Yes, bt_conn_unref is called by the application on disconnection.
Before the call here, the reference counter equals  to 1. After the call, it is still equal to 1 (it is increased by bt_le_adv_resume())
I'll find some time to provide sample code.

Can you make sure you describe the sequence in a way that is unambiguous?
I understand that:
You enable CONFIG_BT_PERIPHERAL and CONFIG_BT_CENTRAL, set CONFIG_BT_MAX_CONN to 2.

Zephyr starts connectable advertising
Zephyr gets connected as a peripheral
Zephyr establishes a connection as a central
Now Zephyr is both a central and a peripheral
Zephyr disconnects the connection it has as a central
Now Zephyr is only a peripheral
Zephyr tries to establish a connection as a central, fails with -ENOMEM

Is this correct?

@eloisesko could you please try using BT_LE_ADV_OPT_ONE_TIME when you start connectable advertising so that the stack doesn't automatically restart it after connection?

Sorry for the late reply, I finally made a  sample project that reproduces the issue.
With BT_LE_ADV_OPT_ONE_TIME flag, the issue with connection references does not happen.

When you do not use BT_LE_ADV_OPT_ONE_TIME and have BT_MAX_CONN > 1, then the broadcaster will restart connectable advertiser after a connection in peripheral role (in the local device) is established, this is to allow multiple peer central devices to be able to connect to the local device.
Such restarted connectable advertising depletes one of the two connection instances in your case, hence the attempt to create a connection to a remote peripheral device would fail with -ENOMEM when you have an active connection in peripheral role and a connectable advertising too.

Closing as per the explanation above. If you have more questions feel free to reopen.

#51256 fixes the issue


LeetCode 1047

I have 4 pull requests, with valid codes for CP and algorithms Can they be hacktoberfest-accepted?

Please merge this


[deb/test] Minor update to debian packaging and unittests

Add nnstreamer filter in the packaging
Also update the unittests to use the meson tests
Update unittest tolerance to be 1e-5 for debian build to match
across platforms (bionic, focal) and architectures.
Similar issues have occured for i586 tizen as well.
So, this patch lowers the tolerance for all ccapi and capi test.
This issue occurs to os and library versioning issues.
Update debian packaging:

update the unittests to use meson tests
update dh_missing to fail than give warnings

Remove run_unittests
Self evaluation:

Build test: [x]Passed [ ]Failed [ ]Skipped
Run test: [x]Passed [ ]Failed [ ]Skipped

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #1248. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnstreamer.mooo.com/.


Inet Layer Causes a Segment Fault When Running Inet Layer TCP End Point Test against LwIP

There appears to be a segment fault in both the sender and receiver in the TCP portion of the Inet layer when running the Inet layer functional test built against LwIP when the sender attempts to, and fails, to connect to the receiver.

The receiver segment faults here:
Thread 2 "TestInetLayer" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6e85700 (LWP 7347)]
0x0000555555709217 in tcp_input (
    p=0x555555a018e0 <memp_memory_PBUF_POOL_base+14112>,
    inp=0x5555559e1340 <netIF>)
    at third_party/lwip/repo/lwip/src/core/tcp_in.c:292
292	      if ((pcb->netif_idx != NETIF_NO_INDEX) &&
(gdb) where
#0  0x0000555555709217 in tcp_input (
    p=0x555555a018e0 <memp_memory_PBUF_POOL_base+14112>,
    inp=0x5555559e1340 <netIF>)
    at third_party/lwip/repo/lwip/src/core/tcp_in.c:292
#1  0x000055555571af2a in ip6_input (
    p=0x555555a018e0 <memp_memory_PBUF_POOL_base+14112>,
    inp=0x5555559e1340 <netIF>)
    at third_party/lwip/repo/lwip/src/core/ipv6/ip6.c:811
#2  0x000055555571176d in ethernet_input (
    p=0x555555a018e0 <memp_memory_PBUF_POOL_base+14112>,
    netif=0x5555559e1340 <netIF>)
    at third_party/lwip/repo/lwip/src/netif/ethernet.c:223
#3  0x00005555556f6f22 in tcpip_thread (arg=0x0)
    at third_party/lwip/repo/lwip/src/api/tcpip.c:130
#4  0x00007ffff7bbd6db in start_thread (arg=0x7ffff6e85700)
    at pthread_create.c:463
#5  0x00007ffff755d88f in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

This issue has been fixed upstream at http://git.savannah.nongnu.org/cgit/lwip.git/commit/?id=0545eba002d25a0116daf7dddda8e7a7ce5527cf.
Applying the patch, the sender and receiver no longer segment fault.

https://github.com/openweave/openweave-core/pull/150


Browser dev console errors when running workshop

Launched Spring Boot lab from https://hub.prod.eduk8s.io/
I noticed errors in the (Firefox) dev console when I clicked on the link which triggers the Spring Initializr extension in VS Code.

Clicking on the link to " open up the main application class " results in more errors.

Looks like @kdvolder and I addressed issues above with 97d8738377927dc911feb247ddae3e092bdf5cc4 and commits to eduk8s-vscode-helper repo

Closing this. @jldec Please raise new issue if you see more errors that should be addressed.


Table: Add support for alternate sort icons

Description
Add the ability on the table component to switch the sort icon set to the icons listed here: https://github.com/trimble-oss/modus-icons/issues/353
This feature was in response to feedback received from users that they cannot see when the column is sorted. It is hard to notice which column is sorting the table. Also, the A-Z icon is confusing if you're sorting numerical data. We propose a one-arrow icon that is simpler to understand.
References #2089
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update

How Has This Been Tested?
All unit and e2e tests passed when executing npm run test
Exploratory testing also performed in browser using modus-table component
Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[x] I have checked my code and corrected any misspellings

Validated.   Working as expected.

When I hover over the sort icon

Then display the appropriate tooltip per the design after a 300ms delay.

Details

When I click the sort icon

Then sort the column content by ascending order.

Details

When I click the sort icon
 after the column content has been sorted in ascending order
Then sort the column content by descending order.

Details

Given I hit the Tab key to access the sort button

When the sort icon has focus

Then display the focus outline around it
And the appropriate tooltip per the design after a 300ms delay.

Details

Given the column sort icon has focus

And the column is already sorted by ascending order

When I hit the Enter key

Then sort the column content by descending order

And display the appropriate tooltip per the design

Given the column sort icon has focus

And the column is already sorted by descending order

When I hit the Enter key

Then unsort (reset) the column content

And display the appropriate tooltip per the design.

Details


install script updates

Changed the macOS and Linux scripts to end in .sh
Added Windows setup script. Powershell-based, tested against Windows 11
Let me know if you have any questions

I wish you looked at my pull request, where I already addressed the issues with the Linux and macOS install scripts and even improved them 😕
This PR should've been just the Windows install script in my opinion.

Fails on Windows 11 Sandbox:
pkg-config not found

Hey @ByzantineProcess - that was the environment I tested in. Does the script itself fail or does the compile of Webx fail? I can't seem to reproduce.

I wish you looked at my pull request, where I already addressed the issues with the Linux and macOS install scripts and even improved them 😕
This PR should've been just the Windows install script in my opinion.

 I'll undo that then. Didn't mean to step over you, I just added .sh to the end. lol

This installs the msvc toolchain by default even though only the gnu toolchain is needed. So we end up downloading 2 toolchains, which on the VM I'm testing the script on is taking a lot of time
Does rustup-init.exe support CLI commands for the default toolchain? I remember running it and it had an option for that.
If it does, we could modify this line of code
Start-Process -FilePath $rustup -ArgumentList "-y" -Wait

Hey @ByzantineProcess - that was the environment I tested in. Does the script itself fail or does the compile of Webx fail? I can't seem to reproduce.

It's the compilation of Webx that fails.

This installs the msvc toolchain by default even though only the gnu toolchain is needed. So we end up downloading 2 toolchains, which on the VM I'm testing the script on is taking a lot of time
Does rustup-init.exe support CLI commands for the default toolchain? I remember running it and it had an option for that. If it does, we could modify this line of code
Start-Process -FilePath $rustup -ArgumentList "-y" -Wait

In my testing, (unless it happened very quickly and silently), it didn't seem to install MSVC. I don't have install logs to double-check, I just don't remember Rust trying to install it, as it didn't block the install waiting for the user to install it themselves like it did on another machine I installed napture on.

mine got rewritten 🗿


slog relative pathname handling is inconsistent with standard functions

In the documentation for slog, it is stated explicitly that the process's working directory is used for log files, and that the portable fallback (make-pathname :name nil :type nil :version nil :defaults *default-pathname-defaults*) is almost certainly wrong.
However, this means that the method slog uses to resolve relative pathnames is different from the method used by all functions defined in the CL standard, which are defined to merge all pathnames with *default-pathname-defaults* before filesystem access (additionally, setting certain components of *default-pathname-defaults* to nil before performing merging is not in the specification, should generally be unnecessary, and further deviates from the standard procedure).
In the standard, it is stated that *default-pathname-defaults* is "typically in the working directory that was current when Common Lisp was started up", so in general the behaviour of slog would not change for most programs if the merging was done with respect to *default-pathname-defaults*, unless they change their working directory with chdir without also updating *default-pathname-defaults* (which is somewhat of an unusual thing to do, in my opinion, and also makes the standard functions behave in a surprising way and so is generally avoided), and may be surprising if, for instance, a user binds *default-pathname-defaults* lexically and expects files which were being placed in the current directory to be placed elsewhere.
Additionally, the pathname canonicalization function should probably call translate-logical-pathname on the input before merging. This allows using logical pathnames, which could be very useful for logging (e.g. a client could define a logical pathname host called log, set to the platform-appropriate logging location, and then specify its log-file paths as log:foo.log log:bar;baz.log etc.), and also lines up better with the behaviour of open and other standard filesystem functions, which also perform logical pathname translations.
I am willing to create a pull request implementing these behaviours, if desired; I submitted an issue first to gauge opinion on this.
EDIT: actually, it is possible to use logical pathnames in the current state; the issue is that, without translating them, a logical pathname will have a different stream than its equivalent, translated, physical pathname, as follows:
CL-USER> (setf (logical-pathname-translations "log") '(("**;*.*.*" "/var/log/**/")))
(("**;*.*.*" "/var/log/**/"))
CL-USER> (org.tfeb.hax.slog:slog-to "log:foo;bar.log" "test1")
#<ORG.TFEB.HAX.SLOG:SIMPLE-LOG-ENTRY "test1" {10081F14A3}>
CL-USER> (org.tfeb.hax.slog:slog-to "/var/log/foo/bar.log" "test2~%")
#<ORG.TFEB.HAX.SLOG:SIMPLE-LOG-ENTRY "test2~%" {100820A1D3}>
CL-USER> (org.tfeb.hax.slog:flush-open-log-file-streams)
(#P"/var/log/foo/bar.log" #P"LOG:FOO;BAR.LOG")

Note that in this example "/var/log/foo/bar.log" and "log:foo;bar.log" point to the same file.

@goose121 thanks for this.
For the *default-pathname-defaults* / current working directory thing.  The problem here is that there is a choice between doing the right thing and actually working reasonably well.  The right thing is simply using *default-pathname-defaults*, clearly.  But for the right thing to work, the value of that needs to correspond to the current working directory, which means that whatever (ultimately implementation-defined) method is used to change working directory also needs to set *default-pathname-defaults* and, worse, something like this needs to work:
(progn
  (let ((*default-pathname-defaults* *default-pathname-defaults*))
    ... change directory, also changing *default-pathname-defaults* ...
    ... code in new directory ...)
  ... code in *old* directory ...)

It is extremely unlikely that anything like this could be made to work in any implementation which sits on a platform (like Unixoid systems) where there is a notion of a current working directory for a process, without treating *default-pathname-defaults* in some completely magic way.
But it's worse even than that: the interfaces that actually exist to change working directory (for instance uiop:chdir) don't set *default-pathname-defaults* anyway, so everything is completely hopeless before you even start.
So there are two choices:

listen to *default-pathname-defaults* (the right thing) ...
... or respect the current process working directory in any implementation I  have tried (which is, pretty much, SBCL, LW, CCL, and anything with ASDF).

You can't do both, and I've taken the latter choice, because I think it's much closer to being useful.
However all is not lost.  The underlying problem here is that what the system needs to know is the truename of a file which may not yet exist and which it does not want to open or create.  Well, that can be fixed easily: just open the wretched file, creating it if need be.  So if it opens log files at the point they're first mentioned (so, usually in the expansion of logging macro), rather than at the moment a handler first wants to write to that file, the truename is then known, and none of this fanciness is needed.
And that's better in other ways, too, as it means that if the file can't in fact be opened you get the error at a much better time and in particular not when the first event which ends up wanting to write to the file happens, which is a very bad time.
So I'm probably going to modify slog (incompatibly) to do that, which will make this entire issue go away I think.
I will leave this open until then.

@goose121 PS if you're happy to check the new version that would be cool.  It will likely take me some days depending.

I would be happy to check the new version; I think this is an interesting project and I'd like to do what I can to help it flourish.
I think it might be informative to see what other CL software does with regards to *default-pathname-defaults*; from what little I've seen in in CL, most software I've seen that works with relative pathnames completely ignores Unix's version of working directories (thus making it behave consistently within the ecosystem, even if it doesn't behave consistently with how most other Unix software works). From what I have seen the right thing is different in Common Lisp than in other software; it seems that Unix's idea of "current directory" is what would be considered "surprising"  because users generally set their current directory with (setf *default-pathname-defaults*) due to the fact that this is the one which affects most built-in Lisp functions, and chdir seems to be reserved for FFI and for ensuring child processes are spawned with the right pwd.
Admittedly, I haven't seen much code dealing with this at all (I don't see a lot of CL software that deals explicitly with the working directory; usually it just lets open and such handle that), so further research may be needed.
P.S. even treating *default-pathname-defaults* in a magic way probably wouldn't work, as the value of a special variable is supposed to be local to a thread, while the working directory is global within a process; I think this is also part of the reason why *default-pathname-defaults* tends to be used over chdir in CL programs

@goose121 Thank you.  I have a new version which now does no pathname magic at all: the only thing it does is call pathname to turn strings into pathnames.  It is potentially slower in some cases than the old one if you treat it badly and I've currently tried it only on a single implementation/platform.  Most importantly I need to rewrite the README as various things are pretty different.  I'll probably not have time to do that before early next week.  I'll commit it on a branch then and let you know.

I am closing this against 22361884d15e8c013a5df7f7596f63dfeb7ac62d, which I've just merged: this version of slog may have bugs, but it does no longer do anything unconventional with directories, and I needed to merge the branch.

looks good! sorry for the lack of response

@goose121 no problem, sorry if my comment made it sound like I expected you to have done work which I wasn't: I was just needing to merge it while I could still fast-forward it...


Refactor dependsOn into References

See #233 for some discussion. DO NOT MERGE - need to update doco if we agree. Also, integration-test may be broken (unclear what's happening on first glance).
Why we want this:

avoid problem of messy {{x#x#x}} format of references
adds escapability of references (multiple !s)
if we do want to reintroduce string interpolation, this makes it simpler/cleaner
sets up situation where it's easy to mark particular references as 'secret' (which will cause service catalog processing to make them automatic secrets, etc. etc. - see #233)

Why we don't want this:

verbosity for simple cases
we 'hack' a simple dependsOn (without references), which looks a bit ugly (maybe?). Could instead have a nested structure (e.g. resource then a list of 'names' that we extract from it)
not backwards compatible (will need to change voyager once we merge)
there is a nicer solution we haven't considered

@nilebox take a look at the proposal here https://github.com/atlassian/smith/issues/233#issuecomment-373575105 - this should clarify what is going on in this PR.

@wryun would be great to also update all the documentation to use the new syntax introduced in this PR.

@wryun To keep this PR smaller I suggest to remove escaping functionality from it. And then add it in a later PR. We need to discuss it first, I have a feeling it might require more code than we have here.

The remaining work here is to fix the docs.


Bug with "item"

In the following typescript:
["whatever", ["again", "testing"]];

With ["again", "testing"] selected, saying "take item" results in selecting "again", "testing". Instead it should be a noop.
Functionally, this occurred while trying to say "clone item square" with my cursor inside again.

I believe we will get this one for free with #484


zh_cn

zh_cn.zip

I'm not clicking that.

Sorry, this is the Chinese lang file I made for roots3

ok,here is the link
https://pastebin.com/jymcG8EB

I revised it again:
https://pastebin.com/JniK0cR1

This seems pretty good! I'll have @noobanidus take a look. Thanks!


Add dataset example to README

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

Coverage data is based on head (884149e) compared to base (f956aa1).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##           master      #78   +/-   ##
=======================================
  Coverage   78.86%   78.86%
=======================================
  Files          20       20
  Lines        1211     1211
  Branches      211      211
=======================================
  Hits          955      955
  Misses        217      217
  Partials       39       39

Flag
Coverage Δ

unittests
78.86% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Some chore fix

  * Add new requires in spec file
  * Remove duplicated requirements
  * Little pydoc fix

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 67.017%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1656

Relevant Lines:
2471

💛  - Coveralls


Registry addition to the capp

Hi @piizei @ms-henglu Any idea how to add container registry details here ?, I tried multiple ways to add the details, but running into  below errors.
Sorry, I do not find much of help out, So requesting your input here. Thanks!
Code:
  configuration = {
    secrets : [
      {
        name : containerRegistryPasswordRef
        value : "ABC"
      }
    ]
    registries : [
      {
        server : containerRegistry
        username : containerRegistryUsername
        passwordSecretRef : containerRegistryPasswordRef
      }
    ]

Error: Error: Invalid reference
│
│   on container-app.tf line 41, in resource "azapi_resource" "container_app":
│   41:             name : containerRegistryPasswordRef
│
│ A reference to a resource type must be followed by at least one attribute
│ access, specifying the resource name.
╵
╷
│ Error: Invalid reference
│
│   on container-app.tf line 53, in resource "azapi_resource" "container_app":
│   53:             passwordSecretRef : containerRegistryPasswordRef
Even tried harcoding the ACR details in the registry block then getting below 400 error.
RESPONSE 400: 400 Bad Request
│ ERROR CODE: ContainerAppRegistriesPasswordSecretRefNotFound

Hi @kkadiyam,
For me it looks like it's a bug in Container Instances, as the ARM payload is failing even with rest client. I will create an issue to their repo.

Issue https://github.com/microsoft/azure-container-apps/issues/212

This seems to work now, I changed the example to use private registry.


zed-editor: 0.162.3 -> 0.162.5

https://github.com/zed-industries/zed/releases/tag/v0.162.5

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 358197

aarch64-darwin

:white_check_mark: 1 package built:

zed-editor

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 358197

x86_64-linux

:white_check_mark: 1 package built:

zed-editor

aarch64-linux

:white_check_mark: 1 package built:

zed-editor

x86_64-darwin

:white_check_mark: 1 package built:

zed-editor

aarch64-darwin

:white_check_mark: 1 package built:

zed-editor


Better description how can I build the android version of engine-x

Wish:
Better description how can I build the android version of engine-x like for Windows with Visual Studio.

well, the build guide is same with https://docs.cocos2d-x.org/cocos2d-x/v4/en/installation/CMake-Guide.html

The repo: https://github.com/halx99/android-dev may helpful, if you network is fast, I think install android studio is enough.

I will inform you tomorrow. Thanks.

Does the latest README.md Android build guide correct for you to build apk?

What I have done:

Only installed Andriod Studio IDE
Select on SDK Manager:

NDK (Side by Side) 20.1.5948944

Gradl sync started...
and get this error:
NDK not configured.
Download it with SDK manager.
Update NDK version to 20.1.5948944 and sync project

Starting Gradle Daemon...
Gradle Daemon started in 6 s 91 ms
FAILURE: Build failed with an exception.

What went wrong:
A problem occurred configuring project ':CppTests'.

NDK not configured.
Download it with SDK manager.

Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Exception is:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring project ':CppTests'.
at org.gradle.configuration.project.LifecycleProjectEvaluator.wrapException(LifecycleProjectEvaluator.java:79)
at org.gradle.configuration.project.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:72)
at org.gradle.configuration.project.LifecycleProjectEvaluator.access$600(LifecycleProjectEvaluator.java:53)
at org.gradle.configuration.project.LifecycleProjectEvaluator$NotifyAfterEvaluate.run(LifecycleProjectEvaluator.java:198)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
at org.gradle.configuration.project.LifecycleProjectEvaluator$EvaluateProject$1.run(LifecycleProjectEvaluator.java:111)
at org.gradle.internal.Factories$1.create(Factories.java:25)
at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:183)
at org.gradle.internal.work.StopShieldingWorkerLeaseService.withLocks(StopShieldingWorkerLeaseService.java:40)
at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.withProjectLock(DefaultProjectStateRegistry.java:226)
at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.withMutableState(DefaultProjectStateRegistry.java:220)
at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.withMutableState(DefaultProjectStateRegistry.java:186)
at org.gradle.configuration.project.LifecycleProjectEvaluator$EvaluateProject.run(LifecycleProjectEvaluator.java:95)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:67)
at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:693)
at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:141)
at org.gradle.execution.TaskPathProjectEvaluator.configure(TaskPathProjectEvaluator.java:35)
at org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:62)
at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:41)
at org.gradle.initialization.DefaultGradleLauncher$ConfigureBuild.run(DefaultGradleLauncher.java:302)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
at org.gradle.initialization.DefaultGradleLauncher.configureBuild(DefaultGradleLauncher.java:210)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:151)
at org.gradle.initialization.DefaultGradleLauncher.getConfiguredBuild(DefaultGradleLauncher.java:129)
at org.gradle.internal.invocation.GradleBuildController$2.execute(GradleBuildController.java:67)
at org.gradle.internal.invocation.GradleBuildController$2.execute(GradleBuildController.java:64)
at org.gradle.internal.invocation.GradleBuildController$3.create(GradleBuildController.java:82)
at org.gradle.internal.invocation.GradleBuildController$3.create(GradleBuildController.java:75)
at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:183)
at org.gradle.internal.work.StopShieldingWorkerLeaseService.withLocks(StopShieldingWorkerLeaseService.java:40)
at org.gradle.internal.invocation.GradleBuildController.doBuild(GradleBuildController.java:75)
at org.gradle.internal.invocation.GradleBuildController.configure(GradleBuildController.java:64)
at org.gradle.tooling.internal.provider.runner.ClientProvidedPhasedActionRunner.run(ClientProvidedPhasedActionRunner.java:62)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.launcher.exec.BuildOutcomeReportingBuildActionRunner.run(BuildOutcomeReportingBuildActionRunner.java:58)
at org.gradle.tooling.internal.provider.ValidatingBuildActionRunner.run(ValidatingBuildActionRunner.java:32)
at org.gradle.launcher.exec.BuildCompletionNotifyingBuildActionRunner.run(BuildCompletionNotifyingBuildActionRunner.java:39)
at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:49)
at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:44)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:315)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:305)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:101)
at org.gradle.internal.operations.DelegatingBuildOperationExecutor.call(DelegatingBuildOperationExecutor.java:36)
at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:44)
at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:49)
at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:46)
at org.gradle.composite.internal.DefaultRootBuildState.run(DefaultRootBuildState.java:78)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:46)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:31)
at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:42)
at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:28)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:78)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:52)
at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:59)
at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:36)
at org.gradle.tooling.internal.provider.SessionScopeBuildActionExecuter.execute(SessionScopeBuildActionExecuter.java:68)
at org.gradle.tooling.internal.provider.SessionScopeBuildActionExecuter.execute(SessionScopeBuildActionExecuter.java:38)
at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:37)
at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:26)
at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:43)
at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:29)
at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:60)
at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:32)
at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:55)
at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:41)
at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:48)
at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:32)
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:67)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:37)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:26)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:34)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:74)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:72)
at org.gradle.util.Swapper.swap(Swapper.java:38)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:72)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:62)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:81)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:50)
at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:295)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
Caused by: org.gradle.api.InvalidUserDataException: NDK not configured.
Download it with SDK manager.
at com.android.build.gradle.tasks.ExternalNativeJsonGenerator.create(ExternalNativeJsonGenerator.java:696)
at com.android.build.gradle.internal.TaskManager.createExternalNativeBuildJsonGenerators(TaskManager.java:1711)
at com.android.build.gradle.internal.ApplicationTaskManager.lambda$createTasksForVariantScope$10(ApplicationTaskManager.java:210)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:81)
at com.android.build.gradle.internal.ApplicationTaskManager.createTasksForVariantScope(ApplicationTaskManager.java:205)
at com.android.build.gradle.internal.VariantManager.createTasksForVariantData(VariantManager.java:530)
at com.android.build.gradle.internal.VariantManager.lambda$createAndroidTasks$1(VariantManager.java:352)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:81)
at com.android.build.gradle.internal.VariantManager.createAndroidTasks(VariantManager.java:348)
at com.android.build.gradle.BasePlugin.lambda$createAndroidTasks$6(BasePlugin.java:749)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:81)
at com.android.build.gradle.BasePlugin.createAndroidTasks(BasePlugin.java:744)
at com.android.build.gradle.BasePlugin.lambda$null$4(BasePlugin.java:650)
at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:81)
at com.android.build.gradle.BasePlugin.lambda$createTasks$5(BasePlugin.java:646)
at org.gradle.configuration.internal.DefaultListenerBuildOperationDecorator$BuildOperationEmittingAction$1$1.run(DefaultListenerBuildOperationDecorator.java:150)
at org.gradle.configuration.internal.DefaultUserCodeApplicationContext.reapply(DefaultUserCodeApplicationContext.java:58)
at org.gradle.configuration.internal.DefaultListenerBuildOperationDecorator$BuildOperationEmittingAction$1.run(DefaultListenerBuildOperationDecorator.java:147)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
at org.gradle.configuration.internal.DefaultListenerBuildOperationDecorator$BuildOperationEmittingAction.execute(DefaultListenerBuildOperationDecorator.java:144)
at org.gradle.internal.event.BroadcastDispatch$ActionInvocationHandler.dispatch(BroadcastDispatch.java:91)
at org.gradle.internal.event.BroadcastDispatch$ActionInvocationHandler.dispatch(BroadcastDispatch.java:80)
at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:42)
at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:230)
at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:149)
at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:58)
at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:324)
at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:234)
at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:140)
at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:37)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy37.afterEvaluate(Unknown Source)
at org.gradle.configuration.project.LifecycleProjectEvaluator$NotifyAfterEvaluate$1.execute(LifecycleProjectEvaluator.java:190)
at org.gradle.configuration.project.LifecycleProjectEvaluator$NotifyAfterEvaluate$1.execute(LifecycleProjectEvaluator.java:187)
at org.gradle.api.internal.project.DefaultProject.stepEvaluationListener(DefaultProject.java:1419)
at org.gradle.configuration.project.LifecycleProjectEvaluator$NotifyAfterEvaluate.run(LifecycleProjectEvaluator.java:196)
... 105 more

Get more help at https://help.gradle.org

CONFIGURE FAILED in 28s

Sorry Im really new to android studio :(

ok, I will check later

Please wait (im ask google first)

Yeah, the sdk & ndk dir can be specific at local.properties

And ndk can be auto discover by android studio, if you put it a sdk/

And ndk can be auto discover by android studio, if you put it at sdk/

Only for interesting: Where is this folder?

D:__GitHub_EGNX\LATEST\engine-x_20200805\tests\cpp-tests\CMakeLists.txt : C/C++ debug|armeabi-v7a : CMake Error at D:/__GitHub/_EGNX/LATEST/engine-x_20200805/cocos/CMakeLists.txt:93 (add_subdirectory):
The source directory
D:/_____GitHub___/_EGNX/LATEST/engine-x_20200805/external

does not contain a CMakeLists.txt file.
Affected Modules: CppTests

The adt download from https://dl.google.com/android/adt/adt-bundle-windows-x86_64-20140702.zip?utm_source=androiddevtools&utm_medium=website

It's strange you encounter the error does not contain a CMakeLists.txt file. Actually, the external folder have CMakeLists.txt

Thats my next error
Failed to find Build Tools revision 29.0.2
=> Solution:
download last version platform-tools this link https://developer.android.com/studio/releases/platform-tools
copy platform-tools to sdk\platform-tools
rebuild

It's strange you encounter the error does not contain a CMakeLists.txt file. Actually, the external folder have CMakeLists.txt

I forgot to download the externals :(

I have downloaded: platform-tools_r30.0.4-windows (the latest)
I got this error again: Failed to find Build Tools revision 29.0.2
Can I switched to r30.0.4 and how on cpp-tests?

please check the files: gradle.propeties and build.gradle

Another question:
Is it useful to run  setup.py too?

Actually, I'm not use it, I download adt, ndk ansroid studio maually through BT, because network not fast
It
It stupid if Android studio can't auto download and install speccific dep tools refer to proj.android gradle config

I forgot to install 29: do it now...hope it works
Packages to install:

Android SDK Platform 29 (platforms;android-29)
Sources for Android 29 (sources;android-29)

Preparing "Install Android SDK Platform 29 (revision: 4)".
Downloading https://dl.google.com/android/repository/platform-29_r04.zip

Normally, when gradle sync failed with dep tool missing, the output of android studio shoud have a link to click download and install

Normally, when gradle sync failed with dep tool missing, the output of android studio shoud have a link to click download and install

Failed to find Build Tools revision 29.0.2  <=  thats the only information (no link)

Failed to find Build Tools revision 29.0.2 comes again
Downloading now: (I think thats the missing packet)
Packages to install:

Android SDK Build-Tools 29.0.2 (build-tools;29.0.2)

Preparing "Install Android SDK Build-Tools 29.0.2 (revision: 29.0.2)".
Found existing prepared package.
"Install Android SDK Build-Tools 29.0.2 (revision: 29.0.2)" ready.
Installing Android SDK Build-Tools 29.0.2 in C:\Users\eismpesd\AppData\Local\Android\Sdk\build-tools\29.0.2
"Install Android SDK Build-Tools 29.0.2 (revision: 29.0.2)" complete.
"Install Android SDK Build-Tools 29.0.2 (revision: 29.0.2)" finished.

Build runs now (I got no "blocking" errors).
Next step.... virtual device installation

Oh dear,
Im wrong:
Errors while building APK. You can find the errors in the 'Messages' view.
More than one file was found with OS independent path 'lib/armeabi-v7a/libmpg123.so'. If you are using jniLibs and CMake IMPORTED targets, see https://developer.android.com/studio/preview/features#automatic_packaging_of_prebuilt_dependencies_used_by_cmake

Here are the short description:
With Android Gradle Plugin 4.0, the above configuration is no longer necessary and will result in a build failure:

What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.

A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
More than one file was found with OS independent path 'lib/x86/libprebuilt.so'

External native build now automatically packages those libraries, so explicitly packaging the library with jniLibs results in a duplicate. To avoid the build error, move the prebuilt library to a location outside jniLibs or remove the jniLibs configuration from your build.gradle file.

Will you change/adapt it "global"?
Or is it a part of the documentation?

Because you use Plugin 4.0? The default of egnx plugin is 3.1.0?

Yes. It was a recommendation which comes up on Android Studio

OK, I will try it, may put to next alpha prerelase

OK, I will try it, may put to next alpha prerelase

Thanks. So I have to wait? Or can I switch back to plugin is 3.1.0? If Yes, how?

Can you post a PR to upgrade this, I agree to update.

Here are some more infos on the web:
Known issues
This section describes known issues that exist in Android Gradle plugin 4.0.0.
Race condition in Gradle worker mechanism
Changes in Android Gradle plugin 4.0 can trigger a race condition in Gradle when running with --no-daemon and versions of Gradle 6.3 or lower, causing builds to hang after the build is finished.
This issue will be fixed in Gradle 6.4.

Remember change all tests proj.android/build.gradle to 4.0.1

So, let's wait they solve the issue?

So, let's wait they solve the issue?

Of course.
Thanks always for your fast fix and time for some of my silly questions too.

Or if upgrade Plugin to 4.0.1 and upgrade gradle to 6.4+?

So, let's wait they solve the issue?

Of course.
Thanks always for your fast fix and time for some of my silly questions too.

You are welcome.

Or if upgrade Plugin to 4.0.1 and upgrade gradle to 6.4+?

I will try it.  But I got this error:
Fail to load plugin descriptor from file gradle-6.5.1-all.zip

I have test, gradle sync success with 6.5.1 & plugin 4.0.1

I have test, gradle sync success with 6.5.1 & plugin 4.0.1

So this are the recommended versions for gradl and plugin on EGNX?

Yeah, just do it, and I build apk sucess

I think it will build here too.
So another question is:
Which Virtual Device is the recommendation for a first look?
Or how is your "debug process on apk's"?

Real device is recommand, I never use Virutal Device to debug

android.gradle plugin-4.0.1, gradle-6.5.1 is not helping on my android setting, I got always this error:
More than one file was found with OS independent path 'lib/armeabi-v7a/libmpg123.so'. If you are using jniLibs and CMake IMPORTED targets, see https://developer.android.com/studio/preview/features#automatic_packaging_of_prebuilt_dependencies_used_by_cmake

Just comment follow two lines:

That is what I get:

Should delete .so from src/man/jniLibs

Should delete .so from src/man/jniLibs

Should it not the build itself?

you should delete manually to avoid confilicit

I got the apk now. Great. Thanks so much.

So I have installed om my phone. some tests works some crashing

Please list the crashing tests

Android build guilde should be finish by the latest commit README.md/README_CN.md


docs(README): update

Deploy preview ready!
Built with commit 9e59fde07ecff4b30b436a440fc210691f01a0d9
https://deploy-preview-4--react-svg-drag-and-select.netlify.com


Make sure ScriptMain directly uses no managed variables

I didn't notice sGameReloaded was a managed variable and could make it unmanaged without crashing during the first session load when #1167 was merged. No wonder some managed function call was needed before ScriptMain got called once if ScriptMain was unmanaged (24fa6e5).
I create this PR because I just want to make sure this won't create new issues compared to #1167.

Turns out the game may crash sometimes before the game completely loaded for the first time.

This answer might help if we have to avoid any managed function calls in DllMain in the future and legiminately invoke managed functions from ScriptMain?


Optionally allow skipping authentication for preflight requests (CORS)

Motivation:

We have an internal single-page application and api behind oauth2_proxy, so before users could use the app itself or the api they have to be authorized
In normal environment - staging or production - everything is fine since SPA is making requests to the same host
But there is a pain during local development of the app, since cross-origin policies kick in.
GET requests can be enabled through extending CORS rules and setting XMLHttpRequest.withCredentials to true (so the proxy's cookies would be sent) - as a result if a user was authorized on the staging, for local development a user will act under his own credentials.
However, POST requests require pre-flight requests to be sent out. Due to w3c standards, for preflight requests (OPTIONS) the proxy's cookies cannot be sent even with XMLHttpRequest.withCredentials=true, so POST/PUT/DELETE actions cannot pass unless we allow skipping authentication for preflight requests.
We intend to use it only on staging for speeding up local development, that's why it should be a configurable and disabled by default.
Due to not so standard and extended usage, oauth proxy is still easiest and fastest way for us to have an authorization for out app.

Preparing a PR now.

resolved by #370


CUDA: Numerical differences between CPython / CPU target and the CUDA target in math.pow

Originally noticed on Discourse.
The following:
from numba import cuda, njit
import numpy as np
import math

def inner(x, y):
    return int(math.pow(x, y))

cpu_jitted = njit(inner)

def cuda_jitted(x, y):
    inner_device = cuda.jit(device=True)(inner)

    @cuda.jit
    def outer(r, x, y):
        r[()] = inner_device(x[()], y[()])

    r_arr = np.array(0, dtype=np.int64)
    x_arr = np.array(0, dtype=np.int64)
    y_arr = np.array(0, dtype=np.int64)
    x_arr[()] = x
    y_arr[()] = y
    outer[1, 1](r_arr, x_arr, y_arr)

    return r_arr[()]

x = 3
y = 1

print(inner(x, y))
print(cpu_jitted(x, y))
print(cuda_jitted(x, y))

prints
3
3
2

This can cause some surprise.

Similar occurs in CUDA C / C++:
// Compile with:
// nvcc -gencode arch=compute_75,code=sm_75 -std c++17 mini.cu -o mini
//
// produces:
//
// 3
// 2

#include <iostream>
#include <cstdint>

template<typename T>
__global__ void kernel(T* r, T* x, T* y)
{
  r[0] = std::pow(x[0], y[0]);
}

template <typename T>
T host(T x, T y)
{
  return std::pow(x, y);
}

__managed__ uint32_t r_32;
__managed__ uint32_t x_32;
__managed__ uint32_t y_32;

int main(int argc, char **argv)
{
  x_32 = 3;
  y_32 = 1;
  kernel<<<1, 1>>>(&r_32, &x_32, &y_32);
  cudaDeviceSynchronize();
  std::cout << host(x_32, y_32) << std::endl;
  std::cout << r_32 << std::endl;
}

The CUDA target doesn't end up using int_power_impl, but the CPU target does. This will likely need some adjustments in the typing / lowering for math.pow for CUDA, but because of the mix of implementations (those from the CPU target, impl_pow_int and impl_binary in mathimpl.py) means that it will need a bit of careful thinking about / testing.

I think I'm going to label this as an actual bug because I think it should be fixable to be less surprising, even though the same occurs in CUDA C/C++.

If the result is expected to be integral, it is possible to solve this in the same way as CuPy with an exponentiation-by-squaring algorithm, as I noted in the cuDF issue you linked. https://github.com/rapidsai/cudf/issues/10178#issuecomment-1029200496

Thanks @bdice - this is indeed what should be happening - it should be picking up this implementation: https://github.com/numba/numba/blob/main/numba/cpython/numbers.py#L206 but it isn't.
There's a wider question of why CUDA even needs to redefine the typing / lowering of things that already have implementations, which also needs looking at, possibly at the same time as this - having unnecessary redefinitions increases the chances of issues like this occurring.


Add C++11 flag

Added C++11 flag, like in https://github.com/ros2/rmw_opensplice/blob/master/rmw_opensplice_cpp/CMakeLists.txt#L5
Connects to https://github.com/ros2/rmw/pull/69

@wjwwood thanks.


Add NewWithReadline to have a shell with custom readline Instance

This PR creates a new helper function NewWithReadline in ishell.go to allow users to create a shell instance with a custom readline instance.
Plus we use this function in NewWithConfig to refactor code.
I needed that in a project to call some member methods of the readline instance.
I've been using ishell for a few weeks now, nice and clean project, thanks!

Thanks!


Add configurability for hf checkpointer register timeout

Also increases the default from one hour two hours.

@mvpatel2000 yup, see PR description


Hi, in the server console is the following issue.

https://pastebin.com/NsX31fAU

Think this should be fixed for the next release :)


Android Basics: SQL Basics

there's no seconde step in "Open the project in Android Studio" when it ask tu execute the code

Hello @Othot1992,
Thanks for reporting that missing step, it will be fixed.


How how handle server submit errors that don't follow the validation schema?

If the server returns a error that is not specifically tied to a form control, then how do i store the error since I can't transform the error to the form schema?

Also had this issue

DId you figure this out? Its not documented....

Just handle it outside using a variable. The error handling seems to be configured purely towards the form fields themselves. In theory you could add a fake field to the errors store and use a validation reporter for it, but I haven't tried that and feel it would get messy fast. Also likely to result in type errors if you are using TS.
My implementation (in TS):
onError: (error) => {
        if (error instanceof Error) {
          formError = error.message;
        } else if (error instanceof HttpError) {
          return error.errors;
        }
      },

Where formError is a block alert above the form.  error.errors from any HttpError object will be server side validations in the format expected by Felte.


✨ [Feature request]: I want to improve the UI of play video preview

Is your feature request related to a problem? Please describe.

No loading state
This search bar is not  ooking that good
There is no gap in two video
Right side has extra space and video is located in left

Describe the solution you'd like.
I can solve all of the given problem
Describe alternatives you've considered.
Not necessary I think
Screenshot / Screenshare
No response
Additional context
No response
Record

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I want to work on this issue
[X] I am a Hacktoberfest contributor

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hey @BayajidAlam!
Have assigned you the issue. We are looking forward to your contribution 🙌
The PR of this issue will be counted under the NINJA CHALLENGE. Join our discord community for more details.

@PriteshKiri Thanks for assigning me the issue! I’m excited to contribute 🎉. Just a quick note – I’m participating in Hacktoberfest, so I’d like this PR to count towards that, if possible. Could you please confirm if that’s okay?
Looking forward to contributing!

Yes @BayajidAlam!!
PR for this issue will be counted under hacktoberfest.


Information available to sharding codec

Currently the sharding codec spec reads that "each integer must by divisible by the chunk_shape of the array as defined in the chunk_grid Array metadata.". However, array->array codecs can change the shape of the requested chunk (e.g. the transpose codec permuting dimensions); in this case, the sharding codec's chunk shape should correspond to the permuted shape rather than the array's shape.
The sharding codec will also need to duplicate empty-chunk logic from the array class, which also means it will need access to the array's fill value. However, as array->array codecs could feasibly change values in the array (could they also change the data type?), the fill value may also need these transformations applied to it.
This probably all falls under  the codec.compute_encoded_representation_type method in the spec.

In zarrita I pass a subset of the array metadata to the codecs: https://github.com/scalableminds/zarrita/blob/v3/zarrita/array.py#L101-L110

As far as the issue of the chunk shape being affected by prior codecs (also applies if there is nested sharding), you are correct.  I tried to fix the wording to address that issue in this (otherwise unrelated) PR https://github.com/zarr-developers/zarr-specs/pull/237/files
As far as the fill value, that is indeed an issue that I hadn't considered.  I agree that we should resolve this issue by saying that for "array -> array" codecs, compute_encoded_representation_type also needs to compute the new fill value for the "encoded" representation.


Updated for v12 and PbtA v1+. updated one move.

Updated for v12
PbtA v1+
updated one move.

fixes from ephson for foundry v12


444 meta table for semaphore failing

To test you can run test:
docker exec semaphore-core python3 -m pytest
Try running a model:
docker exec semaphore-core python3 src/semaphoreRunner.py -d TestModels/test_dspec.json
You can also cause semaphore to fail somewhere.
You can see the results by querying the db:
SELECT * FROM outputs
JOIN model_runs ON outputs."id" = model_runs."outputID"
This PR contains a DB migration script, the number might need to be changed on merge

Tests Passed


Fixing empty output warning

Task name: DockerComposeV0
Description: When command output is empty it results in a warning like:
##[warning]No data was written into the file /home/vsts/work/_temp/task_outputs/tag_ajinkya599hello-world_1612183887458.log
Fixing this by adding a newline to the output in such a case.
Documentation changes required: Y
Added unit tests: N
Attached related issue: #12470
Checklist:

[x] Task version was bumped - please check instruction how to do it
[x] Checked that applied changes work as expected

Warning won't go away with empty string.


ci(docker): bump version

hello!
bumping version to: https://github.com/celestiaorg/.github/releases/tag/v0.5.0
best!

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

Project coverage is 45.36%. Comparing base (2469e7a) to head (53d5ce7).
Report is 375 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3914      +/-   ##
==========================================
+ Coverage   44.83%   45.36%   +0.52%
==========================================
  Files         265      307      +42
  Lines       14620    21834    +7214
==========================================
+ Hits         6555     9905    +3350
- Misses       7313    10861    +3548
- Partials      752     1068     +316

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


Visitor holding Value

As requested on the discord, posting a detailed issue about trying valuable for Tera.
Background
I am trying to see if valuable could replace serde_json::Value for Tera.
The goal in a template engine is to find the value the user wants to use in a given context.
Right now, the context in Tera is just serde_json::Value, which means we serialise everything even though we don’t really need it.  See https://docs.rs/tera/1.10.0/tera/struct.Context.html for examples of Context.
In Tera, you need to evaluate expressions based on the context. For example:

{{ get_metadata(path=page.path ~ “image.jpg”) }}: this concatenates into a single string which is then passed as an argument to a function
{% if user.is_admin or data.public %}: this evaluates the fields truthiness
{{ item.price * current_rate | format_currency }}: this multiplies the value found in the context and then applies a filter on the output
{% for result in data.results[user.birth_year] %}

There are more examples on the Tera documentation: https://tera.netlify.app/docs/
If you are familiar with Django/Jinja2/Twig/Liquid this is essentially the same thing.
The way it currently work is the following:

Convert the whole context received into serde_json
Evaluates values in brackets, like user.birth_year in the example. If the value is an integer, we assume it’s the index of the array so we don’t change anything
Replace the values in brackets by their actual value and create a JSON pointer based on it
Use https://docs.serde.rs/serde_json/enum.Value.html#method.pointer on the context to retrieve the value (or not if it wasn’t found)
Do pattern matching on the Value kind: if we’re doing a math operation like *, we need to make sure both operands resolve to a Value::Number for example, string concatenation with ~ only work on Value::String and so on

Where valuable comes in
As mentioned, it currently serialises the whole context which can be very costly. For example, rendering a section in a Zola site will clone the content of all the sub-pages if pagination isn’t set up, which can quickly become slow.
The whole Tera cloning the context is actually one of the biggest current perf bottleneck in Zola as you need to clone the content every time you render the page, which can be pretty big considering it’s potentially thousands of HTML pages.
Examples
What I’d like to accomplish is be able to visit the context and extract the Value for each identifier. Let’s use https://github.com/tokio-rs/valuable/blob/master/valuable/examples/print.rs as an example data and say that the person variable is our context.
{{ name }}
The path is [“name”] so we only need to visit Structable and Mappable and look for that key
{{ addresses.1.city }}
The path is [“addresses”, 1, “city”]. We visit Structable/Mappable because it begins with a string and visit the field where it is equal to addresses. This is an array so we visit Listable. We know we want to only care about the element at index 1 so we could only visit that one ideally (see https://github.com/tokio-rs/valuable/issues/52). Once there, there is only city left to match so we visit in Structable/Mappable again.
{% for address in addresses %}
Here we want to iterate on the Vec<Address> so I think we just need to visit the addresses and get a Vec<Structable> which we visit in its entirety one by one (since you can break from the loop).
The goal
In all cases above we want to get the Value corresponding to the path out of the visit and pattern match later. Since visit doesn’t return anything, I need to store it on the visitor struct. The Value found could be a primitive, a Mappable/Structable (for loops on key values) or not found at all.
However I get a lifetime error if I try to assign a Value in a small toy example: https://gist.github.com/Keats/150acda601910c5f8a6bd9aceba2ddfd so I’m not sure how I would accomplish that. Is there an example of a visitor holding a Value somewhere?
The article at https://tokio.rs/blog/2021-05-valuable specifically mention template engine so I’m wondering if the idea was limited to writing the value to a string buffer or whether it is too limited for Tera.

{% for address in addresses %}

For most of this, it seems like we need a "pointer" concept similar to a JSON pointer, which should be totally doable as an additional trait fn.

Here we want to iterate on the Vec<Address> so I think we just need to visit the addresses and get a Vec<Structable> which we visit in its entirety one by one (since you can break from the loop).

I'm not following this, why does {% for address in addresses %} require collecting all the addresses into a Vec instead of rendering each partial in the visitor.

I'm not following this, why does {% for address in addresses %} require collecting all the addresses into a Vec instead of rendering each partial in the visitor.

You have a few specific variables available in a loop that require knowing the length and the current index of the item and (not yet implemented in Tera) a variable holding the previous and next item: https://jinja.palletsprojects.com/en/3.0.x/templates/#for

Hmm, Ok. It may be worth considering switching Listable to be fixed length.
Is loop.changed(*val) relevant here?

Is loop.changed(*val) relevant here?

Not for Tera at least

@hawkw @taiki-e thoughts on if Listable should be fixed-sized?

thoughts on if Listable should be fixed-sized?

What does fixed-sized list in the context of valuable mean? How does it differ from matches!(size_hint(), (x, Some(y)) if x == y) listables?

@taiki-e the main difference is that it would not be permitted to have an unknown length. i.e. instead of targeting any Iterator we would only permit ExactSizeIterator.

Actually in template/expression engine we might not use the visitor pattern for all cases. I prefer as_value and Value APIs for path navigation. Does it make sense to add methods like get_by_key and get_by_index for Mappable and Listable?

With https://github.com/tokio-rs/valuable/pull/59 working with strings, it should work well.

As long as Mappable's visit api is implemented like this, it always take O(n) to access a field using visitor API.

@sunng87 for fast lookups, using Structable is better than Mappable. Note how Structable supports dynamic fields. The idea is, if you know fields you want to lookup "fast", define them as a structable, then have the rest of the fields as dynamic fields.

get_by_key is not really possible to implement for Mappable w/ generic key types for HashMap (as far as I could tell).


RateLimits not being applied with external redis

Expected
RLP applied and for requests to be ratelimited
This worked well when not using an external redis
I expected it to keep working after updating the limitador CR to add a redis storage credential. Instead rate limitis stop being applied, even though the policy is marked as enforced and kuadrant is marked as ready.
Reproduce

Deployment was across two clusters using v1-rc4
Updated Limitador CRD in both clusters to have a valid credential ref:

spec:
  storage:
    redis:
      configSecretRef:
        name: redis-credentials

Kuadrant became ready and the RLP remained in an enforced state but my curl requests continued to always return 200

RateLimitPolicy used :
apiVersion: kuadrant.io/v1
kind: RateLimitPolicy
metadata:
  name: gw-rlp
  labels:
    policy: 'gateway'
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: external
  limits:
    'global':
      rates:
        - limit: 5
          window: 10s

@alexsnaps FYI

@jsmolar @averevki do we have additional tests covering use of external redis? Would like to cover it to see is this an actual issue or something unique to my setup

@maleck13 we aim to have manual test scenario for this. Unfortunately it is not finalized yet. I tried this myself and I was not able to make it work either.  However, I did test the external redis (aws elasticache) back in April so quite a long time ago, there have been a lot of changes since then so I could easily make some user error. I will try again tomorrow but for now I would say that we should treat this as a real issue.

Also, it is worth mentioning that the Kuadrant-operator will default (tho, I think it can't be configured any other way as of now) to configure the wasm-shim to allow request through on failures to talk to Limitador (or that error'ing out because of that not being able to talk to the configured Redis). So it's important to gather logs from these participants when things fail here in that very way, as this is the expected behavior in the face of configuration/transient issues...

@alexsnaps I am sorry for not being clear enough.
Yes, there are automated tests around Ratelimiting - along the lines of creating RLP and ensuring 429 is returned after expected no. of requests, but only with trivial (empty .spec) Limitador CR. Back in April I tested Kuadrant with AWS Elasticache but I used .redis-cached. I am not aware of any testing of non-cached Redis being done by QE.
Today I tried this more thoroughly. By "this" I mean creating a new OCP cluster in AWS. Installing Kuadrant v1 rc4 there. Setting up GW, HTTPRoutes, policies etc and making sure it works, including RLPs (429s returned as expected). Then I created Elasticache instance in cluster's VPC, removed RLPs and updaded Limitador CR (.spec.storage.redis.configSecretRef.name) so that it uses Elasticache instance for persistence. I recreated the RLPs and tried again. This time I got 429s as expected so it seems it works just fine.
Not sure what I did wrong yesterday.

thanks @trepel I am going to re-test locally here and see do I hit the issue again also. Will provide more details if I do.

yw, fyi, I connected to my elasticache instance and I can see the key for my RLP limit there:
keys *
1) "namespace:{scale-test-0/httproute-gw1-l1-i0},counters_of_limit:{\"namespace\":\"scale-test-0/httproute-gw1-l1-i0\",\"seconds\":10,\"conditions\":[\"limit.httproute_level__1b8e78f8 == \\\"1\\\"\"],\"variables\":[]}"
```

👌 Awesome... and again, @maleck13, if something "isn't working", please look into the Limitador CR to see if it reflects the changes you'd expect, and the logs of your limitador pod and envoy... As @trepel points out, looking into the Redis(-alike) is certainly one way to validate things are fine.

I don't think we should expect the ratelimitpolicy to be removed if the storage changes in limitador?

Yeah, removing the RLP shouldn't be a requirement... Again, other that event triggering something "else", there is also no need for it... It all should trigger the Limitador CR to be updated. Changing the storage, unlike adding & removing limits, requires the Limitador process/pod to be restarted tho

Before RLP applied
redis keys
KEYS *
(empty array
After RLP applied and Limitador updated

"namespace:{gateway-system/toystore},counters_of_limit:{"namespace":"gateway-system/toystore","seconds":10,"conditions":["limit.global__dc30d66c == \"1\""],"variables":[]}"
"namespace:{gateway-system/toystore},counter:{"limit":{"namespace":"gateway-system/toystore","seconds":10,"conditions":["limit.global__dc30d66c == \"1\""],"variables":[]},"set_variables":{},"remaining":null,"expires_in":null}"

So I will close this as cannot reproduce. I am not sure what the issue was unfortuantely with the previous install...

Adding as much context as I can. I don't know right now what in the stack isn't working:  The Limitador CR reports no issues and the kuadrant-operator does not report any issues in the logs
# BEFORE APPLYING STORAGE
apiVersion: limitador.kuadrant.io/v1alpha1
kind: Limitador
metadata:
  name: limitador
  namespace: kuadrant-system
spec:
  limits:
  - conditions:
    - limit.global__f63bec56 == "1"
    max_value: 5
    namespace: gateway-system/toystore
    seconds: 10
    variables: []
status:
  conditions:
  - lastTransitionTime: "2024-11-13T12:18:13Z"
    message: Limitador is ready
    reason: Ready
    status: "True"
    type: Ready
  observedGeneration: 2
  service:
    host: limitador-limitador.kuadrant-system.svc.cluster.local
    ports:
      grpc: 8081
      http: 8080

---
#AFTER APPLYING STORAGE
apiVersion: limitador.kuadrant.io/v1alpha1
kind: Limitador
metadata:
  name: limitador
  namespace: kuadrant-system
spec:
  limits:
  - conditions:
    - limit.global__f63bec56 == "1"
    max_value: 5
    namespace: gateway-system/toystore
    seconds: 10
    variables: []
  storage:
    redis:
      configSecretRef:
        name: redis-credentials
status:
  conditions:
  - lastTransitionTime: "2024-11-14T08:40:18Z"
    message: Limitador is ready
    reason: Ready
    status: "True"
    type: Ready
  observedGeneration: 3
  service:
    host: limitador-limitador.kuadrant-system.svc.cluster.local
    ports:
      grpc: 8081
      http: 8080

The limitador operator also does not seem to have an issue when I add or remove the configuration for storage other than the occasional :
 the object has been modified; please apply your changes to the latest version and try again. Which is a common error in controllers

limitador-operator-controller-manager-6687869587-sqzmr manager {"level":"info","ts":"2024-11-14T08:47:07Z","logger":"limitador","msg":"update object","limitador":{"name":"limitador","namespace":"kuadrant-system"},"GKV":"apps/v1, Kind=Deployment","name":"limitador-limitador","namespace":"kuadrant-system"}
limitador-operator-controller-manager-6687869587-sqzmr manager {"level":"info","ts":"2024-11-14T08:47:07Z","logger":"limitador","msg":"successfully reconciled","limitador":{"name":"limitador","namespace":"kuadrant-system"}}


avoid storing redundant tx from blockpropose event

this PR for now fixes wallet/browser and nightfall_client

only storing relevant transaction
also only storing block object for which any transaction is stored to db

fixes #667

Do we need to apply these changes to client-nightfall?

yes I believe, that why I refactored client as well in this PR

Can you think of how we can test this?

the best way to test is (and the way i did is) to customise erc20.test.mjs for all scenario, I also run wallet app for case where client is not hosting a particular user (i.e keys are not store in client).

Hey @LijuJoseJJ, are you still working on this PR?

Hey @LijuJoseJJ, are you still working on this PR?

didn't notice merge conflict, will fix by tomorrow


Laravel 5.3 - Broadcast Facade autocompletion missing

Laravel 5.3 - Broadcast Facade auto-completion is missing...

Also, using it like app(BroadcastManager::class)->routes(); works, but again, autocompletion is partial. For instance, app(BroadcastManager::class)->channel(); doesn't get proper autocompletion.

+1

Are you generating the file yourself? And have added the facade in your config/app.php?

Had the same problem. Fixed it with adding
'Broadcast' => Illuminate\Support\Facades\Broadcast::class,
as an alias in config/app.php and regenerating the file with composer update

+1

+1

+1

This was fixed in Laravel via https://github.com/laravel/framework/pull/24531 in Laravel 5.6, nothing we can do for Laravel 5.5
@barryvdh issue can be closed :}


Context Menu

Context Menus - Feature Request
Not sure if it breaks design rules for semantic-ui but I would like to suggest a feature to have a context menu on right mouse click.  There does seem to be most of the functionality required already working.
For example the popup function with wide menu as shown in the popup examples is very close to creating this feature.
$('.example .custom.button')
  .popup({
    popup : $('.custom.popup'),
    on    : 'click'
  })
;

Just changing the on event to support 'context' or 'rightclick'.

#203 Continue discussion there