text:
Recreate Health & Hygiene Page

The existing page looks too filled and is not responsive too.
I want to update complete page as well as fix the responsiveness.
Please assign under JWOC

ok

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
calculator: nicer Android adaptation with API 21 + variant

Improve the look of the Android variant for the calculator using style resources from the AOSP calculator. Also intro another variant for Android API 21+ which changes the font and deactivates the virtual keyboard.
This should also fix the calculator missing from our f-droid repository. However, I don't know yet how f-droid handles more than one APK per package...
For an idea of the result, you can take a look at the 6 different resulting calculators alongside the latest AOSP calculator: http://xymus.net/pub/calcs.pdf

+1

+1

why not API 22?

source: gharchive/pull-request

authors: MehdiAit privat xymus

repo: nitlang/nit


text:
authentik.service is ordered after network-online.target but doesn't depend on it

Hi,
during evaluation nix/colmena is complaining about:

authentik.service is ordered after network-online.target but doesn't depend on it.

Here is the full output:
❯ COLMENAHOST=shel1sso00; colmena apply --on ${COLMENAHOST} --build-on-target --nix-option builders 'ssh-ng://${COLMENAHOST} aarch64-linux'
warning: Git tree '/Users/phg/workspace/privat/nix_config' is dirty
[INFO ] Using flake: git+file:///Users/phg/workspace/privat/nix_config
[INFO ] Enumerating nodes...
[INFO ] Selected 1 out of 5 hosts.
           ❌ 2s Failed: Child process exited with error code: 1
shel1sso00 ❌ 2s Evaluation failed: Child process exited with error code: 1
[ERROR] Failed to evaluate shel1sso00 - Last 20 lines of logs:
[ERROR]   stderr)           959|         || pred here (elemAt values 1) (head values) then
[ERROR]   stderr)           960|           head values
[ERROR]   stderr)              |           ^
[ERROR]   stderr)           961|         else
[ERROR]   stderr)
[ERROR]   stderr)        … while evaluating the attribute 'value'
[ERROR]   stderr)
[ERROR]   stderr)          at /nix/store/rqdf3gfjq8zh488msnv62h03kkzr308q-source/lib/modules.nix:809:9:
[ERROR]   stderr)
[ERROR]   stderr)           808|     in warnDeprecation opt //
[ERROR]   stderr)           809|       { value = builtins.addErrorContext "while evaluating the option `${showOption loc}':" value;
[ERROR]   stderr)              |         ^
[ERROR]   stderr)           810|         inherit (res.defsFinal') highestPrio;
[ERROR]   stderr)
[ERROR]   stderr)        (stack trace truncated; use '--show-trace' to show the full trace)
[ERROR]   stderr)
[ERROR]   stderr)        error:
[ERROR]   stderr)        Failed assertions:
[ERROR]   stderr)        - authentik.service is ordered after 'network-online.target' but doesn't depend on it
[ERROR]  failure) Child process exited with error code: 1
[ERROR] Failed to complete requested operation - Last 1 lines of logs:
[ERROR]  failure) Child process exited with error code: 1
[ERROR] -----
[ERROR] Operation failed with error: Child process exited with error code: 1
Hint: Backtrace available - Use `RUST_BACKTRACE=1` environment variable to display a backtrace

This can be simply fixed by adding the following patch where also a dependency via wants to network-online.target is established:
diff --git a/module.nix b/module.nix
index bc3ef58..99ca103 100644
--- a/module.nix
+++ b/module.nix
@@ -175,6 +175,7 @@ in
         };
         authentik = {
           wantedBy = [ "multi-user.target" ];
+          wants = [ "network-online.target" ];
           after = [
             "network-online.target"
             "postgresql.service"

fixed by #14

authors: WilliButz shokinn

repo: nix-community/authentik-nix


text:
Config File Support

I'm trying to see if I can get bazelisk working in a Nix (container) environment for https://github.com/bazelbuild/continuous-integration/pull/1799 and I'm running into an issue where Bazel (and many executables it launches) run fine with nix-ld-rs (it gets past the child process issue that nix-ld has) but in some cases Bazel insists on running a child process with a clean environment and hard-coded PATH.
I think the nixpkgs version of Bazel patches out this behavior, if I'm interpreting this correctly (https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/bazel/nix-hacks.patch).  If nix-ld-rs could fall back to reading /etc/nix-ld.conf (for example) to get the values for NIX_LD and NIX_LD_LIBRARY_PATH, that would work around this particular case.
I'm assuming not having config file support is a pretty deliberate choice for a reason I'm not considering.  If not and this functionality would be a good addition, I'd be happy to take a stab at a PR.

I didn't added a configuration file in nix-ld, because it was a bit of a pain to achieve this without libc. In nix-ld-rs this should be easier now. However should only support system or user level configuration and not look up files in projects i.e. .nix-ld.conf. The latter one is a security risk as it allows code execution - except if we would allow to define safe prefixes like git or gdb does.

repo: nix-community/nix-ld-rs


text:
break(flake): use upstream options...

use nixpkgs.flake settings to add nixpkgs
drop symlink flake
replace it with registerSelf, which uses the flake registry
don't add all inputs of self anymore, they can quickly be referenced with self.inputs anyway.

I did no lib.mkRenamedOptionModule for symlinkFlake -> registerSelf, as it's not just a rename.
We say "stable" in the README, but we don't really have releases or anything to communicate
breaking changes yet, I think? Technically, there's another breaking change as this doesn't add all inputs of self anymore - on the main branch for a few days.

/cc @zowoq because he's been affected by this as well

Ok. I assumed because you were duplicating some of the stuff in https://github.com/nix-community/infra/pull/1436

authors: phaer zimbatm

repo: nix-community/srvos


text:
Add getregs()/setregs()/getregset()/setregset() for Linux/musl/aarch64

What does this PR do
I needed this specific API for packaging my project for Alpine Linux distribution:

https://github.com/JakWai01/lurk/issues/4
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71833
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71875

I added support for aarch64-unknown-linux-musl for getregs() function and it builds fine now, but I don't have a way to test it.
Also, I'm not sure if this is the correct way to add support for this architecture - but should be fine!
Let me know what you think and I can try adding support for other functions (such as setregs()) as well.
BTW this is my first PR to the nix crate so please let me know if I'm doing something wrong :bear:
Checklist:

[x] I have read CONTRIBUTING.md
[x] I have written necessary tests and rustdoc comments
[x] A change log has been added if this PR modifies nix's API

but I don't have a way to test it.

Here is a test, maybe you can take a look and try enabling it for musl as well:)

I expanded the scope of this PR a bit and enable the tests. Thought I still wonder why Linux/musl/aarch64 wasn't enabled in the initial implementation in #2044

The tests seem to be passing 🤔

Thought I still wonder why Linux/musl/aarch64 wasn't enabled in the initial implementation in https://github.com/nix-rust/nix/pull/2044

I think it is because the author's use case does not target aarch64-unknown-linux-musl.

I expanded the scope of this PR a bit and enable the tests.

Looks like setregs() is also added, let me edit the PR title (as it will be used as the commit message, we use squash merge).

Awesome, thanks for the merge!
When should we expect a new release? 😇

When should we expect a new release? 😇

Probably not soon, the I/O safety port is still not done, even though we finish it quickly, we still need to test it. Can you guys use a git dependency, though this would stop you from releasing to crates.io, I am not sure if this will block lurk from being included in Alpine Linux

Thanks for letting me know!

Can you guys use a git dependency, though this would stop you from releasing to crates.io,

Yeah, weekly alpha/rc releases would be really useful for these cases. Both for accessing the versions quickly and testing it :)

I am not sure if this will block lurk from being included in Alpine Linux

I'm not sure as well, just asked them 👀

