Text in navigation footer (previous, next) in not translated

Describe the problem
Hi,
The new navigation footer now has "PREVIOUS" and "NEXT" labels. These labels seem to be hardcoded in the css and are not translated when changing the language of the book. While they can be overridden in the CSS, it might be good to have them generated directly in the book's language (I am using "language: fr").
(As a side note, I preferred the old style with "<<", ">>" and the smaller font.)
Thanks,
Pascal
Link to your repository or website
No response
Steps to reproduce
This problem can be seen in any generated book when setting the language to anything different from English.
The version of Python you're using
No response
Your operating system
No response
Versions of your packages
❯ jupyter-book --version
Jupyter Book      : 0.11.2
External ToC      : 0.2.2
MyST-Parser       : 0.13.7
MyST-NB           : 0.12.3
Sphinx Book Theme : 0.1.1
Jupyter-Cache     : 0.4.2
NbClient          : 0.5.3

Tasks

[ ] Look into the translation function from https://github.com/executablebooks/sphinx-book-theme/pull/214 to re-use that function
[ ] Confirm that the translation works as expected

Heya, yeh these navigations are inherited from pydata-sphinx-theme:https://github.com/pydata/pydata-sphinx-theme/blob/f0834772d24c962b7d11643114db88615c43674e/pydata_sphinx_theme/layout.html#L4, and so are not currently handled by the translation functionality included in sphinx-book-theme
So either pydata needs to be "fixed" there (cc @jorisvandenbossche) or we need to override that macro

Ah this was actually a recent change in the CSS to add "previous" and "next" (it was inspired from the Furo docs). This makes me think we might want to change the implementation as I doubt CSS can be translated unless we turn it into a _t template, which seems sub-optimal 🤔

Ah ok yeh no that needs to go in the html templates, so it can be translated

@choldgraf did you check that #374 actually works, because I don't think it will; you are using sphinx's internal translation function which does not include PREVIOUS/NEXT, rather than using the translation function I set up in #214

testing in #381

ahhh in that case you are right - I didn't realize we needed a separate setup for this. I will keep this on my plate in that case and try to get to it when I have time.

I can confirm that the translations do not work. I tried using the translate function and looked at the README docs of the translate folder which seems like it would work, with a few confusion points.
@chrisjsewell what languages did you select when you generated the translations? And after that you just put it in a specific folder and then ran python sphinx_book_theme/translations/_convert.py? I think we need to have a "step by step" guide for adding a new translation to the theme so that it's straightforward to do this. I can try to write this but I need to know the steps first haha.

what languages did you select when you generated the translations?

all of them

nd after that you just put it in a specific folder and then ran python sphinx_book_theme/translations/_convert.py

yep should be as easy as that

I spent a while trying to figure out the translation machinery and was not able to do so. I don't have time to work on this now so instead I've opened up an issue about documenting this infrastructure, and added in my steps that I took in that issue in case others have time to take a look: https://github.com/executablebooks/sphinx-book-theme/issues/382
I'll leave this issue open in the meantime, though removing myself from assignment because I'm not sure when I'll have a moment to work on coding stuff. We might also consider reverting back to just using -> instead of english words, so that we don't have to do the translation stuff.

OK I believe that https://github.com/executablebooks/sphinx-book-theme/pull/384 fixed this issue. @pfelber can you install the latest version from master and report back if the translations correctly happen?

I verified and translations happen correctly, thanks!


Not working/loading?

I'm probably being stupid about this but it seems to not be working for me, I have it and all it's dependencies put into the Mods folder in the TLD directory. In game middle mouse clicking and right mouse clicking do nothing to fires and there are no mod options for it.
Melon gives out this error upon loading the mod on start up though.
[InfinityFires] System.TypeLoadException: Could not load type 'Fire' from assembly 'Assembly-CSharp, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null'.
at System.Reflection.CustomAttribute._CreateCaObject(RuntimeModule pModule, RuntimeType type, IRuntimeMethodInfo pCtor, Byte** ppBlob, Byte* pEndBlob, Int32* pcNamedArgs)
at System.Reflection.CustomAttribute.CreateCaObject(RuntimeModule module, RuntimeType type, IRuntimeMethodInfo ctor, IntPtr& blob, IntPtr blobEnd, Int32& namedArgs)
at System.Reflection.CustomAttribute.AddCustomAttributes(ListBuilder1& attributes, RuntimeModule decoratedModule, Int32 decoratedMetadataToken, RuntimeType attributeFilterType, Boolean mustBeInheritable, ListBuilder1 derivedAttributes)
at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeType type, RuntimeType caType, Boolean inherit)
at System.RuntimeType.GetCustomAttributes(Boolean inherit)
at HarmonyLib.HarmonyMethodExtensions.GetFromType(Type type)
at HarmonyLib.PatchClassProcessor..ctor(Harmony instance, Type type, Boolean allowUnannotatedType)
at HarmonyLib.PatchClassProcessor..ctor(Harmony instance, Type type)
at HarmonyLib.Harmony.CreateClassProcessor(Type type)
at HarmonyLib.Harmony.b__11_0(Type type)
at HarmonyLib.CollectionExtensions.Do[T](IEnumerable1 sequence, Action1 action)
at HarmonyLib.Harmony.PatchAll(Assembly assembly)
at MelonLoader.MelonMod.HarmonyInit() in D:\a\MelonLoader\MelonLoader\MelonLoader\Melons\MelonMod.cs:line 40
at MelonLoader.MelonEvent.<>c.b__1_0(LemonAction x) in D:\a\MelonLoader\MelonLoader\MelonLoader\Melons\Events\MelonEvent.cs:line 174
at MelonLoader.MelonEventBase1.Invoke(Action1 delegateInvoker) in D:\a\MelonLoader\MelonLoader\MelonLoader\Melons\Events\MelonEvent.cs:line 143

All mods need updated to work with the new version

Ah ok, thank you


Add boolean attributes

Coverage decreased (-0.2%) to 97.412% when pulling ad84a6ce240368fb63580753730d60ed0ecab26c on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.3%) to 97.279% when pulling 1ef1627d522f62d6553e1fe0280aa9d207105368 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.3%) to 97.279% when pulling 1ef1627d522f62d6553e1fe0280aa9d207105368 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

@johnliu @danielhochman @garrettheel

Coverage decreased (-0.05%) to 97.575% when pulling 5741a8dec6a5f19739336f51e150a647938fceab on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.474% when pulling a2d4c3aaddcfe368419ae7cb0af497ba7147666c on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.4% when pulling deaacefc5db834451ff69b5320a08591312f7c2f on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.43% when pulling e71f9b0736f74630b45a90aa7ffe8d93e3625643 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.1%) to 97.505% when pulling a9842d4afac5f892b0785818c11b2da3a8fa7a8b on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.401% when pulling 56a8e0639500632b40b76f186ca79e891e3b7266 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.404% when pulling 235d996db72fd79ba95a39385340bf826f13e0ec on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.463% when pulling 1d92a05779efcfa348a421d4bcc7b0ac7c6d6bd9 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.463% when pulling 1d92a05779efcfa348a421d4bcc7b0ac7c6d6bd9 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.463% when pulling 1d92a05779efcfa348a421d4bcc7b0ac7c6d6bd9 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.463% when pulling 1d92a05779efcfa348a421d4bcc7b0ac7c6d6bd9 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.463% when pulling 1d92a05779efcfa348a421d4bcc7b0ac7c6d6bd9 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

+1 pending last two comments

Coverage decreased (-0.2%) to 97.439% when pulling c9915b35225ac73e4e69dad24da69c5715a2f798 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.439% when pulling c9915b35225ac73e4e69dad24da69c5715a2f798 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.4%) to 97.253% when pulling 5e480fdb216333c512a07fe44b87187ffe7d49f6 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.462% when pulling 5e480fdb216333c512a07fe44b87187ffe7d49f6 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.2%) to 97.462% when pulling 5e480fdb216333c512a07fe44b87187ffe7d49f6 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.4%) to 97.253% when pulling 5e480fdb216333c512a07fe44b87187ffe7d49f6 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.

Coverage decreased (-0.4%) to 97.253% when pulling 9549ed23e7878b7995d41f4fd16a6bfa9bc0cf24 on jmphilli:boolean-attributes into ebbf3348d614008f9d2e61a94f3037e7339c9101 on jlafon:devel.


How-To Ignore or Fix vSphere SSL Certificate Failure

We have an untrusted certificate on our vSphere vCenter.  I can't get anyone to fix this.  This used to work, but now, we are getting an error: 'certificate signed by unknown authority'.
How can I specify to 'trust' certificate or add a trusted certificate to the job?
Here is the problem area:
deploy-opsman-vm
09:36:44 Running deploy of OpsMgr VM task...
09:36:44 {Properties redacted}
09:36:44 Importing OVA of new OpsMgr VM...
09:36:44 Running govc import.ova -options=opsman_settings.json /tmp/build/39dbd1bf/pivnet-opsmgr/pcf-vsphere-1.12.5.ova
09:36:44 govc: Post https://cvgapvxrvcs01.td.afg/sdk: x509: certificate signed by unknown authority

Hi @gaigaslab
Which version of the pipelines are you using? We introduced new parameters recently:
vcenter_insecure: CHANGEME         # vCenter skip TLS cert validation; enter `1` to disable cert verification, `0` to enable verification
vcenter_ca_cert: CHANGEME          # vCenter CA cert at the API endpoint; enter a value if `vcenter_insecure: 0`

which will allow you to enable/disable this setting.

Hi @gaigaslab, closing this issue because we've introduced parameters which would allow you to control vCenter cert verification. Please do not hesitate to reach out and create a new issue if you have any feedback or questions. Thanks.


Fully remove remnants of components/automate-chef-io

The automate.chef.io microsite has been fully decommissioned and all
documentation is now delivered via doc.chef.io!
Signed-off-by: Seth Chisamore<EMAIL_ADDRESS>

@schisamo I'll fix the docs problem this afternoon


include buildTemplate in createDeltaPkg instead of retrieveAsTemplate / CSCLSROZ-555

the current approach does not actually use the files committed to git but retrieves again from the server -that might break things given that DEV might have already changed by the time this runs.
therefore, buildTemplate must be added which does what retrieveAsTemplate does, only completely local, without a retrieve

was duplicated by #19 - closed the other one to work in this one


Dependency break detection for ranges

