Can not access Steam client

As u can see, after using a command to start ets2 with proton it can't access steam. It worked 2 weeks ago.
I use Arch btw

I am affected by the same. I am on Debian so I also tried the PR that checks for steam location.

Same here, using Manjaro

Archlinux, even when starting game in steam with proton you get the same error unless you use the latest 4.11 proton witch just gives bunch of errors if you change your proton version in truckersmp-cli.

Since the last ETS2 and ATS updates truckersmp-cli is very much outdated.
Please try #31 which should work in the meantime until it's merged in master.

that python port gives me an error when i selected the game dir saying that it doesn't find the game

Since the last ETS2 and ATS updates truckersmp-cli is very much outdated.
Please try #31 which should work in the meantime until it's merged in master.

That's still giving the same error

I can reproduce this when Proton 4.2 is used. For some reason Proton 4.2 stopped working recently, and truckersmp-cli users need to switch to Proton 4.11 (-i 1113280).
If you already have Proton 4.2 in our data directory, don't forget to update (-p -u) to 4.11. You can check its version (e.g. cat ~/.local/share/truckersmp-cli/Proton/version). If the version is 4.2 (e.g.<PHONE_NUMBER> proton-4.2-9), it won't work even if Python port is used.
If you already have Proton 4.11 in your Steam installation, you can use -o option and specify the path to Proton 4.11 directory (e.g. -o ~/.local/share/Steam/steamapps/common/Proton 4.11). I usually use the option because Proton 4.11 is already installed in my Steam directory.

Proton 4.11 doesn't work for me. I can launch, the game gets started, but for some reason the mod cannot find the MPmod images. I just get a bunch of errors

Yes, I've ran -u before -s and the images seem to be there

I'd appreciate any pointers as to what I could do about this.

Proton 4.11 doesn't work for me. I can launch, the game gets started, but for some reason the mod cannot find the MPmod images. I just get a bunch of errors

Yes, I've ran -u before -s and the images seem to be there

I'd appreciate any pointers as to what I could do about this.

Exactly the same here. Debian 10 with Proton 4.11.

I can reproduce the "Failed to load texture" errors with Proton 4.11 when D3D11 renderer is used and built-in (Wine/Proton) version of d3dcompiler_47.dll is used.
You can see its details in my comments (563134705 and 564026845).
BTW, if you want to use DXVK, you no longer need to replace DXVK files because Proton 4.11-10 has been released and the bundled DXVK has been "fixed".
I plan to add "rendering backend" related stuff into README.md in PR 31: Draft is available.

When I add the --disable-d3d11 I can get into the game and onto mp servers, just the mouse freezes at times an the only way to fix it is to alt-tab from the game and get back in. I worry this would happen while driving.
Adding -c with -s doesnloads the dll and the game gets started and I get no Failed to load texture ..., but the MP login screen doesn't show.
Thanks for that suggestion @kakurasan, I can go into Arcade so I don't ram people accidentally.

@edvordo

just the mouse freezes at times an the only way to fix it is to alt-tab from the game and get back in. I worry this would happen while driving.

Unfortunately, mouse works for me so far. Thanks for reporting.

Adding -c with -s downloads the dll and the game gets started and I get no Failed to load texture ..., but the MP login screen doesn't show.

Always? Actually, when I tested Steam Overlay support on Proton (added recently, can be disabled by --disable-proton-overlay), the same thing happened once or 2 times. Could you test multiple times and try --disable-proton-overlay option?

Unfortunately, mouse works for me so far. Thanks for reporting.

Yesterday it worked fine without issues for me as well :)

Always? Actually, when I tested Steam Overlay support on Proton (added recently, can be disabled by --disable-proton-overlay), the same thing happened once or 2 times. Could you test multiple times and try --disable-proton-overlay option?

Well, it seems this thing does not work for me at all. It has worked the first time (except for the MP login screen), but any consecutive tries resulted in some crash (game started, but no ui images) or another (the start failed altogether). Sorry, haven't saved any logs, only just realised I should have.
Also I don't seem to have a version of the script which supports the --disable-proton-overlay option, haven't tried updating the script tho, so I'll try again today.