authors: SteveLauC orhun

repo: nix-rust/nix

license: mit

license_source: bigquery


text:
there should be tests for ReceiveBuffer's big-O behavior

It's security-critical that ReceiveBuffer's methods have linear worst-case complexity, and the code we use to accomplish this is non-trivial. There should be tests that we have successfully avoided the O(n^2) trap.
Automated tests for speed are difficult, but I think it's not so bad in this case, because quadratic behavior is so dramatic. So like we could do a worst case test (e.g. repeatedly read 1 byte from an N byte buffer) with N = k and N = 100*k. If we got it right then the latter will be 100x slower; if we got it wrong it'll be 10,000x slower. So we can check that it's less than 1,000x slower, and that gives us a large safety margin on both sides.

@njsmith not too familiar with the codebase but this seems reasonable. You might want to explore the JIT disabling flags for PyPy though (if you're testing against it) in order to prevent any well intentioned surprises. Also, any chance of just writing your own bytearray module in pure Python, then testing deletion from the front? I imagine it would be much simpler.

We do test against PyPy, yes. I'm not quite sure how the JIT would cause a problem here, and I'd be nervous about testing a configuration we don't run on, since this would be a safety check, but it makes sense to watch out for it.
ReceiveBuffer is already a pretty thin layer on top of bytearray. (I say "non-trivial" in the original post, and it is, but I just mean "complicated enough to need a test". It's still only like 30 lines or something :-). A little bit of that is to get O(1) reads from the front; more of it is to get good big-O behavior for doing repeated searches for the same terminator (e.g. line endings) in a buffer that keeps growing as more data arrives.

@njsmith I was assuming that in order to do timing tests you'd run the function repeatedly and compare the total running times.  But if you're suggesting to only run the function once the JIT would probably not have a large impact if it didn't already compile the code due to repeated calls from the previous tests.
My worry is that in the middle of running the code repeatedly, say 1000 times for N=k, when the tests start for N=100*k the JIT kicks in and optimises the method, which may produce much faster code and thereby hiding the big-O behaviour.

Ahh, I see, right, that would be a big concern! I was imagining that we'd pick k such that the shorter test takes long enough that it's timing is not too hard to measure (likes tens of milliseconds say) so that we can get reasonable timings by running it ~3-5 times. There still is the concern that because the test itself contains a loop the JIT might kick in at some point (there's a for i in range(k): ...) even with a small number of runs. I can imagine a few possible counter-measures... pre-warm the test by running it "enough" times before taking timings, interleave the runs of the small and large tests so that if the JIT kicks in at some point it affects them both ~equally. Or just always run the big large test first, so if the JIT does mess things up it will cause a visible failure. Or maybe it won't even come up as a problem :-). Probably we need to try it before spending too much time worrying.

authors: eugene-eeo njsmith


text:
publish the latest node version as well as the LTS

maybe it could be published as a prerelease (for example like i did with https://github.com/breuerfelix/chromedriver-py/pull/43)

Done: https://pypi.org/project/nodejs-wheel-binaries/22.9.0rc0/#files

authors: DetachHead njzjz

repo: njzjz/nodejs-wheel


text:
Time zone

Is there anywhere to adjust your local time zone?  I'm in GMT-5 and at 1900 local time it started pulling historical data for tomorrow's date.
Thanks in advance.  I love the module.  Keep up the great work.

Thanks for this issue. I understand the problem. Any idea of a simple solution?

I'm not quite sure.  I am not a programmer just a simple read the manual and copy/paster.

A possible solution could be to define an offset config option for pausing the module data updates. The module would not update its data, if you are in a time range between the configured offset and midnight. But I think this only works if you are behind GMT, it is not possible to get data from the future.

I get what you are saying, Wikipedia is on GMT there is no way to offset the timezone locally.  You are correct, it would be an update delay and only effect us in the past.  If you figure out how to get data from the future, tell no one besides me.

I think this is a useful feature so I will work on it as soon as possible.

I added this feature in branch update_delay. Are you able to test it on you mirror? Thanks in advance.

I  believe I have it all setup and implemented my necessary 5 hour delay.  I'll check to see if it works at my 00:00 and report back.  Thanks!

It did not appear to work.  It pulled the update at the same 19:00 local time

Did you set updateDelay: 5 in the config and restarted your mirror? Could you please post your config? Thanks.

Yes I do and yes I did.
{
module: 'MMM-OnThisDay',
position: "lower_third", // All available positions
config: {
maxWidth: "725px",
updateInterval: "3600",
textSize: 'small',
updateDelay: 5,
}
},

And you are using the correct branch update_delay? If yes, I need to investigate this on my mirror with a different time zone. Thanks again for your feedback.

Closing this issue because of inactivity.

repo: nkl-kst/MMM-OnThisDay


text:
Current date FG issue

I know Gradience is not supported, but is there any chance, this could be patched? I am guessing you are using a color name rather han a variable name.

I will look what CSS class to add so you can fix this using CSS overriding.

Awesome, thank you!

https://github.com/nlogozzo/NickvisionMoney/releases/tag/2023.1.0-beta3

authors: fsobolev nlogozzo stpnwf

repo: nlogozzo/NickvisionMoney


text:
Allowing this library to be used by package managers

This library lacks a cmake config file, which means it cannot be easily found with find_package.
Currently, the vcpkg port uses hacky patches to enable it be to used:
https://github.com/microsoft/vcpkg/pull/8458
https://github.com/microsoft/vcpkg/issues/10809
https://github.com/microsoft/vcpkg/pull/10850
This pull request allows this library to be easily ported to package managers such as vcpkg.

Seems that the appveyor image only contains cmake 3.16, I've change the cmake script so it can used by older versions.

The original commits for the PR were a bit messy, so I've squashed them in 5 commits (from 11).


text:
Compilation with -fmodules-ts and use inside of a module

Description
Hi,
When just including #include <nlohmann/json.hpp> in a module, the compiler complains about impossible references.
It is not happening when not inside a module.
Reproduction steps
Just include the header inside a module and compile with -fmodules-ts.
This is the triggering flag, really.
Expected vs. actual results
No error
Minimal code example
//mod.cxx:

module;
#include <iostream>
#include <string_view>
#include <string>
#include <nlohmann/json.hpp>
export module hello;

export {
        namespace X {

                void greeter ( std::string_view const &name ){
                        std::string h = "exported greeter";

                        std::cout << "Hello " << name << "!" << h << "\n";

                }

        }
}

// main.cpp
import hello;

int main ( void ){

        X::greeter("ok");
        return 0;
}

// compile with
~/gcc-12.1/g++ -fmodules-ts -std=c++20 -I/my_path/include/ mod.cxx main.cpp

Error messages
`/usr/include/nlohmann/adl_serializer.hpp:41:17: error: ‘static decltype ((nlohmann::{anonymous}::to_json(j, forward<ValueType>(val)), void())) nlohmann::adl_serializer<T, SFINAE>::to_json(BasicJsonType&, ValueType&&) [with BasicJsonType = nlohmann::basic_json<>; ValueType = bool&; <template-parameter-1-1> = bool; <template-parameter-1-2> = void; decltype ((nlohmann::{anonymous}::to_json(j, forward<ValueType>(val)), void())) = void]’ references internal linkage entity ‘constexpr const nlohmann::detail::to_json_fn& nlohmann::{anonymous}::to_json’
   41 |     static auto to_json(BasicJsonType& j, ValueType&& val) noexcept(`

Compiler and operating system
Linux GCC-12.1
Library version
Latest
Validation

[ ] The bug also occurs if the latest version from the develop branch is used.
[ ] I can successfully compile and run the unit tests.

If the issue is what I suspect it is, this should be easily fixable. I'll take a look.

I was able to fix the linkage issues by marking the relevant entities inline but your code then results in an ICE:
 $ g++-13.0.0 -fmodules-ts -std=c++20 -I../fix-c++20-issues-part2/include/ mod.cxx main.cpp
main.cpp: In function ‘int main()’:
main.cpp:4:12: internal compiler error: Segmentation fault
    4 |         X::greeter("ok");
      |            ^~~~~~~
0x7fcf08bf793f ???
        /var/tmp/portage/sys-libs/glibc-2.35-r4/work/glibc-2.35/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7fcf08be3389 __libc_start_call_main
        ../sysdeps/nptl/libc_start_call_main.h:58
0x7fcf08be343b __libc_start_main_impl
        ../csu/libc-start.c:392
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.

(And GCC 12 crashes as well.)
You can grab the fixed code from my modules branch. Maybe you can figure out why GCC is crashing.
https://github.com/falbrechtskirchinger/json/tree/modules
(The code is running through CI right now. If there're any problems I will update this post.)

Thanks!
There is a much deeper issue in the handling of modules in gcc and I reported a bug this morning.
I will try your fix once I get some lights 👍👍

@nlohmann This bug can be closed. Fixed by #3446 (4f744f4).

repo: nlohmann/json


text:
Preload the data node with a small dataset

When the data node is launch, check if the dataset "example-dataset" exists. If not, create it:

create "example-dataset"
create "example-fhir-store"
create "example-annotation-store"
push Patient and Note objects for 2 patients
push Date, Person Name and Physical Address Annotation for the clinical notes pushed

These data can be taken from the 2014 i2b2 training dataset
EDIT: The motivation is that this will simplify the tutorials and demonstrations.

There are other resources that will show how to push datasets and other resources to the data node. Below is a couple of repositories where this information will be made available:

https://github.com/nlpsandbox/i2b2-phi-dataset
https://github.com/nlpsandbox/nlpsandbox-client

repo: nlpsandbox/data-node


text:
Parser misbehaves on empty assignments

With this simple Makefile:
EMPTY=
all:
        echo "Hello"

The parser gets confused by the empty assignment and returns nonsense:
λ> parseMakefile
Right (Makefile {entries = [Rule (Target "EMPTY=\nall") [] [Command "echo \"Hello\""]]})

I would expect this instead:
Right (Makefile {entries = [Assignment "EMPTY" "",Rule (Target "all") [] [Command "echo \"Hello\""]]})

The latest commit should fix the issue. Feel free to close.

Wonderful, thanks!

authors: RyanGlScott nmattia

repo: nmattia/mask


text:
Delete obsolete LocalAccounts on App startup

Readiness checklist

[x] I added/updated tests.
[x] I ensured that the PR title is good enough for the changelog.
[x] I labeled the PR.
[ ] I self-reviewed the PR.

🔥

repo: nmshd/runtime


text:
C++ Example

Hi!
In your "readme.md" and "examples" folder, examples are provided only with python bindings.
In https://github.com/jlmelville/rcpphnsw rough equivalent of the serialization/deserialization example from this hnswlib README file is provided in 'R' language.
But nowhere C++ example of serialization/deserialization equivalent to current README example is provided. I want to use hnswlib in my c++ project. I was wondering how to do the exact functionality in c++.  It would be great if you translate examples given in python to c++.
Thank you!

@ashfaq92
Thanks for noticing! I'll make an example.

The basics of creating/re-sizing/re-loading an index, as used in RcppHNSW are below. It doesn't really do anything, but it should compile and run without causing your computer to explode, which is 90% of the battle in C++. Hopefully you can work out the rest!
#include <memory>
#include "hnswlib.h"
void example()
  auto dim = 16;
  auto num_elements = 100000;
  auto init_num_elements = num_elements / 2;
  auto M = 16;
  auto ef_construction = 200;

  using dist_t = float;
  using Distance = hnswlib::L2Space;

  // create the index
  auto space = std::unique_ptr<Distance>(new Distance(dim));
  auto appr_alg = std::unique_ptr<hnswlib::HierarchicalNSW<dist_t>>(
    new hnswlib::HierarchicalNSW<dist_t>(space.get(), init_num_elements, M,
                                         ef_construction));

  // resize it
  appr_alg->resizeIndex(num_elements);

  // or save and reload it
  std::string path_to_index = "myindex.hnsw";
  appr_alg->saveIndex(path_to_index);
  appr_alg.reset(new hnswlib::HierarchicalNSW<dist_t>(space.get(), path_to_index));
};

@jlmelville thanks for prompt response. Sorry for late reply due to "timezones :(". I have run your code and it works without error (as you said :). But it would be really nice if you update this code according to the readme file. I mean if it make HNSW graph with random numbers and finds nearest neighbor for any random query point. Then we may add this code in readme files so that future c++ beginners may embed that in their code (like me).

With the addition to above code
`auto dim = 512;
auto num_elements = 100000;
auto init_num_elements = num_elements / 2;
auto M = 16;
auto ef_construction = 200;
using dist_t = float;
using Distance = hnswlib::L2Space;

// create the index
auto space = std::unique_ptr<Distance>(new Distance(dim));
auto appr_alg = std::unique_ptr<hnswlib::HierarchicalNSW<dist_t>>(
        new hnswlib::HierarchicalNSW<dist_t>(space.get(), init_num_elements, M,
                                             ef_construction));

//    // resize it
////    appr_alg->resizeIndex(num_elements);
typedef size_t labeltype;
appr_alg->setEf(200);
auto ret=appr_alg->searchKnn(default_emb,1);//'1' is the nearest neg
std::vector<std::pair<dist_t, labeltype>> result;//result return after knn search

//    while (!ret.empty()) {
//        result.push_back(ret.top());
//        ret.pop();
//    }
int f=0;
int id_label;
float mn=100000;
if(ret.size()==0)
{
    counter_value+=1;
    appr_alg->addPoint(default_emb,counter_value);
    LOGD("This is empty ret");
} else{
    LOGD("Non empty ret");
    while (!ret.empty()) {
        result.push_back(ret.top());
        ret.pop();
    }
    for(int i =0;i<result.size();i++)
    {
        LOGD("hnswlib result:(1)distance:) %f => (2)label:) %d",result[i].first,result[i].second);
        if(result[i].first<(0.5)&&mn>result[i].first)
        {
            f=1;
            mn=result[i].first;
            id_label=result[i].second;
        }
    }
    if(f==0){
        counter_value+=1;
        id_label=counter_value;
        appr_alg->addPoint(default_emb,counter_value);
        LOGD("New entry generated");
    }else{
        LOGD("Id we get:%d",id_label);
    }
}

result.clear();`

repo: nmslib/hnswlib


text:
Do not require "-f/--file" to specify state

Since the network state file is always requirer/not optional, specify it
as an argument, not as an option.

I was thinking we could use stdin as an alternative to --file, don't you think it is worth it?

We can add that - as a file would  make it read from stdin, not sure if it is useful for the PoC. Usually you can use /dev/stdin in bash to specify stdin anyhow.

@tyll I would go with the --f -, it's somehow expected.

I believe there are different expectations. -f is also used to force things somethings and since the state file is not optional for the set command, it should not be an option IMHO, see for example sort, cut or cat.

The reason that --file  looks better is due to the explicit naming of the argument.
Perhaps we could specify something like this:

"--file" is optional, if it is not specified, a default desired-state.json is expected to exist. That fits with most config files pattern.
We could change the name to something like "-s , --desired-state-file".

Will this fit better?

If the arguments should be explicitly named, then it would need to be nmstatectl --action set --state foo.state. I am not convinced, that making it an option, i.e. requiring any --string makes it better. And I also do not see this in other tools. For example xrdb is used to load the X ressources into an X session (just like nmstatectl is used to load the network state) and the command line would be xrdb filename. Since xrdb needs to file to read from, it does not make sense to make the filename an option.
Also I would not call the state a configuration file for nmstate, this would be a file that describes how nmstate behaves not a file that is used by nmstate.

Not all arguments, only the file one.
The comparison to the configuration was only to give an example of how a default state file could be used. Why do we need to require a file path to be given? That is not minimalistic.
If you have strong opinions on this, I will take the PR in, but I would feel more comfortable with another unix cli geek giving an opinion on this.
@dankenigsberg ,   @thom311 ?

Good point about the minimalist example, I guess we could just read from stdin when no file is presented, just as cat or grep does (when the file is omitted). However, I guess endless hours where wasted for people to wait for grep foo when they meant grep foo *.

ping?

Could you please update the README now?
Will be nice to see all the options on how to use it now in the commit message.
Specifically, is this supported?
cat desired-state.json | nmstatectl set

I update the README, squashed/rebased the commits and mentioned all possibilities in the README.

authors: EdDev phoracek tyll

repo: nmstate/nmstate


text:
[Wait for #1294] [Layer] Add trainable prop

[Pending commit: #1294]

[Layer] Add trainable prop

This patch add trainable property to layer

**Self evaluation:**
1. Build test: [X]Passed [ ]Failed [ ]Skipped
2. Run test: [X]Passed [ ]Failed [ ]Skipped

Signed-off-by: Jihoon Lee <jhoon.it.lee@samsung.com>

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

:octocat: cibot: @zhoonit, nntrainer/layers/common_properties.h does not include Doxygen tags such as @file @brief @author @bug. You must include the Doxygen tags in the source code. Please refer to a Doxygen manual at http://github.com/nnstreamer/TAOS-CI/blob/main/ci/doc/doxygen-documentation.md

:octocat: cibot: @zhoonit, nntrainer/layers/common_properties.h does not include Doxygen tags such as @file @brief @author @bug. You must include the Doxygen tags in the source code. Please refer to a Doxygen manual at http://github.com/nnstreamer/TAOS-CI/blob/main/ci/doc/doxygen-documentation.md

:octocat: cibot: @zhoonit, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnstreamer.mooo.com/nntrainer/ci/repo-workers/pr-checker/1298-202106171036280.99548602104187-ddcb476167072267b4901d7cc729cacef5c7dccd/.

Discussed offline, trainable will later move to LayerNode.
Lets merge this PR for now.

authors: kparichay taos-ci zhoonit

repo: nnstreamer/nntrainer


text:
Allow for custom NWM cache dir

Right now it only allows True or False to be specified for cache argument of NWM config. This limits user to using home directory. On an HPC, a user might want to try and set a path on scratch to be the location where the NWM data is cached.
See:
https://github.com/noaa-ocs-modeling/CoupledModelDriver/blob/7d2d85feab0428c5488b7dd9642115234c100796/coupledmodeldriver/configure/forcings/base.py#L833

As noted in https://github.com/schism-dev/pyschism/issues/123, adding custom path still doesn't solve the issue of need for internet access

repo: noaa-ocs-modeling/CoupledModelDriver


text:
Hi, I've some problem for routing

My Folder is
-Controller
---Demo.php
-vendor
-.htaccess
-index.php
My localhost url: http://localhost/test/macaw/
/------My .htaccess file-----
RewriteEngine On
RewriteBase /test/macaw/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?$1 [QSA,L]
-------/
My index.php file and my demo.php file like yours readme file (https://github.com/noahbuscher/Macaw/#example-passing-to-a-controller-instead-of-a-closure)
But I see 404 on my page.
Can you see where i make mistakes?
Thank you.

I don't only that I don't see a composer.json file in your example.

Thanks for your interest.
my composer.json file
{
"require": {
"noahbuscher/macaw": "dev-master",
"smarty/smarty": "~3.1",
"php-curl-class/php-curl-class": "^7.3",
},
"autoload": {
"files": [
],
"psr-4": {
"": ""
}
}
}

I think I solved this problem, Do not know if my approach is correct, Only two lines of code.
Changed place
Macaw.php
line 25
  public static $error_callback;
+ public static $root;

line 63

  public static function dispatch(){
    $uri = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
+   !empty(self::$root) && self::$root !== '/' && $uri = self::$root === $uri ? '/' : substr_replace($uri, '', strpos($uri, self::$root), strlen(self::$root));
    $method = $_SERVER['REQUEST_METHOD'];
    ...
  }

route
<?php

use NoahBuscher\Macaw\Macaw;

Macaw::$root = 'test/macaw';

Macaw::get('test', function () {
  echo 'ok';
});

Macaw::dispatch();

access url: http://localhost/test/macaw/test

I did something similar for adding a base URL to route but changed the code in a different way https://github.com/ppazos/amplify-prototype/blame/master/router/Macaw.php

authors: GHBJayce daveismyname mcyumustutan ppazos

repo: noahbuscher/macaw


text:
Errors on Script

I am receiving the below errors on the script.  I also loaded the aws sdk (installed) but the original AWSSDK.dll doesn't exist in that folder so I modified it to EC2 for my AWS SDK Path.  Can I change it to this dll?
#AWS SDK Path
Add-Type -Path "C:\Program Files (x86)\AWS SDK for .NET\bin\Net45\AWSSDK.EC2.dll"
This is the Error I am receiving after I errored out on the above:
Unable to find type [Amazon.AWSClientFactory]: make sure that the assembly
containing this type is loaded.
At C:\AWS\AWSConfig.ps1:42 char:1

$EC2_CLIENT=[Amazon.AWSClientFactory]::CreateAmazonEC2Client($accessKeyID,
$secr ...

    + CategoryInfo          : InvalidOperation: (Amazon.AWSClientFactory:TypeN
   ame) [], RuntimeException
    + FullyQualifiedErrorId : TypeNotFound

New-Object : Cannot find type
[Amazon.SimpleEmail.AmazonSimpleEmailServiceConfig]: make sure the assembly
containing this type is loaded.
At C:\AWS\AWSConfig.ps1:45 char:13
+ $ses_config=New-Object Amazon.SimpleEmail.AmazonSimpleEmailServiceConfig
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidType: (:) [New-Object], PSArgumentExcepti
   on
    + FullyQualifiedErrorId : TypeNotFound,Microsoft.PowerShell.Commands.NewOb
   jectCommand

Property 'ServiceURL' cannot be found on this object; make sure it exists and
is settable.
At C:\AWS\AWSConfig.ps1:46 char:1
+ $ses_config.ServiceURL = $sesURL
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : PropertyNotFound

Unable to find type [Amazon.AWSClientFactory]: make sure that the assembly
containing this type is loaded.
At C:\AWS\AWSConfig.ps1:47 char:1
+ $SES_CLIENT=[Amazon.AWSClientFactory]::CreateAmazonSimpleEmailServiceClient($
acc ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidOperation: (Amazon.AWSClientFactory:TypeN

ame) [], RuntimeException
+ FullyQualifiedErrorId : TypeNotFound

I receive this error
27/08/2015 09.15.16 WriteToLog : System.NotSupportedException: Specified method is not supported.
at System.Management.Automation.ParameterBinderBase.CoerceTypeAsNeeded(CommandParameterInternal argument, String parameterName, Type toType, ParameterCollectionTypeInformation collectionTypeInfo, Object currentValue)

@dms2015 you can find some help in this closed issue.
https://github.com/noahlh/aws-automated-backup-powershell/issues/14#issuecomment-131584777

I fixed this while implementing support for a custom email server, although forgot to mention it in my commit comment. See pull request #19.

authors: amanakash dms2015 matteobraga necarlson

repo: noahlh/aws-automated-backup-powershell


text:
Fix typo for "ASDF"

My apologies for introducing this typo

I fixed it in the Google Doc as well.

repo: noaodatalab/data-viz-tools


text:
Read handles from characteristics and services for linux platform

As the topic sais, I changed the linux part of the system, to make it able to read the handle for a characteristic or service. These values are needed in future use for me, so I would like to hear your opinion on this commit.
Also is it correct to return the startHandle or is a combination of the startHandle and endHandle needed?

@Steckdoserich thanks for submitting this PR!
I'm not too keen on promoting the use of handles. However, I am planning on introducing an id field for services, characteristics, and descriptors to resolve #175. The id will most likely be mapped to the service start handle, and characteristic/descriptor handle for both OS X and Linux.

Please forward change to downstream fork:
#923

Relate-to: https://github.com/noble/noble/issues/923#issuecomment-687851954

authors: janoelker rzr sandeepmistry

repo: noble/noble


text:
Documentation in README emptied with Commit 0ba7470

Hi,
I just saw that with commit 0ba7470 the API documentation was removed from README.md. Most likely this is intentional since you are switching to Promises with Version 5.0.0? It would be awesome if you could re-add the documentation for developers who are using a version < 5.0.0.
Thanks.
Take care,
Simon

What do you want the documentation to keep from the outdated version? Why don't you use version 5 which is self-documenting with the types? I'm sorry, but I have to delete the deprecated code.
You can look at the documentation of version 4 in the commit that you tell me.

@botika - not everyone uses TypeScript or an IDE, and likely don't want to have to read through the code to figure out how it works before downloading the library.  Some basic examples in the README would probably help get people to use node-cache-manager.  The README, as it is now, tells users very little about what the library does.

I'm quite sure I'm not the only one currently using a < 5.0.0 Version, since migrating to a new API without proper documentation needs time and testing. I also agree with Bryan – not everyone is using TypeScript in their projects.
I understand that you don't want to maintain the deprecated examples in the Readme. How about adding a paragraph pointing users to the old version of the Readme? This will mitigate the time one is spending searching for the deprecated documentation.

https://github.com/node-cache-manager/node-cache-manager/commit/9f7c46ec6142e068ea6ffe790c2e6634fda9f557

authors: BryanDonovan botika simon-scherzinger

repo: node-cache-manager/node-cache-manager


text:
Set own default UserAgent

If i want to use my own user-agent on every request i am doing with node-fetch i currently have to add the header every time i use fetch.
In my opinion there should be a possibility to set a global default user-agent because the user-agent is always static for the lifetime of the application (or not?) and setting it every time is a unnecessary overhead.
Something like:
fetch.setDefaultUserAgent('myApp/1.0.1 (MYSERVER; Linux) node-fetch');

Have been lots of talk about making intercepters where you can always debug and or modify request & responses...
Would something like that be of any interest?
I would just imagen it could work something along the line of express use method or how the service worker dose it
kinda like:
// add agent header to all further request.
onfetch = (evt) => {
  evt.request.headers.set('agent', 'myApp/1.0.1 (MYSERVER; Linux) node-fetch')
}

it would be more generic and you can modify mostly anything that way.

Yeah, i like the middleware approach. Like you said, it would be generic and can be used for just any kind of global modification. At this time there is at least one use case apart from the userAgent i could use this for.
But i would say it's enough to give the possibility to modify the request object before the request is executed. Anything more complex, like modifying the response as it's possible in a service worker, is mainly request specific and could better be implemented with functions that are reused in the promise .then method.
fetch.use((req) => {
  req.headers.set('user-agent', 'myApp/1.0.1 (MYSERVER; Linux) node-fetch')
});

fetch('...')
   .then(validateResponseFunction) // validate or modify response
   .then(response=> console.log(response))

Are there already plans of implementing something like that?

lots of talks but no active development
There are usecases too that involves modifying responses. and knowing when it's done so there are usecases for both

Okay, sounds like it's still a long way till it can be used.
Is there already an issue or a place where all the ideas and usecases which resulted from that talks are summed up and gets discussed?

Over the years people asked for a defaults option where you can specify a set of options/headers that would be used on every fetch.
But I have resisted that idea mostly because in client-side you treat fetch like a function that returns a promise, that's it. So really you should be passing in your custom UA header every time.
But of course there are people who are tired of this and wrote their own addons, you might have a go at it (I haven't tried myself, but it's one of the top search result)
https://github.com/moll/js-fetch-defaults

have a look at this issue #284

Okay i can understand that fetch should work like the client-side implementation and without these side effects.
But the user agent gets already set by this package and i only want to change the default value of it to something meaningful, once at application startup.
At the client-side the browser does the same, he adds information about the browser, its version and the os to the user agent and the fetch implementation uses this user agent. There the user agent is a global value and it is added to every request.

easies thing you could do right now is maybe to just build a own wrapper around node-fetch
// fetch.js
const fetch = require('node-fetch')

module.exports = (url, args = {}) => {
  args.headers = args.headers || {}
  args.headers['user-agent'] = 'my own'
  return fetch(url, args)
}

// main.js
const fetch = require('./fetch.js')
fetch('https://httpbin.org/get')

@jimmywarting will it set default headers in this case?

nope

Probably we did not understand each other. The documentation says, that if I don't provide headers parameter, it will be generated automatically and will include 'Accept', 'Content-Length', ... headers.
It is not clear, what happens if I provide 'User-Agent' header only. Will it still add Accept, Content-Length, ... headers or not. According to the source code, it will change User-Agent and still generate other headers (Accept, Content-Length). That's what I expected. Sorry for that misunderstanding

@gugu What did you end up doing?

I ended up creating a wrapper around node-fetch like @jimmywarting suggested and restricting direct imports of node-fetch throughout the codebase with eslint's no-restricted-imports rule.
// eslint-disable-next-line no-restricted-imports
import nodeFetch, { RequestInfo, RequestInit } from "node-fetch";
import pkg from "../../package.json";

const USER_AGENT = `puddle/${pkg.version}`;

export const fetch = (url: RequestInfo, { headers, ...options }: RequestInit = {}) => {
  return nodeFetch(url, {
    headers: {
      "user-agent": USER_AGENT,
      ...headers,
    },
    ...options,
  });
};

// .eslintrc.js

module.exports = {
  ...
  rules: {
    ...
    "no-restricted-imports": [
      "error",
      {
        // Prevent people from importing node-fetch directly
        paths: ["node-fetch"],
      },
    ],
  },
};

A crude alternative could be to make use of 'patch-package': https://github.com/ds300/patch-package

authors: bitinn etienne-martin gugu jimmywarting kmathmann nik-john ustun

repo: node-fetch/node-fetch


text:
Modify the FFI library, apply to loongson platform

Need nan library and node-gyp library to support,before  compilation.
Can you try again,we need to integrate the node-ffi library in out platform.

repo: node-ffi/node-ffi


text:
After Upgrading to node v5.2.0 I got an debug error

Error: Cannot find module '/usr/lib/node_modules/node-inspector/node_modules/v8-debug/build/debug/v0.7.0/node-v47-linux-ia32/debug.node'.
I have seen something looks like that. But it doesn't resolved for you.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

nearly the same error for me, for node 5.5.0, on Windows 7 :
Error: Cannot find module 'C:\Program Files\nodejs\node_modules\node-inspector\node_modules\v8-debug\build\debug\v0.5.2\node-v47-win32-x64\debug.node'

I just reinstall node-inspector whith npm install -g node-inspector and now everything works perfectly

No longer relevant for me

authors: Attrash-Islam abenhamdine

repo: node-inspector/node-inspector


text:
Let themes change radialMenu text colors

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

Proposed changes

As described in https://github.com/node-red-contrib-themes/theme-collection/issues/239, the text in the radial menu becomes unreadable when using themes. This PR fixes that.

Now
	Then

Default theme

Dark theme

Checklist

[x] I have read the contribution guidelines
[ ] For non-bugfix PRs, I have discussed this change on the forum/slack team.
[ ] I have run grunt to verify the unit tests pass
[ ] I have added suitable unit tests to cover the new/changed functionality

Coverage: 68.261%. Remained the same when pulling f7371626973bbaf4cb84713179ff0b4248020fba on bonanitech:radialMenu into b3ce0c007907b93aeb52e13631597ff258719254 on node-red:master.

authors: bonanitech coveralls

repo: node-red/node-red


text:
replacer

I needed a yaml dumper that included a replacer option similar to JSON.stringify.
This turned out to be a simple modification to js-yaml; there may be details not covered.
Its use changes the handling of undefined fields so that they are omitted from the yaml (similar to JSON).
If there is any interest in this change I will make it available.
I will probably add a reviver option for parsing.

I'm not sure this is needed here, but leave this open to collect feedback.

Thanks for the comment.
For background information:  The reason we need the replacer is to prevent some objects getting placed in the output.  We have an application using three.js, and many of my objects have associated THREE objects.  However, when we dump the state we don't want to dump most of those, especially not the gory details of large vertex buffers, but rather recreate them after load.
We used to use JSON, but it was very noisy, especially for multiline strings with double quotes,;so awkward when we needed to edit by hand.  (At least it wasn't nearly as bad as XML)

You could just create filtering function before calling yaml dump: yaml.safe_dump(your_filter(data))

I don't want to modify my data structure or clone the major part of it; which if I understand you right is what you expect your_filter(data) to do?  Rather, just to omit certain objects from the dump.

In the same boat (wanting to discard undefined field); it is odd that the behaviour should differ from json as yaml is supposed to be a superset of json.

Added in https://github.com/nodeca/js-yaml/commit/359b264c0fbadfae86caff91879bf40e902df690 (currently in dev branch).
Tried to do this in a simplest possible way, so there're a few limitations:

no array syntax for replacer (it can be done via replacer function)
no toJSON (it can be done via replacer function)
no reviver (does someone need it?)

authors: puzrin rlidwka sjpt zakhenry

repo: nodeca/js-yaml


text:
feat: legacy html generator

Description
This PR introduces the Legacy HTML generator, which aims to generate an almost 1:1 replica of the existing https://nodejs.org/api/ documentation.
This PR introduces the fully-fledged legacy-HTML generator, with all the related utilities and tools to make complete API docs in HTML.
Diversions from the original version:

Some of the outputted HTML in the "view source" might be different
The styles got a bit updated due to CSS conflicts with Shiki (Syntax Highlighter)
A new syntax highlighter is being used (same as the Node.js Website), meaning token colors will differ.
Sidebar Navigation is generated on-demand instead of relying on nodejs/node/doc/api/index.md

This means some of the entries are a bit different, although I believe they are fine.

Copy button for CodeBoxes on the top instead of the bottom.
Stability Index position is slightly below now (below the History Table and Source Link)

Things to be done:
None. We're feature complete!
Future generators

json generator, being able to generate .json files for API docs
react generator, the redesign of API docs generator.

Validation
Clone, run npm install, then run the command against Node.js API docs, for example:
npx api-docs-tooling -i "/path/to/node/doc/api/*.md" -t legacy-html -o /tmp/out

You can just open the desired files on your browser.
Preview
This is deployed temporarily on Netlify (not auto deployed on commits, I'm manually deploying it): https://node-api-docs-legacy-preview.netlify.app/
Related Issues
Closes https://github.com/nodejs/api-docs-tooling/issues/15

cc @nodejs/collaborators and @nodejs/documentation as this PR changes a few aspects on the generated HTML as mentioned above.

Dropped support of all.html

Can this be avoided?

Dropped support of all.html

Can this be avoided?

Is there any concrete reason why? Afaik, nothing officially gets referenced to all.html; We can still write an all.json tho;

Well I'm using it a lot (to CTRL+F because we don't have a good docs search feature), so I expect it to be the case for other people. This is a disruptive change that I would not like to see before the docs redesign.

Well I'm using it a lot (to CTRL+F because we don't have a good docs search feature), so I expect it to be the case for other people. This is a disruptive change that I would not like to see before the docs redesign.

Gotcha, yes, the docs redesign aims to solve this. To be honest, the https://nodejs.org search box already includes all the API data, and it is continuously updated. (Also, the search box API data indexing will be done on the nodejs.org repository, so technically, it is decoupled from the actual API docs, or at least so it will be for the initial implementation.
For local dev environments, I believe it can source the results locally, but I'm not sure if they will match since Orama (our search provider) has some extra processing on their cloud.
I understand this is a pain point, but I do feel hesitant on an all.html, but I believe I can make it happen.

To be honest, the https://nodejs.org/ search box already includes all the API data

It only works for the latest LTS version (AFAIK)

To be honest, the nodejs.org search box already includes all the API data

It only works for the latest LTS version (AFAIK)

Correct, it indexes the LTS version. That's a good point. @micheleriva, what are the alternatives here? Can we make it for API doc generation so the whole database can be built locally based on metadata we ingest? i.e., is it a static database stored in a static file and loaded by the Orama client during bootstrap (client side)

@targos I've added a legacy-html-all generator which extends on the legacy-html generator for generating the API docs + all.html

cc @nodejs/web-infra, can we have a 2nd thorough review and verify that the pages match?
I still need to update the code that generates the CodeBoxes and the Stability overview. I'll do that later tomorrow or today.

Correct, it indexes the LTS version. That's a good point. @micheleriva, what are the alternatives here? Can we make it for API doc generation so the whole database can be built locally based on metadata we ingest? i.e., is it a static database stored in a static file and loaded by the Orama client during bootstrap (client side)

@ovflowd sorry for my late reply. Yes, we can definitely do this. Let me just point out that the search results may slightly differ from Orama Cloud (more performant, more accurate results) and Orama OSS. I hope that's not a dealbreaker.

I think that's a fair trade-off, at least within directly the Node.js API docs pages. Are there docs out there on how we can use this?

I think that's a fair trade-off, at least within directly the Node.js API docs pages. Are there docs out there on how we can use this?

We have our docs at https://docs.orama.com/open-source, and you would probably need to use that plugin: https://docs.orama.com/open-source/plugins/plugin-data-persistence.
We can give you support probably starting next week or so to write down a reference architecture/implementation 🙏

This PR is quite massive (would it have been possible/feasible to break this up—at least smaller chunks into a feature branch that was then wholesale merged?),

I think I could move the bug fixes to a different branch, yes, and the unrelated changes. I'll do this when this branch is feature-complete. Although the PR is open, I believe it should be a draft PR.

I think that's a fair trade-off, at least within directly the Node.js API docs pages. Are there docs out there on how we can use this?

We have our docs at docs.orama.com/open-source, and you would probably need to use that plugin: docs.orama.com/open-source/plugins/plugin-data-persistence.
We can give you support probably starting next week or so to write down a reference architecture/implementation 🙏

Awesome! cc @canerakdas or @AugustinMauroy can any of you open an issue to keep track of the search box work for this repo? For all's worth, it should be another generator to generate the Orama local database.
The search component itself would be either the same from the Node.js website or on the react generator here in the future; Butb the database generation should be a generator.

I've rebased the branch and am going to keep working on the features.

@AugustinMauroy tests are failing, I assume because I changed the way how stability indexes are built. Can you look into it?

cc @nodejs/web-infra another review please 🙏 I changed the HTML creation to be mostly

FYI: After the next review, I once again will need to decouple changes. Apologies for the prolonged review, implementing this is time consuming, and I want to ensure things work as expected.

FYI @nodejs/web-infra I split the changes: https://github.com/nodejs/api-docs-tooling/pull/66, waiting for review to getting it merged back here.

cc @nodejs/web-infra please add another round of reviews 🙏

There are changes in the name on the left menu. For example;- Assertion testing
+ Assert
- C/C++ addons with Node-API
+ Node-API
- Child processes
+ Child Process

There are differences in the listing in the left menu; hr should be after "Usage and example."

Have you read the PR description? 😅 -- navigation generation is done automatically from now on, instead from reading the manually defined navigation file that exists on /doc/api :P, so yes, it will be different, and that's intentional.

Jump links don't exist/work

What are jump links?

The sequential links on the /errors page do not seem to be generated correctly;

This issue is likely related to the above, but there are also problems with the type references on the following pages:

/url
<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object) | [`<string>`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#String_type" class="type"><Object>

/os
<number>

This issue also appears on other pages

Except for these minor issues, it looks content-wise 1-1 identical to the current pages ✨

Fixed! Thanks for noticing it!

Jump links don't exist/work

What are jump links?

Anchors with a unique id located to the right of the headings;

Jump links don't exist/work

What are jump links?

Anchors with a unique id located to the right of the headings;

Oh they were working before 🤔

cc @nodejs/collaborators @nodejs/build this PR is finally ready, and all the features from the current legacy API docs template are built-in here.
Please, if possible test/run locally and check if the templates, and API docs look in a way y'all are satisfied with :)

cc @nodejs/web-infra for a final code review 🙏

More than the code, I'd like to review the output. Is there a preview somewhere or do I have to build it locally?

Unfortunately need to build locally. I'm not sure where I could upload a preview here. I recall you had a Netlify account or something? If you build you can simply upload the out/ folder

(Im not sure if I can deploy static files to Vercel)

Do we have a good input file that we can test with?

Do we have a good input file that we can test with?

If you want to generate against all docs:
node bin/cli.mjs -i "/path/to/node/doc/api/*.md" -o /tmp/out -t legacy-html-all

@targos here's a deploy using Node v22.7.0 as a binary and targeting this commit from nodejs/node for the doc files: https://66cb17954600d7f933d95110--candid-sprinkles-58d2ce.netlify.app/

Little inconsistency with the index page's title:

View on a single page option is missing (screenshot is from current docs), although the all.html page exists:

Every method has a "History" table always

I don't like that, because it seems that the history falls back to "Introduced in: v0.10.0", which is probably wrong in most cases.

Every method has a "History" table always

I don't like that, because it seems that the history falls back to "Introduced in: v0.10.0", which is probably wrong in most cases.

Could you give examples?

FYI @targos I've made a redeploy with a hot fix regarding the CJS/MJS pre elements.

Is it possible to have a light theme for code blocks when the page is in light mode?
Current:

New:

Little inconsistency with the index page's title (above is the new version):

Fixed

View on a single page option is missing (screenshot is from current docs), although the all.html page exists:

Fixed

Is it possible to have a light theme for code blocks when the page is in light mode?
Current:
New:

I could check on Shiki docs how they do that and I'll circle back to you :)

Fixes deployed on https://66cb2105b3f6bc035a2f6e2f--candid-sprinkles-58d2ce.netlify.app/

Sidebar Navigation is generated on-demand instead of relying on nodejs/node/doc/api/index.md
This means some of the entries are a bit different, although I believe they are fine.

I think that's fine (IIUC we can update the page headings to change the navigation text), except:
Now "Usage and example" is sorted with the other API docs pages, which doesn't make sense. I guess we're also lucky that "About" is sorted first ^^

Consequence of the light mode issue:

Sidebar Navigation is generated on-demand instead of relying on nodejs/node/doc/api/index.md
This means some of the entries are a bit different, although I believe they are fine.

I think that's fine (IIUC we can update the page headings to change the navigation text), except: Now "Usage and example" is sorted with the other API docs pages, which doesn't make sense. I guess we're also lucky that "About" is sorted first ^^

Correct. Although, the reasoning behind this change is to not depend on the existence of an index.md to source from -- this tooling tries to be agnostic as much as possible.
In the future, with the new generator (redesign of API docs) the sidebar will be grouped by module type (Module, Class, Globals, etc) as it was for a short while on https://nodejs.dev

Now "Usage and example" is sorted with the other API docs pages, which doesn't make sense.

Agreed. Although the synopsis page never made sense to me, and even less now with the Node.js Website Learn section. I think that page could be removed IMO.

Every method has a "History" table always

I don't like that, because it seems that the history falls back to "Introduced in: v0.10.0", which is probably wrong in most cases.

Could you give examples?

Forget it, it's actually part of the markdown source code. I just happened to click on three pages that had the same version by chance.

Is it possible to have a light theme for code blocks when the page is in light mode?
Current:
New:

I could check on Shiki docs. I believe they have support for dark/light theme modes.

Fixed.

Consequence of the light mode issue:

Fixed.

Re-deployed on same URL with Codebox fixes. (Including some margin between CJS and Copy Button)

On https://node-api-docs-legacy-preview.netlify.app/async_context, compared with https://nodejs.org/docs/latest/api/async_context.html, the "Other versions" dropdown doesn't show version 16.x.
This page was introduced in v16.4.0.
Now I understand why https://github.com/nodejs/api-docs-tooling/pull/55#issuecomment-2308818808 was bugging me. The first "History" entry is misleading. It is about the introduction of the page in the documentation, not the introduction of the API.

On https://node-api-docs-legacy-preview.netlify.app/async_context, compared with https://nodejs.org/docs/latest/api/async_context.html, the "Other versions" dropdown doesn't show version 16.x.
This page was introduced in v16.4.0.
Now I understand why https://github.com/nodejs/api-docs-tooling/pull/55#issuecomment-2308818808 was bugging me. The first "History" entry is misleading. It is about the introduction of the page in the documentation, not the introduction of the API.

Hmm, no, it is just the semver comparison I'm doing, I should fix that. It should definitely have on the v16 list.

But yes, the introduced_in I believe is when it got introduced in Node, and added, when it got added to the docs?

I think we should not show a history table for introduced_in. This is jsut metadata that was added so we can build the version selector.
Sometime, like in the case of AsyncLocalStorage, we create a new page and move around the documentation. The new page then has an introduced_in version that doesn't correspond to the version that any API was introduced in. It's just the first version in which the page exists.

I think we should not show a history table for introduced_in. This is just metadata that was added so we can build the version selector.

Aha, noted. Making changes.

I've fixed the semver comparison -- but wonder if we should remove "Introduced In" from the "History", because I also added the following to be part of the History table:

This was done, so that the metadata stays in one place and tom simplify it.

I may be wrong, but I think introduced_in is like source_link, a special metadata that has nothing to do with API updates like the other ones in your screenshot.
It is only used once per markdown file, near the top.

I may be wrong, but I think introduced_in is like source_link and type, a special metadata that has nothing to do with API updates like the other ones in your screenshot. It is only used once per markdown file, near the top.

@targos Ive updated the code so that the metadata generation is like on the current API docs. I will update the tests of this PR later.

@nodejs/web-infra @canerakdas one last code review? 🙏
Also, @targos let me know if you find any other inconsistency 🙏

FYI I'merging this for the time being, to unblock @flakey5; Happy to iterate on following PRs. @AugustinMauroy I would love if you could help with some extra tests now that the logic is full I believe you have more material to test! 😃
If you want you can also use the experimental snapshot feature for snapshot tests of html output based on mock markdown sources that mock numerous different pieces of our metadata and content (code blocks, switchable code blocks, all sort of yaml metadata etc)
I think that working on said tests would be awesome for you to get familiar with the nitty gritty of our API docs stuff ;D

@targos let me know if perchance I also missed anything. @flakey5 is working on the json generator (legacy-json and legacy-json-all) to generate matching json output for the current api docs :)

authors: canerakdas cclauss micheleriva ovflowd targos

repo: nodejs/api-docs-tooling


text:
feat: legacy json generator

Description
Legacy json generator aiming to repro 1:1 the existing json format for docs
Still a sizeable amount left to be done, so opening this as a draft.
TODO

[ ] fix type references (i.e. Returns: {boolean} instead of Returns: [](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#Boolean_type))
[x] descriptions
[x] introduced_in doesn't work?
[x] Invalid param "{ lineLengths }" error

Validation
mkdir original && mkdir new

node node/tools/doc/generate.mjs node/doc/api/addons.md --output-directory original/

node api-docs-tooling/bin/cli.mjs -i node/doc/api/addons.md -t legacy-json -o new/

git diff original new

Marking ready for review since there shouldn't be any big changes left, but note this isn't generating a full 1:1 match with the original generator yet. There's still some fixes and testing I need to do

Marking ready for review since there shouldn't be any big changes left, but note this isn't generating a full 1:1 match with the original generator yet. There's still some fixes and testing I need to do

Can you describe some of the notorious changes? Some discrepancies might be fine :)

@flakey5 what is still missing here?

Good news! My local changes are almost 1:1 with the original JSON. Currently, the only thing not 1:1 is the HTML desc options.
While working on this, I noticed that some of the old parser's output (regarding signature parsing) was incorrect, so those parts are also not 1:1, but I don't believe they have to be.
Changes: https://github.com/nodejs/api-docs-tooling/commit/cd62cd85347838844e718aff7e0a34881256d3e8
Diff: https://github.com/nodejs/api-docs-tooling/commit/cd62cd85347838844e718aff7e0a34881256d3e8.diff

I can open a PR into your branch?

That sgtm! Thank you!

I tried to open a PR, but it has a conflict, probably because I rebased.
You can still apply the changes with git apply and the diff file in the comment above
https://git-scm.com/docs/git-apply

I now believe my modifications are as close to 1:1 as possible. I'll do some final checks, but if that's the case, I'll open a second PR stemming off of this one, as I can't merge them due to conflicts.

I hope you don't mind I opened https://github.com/nodejs/api-docs-tooling/pull/142. If you mind, you can use the data from that PR and merge it into this one, but that'll have conflicts, and I don't have the access to do it myself.

Superseded by #142

authors: RedYetiDev flakey5 ovflowd


text:
Format section headings

Just adding some ##'s to the sections to format them and make them linkable.

This has been open for more than 24 hours to give people a chance to comment, and since there are no other objections, I'm going to merge it now.

authors: nebrius williamkapke

repo: nodejs/community-committee


text:
proposal: use hard wrapping for code and soft wrapping for prose

As a newcomer, I find hard wrapping prose to be extremely annoying and time consuming. I'm eager to hear counter arguments, but IMHO, it seems like a rule that just creates extra work for writers and reviewers.

Consistency > convenience.  The rule in core is 80 columns, the documentation should not be an exception.

When you say "core", you're talking about a rule for code files, right? I've never heard of hard-wrapping paragraphs in markdown—is this already being done like this?

On Jan 9, 2016, at 8:12 AM, Ben Noordhuis notifications@github.com wrote:
Consistency > convenience. The rule in core is 80 columns, the documentation should not be an exception.
—
Reply to this email directly or view it on GitHub.

I mean the markdown files here -  https://github.com/nodejs/node/tree/v0.5.4/doc/api - and those are hard-wrapped at 80 columns.  You may find a few lines that are longer if you go looking but those are the exception, not the norm.

I'm +1 on this, it feels like a very arbitrary limit for doc text.

You may find a few lines that are longer if you go looking but those are the exception, not the norm.

While this is true, it demonstrates how inconsistent doc contributions are. Simply put, it's easy to forget to to apply the rule as a writer and check for it as a reviewer. Don't get me wrong, I'm in complete agreement about maintaining consistency of code contributions, no matter if they're in the core or the docs. But I argue that those same rules might not make sense with prose contributions.

I think most of the existing style violations date back from years ago, when reviews were much sloppier than they are today.

I much prefer hard wrapping at 80 since many will be editing the docs in monospace; this should be automatically checked though.

-1 In some cases, the place in which the content is being viewed may not provide soft-wrapping and will instead require horizontal scrolling, which is even more annoying, in my opinion.

In some cases, the place in which the content is being viewed may not provide soft-wrapping and will instead require horizontal scrolling, which is even more annoying, in my opinion.

Any example for such a place @Qard ?

Many command line text editors, github raw view, probably lots of other places.

@Qard command line text editors don't have to wrap if its kept at 80 chars, and github raw view doesn't, either. A number of github tools in fact work quite poorly for text over 90 or a 100 chars, often you can't even see the horizontal scrollbar at the bottom as you stare at the beginning of an unwrapped line.
That's the point of hard wrapping in-source: the author does it, so that all the wide variety of tools that come after do not.
@ryansobol What editor do you use? I'm surprised it won't wrap for you.

And as far as node's source goes: having one rule for markdown and one for all the others is not so handy.

Yea, I think it should be a hard limit for both code and docs for consistency. -1 from me.

Yea, I think it should be a hard limit for both code and docs for consistency.

I agree with this. -1.
What is the procedure in place for coming to consensus on closing (or merging) this PR?

There rather is no process. This can be closed as the majority of contributors is against it.

thanks for the proposal though, Ryan.

authors: Qard RichardLitt benjamingr bnoordhuis chrisdickinson eljefedelrodeodeljefe evanlucas jasonrhodes ryansobol sam-github

repo: nodejs/docs


text:
2.9.1 errors at npm install

Here's the output. Working on 2.8.0
Not sure if I can be of any help let me know if I can provide more info!
node: 8.1.4
npm: 5.0.3
os: macOS 10.12.6
/Users/sommerq/work/lol/node_modules/nan/nan.h:1359:11: error: no type named 'async_context' in namespace 'node'
    node::async_context context;
    ~~~~~~^
/Users/sommerq/work/lol/node_modules/nan/nan.h:1290:60: error: too few arguments to function call, expected 4, have 3
      context = node::EmitAsyncInit(isolate, resource, name);
                ~~~~~~~~~~~~~~~~~~~                        ^
node/v8.1.4/include/node.h:543:13: note: 'EmitAsyncInit' declared here
NODE_EXTERN async_uid EmitAsyncInit(v8::Isolate* isolate,
            ^
In file included from ../src/api/tools/v8Tools.cpp:1:
In file included from ../src/api/tools/v8Tools.h:5:
/Users/sommerq/work/lol/node_modules/nan/nan.h:1306:67: error: too few arguments to function call, expected 4, have 3
      context = node::EmitAsyncInit(isolate, resource, name_string);
                ~~~~~~~~~~~~~~~~~~~                               ^
node/v8.1.4/include/node.h:543:13: note: 'EmitAsyncInit' declared here
NODE_EXTERN async_uid EmitAsyncInit(v8::Isolate* isolate,
            ^
In file included from ../src/api/tools/v8Tools.cpp:1:
In file included from ../src/api/tools/v8Tools.h:5:
/Users/sommerq/work/lol/node_modules/nan/nan.h:1359:25: warning: private field 'context' is not used [-Wunused-private-field]
    node::async_context context;
                        ^

We have the same issue on Mac only

Can confirm it's happening on mac

Duplicate of #235 subscribe to that issue instead.

authors: etherElric kkoopa quentin-sommer

repo: nodejs/nan