For those who like to keep semver ranges in their package.json (as opposed to pinning versions), is there a need to still test new versions for breaking? e.g. if dependency a is configured for semver ^1.0.0 and a new version 1.3.0 comes out that still satisfies this range, should we:

Create a branch to test it?
Warn (e.g. via PR or issue?) that the range is currently "broken"?

And in such a case, what's the preferred solution, assuming that it's dependency's a fault? e.g. pin to the last known working version such as 1.2.2 ? Or 1.1 || 1.2 etc?
I had thought for a second that using lock files might avoid this problem, but that would work only temporarily. If dependency b is subsequently updated then the existing lock file will be invalidated  and npm or yarn will attempt to install the latest of everything, including a version 1.3.0. Hence the breaking of a will prevent upgrading of all other dependencies until 1.3.0 is retracted or fixed.

@hbetts @destroyerofbuilds I think this is relevant to you. Another reason that semver ranges make me uneasy..

is there a need to still test new versions for breaking

Perhaps, or perhaps not.
What I do is run renovate in it's normal setup to upgrade major versions of my dependencies (since those are the only upgrades given that I use range versions in package.json).
I then run a weekly job using the maintenance feature to upgrade the lock file for all my projects. (I don't want to update my yarn.lock file any more than once a week, as that ends up being a ton of commits on my repo that don't serve any value to downstream consumers).
For the maintenance case, renovate submits a merge request against my project, and my project's CI job kicks off. It either passes or fails.
If it fails, it could be because an upstream project submitted a breaking change as a minor or patch version. In that situation, I typically pull down the renovate branch and begin isolating the failure.
It's a little bit time consuming, but it works.
Now, renovate could create branches on my repository, running yarn upgrade [PACKAGE], to test individual packages for compatibility, and then file an issue if the upgrade fails CI.
The downside of doing that is the noise. Someone submits a bad change, realizes it within a short period of time, and submits a fix. In that time, renovate may be filing issues against dozens, or even hundreds, of projects.

pin to the last known working version such as 1.2.2 ? Or 1.1 || 1.2 etc?

So acting on the CI failure by submitting a pull request that pins the direct dependency in package.json is a compelling benefit from the feature you're suggesting. That would be a direct benefit to my down stream consumers. It would also save me from dealing with issues filed against my repository that might be caused by the broken upstream dependency.
Just a side note here, my hope would be that renovate could re-test the dependency when it releases a new version, and submit a pull request that brings back the version range (though with a minimum version now matching the release that fixed the build).

npm or yarn will attempt to install the latest of everything

That's definitely an ergonomic issue with both npm and yarn.
Could renovate run yarn upgrade [PACKAGE] for every direct dependency marked as outdated by yarn outdated? For each upgraded dependency, push to a branch and wait for CI to pass or fail. If it fails, skip that dependency as part of the lockfile update, and file a pull request to pin it to a working version?


Enforce AISP consent ExpirationDateTime limit

Only affects Test Facility, not live systems
ExpirationDateTime	 - Specified date and time the permissions will expire. If this is not populated, the permissions will be open ended.
In AISP resource access we should be checking that access has not expired, if it has a suitable error should be raised.
When the consent is submitted, we should be validating that the value is in the future.

Hey team! Please add your planning poker estimate with Zenhub @dbadham-fr @jorgesanchezperez


Fix: missing link in readme

Added link for elemental.html in the readme file because it was missing

Oh wow can't believe that's missing~


Remove redundant 'if' statement

Codecov Report

Merging #82 (8b1619c) into master (bcb8fdf) will decrease coverage by 0.15%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master      #82      +/-   ##
============================================
- Coverage     61.48%   61.33%   -0.16%
+ Complexity      194      193       -1
============================================
  Files            11       11
  Lines           914      913       -1
  Branches        140      139       -1
============================================
- Hits            562      560       -2
- Misses          302      303       +1
  Partials         50       50

Impacted Files
Coverage Δ
Complexity Δ

...bs/ci/sauceconnect/AbstractSauceTunnelManager.java
58.51% <100.00%> (-0.62%)
26.00 <0.00> (-1.00)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bcb8fdf...8b1619c. Read the comment docs.


error -> verbose on bootstrap

Change level of "No bootstrap found" message.

Coverage remained the same at 100.0% when pulling 6fab7b41f04414c4730fbd0ff4cd6c8d9d6673d2 on bootstrap-warn into fff47c48729996f1c67143fc5c6506645dcd8ef5 on master.

I think it should be info level at very least, potentially warn.

@larrychevres @cruzanmo and I were discussing it and i think we wanna leave this as is for now because it relates to a wider conversation clay & bootstraps. closing.


Invalid data directory