@edvordo Thanks for reporting again, Python port now uses OpenGL by default because it's stable and native DLL is not needed.
If your script is old and doesn't support --disable-proton-overlay yet, you didn't use Steam Overlay (it's enabled by default for now). This means it was not related to Steam Overlay in your case.

After updating the script I can get into the game (ets2/ats) no problem.
One thing tho'. When I try to change the in-game tag color, the game crashes with this in the terminal
wine: Unhandled exception 0x40000015 in thread 33 at address 0x140eb3e1a (thread 0033), starting debugger...
0058:fixme:dbghelp:elf_search_auxv can't find symbol in module
0058:fixme:dbghelp:elf_search_auxv can't find symbol in module
         ^ repeated about 50 times
0058:err:seh:setup_exception stack overflow 288 bytes in thread 0058 eip 000000007bcb2c5f esp<PHONE_NUMBER>1314f0 stack 0x130000-0x131000-0x230000
pid 14572 != 14571, skipping destruction (fork without exec?)

Not sure if it's related to the error or not.
Happens with all combinations of arguments (-c, --disable-proton-overlay).
I'm on Ubuntu 18.04.

When I try to change the in-game tag color, the game crashes with this in the terminal

I can reproduce this crashing but unfortunately I'm not sure how to fix it. I guess this is a bug in Wine/Proton. (But I remember, it was working on Wine 1 year ago)
Workaround:
The tag color can be changed by editing the value of tag_color in config.txt. The default paths (for Proton) are:

ETS2: ~/.local/share/truckersmp-cli/Euro Truck Simulator 2/prefix/pfx/drive_c/users/steamuser/My Documents/ETS2MP/config.txt
ATS: /.local/share/truckersmp-cli/American Truck Simulator/prefix/pfx/drive_c/users/steamuser/My Documents/ATSMP/config.txt

You can pick a color from any of "HTML color picker" web sites and use its decimal value.
For example, if you want to use color #cccc00, specify 0xcccc00 = 13421568 and overwrite the file:
{
   "extra" : {
      ...
   },
   "generals" : {
      ...
      "tag_color" : 13421568,
      ...
   },
   ...

python3 is useful to get decimal value:
$ python3
>>> 0xcccc00
13421568
>>> (Ctrl-d)

Hi,
I'm trying to run Truckers MP on Xubuntu with Proton 4.11.
I used command:
./truckersmp-cli -epvs  -n ggplayerbenx -i 1113280 -o "/home/ramon/.steam/steam/steamapps/common/Proton 4.11/
But I'm always getting this error message: "Application Load Error 3:00000065432".
The original game runs without issues.

Best regards

@Joggingbrot551 You're in the wrong Issue, this is your solution: https://github.com/lhark/truckersmp-cli/issues/41#issuecomment-524785621

@Lucki I'm sorry, I'm new here. Thanks for the hint.
I managed to switch to the new python port and start the game with --singleplayer option.
The Multiplayer creates the following error:

Since this issue was Proton 4.2 related (now Proton 5.0 is used by default), I think we can close this.


Binutils: libctf fails to compile

libctf fails to compile:
  CCLD     libctf-nobfd.la
ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_set' failed: symbol not defined
ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_get' failed: symbol not defined
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [Makefile:687: libctf.la] Error 1
make[3]: *** Waiting for unfinished jobs....
ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_set' failed: symbol not defined
ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_get' failed: symbol not defined
ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_arc_open' failed: symbol not defined
ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_fdopen' failed: symbol not defined
ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_open' failed: symbol not defined
ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen' failed: symbol not defined
ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen_ctfsect' failed: symbol not defined
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [Makefile:684: libctf-nobfd.la] Error 1
make[3]: Leaving directory '/sources/binutils-2.40/build/libctf'
make[2]: *** [Makefile:583: all] Error 2
make[2]: Leaving directory '/sources/binutils-2.40/build/libctf'
make[1]: *** [Makefile:12000: all-libctf] Error 2
make[1]: *** Waiting for unfinished jobs....
make[4]: Leaving directory '/sources/binutils-2.40/build/gas'
make[3]: Leaving directory '/sources/binutils-2.40/build/gas'
make[2]: Leaving directory '/sources/binutils-2.40/build/gas'
make[1]: Leaving directory '/sources/binutils-2.40/build'
make: *** [Makefile:1005: all] Error 2

Current system linker: /usr/bin/ld (symlink to LLD)
Current system compiler: clang (LLVM-17.0.5)

According to bugzilla ticket for binutils:

You are overwriting the ld program in your PATH, which was also configured to use for building.

The problem is installation order: ld is being installed before libctf, but ld uses libctf and thus if libctf is relinked for any reason by the install phase, ld might find itself calling on symbols that aren't in the libctf already present on the system (if it even is there).

if I make /usr/bin/ld unavailable:
mv -v  /usr/bin/ld{,.disabled}

binutuils compiles with no errors.


Tensor mismatch on embedding op using bfloat16 weights.

Running single op embedding test for bfloat16 weights causes tensor mismatch.
However, this can't be reproed on ttnn embedding test.
Here is the ttnn IR of transpose case causing tensor mismatch: test_embedding_bfloat16_data_mismatch_ttnn.txt
Here is the ttnn repro test that passes:
@pytest.mark.parametrize("batch_size", [1])
@pytest.mark.parametrize("sentence_size", [12])
@pytest.mark.parametrize("hidden_embedding_dim", [3200])  # Bert_Num_Cols_768, Llama_Num_Cols
@pytest.mark.parametrize(
    "vocabulary_size", [32000]
)  # Bert_Position_Embeddings_512, Bert_Word_Embeddings_30528, Llama_Position_Embeddings,
@pytest.mark.parametrize("dtype", [ttnn.bfloat16])
@pytest.mark.parametrize("input_mem_config", [ttnn.DRAM_MEMORY_CONFIG])
@pytest.mark.parametrize("output_mem_config", [ttnn.DRAM_MEMORY_CONFIG])
@pytest.mark.parametrize("layout", [ttnn.ROW_MAJOR_LAYOUT])
def test_embedding(
    device,
    batch_size,
    sentence_size,
    hidden_embedding_dim,
    vocabulary_size,
    dtype,
    input_mem_config,
    output_mem_config,
    layout,
):
    torch.manual_seed(1234)

    torch_input_tensor = torch.randint(0, vocabulary_size - 1, (batch_size, sentence_size))
    torch_weights = torch_random((vocabulary_size, hidden_embedding_dim), -0.1, 0.1, dtype=torch.bfloat16)
    torch_output_tensor = torch.nn.functional.embedding(torch_input_tensor, torch_weights)

    input_tensor = ttnn.to_device(ttnn.from_torch(torch_input_tensor), device, memory_config=input_mem_config)
    weights = ttnn.to_device(ttnn.from_torch(torch_weights, dtype=dtype), device, memory_config=input_mem_config)

    output_tensor = ttnn.embedding(input_tensor, weights, memory_config=output_mem_config, layout=layout)
    output_tensor = ttnn.to_torch(output_tensor)

    assert_with_pcc(torch_output_tensor, output_tensor)

Comparing ttnn test and ttnn IR I can't find what is the difference that could cause ttnn test to pass and ttnn IR to fail.
Need help from someone on mlir side @sdjordjevicTT.
Note: Embedding op doesn't support float32 as weights therefore I tried bfloat16 and ran into this.

We have a "new" golden flow that we are developing that I think could be used for unit testing ops like this.  See: https://github.com/tenstorrent/tt-mlir/blob/main/test/python/golden/test_ttir_ops.py
Embedding op + golden func will have to be added to https://github.com/tenstorrent/tt-mlir/blob/main/python/test_infra/ttir_builder.py
Sync with @ctodTT for questions.


idea about k8s crd &  skywalkingcli

Please answer these questions before submitting your issue.

Why do you submit this issue?
[x] Question or discussion
[ ] Bug
[ ] Requirement
[ ] Feature or performance improvement

Question
As we know, k8s is very popular.
when  we are working cli for skywalking. From k8s crd, my idea is that we can use k8s crds to achieve this goal. we can do this directly  when skywalking deployed in  k8s. we also can achieve this by service catalog when skywalking deployed outside of k8s. From the crd we defined, we can do a lot of things.  it is also not conflict with the cli command.

CLI is a stand alone idea. It doesn't need to link to cry.
At the same time, crd is a good goal too. If you want to work on that, @hanahmily and @innerpeacez are the right ones to talk with. We could discuss here or in mail list.

OK. FYI @hanahmily @innerpeacez
I will give my detail idea later here or in mail list. I also need your help.

@hanahmily  seems to have begun to conceive operator. Looking forward to your idea.

SW CRDS & Skywalking
detail idea.
As Skywalking can be deployed on Kubernetes or outside of Kubernetes. Now i am not sure whether we can use union crds to manage both of them. If we don't consider so much, we only use the oap address so we can achieve this. otherwise, we may use service-catalog when Skywalking deployed outside of Kubernetes.
SW crds are easy to defined, same as sw-cli, we also can add other options & parameters, all the same goal they are.
the differences are that sw cli is stand alone tool used in pc directory. but SW crds are working on Kubernetes, which is tool interacted with Kubernetes tightly.
we can use crds to:

list instances like :

kubectl get swinstance -n ${namespace}

list instance endpoints list:

kubectl get swendpoints -n ${namespace}

get single instance

kubectl get swinstance ${name} -n ${namespace}

list service like:

kubectl  get swservice -n ${namespace}

list single service like:

kubectl get swservice ${svc-name} -n ${namespace}

...

Also we can add a lot option, like 'start' & 'end'.
As sw cli needs a configuration. we can add configuration when we install the crds. from describe command we can see the events of conn to oap. like logs to watch the oap server. Also we can control the event what we want know.
FYI @wu-sheng @innerpeacez @hanahmily

Do you know watching this subproject? https://github.com/apache/skywalking-cli
Could you define what is the difference between these two?

Yes, I am watching this subproject. @wu-sheng
But CRD is another choice as cli does, i think the crds tool is familiar with Kubernetes users.
Another way If we don't need another tool, As mentioned above, we can do our operator to manage skywalking on k8s.

In my mind, the operator should focus on the operation side, rather than like CLI to just query and interact with SkyWalking inside APIs. And, you need to notice, there is no operation related GraphQL API today. If you want to do, you need a more detailed document.
Also, as the CLI project has not released yet, and @innerpeacez is working on the helm release project, also Istio CI is WIP, which has a much higher priority.
@wayilau Do you consider about the workload? Do you want to do this alone? Or having other contributors to work with you? Normally, the subproject requires at least one committer to lead, and the PMC to watch, otherwise, the contributor team may break the Apache rules.

But CRD is another choice as cli does, i think the crds tool is familiar with Kubernetes users.
Another way If we don't need another tool, As mentioned above, we can do our operator to manage skywalking on k8s.

I think skywalking-operator is a good way to manage skywalking deployment. And the skywalking-operator can also have a corresponding chart.After the CLI, I don't think SW need to use CRD to do some queries.Because the CLI should eventually be included in the oap image.

Because the CLI should eventually be included in the oap image.

CLI even could has its own image.

I think skywalking-operator is a good way to manage skywalking deployment.

This is the CRD in my mind.

CLI even could has its own image.

Yes, because swctl config has been designed

Yes, they are all crd, but do different jobs. operator used to manage skywalking cluster status. but crds could do things like swcli.
Another question, does cli could sperate the cluster dynamicly when i deployed multiple Skywalking cluster?  or we need to give the oap url for every query?

Another question, does cli could sperate the cluster dynamicly when i deployed multiple Skywalking cluster? or we need to give the oap url for every query?

Today, there is no alias name or cluster name config. But this could be added. CLI is a new project, even 0.1.0 isn't released yet.

Thanks for your proposal @wayilau. It's a great idea to operate SW backend(OAP/UI) in both VM and Kubernetes with the same standard.
I want to pick up CRDs as our final solution of CLI interaction, which is an alternative to Web UI. Because it's the future, and I desire to follow it closely. But the concern is also the "future", well, it didn't come though. Most developers/operators aren't familiar with Kubernetes, not to CRDs.
Another reason is SkyWalking is being used by operators in most cases, this user group prefer an easier way to figure out their jobs. A K8S way will bring much more complex and chaos to them.
So my suggestion is hiding K8S and VM behind SWCLI, then users don't need to care about on which platform they're working. It is not some new idea, and some successful project has followed this way, for instance, Istio.
And for CRDs, I would like to put it into operator, controller, and sidecar injection. The Kubernetes community of SkyWalking focus on making SkyWalking in Kubernetes to work better than other platforms instead of replacing them, which empower the Kubernetes to attract more and more users to work on it.

Thanks for your reply. @hanahmily
Now, it's time for swcli. I want join you when it's time for operator or crds in the future.
Yes, you are right, we just want to empower,  not replacing.  And Is there an repo for Skywalking Operator  ?

Is there an repo for Skywalking Operator ?

Not yet. We usually require you to propose the detailed design, and ask for review that in the mail list. If other committers join, then we could open a repo for that.

I see. @wu-sheng
BTW, @hanahmily  have you begun to do this already ? If you have not, I will .

I'm already working on it. It's arch of Kubernetes native, operator is one
of its components though. We can review it next week(I hope).
Then everyone interested in it would pick up a piece to detail and polish
it.
Alan Lau<EMAIL_ADDRESS>于2019年11月20日周三 上午9:17写道：

I see. @wu-sheng https://github.com/wu-sheng
BTW, @hanahmily https://github.com/hanahmily have you begun to do this
already ? If you have not, I will .
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/skywalking/issues/3889?email_source=notifications&email_token=AAO6UWOFI2NFOFHRSDA3IFDQUSF4FA5CNFSM4JO4YKD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEQLEDI#issuecomment-555790861,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAO6UWLR3MJJAZ77ILAPNVLQUSF4FANCNFSM4JO4YKDQ
.

--
Gao Hongtao
Apache SkyWalking & ShardingSphere

@hanahmily Notice, @innerpeacez has changed the skywalking-k8s repo to release mode, so basically, in the master branch, it only includes 6.5.0 k8s helm. Are you going to need another repo to host this? Is there a separated release process?

@hanahmily
OK, I'm waiting for your good news in the mail list.

Absolutely. I'm also think how to name this repo. And the deployment arch
will follow micro service/multiple processes way since Kubernetes seems
expert at handling it.
On Wed, Nov 20, 2019, 10:01 AM 吴晟 Wu Sheng<EMAIL_ADDRESS>wrote:

@hanahmily https://github.com/hanahmily Notice, @innerpeacez
https://github.com/innerpeacez has changed the skywalking-k8s repo to
release mode, so basically, in the master branch, it only includes 6.5.0
k8s helm. Are you going to need another repo to host this? Is there a
separated release process?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/skywalking/issues/3889?email_source=notifications&email_token=AAO6UWOZGFLCWJTZPMGX2VLQUSK75A5CNFSM4JO4YKD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEQNSHA#issuecomment-555800860,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAO6UWJR7V7R655PT4K53ZLQUSK75ANCNFSM4JO4YKDQ
.

OK, as it is planned to be a separated repo, it is good for me.

OK, I'm waiting for your good news in the mail list.

The same to me

@wayilau maybe you interested in https://docs.google.com/document/d/1tPv3ppjNEMa5frX2qRzUXVNky4U4TuTr8qzaiU2wpso/edit?usp=sharing

Yes,  I am reading the doc. @hanahmily

CLI subproject has been created and released for a long time.


Adjust timing

Central repo now takes more time, since we go in detail through PRs but the distributed section will now take a lot less time since many concepts are revisited.

Centralized exercise slot took 9 - 10:20.


Add documents for MkDocs website integration

This pull request provides the documents needed to deploy a documentation website. We hope to implement automated API documentation in the future and are looking for further insight into how we may do this.

Inside of this PR you are trying to push multiple .DS_Store files. Please delete these, they should never be pushed to the main branch. Once those two files are removed we can look more in depth at the content of this PR. Thanks!

Thanks for reviewing this PR @burgess01. In addition to removing these files, I will add that we should try to avoid committing the files generated by MKdocs and instead include steps in GitHub actions to do that automatically after changes are pushed to main branch

Suggested edit:
diff --git a/Sheetshuttle_Doc/docs/index.md b/Sheetshuttle_Doc/docs/index.md
new file mode 100644
index 0000000..1b6363b
--- /dev/null
+++ b/Sheetshuttle_Doc/docs/index.md
@@ -0,0 +1,19 @@
+# my
+
+#### Welcome to SheetShuttle API Reference Documentation
+
+For full documentation visit [mkdocs.org](https://www.mkdocs.org).
+
+## Commands
+
+* `mkdocs new [dir-name]` - Create a new project.
+* `mkdocs serve` - Start the live-reloading docs server.
+* `mkdocs build` - Build the documentation site.
+* `mkdocs -h` - Print help message and exit.
+
+## Project layout
+
+    mkdocs.yml    # The configuration file.
+    docs/ls
+        index.md  # The documentation homepage.
+        ...       # Other markdown pages, images and other files.
diff --git a/Sheetshuttle_Doc/mkdocs.yml b/Sheetshuttle_Doc/mkdocs.yml
new file mode 100644
index 0000000..d248e7e
--- /dev/null
+++ b/Sheetshuttle_Doc/mkdocs.yml
@@ -0,0 +1,6 @@
+site_name: Sheet~shuttle API Reference Documentation
+site url: https://SheetShuttle.github.io
+nav:
+    - Home: index.md
+
+


Add a metric for number of partitions held

ref #1126
Signed-off-by: Prithvi Raj<EMAIL_ADDRESS>

@vprithvi saying "ref #1126" does not auto-close the ticket on merge, please use Fixes or Resolves.


feat(server): migrate version in info section rule to use context object to support OpenAPI 3

Related to #714

Codecov Report

Merging #828 into master will decrease coverage by 0.05%.
The diff coverage is 83.33%.

@@             Coverage Diff              @@
##             master     #828      +/-   ##
============================================
- Coverage     84.93%   84.88%   -0.06%
+ Complexity      890      889       -1
============================================
  Files           170      170
  Lines          2536     2534       -2
  Branches        386      385       -1
============================================
- Hits           2154     2151       -3
  Misses          152      152
- Partials        230      231       +1

Impacted Files
Coverage Δ
Complexity Δ

...src/main/java/de/zalando/zally/util/PatternUtil.kt
96.15% <ø> (-0.28%)
16 <0> (-1)

...ndo/zally/rule/zalando/VersionInInfoSectionRule.kt
87.5% <83.33%> (-12.5%)
6 <5> (ø)

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 9643b42...47848f7. Read the comment docs.

@tkrop @ddufourboivin-zalando please review

:+1:

:+1:


[Hub Generated] Review request for Microsoft.Insights to add version stable/2022-06-15

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM API Information (Control Plane)
Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[x] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

PR on hold until ARM backend is ready with the new version

Please remove the "ARMChangesRequested" label if you want the API reviewer to look at this review again

Please remove the "ARMChangesRequested" label if you want the API reviewer to look at this review again

Removed. Necessary ARM manifest changes have been deployed.

@grlima do you need this PR to be reviewed again? don't see many updates other than the original removal of operations API

@grlima do you need this PR to be reviewed again? don't see many updates other than the original removal of operations API

Hi @jorgecotillo - I pretty much just need the PR to be merged at this point. It has been reviewed but it was on hold until corresponding ARM manifest changes were deployed. It's good to go now from my perspective. Thank you!

Work the PR assignee then to get this PR merged

@tadelesh to review GO SDK breaking change

/azp run

@tadelesh to review GO SDK breaking change

Approved for Go breaking which come from code generator.


Adds full nonblocking readout support (Multiarm part 4)

Additionally this PR adds fix for shutting down the hardware interface. (Calling deactivate at destruction)
split up of #567

I just rebased this PR onto #596 otherwise there will be merge conflicts


Add ProgressDialogDoWorkEventArgs extension (non-breaking)

PoC for https://github.com/ookii-dialogs/ookii-dialogs-wpf/pull/54

Pros:

Allow a CancellationToken to flow through the DoWork event handler
Non-breaking change. Could be released with v3.2.0

Cons:

User needs to cast  DoWorkEventArgs to ProgressDialogDoWorkEventArgs in order to access the CancellationToken

Relates to #53

Merging this as-is following discussion on https://github.com/ookii-dialogs/ookii-dialogs-wpf/pull/54#discussion_r702780552
@vpenades might need to make some changes to the code introduced here.


Doesn't support different services than anope.

NickServ authentication check through services like atheme doesn't work for those services work differently. NickServ authentication by the bot is currently "obligatory" and should be done if and only if a password is given on startup.
Support for other services should be implemented and messed with by flags used on startup.

Update on this, Atheme uses ACC, which produces the same output as STATUS in anope.
From the atheme wiki:
ACC

ACC returns parsable information about a user's login status. Note that on many networks, /whois shows similar information faster and more reliably. The answer is in the form <nick> ACC <digit>:
0 - account or user does not exist
1 - account exists but user is not logged in
2 - user is not logged in but recognized (see ACCESS)
3 - user is logged in

If the account is omitted the user's nick is used. Account * means the account the user is logged in with.

Syntax: ACC
Syntax: ACC <nick>
Syntax: ACC <nick> <account>
Syntax: ACC <nick> *

Example:
/msg NickServ ACC jilles *

Thanks a bunch for this, @mikotohe2. The bot supports atheme and anope. Other services will have to be worked on as needed.


开启错误

oneplus3:/ $ sh /data/data/me.piebridge.brevent/brevent.sh
rm: /data/local/tmp/brevent: Permission denied
WARNING: /data/local/tmp is not writalbe
ERROR: cannot be run as u0_a137(10137).
1|oneplus3:/ $ su
oneplus3:/ # sh /data/data/me.piebridge.brevent/brevent.sh
WARNING: run as root is experimental!!!
checking...brevent_server started, pid: 30810
checking for stable..quited
please report bug to https://github.com/brevent/Brevent/issues with log below--- crash start ---

logcat -b crash -t '07-17 08:31:53.000' -d
--- crash end ---
--- brevent start ---
logcat -b main -t '07-17 08:31:53.000' -d -s BreventLoader BreventServer
07-17 08:31:54.187 30799 30799 D BreventLoader: loader path: /data/app/me.piebridge.brevent-1/base.apk
07-17 08:31:54.553 30810 30810 D BreventServer: get service: package
07-17 08:31:54.562 30810 30810 I BreventServer: starting Brevent Server 1.3.407-17 08:31:54.569 30810 30810 D BreventServer: get service: package
07-17 08:31:54.571 30810 30810 I BreventServer: brevent user: 0, uid: 0
07-17 08:31:54.572 30810 30810 I BreventServer: brevent data directory: /data/user_de/0/com.android.shell
07-17 08:31:54.585 30810 30810 I BreventServer: loading brevent list
07-17 08:31:54.585 30810 30810 I BreventServer: loading brevent conf
07-17 08:31:54.588 30810 30810 D BreventServer: get service: appwidget
07-17 08:31:54.596 30810 30810 D BreventServer: get service: usagestats
07-17 08:31:55.483 30810 30821 I BreventServer: Brevent Event, now:<PHONE_NUMBER>
07-17 08:31:55.484 30810 30810 D BreventServer: check and brevent
07-17 08:31:55.486 30810 30810 D BreventServer: get service: notification
07-17 08:31:55.493 30810 30821 I BreventServer: system_server: 1164, now:<PHONE_NUMBER>
07-17 08:31:55.636 30810 30810 D BreventServer: get service: activity
07-17 08:31:55.668 30810 30810 D BreventServer: get service: alarm
07-17 08:31:55.669 30810 30810 D BreventServer: get service: wallpaper
07-17 08:31:55.700 30810 30810 D BreventServer: get service: batterystats
07-17 08:31:55.808 30810 30810 D BreventServer: check again in 3600s
07-17 08:31:55.809 30810 30810 D BreventServer: check and brevent, took 324ms07-17 08:31:55.811 30810 30810 I BreventServer: charging: false
07-17 08:31:55.811 30810 30810 I BreventServer: support standby: true
07-17 08:31:55.811 30810 30810 I BreventServer: support stopped: true
07-17 08:31:55.817 30810 30810 E BreventServer: Can't be run as root, please open Brevent
07-17 08:31:55.839 30799 30799 E BreventLoader: worker 30810 exited with status 1
07-17 08:31:55.839 30799 30799 D BreventLoader: signal arrived, update: 0
07-17 08:31:55.841 30795 30795 D BreventLoader: worker 30799 exited with status 0
--- brevent end ---
cannot listen port, please report bug to https://github.com/brevent/Brevent/issues with log above
1|oneplus3:/ #

07-17 08:31:55.817 30810 30810 E BreventServer: Can't be run as root, please open Brevent

按照向导中的方法进行root开启


NDRS-557: introduce basic libp2p network component

Only the second commit of this PR needs to be reviewed.  This first commit comprises https://github.com/CasperLabs/casper-node/pull/548.
The commit sees a new network component added which is enabled for now by setting the env var CASPER_ENABLE_LIBP2P.  The new component runs alongside the current small_network one.
For now, the new network component only starts listening (it uses the same address as specified for the small_network with 100 added to the port number) and will try to connect to any peers specified in network.known_addresses.
On connecting to a peer, they then continuously ping each other every 20 seconds.

bors r+


macOS: setup.py fails when brew is not in PATH

setup.py fails when brew is not in PATH (from nixpkgs darwin build: https://hydra.nixos.org/build/157649245/nixlog/4)
Traceback (most recent call last):
  File "/private/tmp/nix-build-python3.9-pdftotext-2.2.1.drv-0/pdftotext-2.2.1/nix_run_setup", line 8, in <module>
    exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\\r\\n', '\\n'), __file__, 'exec'))
  File "setup.py", line 66, in <module>
    brew_include, brew_library = brew_poppler_include()
  File "setup.py", line 25, in brew_poppler_include
    brew_list = subprocess.check_output(["brew", "list", "poppler"])
  File "/nix/store/x0fw0l4d6zwgfdwbpp23iwhm3c6a1hh3-python3-3.9.6/lib/python3.9/subprocess.py", line 424, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/nix/store/x0fw0l4d6zwgfdwbpp23iwhm3c6a1hh3-python3-3.9.6/lib/python3.9/subprocess.py", line 505, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/nix/store/x0fw0l4d6zwgfdwbpp23iwhm3c6a1hh3-python3-3.9.6/lib/python3.9/subprocess.py", line 951, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/nix/store/x0fw0l4d6zwgfdwbpp23iwhm3c6a1hh3-python3-3.9.6/lib/python3.9/subprocess.py", line 1821, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'brew'

Fixed in version 2.2.2. Thanks!


Changing the language of communication with the Search Service

Please provide us with the following information:

This issue is for a: (mark with an x)
- [ ] bug report -> please search issues before submitting
- [] feature request
- [X] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

run the solution

Any log messages given by the failure

Expected/desired behavior

user prompts are not translated to english

OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

azd version?

run azd version and copy paste here.

Versions

Mention any other details that might be useful

Hi, where in the code could I change the "language of communication" with the Search Service? My queries/prompts are in czech, but as I see, the query gets translated to english for the Search Service - this sadly produces hallucatinations.

Thanks in advance for your response!

Hi @pamelafox ! This helped, thanks a lot! I actually had the prompt in Czech, but had to apply a bit of prompt engineering to tell it the instruction the right way. :D


Variables for fonts

I'm starting a new project with Picnic. Seems a very good framework for my needs. Minimalistic but not too bare-bone. So I'm starting to setup the default variables.
There are no variables for font settings. So there is no way to set my own font except some nasty overwrite with a more specific class or id or modifying picnic itself, which IMHO defies the goal of having a framework.
Is this done for a reason or am I missing something?

They are defined here: https://github.com/franciscop/picnic/blob/master/src/plugins/generic/_plugin.scss
So just changing the font of the body should do the trick. In other places (where needed) they follow the font: inherit; as much as possible, so they should be taken properly.

Sure but then I'll be modifying the framework itself and not making use overwriting options. Why then defining variables in the first place? Aren't they for the most common things you want to change without hacking the framework itself?

But you are making use of the best overwriting option in CSS and part of it's core characteristic: cascading.
Variables are defined so you can chance things in many places within a single place. It is all about repetition:

To change the font in every place you have to change it once on the body.
To change the border-radius everywhere you have to change it in a variable. Same with colors, transitions, etc.

This is because border-radius will be applied independently in many places, and trying to change it manually in CSS would lead you into many small overwrites. These properties have variables to avoid this. However with some properties you can just overwrite them once and it will work properly.
The framework is designed for this use-case as much as possible. Font size will lead to automatically adjusted paddings in buttons (with em ), for instance.

If it wasn't clear (sorry), I mean to overwrite the body font in your own CSS, not to clone the whole repo and change it inside Picnic's code:
<link src="picnic.css" ...>
<style>
  body {
    font-fanily: ...;
  }
</style>


feat(*):update dtype in signature to dType

What type of PR is this?
/kind feature
/area model
/area serving

What this PR does / why we need it:
Which issue(s) this PR is related to (optional, link to 3rd issue(s)):
Fixes #
Reference to #

Special notes for your reviewer:
/cc @simon-cj @songzhiwei7

Does this PR introduce a user-facing change?:

update dtype -> dType in signature

/lgtm

/lgtm


fix(runtime-core): allow using getCurrentInstance with multiple builds of vue

Context: Changes in this pull request, are an attempt to fix the root cause of a long-lasting issue we had with Nuxt 3, composition API, and especially during the server-side-rendering phase but it can be related to any Vue SSR setup with the same situation. There is no single issue or reproduction I could refer to (1) but trying to explain as best as I can.
Vue 3 uses an internal singleton variable for CAPI that temporarily keeps the Vue instance while rendering components. it is used internally and can be accessed using getCurrentInstance() from other compostables.
This works perfectly fine as long as both user and all libraries import getCurrentInstance() from exactly the same file && the same evaluated instance. If for any reason they (or an intermediate composable) is not, the whole CAPI API will be broken with untraceable errors such as Server rendering context not provided or Cannot read property something of undefined.
There could be many reasons for this situation to happen:

Package managers hoist and install different versions of Vue for libraries, frameworks and user
Same version of Vue from different node_modules directories (when npm linking)
Same version of Vue with different builds (Vite picks esm-bundler, externalized dependencies pick cjs build)
Same version and build of Vue with different instances (One can be inlined by bundler and one externalized)
Vue and @vue/runtime-core (however it didn't happen, but I noticed vue package also has a standalone build of runtime-core)

The proposed changes fix this issue by storing temporary variables in a context stored in globalThis instead of local scope. This allows to getCurrentInstance() to work no matter from which version/build/format or instance as long as being in the same tick, the instance is available. It doesn't add perf overhead and wouldn't break concurrency constraints too since we unset it with the same strategy as before. An additional fix I made was is to use Symbol.for for ssrContext injection, deduplicating it using the global Symbol registry otherwise, two Symbol instances differ. (2)

Updates:

Using shared current instance is opt-in with internal API globalThis.__vue__. When it is set, vue uses this object over package local instance.

Notes:
(1) Linked issues: There were many older issues we solved with different methods in Nuxt 3 before. I finally made and verified it in order to fix the root cause of https://github.com/nuxt/nuxt/issues/18563. If needed, happy will list more relevant issues.
(2) Fixes to the core of CAPI for this, are impossible to be done at the userland or framework level. However, if for any reason you are against using globalThis, we can make it opt-in by optionally using globalThis if set by the framework and then falling back to a local variable.

My concern with this is that it doesn't really address the the fundamental issue, since currentInstance isn't the only global singleton that the Vue runtime relies on. Some other examples include the reactivity tracking maps and built-in VNode type symbols like Text or Fragment. Only addressing currentInstance won't fix other similar issues caused by multiple copies of Vue being used.
Also, making it work with multiple copies mask the underlying problem, and can lead to users unknowingly ship multiple copies of Vue in the final bundler, which should be avoided.
So maybe a better direction for this is to introduce something that makes it easier to identify such cases.

Thanks for quick feedback @yyx990803

since currentInstance isn't the only global singleton that the Vue runtime relies on. Some other examples include the reactivity tracking maps and built-in VNode type symbols like Text or Fragment.

Indeed. But at least in Nuxt projects, currentInstance and SSR instance were major case of issues. (We might also extend this fix to other places if you think worth)

Also, making it work with multiple copies mask the underlying problem

I agree. However, this issue is mostly for development time because of externals and other factors being involved, we cannot optimize the Vue version. Rollup/Vite/Nitropack already deduplicate Vue version for production builds.

can lead to users unknowingly ship multiple copies of Vue in the final bundler, which should be avoided.

What do you think to explicitly throw an error in production builds of Vue dist if we detect such situation?

So maybe a better direction for this is to introduce something that makes it easier to identify such cases.

I agree ideally that would be the best. However in practice, solving many of those hoisting issues and dealing with them in dev, has only negative DX issues and is sometimes not easy to solve. I can make this behavior opt-in so that we apply it only for Nuxt.

Update: I have updated the tests. Also made this change completely opt-in via a private API. When globalThis.__vue_ctx__ is set, vue reuses the context over package-scoped context.

Can you check if f597dc69 + 8d2d5bf4 achieve the same end result in your reproductions?
I wanted to centralize the logic so that the rest of the codebase can forget about this constraint.

Using warning and global setters, i think we will have less issues however:

We probably need to avoid showing this warning when same version of Vue is from different locations
This warning can be false-positive only if getCurrentInstance is different
We probably also need to use Symbol.for for SSR injection key (this was second fix)

This feature has already been implemented in https://github.com/vuejs/core/commit/8d2d5bf48a24dab44e5b03cb8fa0c5faa4b696e3. Thank you for your contribution!


Implemented ASCII fast path on writeUtf8 to speedup encoding of ASCII prefixed char sequences

Motivation:
UTF-8 char sequences can be mostly or totally ASCII prefixed hence handling this case better would benefit the common case.
Modifications:
The original writeUtf8 is modified handling the ASCII fast path at first while falling back to the full-fat UTF-8 when the first not ASCII char is met.
Result:
Benchmarks shows an improvement for mostly ASCII char sequences with a negligible impact on full UTF-8 encoding.

The benchmark results show interesting results
on 4.1:
Benchmark                               Mode  Cnt         Score        Error  Units
ByteBufUtilBenchmark.writeAscii        thrpt   20  13933422.759 ± 126652.679  ops/s
ByteBufUtilBenchmark.writeAsciiAsUtf8  thrpt   20  12456281.779 ± 279760.847  ops/s
ByteBufUtilBenchmark.writeFullUtf8     thrpt   20  34670225.086 ± 384342.511  ops/s
ByteBufUtilBenchmark.writeUtf8         thrpt   20   4614812.430 ±  60556.670  ops/s

With this PR:

Benchmark                               Mode  Cnt         Score        Error  Units
ByteBufUtilBenchmark.writeAscii        thrpt   20  13899817.109 ± 108070.691  ops/s
ByteBufUtilBenchmark.writeAsciiAsUtf8  thrpt   20  13828353.123 ± 131895.610  ops/s
ByteBufUtilBenchmark.writeFullUtf8     thrpt   20  36728458.579 ± 304574.246  ops/s
ByteBufUtilBenchmark.writeUtf8         thrpt   20   4709120.778 ±  36624.084  ops/s

Now the fast path of UTF-8 encoding on ASCII encoded char sequences has the same performance of the ASCII one with negligible impacts on the original performances (the benchmark show some improvement, but is in the error marging TBH).

I wasn't able to reproduce the 10% performance increase.
Previous

Benchmark                               Mode  Cnt         Score        Error  Units
ByteBufUtilBenchmark.writeAsciiAsUtf8  thrpt<PHONE_NUMBER>1.016 ± 156616.125  ops/s

Previous with final keyword on c variable

Benchmark                               Mode  Cnt         Score        Error  Units
ByteBufUtilBenchmark.writeAsciiAsUtf8  thrpt<PHONE_NUMBER>8.480 ± 194586.268  ops/s
ByteBufUtilBenchmark.writeFullUtf8     thrpt<PHONE_NUMBER>5.322 ± 274635.697  ops/s
ByteBufUtilBenchmark.writeUtf8         thrpt<PHONE_NUMBER>.899 ±  29517.474  ops/s

Optimised (this PR with modified benchmark to return int / ByteBuf)

Benchmark                               Mode  Cnt         Score        Error  Units
ByteBufUtilBenchmark.writeAsciiAsUtf8  thrpt<PHONE_NUMBER>3.723 ± 236834.007  ops/s
ByteBufUtilBenchmark.writeFullUtf8     thrpt<PHONE_NUMBER>8.826 ± 830499.204  ops/s
ByteBufUtilBenchmark.writeUtf8         thrpt<PHONE_NUMBER>.956 ±  96279.510  ops/s

@johnou I will retry with more forks too! Did you have the writeAsciiString results too of the same benchmarks runs? That's the real baseline for any improvements IMO
It would be great to have this same benchmark using 3 different lengths (short/medium|UUID-like|long) too

@johnou I've modified the benchmark with variable sized strings: these are the results with the new PR:
Benchmark                                    (stringLength)   Mode  Cnt         Score         Error  Units
ByteBufUtilBenchmark.writeAsciiString                     8  thrpt   20  72747959.436 ± 3591213.261  ops/s
ByteBufUtilBenchmark.writeAsciiString                   128  thrpt   20  12181677.898 ±   34360.577  ops/s
ByteBufUtilBenchmark.writeAsciiString                  1024  thrpt   20   1691206.827 ±   15469.176  ops/s
ByteBufUtilBenchmark.writeAsciiStringAsUtf8               8  thrpt   20  77754528.549 ±  763594.754  ops/s
ByteBufUtilBenchmark.writeAsciiStringAsUtf8             128  thrpt   20  11223187.865 ±  119018.589  ops/s
ByteBufUtilBenchmark.writeAsciiStringAsUtf8            1024  thrpt   20   1455686.602 ±   17138.850  ops/s
ByteBufUtilBenchmark.writeFullUtf8String                  8  thrpt   20  47160853.218 ±  553114.475  ops/s
ByteBufUtilBenchmark.writeFullUtf8String                128  thrpt   20   5311433.950 ±   73524.882  ops/s
ByteBufUtilBenchmark.writeFullUtf8String               1024  thrpt   20    643214.613 ±   29458.033  ops/s
ByteBufUtilBenchmark.writeUtf8String                      8  thrpt   20  78539446.469 ±  846538.650  ops/s
ByteBufUtilBenchmark.writeUtf8String                    128  thrpt   20   4804244.447 ±  162650.026  ops/s
ByteBufUtilBenchmark.writeUtf8String                   1024  thrpt   20    677367.937 ±   15832.357  ops/s

@johnou While these ones are with the original writeUtf8:
Benchmark                                    (stringLength)   Mode  Cnt         Score         Error  Units
ByteBufUtilBenchmark.writeAsciiString                     8  thrpt   20  74749874.645 ± 2671759.272  ops/s
ByteBufUtilBenchmark.writeAsciiString                   128  thrpt   20  11459849.272 ±  419816.311  ops/s
ByteBufUtilBenchmark.writeAsciiString                  1024  thrpt   20   1679524.664 ±   38366.004  ops/s
ByteBufUtilBenchmark.writeAsciiStringAsUtf8               8  thrpt   20  72946077.597 ±  480300.273  ops/s
ByteBufUtilBenchmark.writeAsciiStringAsUtf8             128  thrpt   20  13295598.495 ±  124586.538  ops/s
ByteBufUtilBenchmark.writeAsciiStringAsUtf8            1024  thrpt   20   1809970.123 ±   22364.444  ops/s
ByteBufUtilBenchmark.writeFullUtf8String                  8  thrpt   20  50472646.901 ±  359376.878  ops/s
ByteBufUtilBenchmark.writeFullUtf8String                128  thrpt   20   5427233.121 ±   26526.761  ops/s
ByteBufUtilBenchmark.writeFullUtf8String               1024  thrpt   20    701231.707 ±    5607.669  ops/s
ByteBufUtilBenchmark.writeUtf8String                      8  thrpt   20  72335423.290 ±  729530.583  ops/s
ByteBufUtilBenchmark.writeUtf8String                    128  thrpt   20   4599448.039 ±   95454.556  ops/s
ByteBufUtilBenchmark.writeUtf8String                   1024  thrpt   20    683134.535 ±    8943.448  ops/s

@johnou In conclusion: as you have noticed it doesn't seems a clear step forward compared to the original implementation and although it shows some improvements there are regressions as well: what I'm not 100% is why there is such great variance in the results while using the same implementation too, wdyt?
Maybe it could worth to try with more forks?

Not sure if it's worth the trouble, if the method can be inlined and there is no excess object allocation or bounds checking I would leave it as is.

@johnou Agree and I'm pretty surprised too: a similar optimization is contained into the StandardCharset encoders of the OpenJDK too and I'm just guessing why they have use it and which scenarios it was meant to favour...
Re this PR i can close it but probably will push a new ones with the changes in the JMH benchmark, makes sense?

@franz1981 yeah I think we should close this one and just fix the benchmarks :)


Add new icons and purple icon type

💬 Description
Just some icons and a new icon type class
✅ Checklist

[ ] Tests written
[ ] Browser tested
[ ] Added to documentation
[ ] Added to storybook

 Fetch files data properly using existing FetchByFiles


4.g Number of User Stories

A user should be able to see the overall number of user stories.
A user should be able to see the number of completed stories.
A user should be able to see the number of uncompleted user stories.
A user should be able to see the number of deleted user stories.
A user should be able to see the number of user stories, that are currently work in progress.
Priority: LOW
Estimation: 1

numbers are shown at the navigation menu (header) of the user story page


couldn't add swiftCSV as dependency in podspec

Hi,
I am trying to create a pod file which uses the swiftCSV so I need to add it as dependency.
I added the line:
s.dependency 'SwiftCSV'
And the result:
** BUILD FAILED **

The following build commands failed:
	CompileSwiftSources normal i386 com.apple.xcode.tools.swift.compiler
	CompileSwift normal i386
(2 failures)
 -> ReportySdk (0.2.70)
    - ERROR | [iOS] xcodebuild: Returned an unsuccessful exit code.
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/CSV.swift:45:83: error: 'NSStringEncoding' has been renamed to 'String.Encoding'
    - NOTE  | xcodebuild:  Foundation.NSStringEncoding:2:18: note: 'NSStringEncoding' has been explicitly marked unavailable here
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/CSV.swift:57:81: error: 'NSStringEncoding' has been renamed to 'String.Encoding'
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/CSV.swift:64:45: error: 'NSStringEncoding' has been renamed to 'String.Encoding'
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/CSV.swift:33:27: error: single argument function types require parentheses
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/Parser.swift:12:34: error: single argument function types require parentheses
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/ParserHelpers.swift:43:41: error: single argument function types require parentheses
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/CSV.swift:36:25: error: missing argument label 'block:' in call
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/Description.swift:13:27: error: 'joinWithSeparator' has been renamed to 'joined(separator:)'
    - NOTE  | xcodebuild:  Swift.Sequence:3:17: note: 'joinWithSeparator' has been explicitly marked unavailable here
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/Description.swift:16:37: error: 'joinWithSeparator' has been renamed to 'joined(separator:)'
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/Description.swift:17:11: error: 'joinWithSeparator' has been renamed to 'joined(separator:)'
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/Parser.swift:45:41: error: missing argument label 'char:' in call
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/Parser.swift:69:45: error: missing argument label 'char:' in call
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/Parser.swift:89:45: error: missing argument label 'char:' in call
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/Parser.swift:115:41: error: 'successor()' is unavailable: To get the next index call 'index(after:)' on the CharacterView instance that produced the index.
    - NOTE  | xcodebuild:  Swift.String.CharacterView.Index:3:17: note: 'successor()' has been explicitly marked unavailable here
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/Parser.swift:30:17: error: closure use of non-escaping parameter 'block' may allow it to escape
    - NOTE  | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/Parser.swift:12:27: note: parameter 'block' is implicitly non-escaping
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/ParserHelpers.swift:30:40: error: single argument function types require parentheses
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/ParserHelpers.swift:31:39: error: 'enumerate()' has been renamed to 'enumerated()'
    - NOTE  | [iOS] xcodebuild:  Swift.Sequence:3:17: note: 'enumerate()' has been explicitly marked unavailable here
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/ParserHelpers.swift:44:30: error: missing argument label 'block:' in call
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/String+Lines.swift:14:27: error: 'successor()' is unavailable: To get the next index call 'index(after:)' on the CharacterView instance that produced the index.
    - ERROR | [iOS] xcodebuild:  SwiftCSV/SwiftCSV/String+Lines.swift:16:16: error: use of unresolved identifier 'substringToIndex'

Analyzed 1 podspec.

[!] The spec did not pass validation, due to 21 errors.
[!] The validator for Swift projects uses Swift 3.0 by default, if you are using a different version of swift you can use a `.swift-version` file to set the version for your Pod. For example to use Swift 2.3, run:
    `echo "2.3" > .swift-version`.

Please advise.

I guess that is because this library does not support Swift 3.
I recommend you https://github.com/masteage/SwiftCSV/commits/master
It is forked from master but It has been updated to Swift 3.

@GaelPeBer How would one specify that in the podspec, instead of the default repo defined in the Cocoapods Spec Repo?

Sorry, I didn't read you are using CocoaPods.
I guess It is not going to work with pods unless Masteage has created one podspec for his version.
I recommend to you that if it is possible move to Carthage, you only have to add:
github "masteage/SwiftCSV" "master"
to your cartfile.
Good luck

It is not possible to move to Carthage.
Swift 3 has been out for a year, and the code to support it is sitting on a branch. It needs to be merged back in to master so pods work.

Hey guys. I wanted to use this pod in a project, where i need to parse a csv. The thing is I created the podfile, i typed in there this specific pod, and then pod install. Everything was ok. Opened the workspace and did a build....26 errors only in the pod's classes. I tried to put the swift version to both 3.3 and 4.1 in the settings, but it doesn't look like it's changing anything. Can someone please please tell something? Thanks in advance

Since this is so old and the repo currently builds on all modern Swift versions, I'm closing this. @soryncrash13  if the problem persists, please open a new issue with the current Pod v0.5.0


Version 0.20 tracking

This issue tracks the work being done on the next feature release of TypeDoc. I will be posting a weekly update here covering what I've done this week, as well as what's next to be done.
You can try out a beta of 0.20 by installing typedoc@beta with npm i typedoc@beta.

Originally, this release was slated to be version 1.0, it contained a major rewrite which fixed most to all of the issues I have with the current implementation of TypeDoc. However, I've since realized that this was a bad idea - I broke too many things, so "library mode" will be releasing as 0.20 before the end of the year.
Old text
This issue tracks the work being done on version 1.0. I will be posting a weekly update here covering what I've done this week, any new problems discovered, and updating the checklist in this post with what's been completed. The checklist in this post was originally taken from this post in the original PR, without including any of the already completed items.
If you are interested in looking at the work in progress package, you can install typedoc@dev, which will be published whenever a change in version is pushed to the library-mode branch.
At the current rate that I'm getting things done, it's looking like this won't be ready until November/December... I was really hoping for sooner, but can't devote every weekend to this, though I try to do at least one task per week ;)
Tasks
TypeDoc proper

Finish ObjectReflection converter (medium)
Fix converter for destructured outputs (small)
Add indexed signatures to models that can have them. I forgot they existed when rebuilding the models... (medium)
Detect and convert static class members (smallish)
Update plugins that were broken when rebuilding converters

Decorator plugin (medium)
Implements plugin (medium)
Deep comment plugin (small, probably merge with the existing comment plugin)

Test on a bunch of different projects, particularly large ones. (Apache Arrow, Jupyterlab) (??? depends on what issues are found)
(done) Review existing options to see which ones still make sense. (medium)
Update variable converter to possibly convert variables as functions (smallish) (#858, but without requiring @function, #401, )
Sort order option (#112), see src/lib/plugins/sort.ts

Comments

Make @category work again (medium)
Fix {@link} and [[link]] (medium)
Make @inheritdoc work (small/medium)

Themes

Support hideGenerator flag (smallish, need to allow templates access to application.options)
(done) Make overriding templates easy for users (small/medium)
(done) Write docs on how to create a custom theme (medium, I want to do this right, not just the minimal page we currently have, particularly important because 1.0 breaks existing themes)
Talk with the people that built the markdown plugin about how to integrate (medium)
Make search work (medium)
Make sure mobile experience is decent (medium)
(done) Make light/dark code themes configurable (small)
Add icons for reflection types (medium)

Plugins / Developer Docs

Take a look at existing plugins to see what events they use, if the existing emitted events meet those needs, or if we need other events. (medium)
Write "how to build a TypeDoc plugin" (medium)
Update the development page on the website (medium)
Figure out what should be exported, and export only those symbols

Extra (nice to have, but won't block a release)

Highlight headings according to the color scheme chosen by users, not just code snippets (medium? Tricky. I spent a few hours on it, failed)
Add a reflection for "union enums" microsoft/tsdoc#164
Update models to make type parameters have a reflection - #1319.
Recognize global objects and combine them all into a single special module,
Figure out how @event ought to work. The old way of handling it flat won't work anymore... and it isn't particularly clear how it should be used.
Create a second theme

Future (almost certainly not in 1.0, but I'm thinking about it)

JSON deserialization (#910)
Support for /// comments microsoft/TypeScript#39930

Help out
There's still quite a bit to be done. Help on any of the uncompleted items above is greatly appreciated. I could especially use some help on making the default theme better - frontend dev is not my specialty. If you are having trouble, feel free to reach out by making an issue for the task you're working on, through the TypeScript Discord, or through the TypeDoc Gitter.

@Gerrit0  I'm happy to help with light/dark theme for typedoc, based on css custom properties and prefers-color-scheme. Maybe using this: https://github.com/GoogleChromeLabs/dark-mode-toggle

Thanks @bennypowers! We've chatted about this a bit on Discord.

What's been done this week is published as<EMAIL_ADDRESS>Maintenance

Since the currently released version of TypeDoc still needs to be maintained, it is in my best interest to avoid spending more time on it. (and therefore less time working on this!). This week I added automatic publishing to typedoc-default-themes when the version number is updated - it still isn't fully automatic, it doesn't create a tag + a release page, but it saves some time.
Upgraded dependencies for the themes, resolving some security vulnerabilities in devDependencies + removed lunr from dependencies - it was only ever used in bundling... which happens before publish.

Development

This week I spent most of my time figuring out how themes ought to work and writing some documentation for how they will. You can preview the docs here. (The examples will complain because not everything is exported yet... see work added)
PropertyReflection didn't have a isReadonly property, now corrected + properly initialized
I also did some experimentation with performance - #975 has a test case where TypeDoc performs incredibly slowly, taking several minutes to run. This rebuilt version of TypeDoc converts the same declaration file in under 5 seconds on my machine. I was still curious if we could do better, so I did some performance measurements... and the short answer is... not really. TypeDoc code only took up ~5% of that runtime. TypeScript took ~50%, Shiki (highlighting) took another 35%, loading modules 5%, and ~5% unaccounted for (gc?). Exporting JSON only took 2 seconds.
Originally, I wasn't planning on supporting files which were not modules, but while testing performance, I realized that it wasn't very difficult to support global files which contain an exported namespace of the same name as the file (as the monaco.d.ts file there.
I wasn't originally planning on working on themes this week... I got roped into that while looking into which options still made sense. Quite a few didn't. includeDeclarations (just works now if you specify a declaration file as an entry point) excludeNotExported (we only consider exported values now), listInvalidSymbolLinks (this should always be on), externalPattern (this was one of several ways to try to exclude values, shouldn't be necessary anymore, everyone uses modules)

Work added

I realized after writing docs on how themes work, that there wasn't a task for figuring out what should be exported, and exporting only those members... which definitely needs to happen before 1.0. This will need to wait until much closer to release, or I would have done it now.

Fairly small update this week, I didn't have much time to work on TypeDoc.
Maintenance

https://typedoc.org now has syntax highlighting in code blocks thanks to @sidthesloth92
The default theme colors are now WCAG AA contrast compliant thanks to @chadlavi - reinstalling without a lockfile will pick up the update.
Fixed export declarations within namespaces (#1366)
Since I keep spending at least a couple hours in the old code each week... it seemed worth it to upgrade dependencies. I got rid of the deprecated TSLint for ESLint + Prettier (#1190).

Development

I started making {@link} work, but didn't have time to finish it. This is what I'll be starting with next weekend.

My apologies for a lack of an update last week - I went out with some friends and didn't handle the junk food well...
This week was also fairly unproductive... but at least I did one thing! Work has been very busy, not much brain left over for the weekend. Particularly for the rather tricky task of making comment parsing better. While working on {@link}, I realized there were several issues with the existing implementation which would cause problems with the later comment parsing/rendering work... so I set out to remedy that.
Development

Light/dark themes are now configurable
Started working on converting variables as functions... which opened up some questions about what I'm actually doing with this "rewrite"... I need to spend some time next weekend figuring out if I can skip the rewrite. Now that I know more about library mode, I'm not fully convinced it is necessary. There are parts that I still want to change, but this rewrite is really something different than TypeDoc.

This weekend I spent trying to avoid the rewrite. I haven't succeeded yet, but I made some good strides, I believe it is possible to (mostly) use the existing architecture and avoid spending a bunch of time rebuilding code that works today. Toward that end, I ripped out a few options:

ignoreCompilerErrors - This was a bad idea in the first place. If there are compiler errors, we're asking for a crash later on...
mode - File mode was a hacky way of avoiding a ton of modules when using "modules" mode. "modules" mode is a specific case of library mode.
Support for specifying compiler options directly - Restricting this so that compiler options are always read from a tsconfig.json file ensures that we have the same behavior as tsc.

I mostly have library mode working, but am still dealing with some issues where we sometimes need to create references, and sometimes not.... I suspect I'll have a working prototype next week.

in our typescript library repo, we are experimenting with typedoc to generate api documentation.
as typedoc@next, i could do mode="library", which i am guessing is a best mode for us as its a literally a library.
we have both .ts and .tsx files that exposes modules and react-components to our users.
now when i have mode="library", .tsx files are ignored however in mode="modules" those are parsed and .tsx components are documented.
note : i'm not sure whether it's a decision choice or it's a bug.

my current typedoc config

"compilerOptions":{
"jsx": "react",
... other ts config's
...
"typedocOptions": {
    "inputFiles": [
      "src/clients",
      "src/components",
      "src/models"
    ],
    "mode": "modules",
    "out": "../docs/ts-docs",
    "exclude": [
      "**/*+(**Impl|**PostCommand|**WsCommand|**index).ts",
      "**/decoders/*",
      "**/*+(**Utils).ts"
    ],
    "jsx": "react",
    "excludePrivate": true,
    "plugin" : "typedoc-plugin-external-module-map",
    "external-modulemap" : ".*\/(clients|components|models)\/",
    "categorizeByGroup": true,
    "categoryOrder": [
      "Services",
      "Agent-Service",
      "Others"
    ]
  }
}

I wasn't quite able to get library mode working this weekend - mostly due to needing to fix how TypeDoc handles type references. It used to use the getFullyQualifiedName function on TS's type checker, but this doesn't always create a unique name. Particularly, it doesn't work with any global symbols... so the detection for if we had already converted a symbol and needed to create a reference to it was broken, which is an essential part of library mode. While fixing that, I also ran into some other problems with how we deal with types.

Some literal types (1 | true) weren't converted correctly
Sometimes type aliases would get the wrong type parameters + references to type parameters behaved oddly

I fixed these issues + restructured the type converters slightly, which makes it possible now to get warnings when TypeDoc doesn't properly implement a converter for some type and also improved the converter speed, lookup is now O(1) instead of O(n) with n being the number of converters. This revealed a few types that we don't handle right now that I didn't have time to get to. I'll probably skip them for now and just focus on getting something working next week.

Mapped types
Constructor types
Keyword types (null... probably others, really confusing what types are what in the compiler API)

Plan for next week:

Update type.hbs to properly support literal types so that rendering works again
Remove the "Only Exported" button from themes - with these changes, doesn't make sense to have it.
Update the block converter so that it handles references + module names correctly

With those done, I'll hopefully be able to put out a beta which works.

The beta is up! npm install typedoc@beta will install 0.20.0-beta.3. This build seems to work pretty well. I ran it on TypeDoc itself, and it produced significantly better output than file or modules mode (+ made obvious that we should be exporting more than we do...) There were more reference problems leftover that took some sorting out, but I think I've gotten all of them now.
I also spent some time this weekend trying to test this on some projects that I know are currently using the library mode build in #1184... for the most part, this seems to work equally as well, though I'm sure that people more familiar with the projects will be able to point out things I've missed.
A few notes about usage change:

Including a tsconfig file is essential. If TypeDoc doesn't find it, tell it where it is with --tsconfig <path>
You probably don't need the exclude option anymore. It is only used for filtering entry points if you give TypeDoc a folder instead of a file.
If you re-export something from node_modules, it will be included in your docs. If you want to avoid this, use --excludeExternals --externalPattern "**/node_modules/*"
inputFiles has been renamed to entryPoints to better reflect its usage.
If you only provide one entry point, TypeDoc will not create a module, members will be included directly under the project. This behaves similarly to file mode. If you provide multiple entry points, TypeDoc will create one module for each entry point.

How library mode works:

Start the compiler using the provided tsconfig
For each user provided entry point (through the entryPoints option in a config file or on the CLI)

Ask TypeScript for directly exported symbols and document them
Ask TypeScript for reexported symbols and document them, or if already documented, create a reference

Plan for next week:

[ ] Support for mapped types
[ ] Better support for keyword types (null, this...?)
[ ] Figure out what's going wrong with array types... some projects (dc.js) have a ton of "Refusing to recurse" warnings that shouldn't be an issue
[ ] Fix issues reported with beta (please open a new issue for tracking)

This week:

Added support for more literal types (null, bigint, 1n, -1)
Fixed bug with array types where we don't have a type node (I was trying to convert number[] into number[][][]...)
Fixed bug where default exports were not documented (#1382)
Published 0.20.0-beta.7

Plan for next week:

[ ] Try to fix how TypeDoc handles inheritence (#1386) - This might turn out to be a major problem and take the whole weekend...
[ ] Fix issues reported with beta 7 (please open a new issue for tracking)
[ ] Check that #1248 is fixed + add a converter test for it

Stretch for next week:

[ ] Consider adding support for @module or @moduleName - The typedoc-plugin-external-module-name plugin makes it possible to fake library mode with older versions of TypeDoc by specifying the module name in each file. The plugin will then merge modules with the same name together. With this version of TypeDoc most of the need for this has gone away, but it still seems useful to be able to rename modules for projects (SimpleWebAuthn, likely others) which have multiple packages documented under the same entry point.
[ ] Update the default theme to use CSS variables for coloring + add a dark mode
[ ] Make sure the minimal theme still works

If you're looking into inheritance, can I encourage you to spend some time on patterns like
export function CustomElementMixin<Base extends Constructor<HTMLElement>>(superclass: Base) {
  return class Mixed extends superclass {
    thing: number;
  }
}

Expected: I'd expect to see inherits HTMLElement, and maybe in a perfect world a link to MDN (that's even something a plugin should do)
Actual: Typescript ends up copying in the entire HTMLElement interface to the .d.ts, and as a result, typedoc ends up reporting on TEXT_NODE and other HTMLElement stuff that's better documented on MDN than my docs site 😄
So yeah this is probably a TS thing, but if you can hack together a nice fix, it would be nice not to have to https://github.com/apollo-elements/apollo-elements/blob/55e943d3eca62541a52881ab4a43ae7bf587a6d1/scripts/fix-typedoc.ts#L174-L189 (turns out JSDOM's closest implementation is wicked slow 🤷 )

So... mixins != inheritence, not even close. Mixins = hack everything together in a construct which breaks all reasonable ways of interacting with the compiler API. I tossed that into a file and ran the current beta on it, and apparently I've already made the output worse.

I think mixins need their own special converter + reflection type. Useful docs for them aren't anywhere near the same as useful function docs.... I'll make a note in my list to look at that, but can't promise I'll get to it before releasing 0.20.

No pressure. Thanks for the update.

I wasn't able to get inheritance working properly this weekend - but I think I'll be able to finish it up next weekend. I also spent a bit of time on some other issues:

#1248 is still not working, and 0.20 has actually made it worse by relying on TS's type checker to get exports (module.exports = gets converted into a single export= symbol, which we don't expand properly into separate exports)
While working on inheritance I realized (again..) that TypeDoc had some circular imports, and while these particular ones weren't causing issues, it seemed worthwhile to fix them and add a CI check for circularity #1173.
Since some options have gone away, the schema for typedoc.json also needed an update. Rather than manually update it, there's now a script which automatically creates it from TypeDoc's declared options.
Fixed: An earlier beta broke giving TypeDoc a directory as an entry point (each file within is treated as an entry)

Next week:

[ ] Finish fixing inheritance
[ ] Look into #1389

"finish fixing inheritance" was apparently too ambitious. I made good progress, but still don't have everything working. I hope to have some time this week to finish up the remaining issues and publish the work for people to find all the edge cases I missed. The approach I'm taking (ask the type checker for almost everything) works well, but unfortunately has required making changes to literally every node converter. I still need to make the variable converter and class converter work properly again. (Started with interfaces, because statics are annoying)

Thanks for your work on this @Gerrit0, it has been amazing.
I tried the new beta, and wanted to share some feedback, tought it might be useful to you.
The ex-library mode now works perfectly! There are no issues between module/classes.
There is only one issue I haven't been able to fix.
There is a class with a list of parameters, which apparently are in correct JSDoc format,

that aren't being shown in the class Typedoc page.

Any of your input on this would be greatly appreciated, maybe I'm doing something wrong?
The PR with the beta is here https://github.com/pmndrs/cannon-es/pull/54

@Gerrit0 could i ask to bring back ignoreCompilerErrors ? In my case i omit on purpose a lot of typings files to make typdoc faster. It is on purpose and i know it wont have any consequence on my doc.
I could really use that flag. You could set it to false by default.
Thanks

(I pulled the above questions into new issues)

I've been busy. I took some of this week past off, so had extra time for TypeDoc.

Shiki - TypeDoc used to use Highlight JS for syntax highlighting. For the most part, Highlight JS works well, however it maintains a custom parser. Originally, this was prompted by Highlight JS's missing support for tsx, but it has other benefits. Shiki makes it possible for us to get the individual themed tokens. This will make it possible to seamlessly switch between light/dark theme once I get to that... Shiki uses the same underlying code to highlight as VSCode does. However, it doesn't support all of the same languages as Highlight JS. typedoc --help will now print out a list of supported languages, to ease migration.
Inheritance - It works properly now! TypeDoc will pick up inherited properties specified through generic types. #1386 for one example. - I did break one thing, TypeDoc now doesn't resolve type parameters in concrete classes inherited from generic ones. (e.g. class FooList extends Array<Foo> will have functions returning T... even though we know it should be Foo) I might be able to fix that today or tomorrow.
Missing entry points - TypeDoc previously didn't give any sort of indication if it wasn't able to find one of the entry points requested, which lead to confusing behavior where documentation would be empty for no apparent reason.
excludeExternals/externalPattern - External members are now determined based on the file they are declared in. This is a change to previous behavior where each file was determined to be external or not. The externalPattern option now defaults to **/node_modules/**.
JSON schema - #1389 reported inaccurate JSON output types - this was possible because TypeDoc's serialization code used some casts to dynamically build up the output. This has now been fixed, the root JSON object created with --json is typed as import("typedoc").JSONOutput.ProjectReflection
logLevel option - I've found it useful to add some logging to typedoc to track down issues, but much of it isn't useful for a normal user. This lets me add as many verbose logs as desired without cluttering the output unless requested.

@Gerrit0 v0.20 looks awesome looks like i can finally point typedoc to the src folder instead of type declarations (src is commonjs with JSdoc types)
One thing that looks broken is the export symbol name:

That export name is correct - 0.20 documents what is exported under those names. TypeScript's equivalent of module.exports = is export =, there's no better name associated with that export.
However, because your index.is file does the more TS friendly exports.name =..., it should have the correct name there.
You probably don't want to pass TypeDoc the src directory. If you instead give it src/index.js you should have much better output.

export = Key;
import { Key } from "./key";

typedoc can't get Key from this ? you saying we can't use default exports with 0.20 ?
Anyhow changed everything to named exports and stuff starts to look nice and pretty, but still have errors in my utils file
TypeDoc exiting with unexpected error:
AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

  assert(declaration)

    at Object.convertTypeAlias (/Users/hd/code/pl/interface-datastore/node_modules/typedoc/dist/lib/converter/symbols.js:104:5)

declaration is undefined and symbol is this
<ref *2> [
  <ref *1> NodeObject {
    pos: 208,
    end: 248,
    flags: 4325376,
    modifierFlagsCache: 536875008,
    transformFlags: 0,
    parent: NodeObject {
      pos: 186,
      end: 252,
      flags: 4325376,
      modifierFlagsCache: 0,
      transformFlags: 0,
      parent: [NodeObject],
      kind: 311,
      comment: undefined,
      tags: [Array]
    },
    kind: 331,
    tagName: IdentifierObject {
      pos: 209,
      end: 216,
      flags: 4325376,
      modifierFlagsCache: 0,
      transformFlags: 0,
      parent: [Circular *1],
      kind: 78,
      originalKeywordKind: undefined,
      escapedText: 'typedef'
    },
    comment: undefined,
    typeExpression: NodeObject {
      pos: 217,
      end: 233,
      flags: 4325376,
      modifierFlagsCache: 0,
      transformFlags: 0,
      parent: [Circular *1],
      kind: 301,
      type: [NodeObject]
    },
    fullName: IdentifierObject {
      pos: 234,
      end: 248,
      flags: 4325376,
      modifierFlagsCache: 0,
      transformFlags: 0,
      parent: [Circular *1],
      kind: 78,
      originalKeywordKind: undefined,
      escapedText: 'PromiseOrValue'
    },
    name: IdentifierObject {
      pos: 234,
      end: 248,
      flags: 4325376,
      modifierFlagsCache: 0,
      transformFlags: 0,
      parent: [Circular *1],
      kind: 78,
      originalKeywordKind: undefined,
      escapedText: 'PromiseOrValue'
    },
    locals: Map(1) { 'T' => [SymbolObject] },
    symbol: SymbolObject {
      flags: 524288,
      escapedName: 'PromiseOrValue',
      declarations: [Circular *2],
      parent: [SymbolObject],
      isReferenced: 67108863,
      id: 354
    },
    localSymbol: SymbolObject {
      flags: 0,
      escapedName: 'PromiseOrValue',
      declarations: [Array],
      parent: undefined,
      exportSymbol: [SymbolObject]
    },
    id: 3317
  }
]

if i skip the convertTypeAlias call it renders but my utils.js file still gets the export= even though it only uses named exports (.d.ts generated by ts proves it).

export = Key;
import { Key } from "./key";

typedoc can't get Key from this ? you saying we can't use default exports with 0.20 ?

While typedoc could figure out that your local variable is named Key - that is not what it is exported as. It is exported without a name. This is one of the bad things with node's module.exports = ... and export default. Authors of a library probably intend that users name their imports after the library (e.g. import React from "react")... but the name that they actually export from the library is default, or no name at all in the former case. If TypeDoc documented the export as the local name, it would be confusing to users of your library.
Can you open a new issue for the issues you're seeing with instructions for reproducing them? I'd like to keep this issue fairly clean for people looking for updates on the 0.20 release.

Since the last update v0.20.0-beta.26 is out with:

Converter.EVENT_FUNCTION_IMPLEMENTATION has been removed. It was historically inconsistently called for functions. It wasn't fixed to always be fired because not all functions have implementations (.d.ts, types...)
Fixed handling of generic constraints which are arrays (#1408)
An attempt at support for project references (#1414)

I also spent a fair bit of time attempting to solve the generic issue from #2 above, but wasn't able to fully solve it this week.

thanks for the new release, I just played around with it. Looks great so far, one issue I stumpled upon:
I'm in a monorepo,and my tsconfigs extend the tsconfig in the root, e.g.:
{
	"extends": "../../tsconfig.json",
	"compilerOptions": {
		"outDir": "./dist",
		"rootDir": "./src",
		"tsBuildInfoFile": "buildcache.tsbuildinfo",
		"target": "es5"
	},
	"include": ["./src"]
}

this somehow let typedoc think it needs to pick up the name and README from the root, instead of the current directory. The types are documented correctly though, only the "Project" name is wrong and the readme file.
Thanks for your work!

Hmm... that looks like an unintentional side effect of how the PackagePlugin grabs paths changing to deal with multiple projects - it used to get the root names from the singular program, but I'm guessing that what TypeScript considers "root names" due to a change in how the program is constructed, so it is including declaration files in node_modules among the root names - which would explain why hoisting makes a difference.
Looking at this again, it doesn't make much sense to me to use the root names here - it's more appropriate to look for a readme beginning with the common directory for the entry points.
This, as well as a fix to improve the speed for repos using project references, but not a solution style tsconfig, has now been published in 0.20.0-beta.27 (or will shortly... CI is running)

The tag @event is not working after 0.20-beta.24 for methods

I tried the 0.20.0-beta.27, I am having some trouble because I use module-alias in my project but the --baseUrl option is disappeared.

I've just tried 0.20.0-beta.27, and getting this:
Error: Tried to set an option (mode) that was not declared.
Error: Tried to set an option (excludeNotExported) that was not declared.

NodeJS - any version, OS - Windows 10.
My typedoc.json file:
{
  "name": "SUB-EVENTS v1.8",
  "readme": "README.md",
  "mode": "file",
  "out": "docs",
  "theme": "minimal",
  "excludeExternals": true,
  "excludePrivate": true,
  "excludeNotExported": true,
  "disableOutputCheck": true,
  "exclude": [
    "./extras/**/*.ts",
    "./test/**/*.ts"
  ]
}

@vitaly-t remove the „mode“ option. It’s was removed as „library“ mode is now the default.

@Supereg Ok, just did it, so the first error is gone, but the second one remains:
Error: Tried to set an option (excludeNotExported) that was not declared.

@vitaly-t  excludeNotExported was also removed I think, as this is now the default behavior.

Error: No entry points provided

You will need to set the entry point for your application e.g. your index.ts or whatever. entry point should be documented in the typedoc docs.

Note that if I just remove that option from configuration, I start getting this:
Error: No entry points provided

@vitaly-t Read this

The tag @event is not working after 0.20-beta.24 for methods
Fixed in beta 28, no idea what I was thinking there... For some reason I changed the code so that @event would make methods public.

I tried the 0.20.0-beta.27, I am having some trouble because I use module-alias in my project but the --baseUrl option is disappeared.

baseUrl is a TypeScript option - so long as it is set properly in your tsconfig, TypeDoc should pick it up, if it isn't, please open a new issue to make tracking easier.

Beta 28 is out - I think I finally worked out all the edge cases with inheriting from generic classes. There's not much left on the todo list now - https://github.com/TypeStrong/typedoc/projects/5

+3 betas.. up to 31 now.
29 - Fixed missing comment detection on some variable-functions  #1421.
30 - Normalize unions containing true | false to boolean - this only seems to show up in inferred return types #571.
31 - Fixed the @category tag, it was broken on projects with a single entry point due to categorization happening twice for the project.
I am aiming for the 28th for a full release. The one remaining bug I have to resolve is missing index signatures, after that the remaining tasks are mostly updating documentation.
I did pull one feature out of this release - respecting the OS theme in the default themes. This might still end up getting released this year, but I decided I wanted to fix some other issues with the themes while I'm at it, so am putting it off a bit longer.

0.20 is out! https://github.com/TypeStrong/typedoc/releases/tag/v0.20.0
Please open a new issue if you discover any issues with it :)

@Gerrit0 Finally getting this integrated into my project. Works like a dream. I don't see one of those "buy me a coffee/beer" buttons anywhere but just want to say you deserve it :beers:  Thanks for all your work on this.


NN examples

What about adding some tutorials/examples on impementations and applications of NN with DDF?~

I am working on Formal Verification using Coq now... Will consider later


Update codecov CI to stable version of Rust

Should close out #364.
Similar to what was done in ion-rust: https://github.com/amazon-ion/ion-rust/pull/538. Makes some adjustments due to some conformance tests failing and using a different rust GH Actions.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Still looking at why the conformance test repot shows NaNs. Will try re-running that action.

Still looking at why the conformance test repot shows NaNs. Will try re-running that action.

The conformance test report (i.e. lists all the passing and failing tests) generation step now has a new error (example run using #374):
error: the option `Z` is only accepted on the nightly compiler

Seems like I'll need to update the conformance test runner to use a nightly version.


[feature] auto create directory when export a model

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:
/kind bug

/kind feature
What happened:
when I try to export a model after pulling, I got an error:
ormb export -d bbb <IP_ADDRESS>:5678/test-modelset/test-modeset:v1
ref:       <IP_ADDRESS>:5678/test-modelset/test-modeset:v1
digest:    c860afd8f993a754b9910f40fb66e45005988c0e23c7470560a2dd9033843f07
size:      28.9 MiB
format:    MXNETParams
Error: open /aaa/bbb/ormbfile.yaml: no such file or directory
...

I can't get the reason by the message, but when I created a directory called ddd, it exports successfully. So, it needs the export-directory to exist firstly.
What you expected to happen:
create the directory when I run ormb export ... like git clone
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
I may provide a PR to solve it

Can you show the ‘bbb’ file directory？ @tskdsb
Is there a ormbfile.yaml in your model path？


Option to rename git remote on "flynn create" command

Hello guys,
I want to create 2 apps from the same repo, one for staging, one for production. All commands accept the "-a" flag to point the app, but the "flynn create" command replaces the "flynn git remote" when I run it twice.
Actually I workaround this way:
$ git remote -v
flynn	ssh://git@demo.localflynn.com:2222/hares-dumbfound-killaloe.git (fetch) <<< the "stage" app
flynn	ssh://git@demo.localflynn.com:2222/hares-dumbfound-killaloe.git (push)

$ flynn create
Created lemurs-discourage-machin

$ git remote rename flynn flynn-prod

$ git remote add flynn ssh://git@demo.localflynn.com:2222/hares-dumbfound-killaloe.git

$ git remote -v
flynn	ssh://git@demo.localflynn.com:2222/hares-dumbfound-killaloe.git (fetch)
flynn	ssh://git@demo.localflynn.com:2222/hares-dumbfound-killaloe.git (push)
flynn-prod	ssh://git@demo.localflynn.com:2222/lemurs-discourage-machin.git (fetch)
flynn-prod	ssh://git@demo.localflynn.com:2222/lemurs-discourage-machin.git (push)

Discussing with @lmars on IRC, we think that could be useful include a flag on the command, giving the name of git remote. Something like this:
$ flynn create [ -r | --remote ] <name>

@titanous Should we close this issue?

Yep, thanks!


Sticky Scroll make .env file working tree show error.

Does this issue occur when all extensions are disabled?: No

VS Code Version: 1.73.1
OS Version: macOS 13.0.1 (22A400)

Steps to Reproduce:

Click the secord file in Changes.
Scroll the secord file in right window, trigger the Sticky Scroll effect.
Click the env file in Changes.
See the working tree window, you can see the error.

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!