I am trying to run your repository and getting the following issue:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/nlpnet/taggers.py", line 307, in __init__
    super(DependencyParser, self).__init__(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/nlpnet/taggers.py", line 190, in __init__
    self.paths = config.get_config_paths(data_dir)
  File "/usr/local/lib/python2.7/dist-packages/nlpnet/config.py", line 14, in get_config_paths
    assert os.path.isdir(directory), 'Invalid data directory'
AssertionError: Invalid data directory

Please help me soon. I am in a bit urgency.

You closed the issue... did you find the solution?
You are probably supplying an invalid data directory when calling the model.

Yes, I got it...
Actually, I was a bit confused with the dependency folder. But later on when I read your READ.ME file then I came to know where I need to get it.
But anyways, thank you for your consideration. I am glad that you replied.


gather-hosts.yml and remote_tmp

Hi,
I'm using last version of plugin but this problem was noticed by far before.
The problem is that plugin does not works if I use $HOME variable in remote_tmp ($HOME/.ansible/tmp default). But if I change it to /tmp/.ansible  it works.
My environment:

Rundeck <IP_ADDRESS>
Ansible <IP_ADDRESS>-1ppa~trusty
rundeck-ansible-plugig: 1.3.2
rundeck user: rundeck
remote_user (anislbe): ansibleuser
$HOME for rundeck: /var/lib/rundeck
$HOME for ansibleuser: /home/ansibleuser
OS: Ubuntu 14.04

Debug Log:
extraArgs: -e facts=False -e tmpdir='/tmp/rundeck/ansible-hosts8808344132209913859'
tokenized: [-e, facts=False, -e, tmpdir=/tmp/rundeck/ansible-hosts8808344132209913859]
Using /etc/ansible/ansible.cfg as config file
Loaded callback skippy of type stdout, v2.0

PLAYBOOK: gather-hosts.yml *****************************************************
1 plays in gather-hosts.yml

PLAY [all] *********************************************************************

TASK [file] ********************************************************************
.... other hosts ...
task path: /tmp/rundeck/ansible-hosts8808344132209913859/gather-hosts.yml:7
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: rundeck
<localhost> EXEC /bin/sh -c 'LANG=C LC_ALL=C LC_MESSAGES=C /usr/bin/python && sleep 0'
changed: [example.com -> localhost] => {"changed": true, "diff": {"after": {"path": "/tmp/rundeck/ansible-hosts8808344132209913859/data", "state": "directory"}, "before": {"path": "/tmp/rundeck/ansible-hosts8808344132209913859/data", "state": "absent"}}, "gid": 999, "group": "jetty", "invocation": {"module_args": {"backup": null, "content": null, "delimiter": null, "diff_peek": null, "directory_mode": null, "follow": false, "force": false, "group": null, "mode": null, "original_basename": null, "owner": null, "path": "/tmp/rundeck/ansible-hosts8808344132209913859/data", "recurse": false, "regexp": null, "remote_src": null, "selevel": null, "serole": null, "setype": null, "seuser": null, "src": null, "state": "directory", "validate": null}, "module_name": "file"}, "mode": "0775", "owner": "rundeck", "path": "/tmp/rundeck/ansible-hosts8808344132209913859/data", "size": 4096, "state": "directory", "uid": 110}

TASK [template] ****************************************************************
task path: /tmp/rundeck/ansible-hosts8808344132209913859/gather-hosts.yml:9
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: rundeck
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo $HOME/.ansible/tmp/ansible-tmp-1471953777.28-110721411700143 `" && echo ansible-tmp-1471953777.28-110721411700143="` echo $HOME/.ansible/tmp/ansible-tmp-1471953777.28-110721411700143 `" ) && sleep 0'
fatal: [example.com]: UNREACHABLE! => {"changed": false, "msg": "Authentication or permission failure. In some cases, you may have been able to authenticate and did not have permissions on the remote directory. Consider changing the remote temp path in ansible.cfg to a path rooted in \"/tmp\". Failed command was: ( umask 77 && mkdir -p \"` echo $HOME/.ansible/tmp/ansible-tmp-1471953777.26-210807423950274 `\" && echo ansible-tmp-1471953777.26-210807423950274=\"` echo $HOME/.ansible/tmp/ansible-tmp-1471953777.26-210807423950274 `\" ), exited with result 1", "unreachable": true}

PLAY RECAP *********************************************************************
example.com   : ok=0    changed=0    unreachable=1    failed=0

If I try to run gather-hosts.yml from cli it works.
rundeck@ansible:/tmp/rundeck/ansible-hosts8808344132209913859$  ansible-playbook gather-hosts.yml -e tmpdir=/tmp/rundeck/ansible-hosts8808344132209913859 -l -l example.com

PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
ok: [example.com]

TASK [file] ********************************************************************
ok: [example.com -> localhost]

TASK [template] ****************************************************************
changed: [example.com -> localhost]

PLAY RECAP *********************************************************************
example.com   : ok=3    changed=1    unreachable=0    failed=0

Ansible.cfg
[defaults]
vault_password_file = /etc/ansible/vaultpasswd
inventory      = /opt/ansible/inventory/
remote_tmp     = $HOME/.ansible/tmp
pattern        = *
forks          = 5
poll_interval  = 15
ask_sudo_pass = False
ask_pass      = False
transport      = smart
module_lang    = C
stdout_callback = skippy
gathering = smart
host_key_checking = False
allow_world_readable_tmpfiles = True
timeout = 10
remote_user = ansibleuser
private_key_file = /etc/ansible/ssh/ansible_user_rsa
ansible_managed = 'Comment Here'
display_skipped_hosts = False
system_warnings = True
deprecation_warnings = True
fact_caching = redis
fact_caching_timeout = 3600
retry_files_enabled = False
retry_files_save_path = ~/.ansible-retry
[privilege_escalation]
become_ask_pass=false
[paramiko_connection]
[ssh_connection]
pipelining = True
[accelerate]
accelerate_port = 5099
accelerate_timeout = 30
accelerate_connect_timeout = 5.0
accelerate_daemon_timeout = 30
[selinux]

And one intresting thing. I have $HOME folder inside /tmp/rundeck/ansible-hostXXXX
ls -la /tmp/rundeck/ansible-hosts8808344132209913859
total 96
drwx------  3 rundeck jetty    4096 Aug 23 15:02 $HOME
drwx------  4 rundeck jetty    4096 Aug 23 15:02 .
drwxr-xr-x 35 rundeck rundeck 77824 Aug 23 15:20 ..
drwxrwxr-x  2 rundeck jetty    4096 Aug 23 15:12 data
-rw-rw-r--  1 rundeck jetty     253 Aug 23 15:02 gather-hosts.yml
-rw-rw-r--  1 rundeck jetty      52 Aug 23 15:02 host-tpl.j2

Hi @qk4l ,
It is not rundeck role to expand the HOME variable, this should be handled by ansible itself. Personally I had never remote_tmp but I believe this is not related to rundeck or the ansible plugin. Can you try launching the command manually and let me know if it returns the same error ?
Thanks,

Can you try launching the command manually and let me know if it returns the same error ?

It works. Look at second code block in issue description.

Hi @qk4l ,
This looks weird, I tested this and it works fine for me, although I do have "remote_tmp     = $HOME/.ansible/tmp", only difference is I'm using ansible 1.9.6. can you please test with the last version of the plugin ? I will try to update my ansible and check is it still works for me with 2.1.1
Thanks,

@yassineazzouz Yesterday I checked what is wrong with $HOME and when I had redefined it in /etc/rundeck/profile problem gone.
May be it's lost because I use upstart but it should save $HOME.
Nevertheless it's not I a plugin bug. Thank you very much for your time and support.


Ellipses for truncated column text?

I don't know if this is an issue or not but I don't know where to ask questions, really. Is it possible to show ellipses on text that is truncated when it is larger than the column width?

That's easy. Use overflow property of Text() widget. E.g., ellipses in header:

and cell:

That's the result:

I have not yet come across TextOverflow. Thanks a lot. :D


[bug]: NodeJS 16 actions are deprecated forced to use Node 20

Config file of your workflow
N/A
Describe the bug
The following actions uses Node.js version which is deprecated and will be forced to run on node20<EMAIL_ADDRESS>For more info: https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/

Expected behavior
Use NodeJS 20.
Current behavior
Used NodeJS 16.
Logs of the workflow
No response
Aditional information
Related: #309
Self-service

[X] I'd be willing to address this documentation request myself.

Have you read the Contributing Guidelines?

[X] I have read the Contributing Guidelines.

Are you familiar with Contributor Covenant Code of Conduct?

[X] I have read the Contributor Covenant Code of Conduct.

Contact Details
No response

Not Stale

Close #363


Replace default error responses

The 500 error response returns an html page, it should be JSON. There's probably other default error pages that nginx may serve that should be converted as well.

This has been closed with f818bd49f24afd9b590dd2e90989e0e1c659e1f5


UnsafeBuffer may not take offset into account

When calling
public void wrap(final ByteBuffer buffer, final int offset, final int length)
and the ByteBuffer is not a heap buffer, the offset is ignored:
else
{
     byteArray = null;
     addressOffset = BufferUtil.address(buffer);
}

Offheap the addressOffset is the real address with null for the byteArray. On heap the addressOffset is the offset from the byteArray reference/pointer. Neither are ignored. They are used appropriately given context.

If you look at the this test you can see each case being exercised.
https://github.com/real-logic/Agrona/blob/master/src/test/java/org/agrona/concurrent/AtomicBufferTest.java

But if I wanted to share an off-heap ByteBuffer, wouldn't the data be overwritten?
'''
ByteBuffer bb = ByteBuffer.allocateDirect(1024);
UnsafeBuffer ub1 = new UnsafeBuffer(bb, 0, 512);
UnsafeBuffer ub2 = new UnsafeBuffer(bb, 512, 512);
'''

Yes I see now. Forgive me for misreading earlier. Bad jetlag day ;-)

Thanks for the good find.

The current released version to Maven Central does not suffer from this issue. It was introduced while trying to address the Jigsaw issues. Unless someone is building from snapshot then they should be fine.


Hooked into render Journal Entry to add dice symbol rendering to Journal Content

Arg found an issue with rendering this way... fixing.


Proving ownership of identity commitment

Is there a way for a user to proof that he owns a specific commitment?
For example if the group admin wants to remove a member upon his request without keeping a database of user->commitments?

ok thanks. that solution still requires keeping a user/address->commitment list.


Navigate between screens with Compose: Android Basics with Compose

Hello @SergioTellezSanchez,
Thanks for reaching out to us. Whatever you are concerned about, it is fixed now:


Auto play feature is not present

While using this app, and after completing one music, it didn't play the next one automatically and I had to press next.
It would be good if we add auto play feature which plays the next song after completing one song automatically like auto play feature on other apps.

Hey, thanks for the suggestion. Do you want to work on this issue? @abhinav2712

Still, the issue is not resolved. Try again.

Yes I will look into it.

Yes, it's been done by @heysujal . You can check that now. :)


[Discussion] API to associate binding state (pointers) with the JerryScript context

A while ago, JERRY_CONTEXT define and jerry_context_t had been added.
Before that change, all the fields in jerry_context_t were statics that were sprinkled throughout the JerryScript code base. This wasn't great for projects where multiple instances of JerryScript are needed, because statics are by definition "singleton".
Luckily, the addition of the JERRY_CONTEXT define made it easier to create multiple instances of JerryScript. Typically, to support multiple instances, one would provide a custom definition of JERRY_CONTEXT, for example to look up the current jerry_context_t in thread local storage.
However, often, binding code also needs to keep state regarding the native resources that it uses. In a multi-context scenario, each instance of JerryScript needs to have its own "instance" of this binding state as well. Therefore, using static variables cannot be used. Again, because static equals "singleton".
Using __thread or a platform-specific thread local storage (TLS) API could be used of course, but this would make the binding code less portable / re-usable.
Therefore, I think it make sense to try to come up with an API to associate binding state with a JerryScript context in an easy way that promotes re-use and portability of the binding code.
Some design goals that I have in mind for this an API to associate binding state with a JerryScript context:

enable multiple bindings to each associate their own state with a JerryScript context.
making binding code "portable" / re-usable: avoid __thread or a platform specific TLS API.
should not require having to change JerryScript code (incl. jcontext.[h|c]).
"scales down": no bloat when using a single-context (same speed/RAM/code size as today).
easy to use from a developer point of view (probably not as easy as static, but hopefully close?)

I imagining something like a void *user_binding_state[] array in JERRY_CONTEXT, plus a couple of jerry_... functions to register/allocate/get/free the state for a particular binding. But I'm not quite sure how such a solution would "scale down".
Thoughts?

cc @jiangzidong @zherczeg ideas?

What about adding two functions: one for setting a global user pointer and another to getting this pointer?

What about adding two functions: one for setting a global user pointer and another to getting this pointer?

That would mean you'd have to put all the pieces of state from various bindings into one big struct: not great for keeping the various bindings modular.
Or have some custom mechanism on top of the single user pointer to "mux" it into one pointer per binding module: also not great, because everyone would implement their own mechanism for this over and over and bindings would not be easily reusable across projects (unless we magically all implement the exact same thing).
I added a "design goal" to the list: enable multiple bindings to each associate their own state with a JerryScript context.

About "scale down":
IMO, we don't need the perfect "scale down"
It's ok to add a pointer member in the  jerry_context_t, and the pointer points to a struct/array which contains binding states. Then the memory for each jerry context increases sizeof(void *), which should be acceptable.

@martijnthe

because everyone would implement their own mechanism for this over and over and bindings would not be easily reusable across projects

It's hard to implement a general binding state struct/array so that we can reuse other binding codes directly, because binding scenarios are various.
@zherczeg 's method, binding-writer should define what's the pointer points to. A struct or array, totally up to the binding-writer.
@martijnthe 's array method, binding-write should also define the length of the array, and meanings of index.

As for me I would offer such things as an option. From JerryScript core side it would only be a pointer, but there would be utilities which offer more, and people could select what fits their use case. I described this concept in #1716.

You have to also consider that there may be multiple mutually exclusive uses for adding a pointer to the context. For example, V8's isolate has SetData() and the corresponding GetData(), but when we were implementing N-API we wanted to tack binding-specific data onto the Isolate using those APIs but we couldn't, because there are other native modules out there that also do that, making use of one of the four slots.

Fortunately, we're dealing with a JavaScript engine here, right? So, we could create an object that is not exposed to JavaScript and attach it to the context, and then various bindings could claim various property keys on the object and attach their data as the value.
So, like
#define MY_BINDING_DATA_KEY "my_binding_data_key"
...
my_binding_data *my_data = get_my_binding_data();
jerry_value_t context_object = jerry_get_context_object(context);
jerry_value_t my_property_value = jerry_create_object();
jerry_set_object_native_handle(my_property_value, (uintptr_t)my_data, free_my_binding_data);
jerry_value_t prop_name = jerry_create_string_from_utf8(MY_BINDING_DATA_KEY);
jerry_set_property(context_object, prop_name, my_property_value);
...

Basically, I wish to caution that a single pointer is insufficient because there may be multiple independent reasons for attaching data to a context. Thus, we should be exploiting the fact that JavaScript objects are string-keyed hashes.
The example above could be made more efficient with a custom API, of course. After all, we do not need entire JS objects hanging from the one context object, but only native pointers. The important thing IMO is that the pointers are stored in a string-keyed hash, though.

For reference: https://github.com/nodejs/abi-stable-node/pull/206#discussion_r108553527

Basically, we ended up going with a per-module context, allocated when the module is first initialized, and then stored in the context for all native callbacks. This has the following downside: https://github.com/nodejs/node/pull/12246#pullrequestreview-31446438

Another nice benefit of implementing the JS external-data-plus-deleter approach is that, when a context is discarded, the deleters associated with the data will also be called, and so the bindings will be informed that a certain context has been discarded. This is also missing in V8.

Hm, what about reversing the question? Instead allowing setting pointers in JerryScript context, we could retrieve the starting address of the context, which should be unique. This could be a key to access various local properties.

So have a context-keyed hash stored statically and globally in the binding, right? That's also possible, of course, as long as there is one well-known, well-documented key that can be used. Currently it sounds like the jerry_context_t* is that key.

Then the binding won't know that a context has been discarded though and so it won't know that it can delete a key from the hash. There should be a callback to inform about that.

Also it might be real nice if bindings didn't have to implement their own hash table, because five different bindings will implement it five different ways.

It just ends up being boilerplate.

Yes. I do think the global context must be unique for each JerryScript instances, regardless where it is stored. Otherwise they would mess up the global state of others.
The other thing which could be acceptable is having a chain list of pages, where the head is stored in JerryScript, and each page must start with a next and key pointer pair. The key pointer should point to a static const data, where this data could start with a pointer to a free function. This free function could be called when a JerryScript instance is destroyed. The downside is that each data binding must do a linear search to find their corresponding page, which could be costly if too many of them.
The problem is no matter what we offer, there will be downsides, and there will be people who will don't like those downsides. That is why I prefer a system, where people can choose their appropriate solution, rather then forcing one onto them.

If that's the case, you're basically asking various independent projects to agree on a way to attach arbitrary data to a context, and implement a library that does that. You will then make room in the context by giving them a void* so they can actually use that library.

It will likely working this way. Probably there will be 2-3 major libraries which projects can use. They will offer different advantages and their perf/memory cost will be different. Probably there will be a very high level library, which offers generic interfaces at high perf/memory costs, and another utility based library which just offers useful utility functions. The primary aim for JerryScript is that it must work well on a system with 64K RAM and 100MHz 32 bit CPU. That does not offer much space to generic hash tables, especially if the memory is highly fragmented.

However, when you have 512K or more memory and the CPU is 600MHz, the story is different.

Probably shared interfaces could help this. Think about malloc. We have several malloc implementations, TCmalloc, JEmalloc, libc malloc, etc, and you can select the best according to your needs. E.g. TCmalloc is faster but use more memory than other, etc. However, they still offer the same malloc/free/realloc interface. Probably what we should do is standardizing certain interfaces, but their implementation could be replaceable. The recommended interfaces could go into a common interface library.

What about if instead of a void* a context as made available to the public would be a jerry_value_t that was created with global_context.public_context = jerry_value_acquire(jerry_create_object())? That would be a very easy common interface, and the entire JerryScript API that deals with associating external data can be made available.
Is that really so heavy?
In fact, internally, jerry_init() could perform
jerry_set_object_native_handle(global_context.public_context,
  (uintptr_t)&global_context, NULL);

and you could document that if a caller ever did that with the context object the behaviour would be undefined (because they would overwrite internal JerryScript state).

Wait a sec, I just realized you need a context to do jerry_get_object_native_handle() later on. Ha! Ha!
Anyway, instead of a void*, you could still provide a jerry_acquire_value(jerry_create_object())-based jerry_value_t instead.

There won't be that many contexts lying around, right? Just, like, one per thread, so it's not like you're creating thousands of new objects here.

Re. @gabrielschulhof 's idea of using a JS object that is non-reachable from the JS code itself: that would add quite a bit of overhead in terms of runtime speed to access the state.
How about something like:

// jerryscript.h

// Module read-only data.
typedef struct
{
    size_t state_size_bytes;
    void (*init_cb)(void *module_state);
    void (*deinit_cb)(void *module_state);
} jerry_module_t;

// Module index. Assigned at run-time.
// This is not part of jerry_module_t, so that jerry_module_t can be read-only.
typedef int jerry_module_idx_t;

// Registers a module and returns the assigned module index.
// Should only be called once upon booting the system.
jerry_module_idx_t jerry_module_register(const jerry_module_t *module);

// Getter that a module can call to get its state (after being instantiated).
void *jerry_module_get_state(int jerry_module_idx_t);

// Macro Sugar:
#define JERRY_NATIVE_MODULE_DECLARE(name, state_size_bytes, init_cb, deinit_cb) \
static jerry_module_idx_t _jerry_module_id__##name; \
static const _jerry_module_##name = { \
	state_size_bytes, \
	init_cb, \
	deinit_cb, \
}; \
__attribute__((constructor)) \
static void _jerry_module_auto_register__##name (void) \
{ g_jerry_module_id__##name = jerry_module_register(&_jerry_module_##name ); }

#define JERRY_NATIVE_MODULE_GET_STATE(name) jerry_module_get_state(_jerry_module_id__##name)

// my_binding_a.c

typedef struct {
    	int my_binding_x;
    	char my_binding_yz;
} my_binding_state_t;

static void my_init(void *module_state) {
	my_binding_state_t *my_state = module_state;
	// init all the things:
	my_state->my_binding_x = 1;
	my_state->my_binding_yz = 'I';
	// ... any other things it needs to do, open files, start jet engines, etc.
}

static void my_deinit(void *module_state) {
	// clean up here: close files, stop the engines, ...

	// Do NOT free(module_state), will already be taken care of after this function returns.
}

JERRY_NATIVE_MODULE_DECLARE(my_binding, sizeof(my_binding_state_t), my_init, my_deinit);

// jcontext.h
typedef struct
{
    // ... all the existing stuff here ...
    void **module_state_map;
} jerry_context_t;

// config.h
#define CONFIG_MAX_MODULES (8)

// jerry-module.c
static jerry_module_idx_t g_jerry_module_next_index;
static jerry_module_t g_jerry_module_map[CONFIG_MAX_MODULES];

jerry_module_idx_t jerry_module_register(const jerry_module_t *module) {
	g_jerry_module_map[g_jerry_module_next_index] = module;
	return g_jerry_module_next_index++;
}

// Called right after jerry_init()
void jerry_module_init(void) {
	const int num_modules = g_jerry_module_next_index;
	JERRY_CONTEXT(module_state_map) = jerry_port_alloc(num_modules * sizeof(void *));
	JERRY_ASSERT(JERRY_CONTEXT(module_state_map));
	for (int i = 0; i < num_modules; ++i) {
		void *module_state = jerry_port_alloc(g_jerry_module_map[i].state_size_bytes);
		JERRY_CONTEXT(module_state_map)[i] = module_state;
		g_jerry_module_map[i].init_cb(module_state);
	}
}

// Called just before jerry_deinit()
void jerry_module_deinit(void) {
	// Basically similar to jerry_module_init()
	// but then to call deinit_cb() and after that free all the things.
}

I don't mind creating a local object. It could be created at the first time when its value is requested. I have a question though: the object properties are accessed by strings, what will guarantee that different modules use different strings? The address of a static variable is more unique.

// config.h
#define CONFIG_MAX_MODULES (8)

The whole point so far was that we don't know the number of modules at compile time. What happens if a module is loaded/unloaded? Unused modules should not be loaded, that consumes a lot of memory.

What happens if a module is loaded/unloaded? Unused modules should not be loaded, that consumes a lot of memory.

OK, well you could have something like:
void jerry_module_init(jerry_module_idx_t *idxs, size_t num_idxs) {
  // .. only create state for indices that were passed in.
}

The whole point so far was that we don't know the number of modules at compile time.

I think as a project developer you do know the maximum possible number at compile time. I'm not considering loading dynamic libs or anything like that, I think that's probably out of scope ;)
However, a module developer does not know what other modules will be included (both compile+run time) by the project developer.

Name clashes with strings are easy to resolve. See DNS or npm. It's your project name. Or you can use uuidgen :)

I'm not considering loading dynamic libs or anything like that, I think that's probably out of scope ;)

Why? In iot.js only those modules are loaded which are actually used to save memory.

Also, the project developer chooses which modules to bundle so I don't think they're likely to bundle two modules woth an identical name.

@zherczeg absolutely. In https://github.com/gabrielschulhof/zephyr.js/compare/a6c321ab78e16aee8f2519897a97b219111e530c...8192da97418e8558547696b2d14587eb3c8ffd2e#diff-4ade889d164d7d33d2d1f7e7a38b68dfR490 I do exactly that. The module has an attribute((constructor)) which calls napi_module_register() and passes it a global static structure with the module definition. This is context-independent, and jerry_value_ts only start getting created when you require() the module at https://github.com/gabrielschulhof/zephyr.js/compare/a6c321ab78e16aee8f2519897a97b219111e530c...8192da97418e8558547696b2d14587eb3c8ffd2e#diff-4ade889d164d7d33d2d1f7e7a38b68dfR541

Keeping track of modules compiled in or even dlopen()ed in can be done in place if the modules have global static structures.

Ha! I just realized my require() isn't context-aware :) Yaaay!

But basically in that second link is where I would need the jerry_set_property() on the context object, which would accompany the module name in the formal params.

I'm not considering loading dynamic libs or anything like that, I think that's probably out of scope ;)

Why? In iot.js only those modules are loaded which are actually used to save memory.

You're talking about that a require('xyz') call will instantiate the state for native module 'xyz' (which is already compiled-in)? I think that is compatible with what I just sketched and can be added (later?) on top of that:
jerry_value_t require_impl(...) {
   // check + transform args here..
   const char *request = ...;
   jerry_module_idx_t module_id_to_init;
   jerry_value_t (*module_getter)(void);
   if (0 == strcmp('xyz', request)) {
      jerry_module_idx_t id = my_xyz_module_get_idx();
      module_getter = my_xyz_module_get_module_object;
   } else if (...) {
     ...
   }
   if (! jerry_module_get_state(module_id_to_init)) {
     jerry_module_init(&module_id_to_init, 1);
   }
   // ..
   jerry_value_t module = module_getter();
   return module;
}

Re. using indices vs names vs 'symbolic' memory address as identifiers:
I think performance is important, so in my mind, going through a JS object is not a good option.
An index in an array is probably the fastest, but has its limitations... Using a memory address of something in the binding code that uniquely identifies it (@zherczeg suggested it I think) and keeping a map based on that is also a good idea I think.

I'm just glancing cursorily, but in the above snippet I still don't see a context. require_impl() needs to at least take a jerry_context_t* the_context and set a value on it based on a key it retrieves from the list of modules which it has assembled whenever a module registered itself via its __attribute__((constructor)) function. The address of the global static module definition structure can serve as the unique key that identifies the module.
So, at some point, require_impl() needs to be able to do
jerry_context_set(the_context, some_global_static_pointer_such_as_my_module_definition, my_binding_data);

I think we're on the same page, but I just wanna make sure.

require_impl() needs to at least take a jerry_context_t* the_context and set a value on it

@gabrielschulhof re. "set a value" (the binding's state): happens in jerry_module_init(), see my earlier sketch (https://github.com/jerryscript-project/jerryscript/issues/1717#issuecomment-292480279).
I guess I didn't show using the state. I'll edit the earlier sketch to show this as well.

Oh, right ... I see.

The address of the global static module definition structure can serve as the unique key that identifies the module.

Yes, but... After thinking about it a bit longer: I think it's worthwhile assigning an index for each module (at boot, "registration time"). That would make the look-up of the binding's state fast and simple vs. having to look up by address (need a data structure more complicated than a simple array to make that possible).
I think it makes sense to optimize for fast look-up because that is what is likely to happen a lot.
If we don't like...
// config.h
#define CONFIG_MAX_MODULES (8)

... we could also make that array dynamic and realloc when needed, but I suspect most project developers will know at compile time what the max number of modules is.

Yeah, in Zephyr.js, before going with the linked list I also thought about making an array of these module definitions. In JerryScript a run-time fixed-size, compile-time configurable array totally makes sense.

Then, I guess each context will have an array where the indices are the same as what the modules receive at startup and the values are the module state.

I don't really see a theoretical difference between a compile time defined array and a single pointer. Both has the same limitations.
Based on this conversion, my proposal is the following:
JerryScript side (pseudo code only, the names should be better of course)
/* Returns a unique pointer */
void * jerry_get_instance (void);
/* Gets/sets a global pointer in the JerryScript context. */
void *jerry_get_context_pointer (void);
void jerry_set_context_pointer (void *context_p);
/* Registers a function which is called when the context is about to be destroyed. */
void jerry_set_on_destroy (jerry_on_destroy_callback_t on_destroy_callback);

In the JerryScript utility library, there would be an interface:
/* When this interface is used, it controls the context pointer of JerryScript. */

/* Registers a module. Context destroy callback is called when the JerryScript context is destroyed.
   Initial value for the own pointer of the module is also set. Returns 0 on error. */
size_t jerry_module_register (jerry_on_destroy_callback_t on_destroy_callback, void *module_p);
/* Unregisters a module. */
void jerry_module_unregister (size_t);
/* Get/set the module pointer. */
void * jerry_module_get_pointer (size_t module_id, void *module_p);
void jerry_module_set_pointer (size_t module_id, void *module_p);

All modules must use this interface. There could be several implementations: fixed array, chain list, hashmap, and the developer chooses the appropriate one depending on the use case. However the modules must not depend on any implementation, only the interface.

@zherczeg I agree with you except for 2 minor questions. Just to make sure.

jerry_get_instance means return the address of current jerry_context_t right?

About the two types of interface (jerry side and utility side), I think only utilities can use the jerry-side interface (like jerry_get_context_pointer ), and bindings/modules can only use the utility-side inferface (like jerry_module_register ), right?

I just realized that a module cannot store the module id, since it needs a storage. Hence we need a unique pointer (id). Also it would be a good idea to specify the size of the module specific area, since the manager could allocate a single area for a header and a module specific space (useful for a chain list or hashmap based implementation). The modified interface:
// id - it must be a unique pointer, an address of a const data, or a callback
//  function address, a constant string address, whatever
// on_destroy_callback is called when the JerryScript instance is destroyed
// area size - size of the module specific area. If a module needs a re-allocatable
// space, it should be sizeof (void*), and the module just store a pointer there
// returns the same value as jerry_module_get_pointer, or NULL if failed
void * jerry_module_register (void *id_p, jerry_on_destroy_callback_t on_destroy_callback, size_t area_size);
// unregisters a module
void jerry_module_unregister (void *id_p);
// gets the module specific space starting address
void * jerry_module_get_pointer (void *id_p);

@jiangzidong:

Not necessarily. Only one thing is sure: it is a unique pointer for each jerryscript instance. At first we will return with the address of jerry_context_t, but it could be changed in the future. Modifying this area is not allowed.

Yes, it is a dependency. If somebody uses a standard module manager utility (what a name:) ), it will exclusively control this pointer. However if somebody wants to have an own module manager system, or their system has only a single module, they can directly control this pointer. Standard modules should use standard module managers, that can be a dependency as well.

I think "standard module" could be defined somewhere, and each standard module must follow these guidelines (this is independent from JerryScript). Non-standard modules can do whatever they want, and the system developers must handle them.

Another idea: id could be a static string, and it should be the name of the module, so the name of the active modules could be printed. This is just an idea, we could drop it if you don't like it.
Also jerry_get_instance retuns a unique id for the active JerryScript instances. If an instance is deleted, its instance id can be reused later by a new JerryScript instance.

@zherczeg Questions about your proposal:

jerry_module_register(): would it be called once per boot or every time when initing JerryScript (after jerry_init())?

I like your idea of having a "standard" interface that supports multiple implementations that have different design goals.
Suggestion: I'd rather roll up jerry_on_destroy_callback_t on_destroy_callback and size_t area_size into a typedef'd struct. The pointer to that struct can can be used instead of the void *id. So:
// Module read-only data.
typedef struct
{
    size_t area_size_bytes;
    void (*on_destroy_cb)(void *module_state_p);
    char *name; // if we want to add this we can do so w/o breaking the `jerry_module_register` interface.
} jerry_module_t;

void * jerry_module_register(const jerry_module_t *module_p);

It is up to you. I think you have more experience with modules, and for me this is kind of outside the scope of jerryscript core, so I am open to all ideas. I also like your struct based register idea.
The only thing I don't want is adding too much module specific stuff to JerryScript core, which is a JS engine not a NodeJS like system.
I don't mind if we create a new top level directory in jerryscript, e.g. jerry-utilites, and add a module directory there (jerry-utilities/module), where the documentation and source code of standard modules could be placed. I also don't mind adding compilation support to these utilities to the core build system.

After having spoken with @martijnthe we believe we have identified the minimum necessary support from core:
typedef void *(*jerry_user_context_init_cb)(void);
typedef void (*jerry_user_context_deinit_cb)(void *context);

typedef struct {
...// existing stuff
  void *user_context;
  jerry_user_context_deinit_cb deinit_cb;
} jerry_context_t;

// init_cb is called before jerry_init_with_user_context() returns (so no need to save in jerry_context_t)
void jerry_init_with_user_context (jerry_init_flag_t flags,
					  jerry_user_context_init_cb init_cb,
				  jerry_user_context_deinit_cb deinit_cb);

void *jerry_get_user_context(void);

This allows each context to be initialized with a custom "user context", which is allocated and stored during context initialization. It cannot be re-initialized during the lifetime of the context, and it will be deallocated using the provided deleter upon context disposal. The original jerry_init() then becomes
void jerry_init(jerry_init_flag_t flags) {
  jerry_init_with_user_context(flags, NULL, NULL);
}

I will make a separate PR to this effect, affecting only core. I will then render the module utility PR as a second modification that requires this change (and that will likely use #1725 for testing).

Note that by design, we did not provide a "setter", but instead an init_cb, to enforce that the context is only set once.

Exactly, and we want the init_cb and the deinit_cb to appear next to each other to emphasize that there is one void * manager for each context, established when the context is instantiated.

I like this proposal! +1 from me

LGTM


Migration to .net core 3.0.0-preview9

Migration to .net core 3.0.0-preview9
GET /informations: Add system version(such as Debian 9, Windows 10) and runtime version(3.0.0-preview9) to the response body

#33


Add types for color-rgba and color-space/*

Types for color-rgba are available on npm, color-space is not, so I add custom type declarations for the functions used.

@MoonE Thanks for your effort! I think more users could benefit from the color-space types if you submitted them to Definitely Typed instead of adding them here.

Yeah, I thought about that.
There are huge amount of functions, do you feel like they'd accept type declaration for just a few functions? I didn't want to create types for all.

@MoonE, yes I think they'll accept a pull request with only a subset of the signatures typed. Better than nothing!

I made a pull request in https://github.com/colorjs/color-space/pull/57

Thanks, @MoonE !


Thinking Packets Instead of Messages

Hello again friend!
After a few years I have returned again to your wonderful suite of TCP libraries.  This time more armed with knowledge than before!
So I have read numerous articles off-and-on about the performance-woes of TCP... and about how UDP comes with its own connectivity/firewall woes.
I found an book article proposing parallel TCP connections where each connection has only one single in-flight message at any given moment.  The mechanism increases overall connection reliability and consistent improved latency. It can even be used with websockets, which is slick.
Here it is:
http://ithare.com/almost-zero-additional-latency-udp-over-tcp/
Building upon that, when a person begins to scrutinize all of the metrics for deliverability, the issue of max MTU sizing also comes up.  If you send a TCP packet that exceeds an MTU size, it can cause problems.  So what you end up wanting in a perfect world (where latency and reliability is prized foremost) is:

Application takes responsibility for framing its data into small enough messages that one message can be sent in one packet and is guaranteed not to be auto-fragmented in-flight by a network device.

Application can then guarantee when it performs a network send, the data is received all-or-nothing with maximum deliverability, and the application can continue to send other packets on parallel connections if it chooses to do so.

So I went back to looking at off-the-shelf TCP tooling and it looks like Caveman gets the closest to allowing some kind of implementation like this without having to go to bare .NET BCL tooling.
I wonder what are your thoughts on an implementation that accomplishes the objectives above?

Hi @pha3z you've definitely been doing your homework :)

In a general library, you really can't constrain the max message size to ensure it fits within a single MTU (plus framing)
It's really unfair to ask developers to implement their own framing and determine (at runtime) what the MTU is
TCP provides a (reasonable) mechanism for managing the give-and-take between buffer resources vs transmission

Earlier in my career I did a lot of work on application acceleration over wide area networks (https://a.co/d/hx9h0AD) where latency limits performance (protocol inefficiencies), TCP's inefficient give-and-take (sliding window and acknowledgements), and data redundancy hinder performance.  The technology is since irrelevant in a high-bandwidth, low-latency cloud-first world, but the core learnings were:

Application developers shouldn't have to worry about the transport; writing to TCP (or something that appears to be TCP to the application) yields the most portability and platform compatibility
TCP is inefficient in that memory resources (buffers) are dictated by acknowledgements (selective or full), and this is compounded by either a) packet loss of an acknowledgement or b) latency in the exchange of an acknowledgement
Other TCP implementations could yield material value (larger buffers, more aggressive buffer replenishment/less dependency on acknowledgements, multiple underlay parallel connections) but no developer wants to own the underlay transport implementation, so it has to be provided in a transparent manner (see https://en.wikipedia.org/wiki/BIC_TCP)

Personally I'm not investing (much) time at all into TCP because several 1) framing and 2) overlay transport platforms are available (such as websockets, AMQP, etc).  Websockets holds a ton of promise because of integrated framing and its ability to support HTTP/2 which uses parallel (semi-non-blocking) streams.
My personal best practices:

Avoid UDP at all costs (but in some apps, you simply can't, which is why I wrote the SimpleUdp library) due to lack of framing, firewall issues, and lack of segment delivery guarantees
Use something that already runs on top of TCP (websockets, AMQP, others) where possible, many people smarter than me building out these platforms
Use TCP (framed or raw) only where necessary

Looking over the link you sent:
Actually, the idea is dead simple:

We have N TCP connections between Client and Server

For each of these TCP connections – there is a “packet en route” flag. This flag is set to false after TCP connection is established.

On the sending side, whenever an UDP packet comes in – we’re sending it over one of the TCP connections which does not have the packet-en-route flag. Also, we set the packet-en-route flag for the TCP connection where we sent the packet.

Of course, we still need to wrap the packet to send it over TCP (to denote the packet size and/or boundary)

On the receiving side – whenever we get an incoming UDP-over-TCP packet – we send an app-level acknowledgement (as small as 1 byte) back to the sender, over the same TCP connection where we got the incoming message.

On the sending side, when we get this app-level acknowledgement – we reset the packet-en-route flag

This could be a nice proxy implementation, but 1) appears to still use TCP's inefficient congestion control and 2) even if the acknowledgement is tiny (1-byte), it still incurs latency.  Multiple connections don't really solve the overall throughput issue unless you address congestion control (memory/buffer vs acknowledgement pacing) - see BIC-TCP, CUBIC TCP, HTCP, HSTCP, et al.
I guess I'd ask - what are you looking to build?  And sorry for rambling...
Cheers, Joel

Wow, lots of thoughts Joel, thank you!
I'm not sure I wholely agree with your points.  You said "The technology is since irrelevant in a high-bandwidth, low-latency cloud-first world..."
Mobile networks have major latency and reliability problems.  Roaming in particular is especially bad.  If you want to make a Mobile game for folks to play in a moving vehicle, they're going to get hammered by temporary outages, packet loss, and even hung connections.
I want to make a game that relies on timely deliver of short text updates. It is critical that the UI is able to show the latest messages as soon as it can get them -- latency is a killer.  Furthermore, if any message is lost (does not reach the receiver), then this needs to be detected and resent (without head-of-line-blocking for the other messages) and when the receiver does get the message, the receiver should insert it in the proper visual order in a queue so that the user always sees messages in correct time placement -- even if they don't necessarily arrive when expected.
So its a situation where correct order is paramount but out-of-order should not inhibit timely delivery.
Honestly, I don't think my particular situation is so special.  I can imagine a lot of real-world scenarios where you want a live feed that is as always as immediate-as-possible, but you still want the UI to display late deliveries to be in sent order instead of received order.
TCP seems like an obstacle in trying to achieve such a requirement.  I also read that UDP is not a reliable choice if you want to serve a wide audience where some of your users are likely going to be on weird networks that won't even permit UDP, so UDP is out for me on this.
I was reading about how you need to consider switches like TCP_NODELAY on your socket to make sure nagle's algorithm doesn't buffer your data (because you have chosen to send a 1-byte message).  This is critical if your intent is to send data immediately.
I think the main gist of what you're saying is the part about "A library shouldn't put the burden on the developer for framing his data." Fair enough.  I suppose a scenario where the developer wants fine-grained control over messages because his intent is to sent lots of small, precisely crafted messages .. is a scenario in which a developer shouldn't be using a library!   I am reading the .NET documentation on TcpListener.AcceptSocket() and the methods for Sockets and to me it seems very straight forward and like exactly what I want.
But I want to point out, I don't think my design motivation is a small class of problem.  TCP is designed with the idea that the developer wants to think of his data as Streams or Arbitrary-Sized messages.  In reality, those conditions themselves are a particular subclass.
Something interesting to me is that IPv6 doesn't even support packet fragmentation.  Packets sent over IPv6 cannot exceed the End-2-End MTU size on any segment.  Therefore, the data must be fully pre-fragmented into completely self-contained packet by the sender before invoking send().  From my vantage point, it looks like what TCP stack is supposed to offer me is the promise that it will chop the data into packets and then guarantee their delivery for me.  That becomes problematic the moment I want some control over which packets are guaranteed and which ones aren't .... or which packets are guaranteed with order and which ones aren't.  I am still trying to dig into the socket options -- which seems to be where the goodies are at.

I have a very good question.
In terms of bandwidth usage:  is 1 packet = to 1 packet?
If I keep invoking socket.send() at some consistency pace, and I am always sending 1 byte of data, is that going to perform exactly the same as if I was sending 500 bytes of data per packet?

Hi @pha3z thanks for your thoughtful response.  For displaying in sent order, I'd consider including that metadata in the message/data itself, that way it can be sorted on the receiver's side.  Yes, you're right, mobile networks have much higher latency and more bandwidth constraints - I generally deal with server-side apps and heavier clients, which highlights the bias in my response :)
For your use case I'd definitely go with TCP.  UDP would force you to handle delivery guarantees within your own code.  TCP will guarantee in-order delivery of data to your app - that's the intent/purpose behind sequence and acknowledgement numbers.  An app's attempt to read 4KB from the socket won't be served until that 4KB of data - based on its sequence numbers - are actually received into the receive buffer.
Re: your second question - bandwidth usage is measured in bits per second.  A 1-byte payload is going to create less bandwidth usage than a 500-byte payload.  In TCP/UDP (or heck, even IP/Ethernet) load testing, the higher the payload size, the fewer packets/sec you typically see over a given link, assuming you have the hardware available to saturate it.  However, with higher payload size, even though it's fewer packets/sec you're going to see higher transmission rates.  It makes sense, because each transmission requires one (or more) acknowledgements (TCP ACK, SACK), each occurring a one-way latency cost.  With sufficient buffer memory, you may never encounter a situation where you can't "fill the pipe" because you have too many outstanding acknowledgements.
Going back to what you wrote:
I want to make a game that relies on timely deliver of short text updates. It is critical that the UI is able to show the latest messages as soon as it can get them -- latency is a killer. Furthermore, if any message is lost (does not reach the receiver), then this needs to be detected and resent (without head-of-line-blocking for the other messages) and when the receiver does get the message, the receiver should insert it in the proper visual order in a queue so that the user always sees messages in correct time placement -- even if they don't necessarily arrive when expected.

So its a situation where correct order is paramount but out-of-order should not inhibit timely delivery.

TCP should not allow your app to read 4KB (for example) of data if the next 4KB of data is not available.  The example I'm about to share is not how TCP works, but assume 1 message = 1 send to the socket = 1 read to the socket (just to make it easy).  If I send messages 1, 2, 3, ... 10, and message 4 is lost, my app will block until TCP retransmits 4 back to me.  If you have parallel connections, all bets are off, and you'd need some metadata (sent timestamp) in the message itself for sorting.

Thank you for your response!
You confirmed a lot of my understanding.  The information about how bandwidth vs. packets-per-second works is very enlightening.
So TCP is in-order always, which is what I thought.  It fits with the model of thinking about TCP as a "stream" of data.  It makes sense when that's what you want.
Let's suppose I had this case:
`I sent message 1, 2, 3, and 4.  But I want to send each of them exactly 50 milliseconds apart.
If I'm using Socket.NoDelay = TRUE, will each message go out when I send it??  Or is the sender going to wait for an ACK for every single packet?
This is the area I get really confused on.`
My desire is that I could send all four messages exactly 50 milliseconds apart and have all of them arrive as soon as possible -- out-of-order is fine.  There should be no blocking just because one is delayed or lost. I could include a timestamp within the messages so the application can sort them as they arrive. In order to achieve this, Parallel connections seems like the natural solution.

I think I found the answer to my question from the last post.
Here:
https://stackoverflow.com/a/1863157/1402498
The responder said:

The TCP layer will keep resending the packet until it receives a successful ACK.
Send will block until this happens - SendAsync will not block, and you can continue processing other stuff while the TCP layer handles sending the packet.

Ok... So I knew I was probing into a problem area.  And sure enough a 22-upvote question on SO talks about Delayed ACK issue.
https://stackoverflow.com/questions/22583941/what-is-the-workaround-for-tcp-delayed-acknowledgment

Hi @pha3z going back to your question:
I send messages 1, 2, 3, and 4. But I want to send each of them exactly 50 milliseconds apart.

If I'm using Socket.NoDelay = TRUE, will each message go out when I send it?? Or is the sender going to wait for an ACK for every single message before sending the next?

This is the area I get really confused on.

We're getting into one (very important) implementation detail we haven't discussed yet - memory.  When an app opens a socket, a certain amount of memory is allocated for both send and receive operations.  The send memory is for data that the app wishes to send, and the receive memory is for data taken from the network that is awaiting read by the application.
When an app sends data, it is added to the send memory pool (buffer), and sent across the wire.  That data is not removed from memory until the acknowledgement is received.
When data is received, it is added to the receive memory pool (buffer), and when an app reads it, an acknowledgement is sent (generally, this is not always the case, implementation specific), and the data is removed from the receive memory pool.
These memory pools provide two key capabilities: 1) they act as a temporary staging area (not durable) until either the data can be sent (send buffer) or can be read by the app (receive buffer).
The second function it serves is to inform congestion control on when the size of the memory pool, which impacts the TCP window size and other parameters, should be scaled up or down
So to your question: assuming the implementation feels it has levity to continue sending, it will, i.e. it will send 1, 2, 3, and 4 in succession.  NoDelay typically informs the underlay TCP implementation to not wait for more data before sending (you can read more about the PSH flag on this topic too).
But if the memory pool is exactly the same size as a single message, then your .Send() implementation will block until the last message was sent and acknowledged.
As much as I hate to say it, ... it depends ... :)

Hope you don't mind I'm moving this to a discussion btw


Make link absolute

same procedure as #142
blocking build of scs docs: https://github.com/SovereignCloudStack/docs/actions/runs/6937500730/job/18871670721

is no longer required after the move of the advanced guides


ref(*): deep copy from draft pack to current dir

draft create currently only copies top level files
This PR allows draft to copy directories and nested files
over to the current working directory as well

resolves #743

supercedes #551


Add shopping use case

@jobergum PTAL.
@ldalves FYI.
First iteration on this.

@kkraune FYI.

Agree with @kkraune on the script dependencies to move this into the docker container. The centos based image already comes with python2.7

Removed requirement for Python3 - the conversion script works on both 2 and 3 .

💯


Pause on exceptions/uncaught exceptions for Observatory

Observatory is missing the ability to pause on exceptions, both caught and uncaught. Right now if there's an exception Observatory pauses, but only because the isolate is exiting. The stack is already gone, so all you have is the traceback.
It should also have the same options as the debugger to pause on exceptions that are caught. A motivating case for this is debugging tests. If there's a test failure there will be an exception, but it will be caught by the test framework, so you need to be able to pause when it is thrown in order to debug.
Even better, be able to have some level of control over when it pauses for uncaught exceptions, to deal with programs which throw and catch lots of exceptions, where I'm interested in one in particular. Which I suppose if you generalize it, turns into conditional breakpoints.

392a83221ffd8405f671c9669a64bd950d6faf5e


Array.prototype.filter doesn't require callback to return

I dig a bit and found out in #5850 and subsequently in #7779 the signature of filter has been changed not to return a boolean, so that people could return a truthy value in the implementation of the filter.
While I undertand the convenience in terms of ease of use, this as far as I observed puts developers at risk of simple bugs like the following:
const even = [1,2,3].filter(x => {
    x % 2 == 0
})

Notice the missing return statement means the function returns undefined, which translates to false, which filters all the items out. This applies also in the case of noImplicitReturns set to true, since the function return type is any, thus it could be a void function for what the compiler knows.
I believe TypeScript's job should be to put this kind of cases in check actually, so that things like truthy values (which sometimes aren't as obvious as we might think and introduce bugs we don't really understand) can be better taken care of.
One solution to make both parties happy would be to optionally support truthy values (maybe an extra compiler flag? Another truthy type to allow for more relaxed checking?) and reintroduce the original signature of filter.

https://github.com/Microsoft/TypeScript/issues/5850#issuecomment-168878172

Although I'm a fan of strictness the loose signature is justified in this case, IMHO.
PS: I feel a little uneasy adding 👎 on the proposals as it's ambiguous whether it's a vote cast on AMF or not.

As I proposed in #20033:
Maybe a new type (BooleanLike? TruthyFalsy?) would do the trick? It would indicate that the value is meant to be a boolean, but would allow other truthy/falsy values based on the rules that @andy-ms described:

It would behave like any except it would force people to return a value (so really it behaves more like {} | null | undefined.
In --strictNullChecks we could also check that the value is actually potentially truthy/falsy, so string and Node | undefined would work but not just Node.

I'm not sure about this one though. Maybe we should still allow explicit boolean values, e.g. return true or return false.

A new type like TruthyFalsy would also help on the other side of things. For example, if I'm writing a function that accepts a callback:
function doStuff(callback: (arg: string) => TruthyFalsy): string[] {
    let arr: string[] = ["item 1", "item 2", "item 3"];
    let result: string[] = [];
    for (let item of arr) {
        if (callback(item) === true) { // Error: cannot compare type TruthyFalsy to type boolean
            result.push(item);
        }
    }
}

Basically, we don't allow people to compare TruthyFalsy types to any other type. We would only allow them to use TruthyFalsy values in a couple of ways

if (truthyFalyValue)
!truthyFalsyValue

At a minimum, we should use {} | null | undefined instead of any - this forces callbacks to return a value. But if we do that, we should modify similar callbacks (in some, every, filter, for example) to be the same - right now all of these callbacks have a boolean return type. We should be consistent.

A TruthyFalsy type would also allow us to catch bugs in if statements - we could add a compiler option for strictIfConditions or something, which requires the condition of an if statement to be a boolean or TruthyFalsy type. For example:
function isReady(): boolean {
    return false;
}

if (isReady) { // compile error: type '() => boolean' is not allowed in an 'if' condition. Only types 'boolean' or 'TruthyFalsy' are allowed.
}

The bug here, of course, is that we should have done if (isReady()) instead of if (isReady). But currently typescript will not catch that bug, and the code will execute as if isReady is always true.
Same for && and || operators - we could require both operands to be TruthyFalsy.
However, this could end up being overly restrictive. I often like to do if (x) to check if x is not undefined, which would be prohibited. I also like to do const y = x || "default"; (using || as sort of a null-coalescing operator), which would also be prohibited.
As a workaround, we could allow null or undefined types in addition to TruthyFalsy and boolean types. But this seems like a strange/unexpected exception to the rule. Alternatively, we could allow any type except function types, just to prevent this specific bug - then this becomes independent of the TruthyFalsy type.

I understood the TruthyFalsy type to be any type that has at least one truthy and one falsy value. A { foo: number } | null obviously matches. A boolean, string or number also do because they inherently have falsy values. However, neither { foo: 3 }, nor () => {}, nor "string-literal" would match because they are always truthy. Neither undefined, nor null, because they are always falsy. We then need an exception to make literal true or false match TruthyFalsy. This will ensure that we can have “always true” or “always false” filters as well as use constant values in conditions: const DEBUG = false; if (DEBUG) { ... }.
@aj-r, you say it could be overly restrictive. I don’t understand. What am I missing in your examples?

if (x) to check if x is not undefined, which would be prohibited.

If x is { foo: number } | undefined, then it would be allowed, that matches TruthyFalsy, it would not be prohibited. If x is always truthy or always undefined, then the condition is meaningless, and it’s great that it’s prohibited, no?

I also like to do const y = x || "default"; (using || as sort of a null-coalescing operator), which would also be prohibited.

Again, if x can be truthy and falsy, this would not be prohibited. If it’s always truthy or always falsy, the code above is a programmer error, so it’s good it’s prohibited.

@denis-sokolov That's an interesting idea that I hadn't considered - allow types to be implicitly cast to TruthyFalsy, as long as they could be either truthy or falsy. I like it. When I said that strictIfConditions would be overly restrictive, I was thinking that one would need to explicitly cast a value as TruthyFalsy in order to use it with if/||/&&. But your idea solves this problem quite nicely.
I still think we should still allow people to explicitly cast any value as TruthyFalsy using a type assertion (e.g. true as TruthyFalsy). Furthermore, a function that returns TruthyFalsy should accept any value as the return type, without requiring a type assertion. For example:
function callback(value: any, index: number): TruthyFalsy {
    if (typeof value === "string")
        return true; // Should be allowed
    if (typeof value === "object")
        return false; // Should be allowed
    return typeof value === "number" && value > 0;
}

It would be really cool to see this in a future version of TypeScript. My only concern is that this type has some special cases that other types don't have, so it might be a lot of work to implement.

I think it's really unfortunate that these library functions are defined by default to be sloppy instead of strict.
In one of the really old suggestions for making the change from strict to sloppy: https://github.com/microsoft/TypeScript/issues/5850 there was a suggestion to add your own override to make the function more sloppy by allowing any.
However it seems using the same trick to add a new more strict override doesn't really work because the sloppy override still exists in lib.d.ts.
The only solution I could come up with quickly was to add my own filter wrapper that basically just calls Array.filter under the hood. Is there any better solution to this problem?

Our team ran into this today with Array.find and I don't quite understand the reasoning to allow it to be loose.  There's probably a lot of incorrect code out there.
Some Array methods allow for using generics like Array.map, but others do not.  There's inconsistency.


missing Basic Information

The index page should display some information about the stored pictures and the amount by default. It would be nice to add a quick reference to search for available labels

Release v0.3.2 contains a basic overview of the api package and the available labels by default. Look at the Release tab and download the latest version.


chore(NODE-5822): sync CSOT spec tests and setup prose stubs

Description
What is changing?

Sync spec tests
Stub prose tests

Is there new documentation needed for these changes?
None
What is the motivation for this change?
Stubbing out the tests will remove a major portion of the diff as we're able to start enabling them
Double check the following

[x] Ran npm run check:lint script
[x] Self-review completed using the steps outlined here
[x] PR title follows the correct format: type(NODE-xxxx)[!]: description

Example: feat(NODE-1234)!: rewriting everything in coffeescript

[x] Changes are covered by tests
[x] New TODOs have a related JIRA ticket

All failing CI tests are flaky tests or data lake (which currently always fails)


use 'git mv' when renaming a file

(currently, when I rename with VS Code, git thinks the file was removed and a new one was added)

There's extensive discussion on why VS Code doesn't do this: https://github.com/Microsoft/vscode/issues?q=is%3Aissue+sort%3Aupdated-desc+label%3Agit+mv+rename+is%3Aclosed


Async fix

Issue mentioned in https://github.com/assafelovic/gpt-researcher/issues/684, and multiple other issues hidden behind it. Now, multi_agents flow can finish even with "follow_guidelines": true. Set that as the new default in example task.json, as I assume it was turned off because of this issue.

@assafelovic closed the one related issue (created by me) mentioned, I would say https://github.com/assafelovic/gpt-researcher/issues/548 is about a slightly different problem


[FEATURE] Adding a chatbot

Description
hey @apoorvaron ,
I want to create a chatbot for your github repo
pls assign this issue to me
also provide me some questions and their replies that i could dtore in the database
thank you

Ok ill do it by tomorrow

@rohanmittal1163 are you still working on this issue ??

Yess i am working it
Giving it to you today only

good luck @rohanmittal1163


[operator] Enable Audit Logs in Guest Clusters

Issue #, if available: 191
Description of changes:
This PR adds audit logging to guest clusters by default.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Still need to show the logs in CloudWatch - this is not ready.


Finalize exit fee logic for Osmosis v1

https://github.com/osmosis-labs/osmosis/blob/main/x/gamm/keeper/pool_service.go#L336
As described in the code comments, the current x/gamm module can set the exit fee, but there is no logic to process the exit fee. Since we're very close to launch, we need to finalize how to handle this.
I think there are three options:

Remove the exit fee entirely
Send the exit fee to the community pool
Send the exit fee to the fee pool and distribute it to delegators as rewards

If we assume there exists a pot with lockup time of < 1s for each pool, we can send the exit fee to that. I think this fee should be going to the existing pool LPs, not the chain as a whole

Is it not possible to just leave the fee amount in the pool?  Wouldn't that give it to the remaining LPs?

@ValarDragon Sounds good. It would be nice for the pool incentives module to be fixed and merged, then discuss how to implement it.
@sunnya97 Right now, the distribution can only handle pool assets. Because exit fee is not included as a pool asset, the current implementation doesn't support it.


Copy in files to docker volume

NOTE: This doesn't feel like a proposal, but rather a modification of an existing proposal. How should I have formatted this?
Most of the time that I want to create a new docker volume, it's to add configuration files to the volume before I start a container that uses it. Doing this with ansible is clunky right now. Here is an example that creates a volume "example_volume" and adds "example.j2" to it.
- name: Create a container with a new data volume
  docker:
    name: container
    image: centos:7
    detach: no
    volumes:
      - example_volume:/data
  become: yes

- name: Copy over the template
  template: src=example.j2 dest=/tmp/example
  become: yes

- name: Copy in the template
  command: docker cp /tmp/example container:/data/
  become: yes

- name: Remove the template
  file: path=/tmp/example state=absent
  become: yes

- name: Remove the hanging container
  docker:
    name: container
    image: centos:7
    state: absent
  become: yes

Is this behavior useful to others? Should it happen in docker_volume? Is it more of a "docker_copy" (and docker_template, docker_fetch)? Ex:
# Result is example.j2 has been templated and resides at /example on my_volume
- name: Copy in a template
  docker_template:
    src=example.j2
    dest=/example
    volume=my_volume
    image=centos:7

I think this is covered in proposal for docker_file.

Yes, looks like that is where the discussion belongs; the "open issue" referenced there is now closed. Where should I be submit the above feedback? (remote files instead of local files, template handling, fetch vs. copy)?

Also, just as reference, the docker connection plugin, would also allow support for using any of the various existing modules such as copy or template for copying into a container.

Okay so I still don't know where to submit feedback. The proposals do not meet my current business need, which is copying templates and files into remote docker containers. Please note that "docker_file" will not do what I am looking for.
Here is what I'm doing in my infrastructure:

Copy the "copy" and "template" action plugins to create "docker_copy" and "docker_template".
Replace instances of "copy" module with "docker_copy"; sed -e "s/module_name='copy'/module_name='docker_copy'/"  <infile>
Create a docker_copy module as follows (proof-of-concept):

#!/usr/bin/python
"""Copy a file into a docker container."""
from os import path
import shutil
import subprocess
import tempfile

# pylint: disable=wildcard-import,import-error
from ansible.module_utils.basic import *
# pylint: enable=wildcard-import,import-error

def main():
    """Copy a file into a docker container."""
    # pylint: disable=undefined-variable
    module = AnsibleModule(
        argument_spec=dict(
            src=dict(required=True),
            dest=dict(required=True),
            container=dict(required=True),
            original_basename=dict(required=False)),
        add_file_common_args=True)
    # pylint: enable=undefined-variable

    src = module.params['src']
    dest = module.params['dest']
    container = module.params['container']

    if not path.exists(src):
        module.fail_json(msg="Source %s not found" % (src))

    changed = False
    tmpdir = tempfile.mkdtemp()
    try:
        tmpdest = path.join(tmpdir, path.basename(dest))
        try:
            subprocess.check_call(
                ('docker', 'cp', '{}:{}'.format(container, dest), tmpdest))
        except subprocess.CalledProcessError:
            with open(tmpdest, 'w'):
                pass

        checksum_src = module.sha1(src)
        checksum_dest = module.sha1(tmpdest)
        if checksum_src != checksum_dest:
            changed = True
            module.atomic_move(src, tmpdest)

        module.params['dest'] = tmpdest
        changed = module.set_fs_attributes_if_different(
            module.load_file_common_arguments(module.params), changed)
        if changed:
            subprocess.check_call(
                ('docker', 'cp', tmpdest, '{}:{}'.format(container, dest)))

    finally:
        shutil.rmtree(tmpdir)

    module.exit_json(changed=changed)

if __name__ == '__main__':
    main()

Now I can template and copy into a remote docker container without leaving cruft behind.
- docker_copy:
    src=data
    dest=/data
    container=test-container
    mode=0644
- docker_template:
    src=template.j2
    dest=/template
    container=test-container
    mode=0600

@ToBeReplaced,  I believe my comment addresses that, where you would use the docker connection type, and utilize pre-existing modules for templates and files.
See http://docs.ansible.com/ansible/intro_inventory.html#non-ssh-connection-types

@sivel Can you explain exactly how that works on a remote host as opposed to the master? As far as I know, you can only use the connection plugin on the master.
I'm looking for an example that copies file X from master to container Y on host Z.

Maybe I typed too soon... it looks like you can do it if you expose your docker daemon to the network. I'd rather not do that (I'd rather trust freeipa for policy than docker...), but I get it. I guess we can leave this be then. I'll keep using a module that works without networked docker and expect that ansible will continue developing under the assumption of networked docker.

I think this issue is resolved through: https://docs.ansible.com/ansible/latest/collections/community/docker/docker_container_module.html#parameter-mounts


Spec: Add clockTopic field to serverInfo message

Public-Facing Changes

Update spec by adding clockTopic field to serverInfo message

Description
In ROS systems, the /clock topic tells subscribers about the current time of the system. Clients, like Foxglove Studio, may want to subscribe to this topic. In order to stay ROS agnostic, a clockTopic field was added which is used to inform clients about the clock topic name

@jhurliman @jtbandes PTAL
Relevant for https://github.com/foxglove/studio/issues/4908

I proposal that was discussed is to introduce a new opcode for "clock" and abstracting the topic subscription into the bridge implementation. Not sure if better or worse alternative than this approach.

Closing in favor of https://github.com/foxglove/ws-protocol/pull/299


23.11 - Two error messages appear.

I get two error messages if I open latest 23.11

I used it for several years in same location. No Installer, portable like most my other installs.

Thank you very much for quick fix :)


Data instead of JSON - anyone wanna work on this with me?

Is this because Decodable wasn't available before?
I'd like swifter to produce a Data instance which I can use JSONDecoder with. Anyone wanna collaborate on this?
not sure how to decode this JSON so I'm having to stringify with  json.description first which seems like a terrible idea

@meteochu @mattdonnelly hi guys! i'm super grateful for your work, if you have a minute, I would appreciate some guidance: Why is decoding done with a bespoke JSON type, when using JSONDecoder with Swift Data type is so easy and convenient?
Am I missing something? Perhaps the reason I don't see the advantage is because I didn't build the library.
But right now it seems awkward to decode the by applying a set of string keys.

I need this as well and replaced the json with data in my fork.

@steipete any chance you can share your fork?

I submitted a PR for this back in January.  Feel free to take a look at it and see if it works for you:  #341


RA interface setting does not use custom name

[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[X] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
Entirely cosmetic issue.
If I rename my interfaces e.g. WAN "external", LAN "internal" and OPT1 "DMZ", then the RA dialog still shows WAN, LAN and OPT1 while all other parts of the system I am aware of show Uplink, Internal and DMZ.
Steps to reproduce the behavior:

Create a few interfaces, they get names WAN, LAN, OPT1, etc.
Rename said interfaces WAN: external, LAN: internal, OPT1: DMZ
You'll see that these new names (external, internal, DMZ) will now be displayed (almost) everywhere.
EXCEPT, when configuring manual Router Advertisements (Services > Router Advertisements: [new interface name]), here the RA interface still mentions the default (WAN, LAN, OPT1, etc.) name.

Expected behavior
That RA interface should show my custom interface names.

Relevant log files
Environment
OPNsense 21.7.4-amd64
FreeBSD 12.1-RELEASE-p20-HBSD
OpenSSL 1.1.1l 24 Aug 202

Fair enough, I'll fix this. :)
Cheers,
Franco


[Bug] dolphinscheduler/resources createResource method xxx.jar  No suitable resolver

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
dolphinscheduler/resources上线服务端createResourcejar包报错
exceptionHandler(Exception, HandlerMethod)
java.lang.IllegalStateException: Could not resolve parameter [1] in public org.apache.dolphinscheduler.api.utils.Result org.apache.dolphinscheduler.api.exceptions.ApiExceptionHandler.exceptionHandler(java.lang.Exception,org.springframework.web.method.HandlerMethod): No suitable resolver

本地服务上传jar是成功的

非常不理解这是什么问题造成
What you expected to happen
createResource xxx.jar
How to reproduce
createResource /dolphinscheduler/resources xxx.jar
Anything else
No response
Version
3.0.0
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

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

may be under current directory ```(/text0908)``` had existed same name file which named ``` dolphinscheduler-api-3.0.0.jar```

may be under current directory ```(/text0908)``` had existed same name file which named ``` dolphinscheduler-api-3.0.0.jar```

may be under current directory (/text0908) had existed same name file which named  testsss.jar
这个是上传成功的。

上传失败是这个


Fix link to Platforms in index.md

Found a broken link when reading the guide.

@jumski - thanks for catching and fixing this!   👍


Sort generated imports to make sure that they are deterministic

The main content is: 7c18368f33a813c8b79363d390c6e95de4e5deb0
This builds on top of #26 which brings this package up to humble and non-EOL ROS distros which is where I'm developing and can test.
It could be cherry picked as well. But I didn't want to submit it there when I couldn't test it.

I have rebased this on top of the merged version of #26 . Now it's a one line fix only.


Add tests for WindowedValue.

I just realized I forgot to add this file when doing #691 .

R: @aaltay

LGTM


How to evaluate my model every 3 epoch?

What dose param 'epoch' and 'eval_epoch' mean in config file? And how can I evaluate my model every 3 epoch? Thanks.

Hi, "eval_epoch" can be viewed as evaluate times in your total training process. "eval_epoch" should be a multiplier of "epoch" and  "loops" in the dataset. For example:
if you want to train 300 epochs and you want to evaluate every three epochs, you can set "eval_epoch" = 100, and the data "loop" for the training dataset will be automatically set to 3.

Thanks for your reply!


Add a documentation note for CRIO

Currently KuebVirt can not be run on the CRIO runtime.

Should be done in the user-guide

/ref #897

kubevirt/user-guide#79


[Multi-Action]Browse: models and types.

Description
Adding models and types for the browse action.

Risk

Deploy Plan

Merge to main
apply the migration 09 from main on prodbox
Deploy front

Little update: the architecture as changed quite a lot so I am starting again from scratch, reusing code from this PR for copy/pasting when possible. Closing