Couldn't use this as a CDN package in html

Is there any way to use this awesome email editor as a CDN package in html.
I have tried to use it using JSdelivr cdn package, but this doesn't works

Please provide a codesanbox demo.

When i included the files, its giving the exports error.
please have a look at it.
https://codesandbox.io/s/throbbing-snowflake-0otspn?file=/index.html
Also Can we use the below Functions in our custom blocks
import { BasicBlock } from '@core/components/BasicBlock'; // for the custom block element render import { Width } from '@extensions/AttributePanel/components/attributes/Width'; // For custom block panel
If we can use these functionalities, it would be great.

Sorry, I don't know much about CDN package, it seems not very simple so far.

ok, Thanks for the awesome plugin.


Modify references to User to allow for custom User model

Code currently references the auth.User model, but many (most) projects use a custom User model set in settings.AUTH_USER_MODEL, as recommended in django docs. The current code results in errors for any project with custom User installing django-automations.

Modified reference to auth.User in models.py to refer to settings.AUTH_USER_MODEL. Because django-automations uses an app-level settings file, this required importing that setting from the project-level settings.py into the app-level settings.py, and then importing to models.py
For other references to the User model, updated code to use Django's get_user_model()

Referenced in #3

Codecov Report

Merging #1 (45a8f93) into master (8716103) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master       #1      +/-   ##
==========================================
+ Coverage   94.38%   94.40%   +0.02%
==========================================
  Files          13       13
  Lines        1068     1073       +5
==========================================
+ Hits         1008     1013       +5
  Misses         60       60

Impacted Files
Coverage Δ

src/automations/flow.py
93.18% <100.00%> (+0.02%)
:arrow_up:

src/automations/models.py
92.39% <100.00%> (+0.08%)
:arrow_up:

src/automations/settings.py
100.00% <100.00%> (ø)

src/automations/tests.py
99.08% <100.00%> (+<0.01%)
:arrow_up:

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 8716103...45a8f93. Read the comment docs.


Buffer corruption with dvtm and kakoune

I am running abduco -> dvtm -> kakoune (the text editor) and find my buffer systematically corrupted.
This seems to be happening as I move the cursor down the buffer: kakoune displays the line number in its status bar, and as well in the title of the terminal. As the cursor passes a 10-modulo boundary the original buffer text scrolls up by one line, including the dvtm tags at the top. The only way to fix this is by pressing C-g C-l to get dvtm to redraw the screen.
This does not happen if:

I recompile dvtm not to set the term title (term_title_handler)
I run dvtm and kakoune without abduco.

I got a similar issue just running less, but only once and I am unable to reproduce this.
I use the Chrome Secure Shell ssh client, but confirmed the same issue with urxvt.

Closing this as I am getting the same problems with dtach. I will raise an issue with kakoune.


[WIP] update entire doctools site content

Pull Request Description

Restructure, edit, and add content to doctools site, including contribution guidelines and old doc system guidelines. This site will replace doc.common wiki as the primary location for meta doc content.
Fixed Issue(s)

fixes #18

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@rolandtyler thanks for the feedback, but this is still a WIP and marked as a draft! There are still empty pages and I need to make many more editing passes. I usually commit and push changes for large PRs before finishing them as to minimize the risk of losing any work.


Windows support?

I've received a few PRs by @networkfusion (opened in my fork) to compile libdragon tools with MSVC:
https://github.com/rasky/libdragon/pulls
Before reviewing / merging them, I'd like to agree on a general plan of how Windows support in libdragon would look like, so that it's easier to drive contributions in the right direction. Moreover, I'm resisting using POSIX/GNU specific extensions in tools
I'm not really up to date with Windows development nowadays, so forgive me in advance. Focusing on tools only for now, my understanding is that there are three main avenues:

Use WSL (Windows Subsystem for Linux). This is (I simplify) a Linux VM within Windows. My understanding is that libdragon should just work as-is on WSL, no changes required.
Use MinGW/MSYS (with GNU make as build system). This would require very little modifications to the source code of tools (possibly none?) and it would still allow to use things like getopt or asprintf. It might require some changes to Makefiles (different extensions, etc.). It might even be possible to cross-compile the tools for Windows target from Linux CI.
Use MSVC. This is where I'm more confused about. I'm sure this would require some modification to the source code of tools, it would prevent using POSIX-ism / GNU-ism. It would also require changing the build system as MSVC doesn't ship with a GNU make-compatible tool, so we would have to switch to CMake or similar I guess.

As for compiling the actual game/ROM, I would say that we should stick to a cross-compiled GCC / newline / binutils anyway, so on this regard the effort would probably be setting up some script to be able to cross-compile a Windows version of the MIPS GCC toolchain, and then package everything for distribution.
Any comment on the above from some Windows developer?

Hey @rasky .

Yes WSL will work fine for build, but will not work with deploy tools due to no support for USB (in WSL V2 which is basically a docker container).

I have never (personally) liked the dependency on MSYS or CYGWIN for windows, it adds a big barrier to new users and "should" not be required...

It could use Makefiles with careful support for NMake (https://docs.microsoft.com/en-us/cpp/build/reference/nmake-reference?view=msvc-160) to keep the existing MakeFiles (happy). Although there will still be some issues with regards to specific gcc extensions which could easily be handled by an ifdef e.g.

If necessary, a dependency on Ninja is an option (it might improve build speed on linux as well).

linking with #30  the user got fedup and closed it...

https://github.com/DragonMinded/libdragon/pull/100 was the relevant PR for #30 but it was never merged. There was a missingdirent.h when compiling for MSVC.

unfortuately that is a postix lib... but does work if you copy in something like https://raw.githubusercontent.com/tronkko/dirent/master/include/dirent.h

My take on this one as a Windows user at home (this is where I develop for N64);

WSL 1 supports usb devices but with WSL 2 they have changed the infrastucture (based on Hyper-V) and usb support does not work indeed. Actually docker can run on wsl2. On the other hand it is possible to invoke non-wsl executables from a wsl shell with an Windows interop With that setup it should be possible to invoke a Windows executable from within wsl. I once built a toolchain on wsl and it was working as expected.
I never liked it either although it works pretty well once configured properly.
I have hardly used MSVC but IMO, we should concentrate our efforts towards other things rather than maintaining a different set of tools. Do not forget about maintaining tests and other stuff for both etc.

There is also a fourth option, which I still prefer using to this day and that is dockerizing the toolchain. Once we had the docker container in this repository but later I have decided to separate it away as it was causing too much overhead. I suspect trying to do a similar thing by maintaining different build processes and compatbility will increase the efforts required here. As the project folder is mounted on the container it is possible to just use the native USB tools and docker commands for anything else including the tools.
There are a few problems I have faced with the docker setup;

Line endings can be an issue if you want to use shell scripts on a docker mount if your defaults ar CRLF. This is just a minor annoyance once you set up them specifically for your docker based projects.
There is no platform independent way of accessing the host machine (mac and windows have host.docker.internal - see here, but I'm not sure if linux have something similar that we can set once and use). This is something that I want to have b/c I was planning to also have the cross-compiled gdb on the docker machine as well which will connect to a simple socket server running on the host thus talking to the flash cart.

Apart from these caveats I really like this approach because it takes a few minutes to make everything work as it should whatever your working environment is. Even if you completely forget even what to install/build etc. Still I'm a little hesitant on introducing these solutions into the main libdragon repository.
WSL can be a good candidate as well but docker has also the advantag of being out of the box compatible with macOS. If anyone had built the toolchain I'd be happy to hear their experience as well. AFAIR it wants the binaries to be signed. You can self sign them but it is a chore and there are potentially other third party dependencies that are not installed (or maybe built) by default.
In any case someone has to maintain those solutions (including docker) so we should aim for the least resistance path, which is docker for me ATM, which I already maintain for myself. @rasky suggested removing the npm dependency by compiling native versions of the helper, which would be a good improvement.

Thanks. I'm using docker on MacOS for libdragon development and I'm very happy about it. If that can be made to work on Windows, maybe it's a good way to maintain just one platform.
I agree that the NPM wrapper is a nuisance on Windows. We could work on a new tool that's natively compiled, that'd make the docker way more palatable for Windows users I guess.

I haven't been able to do a full build of libdragon or a ROM yet so my experience is "incomplete".
The issue that I had was the use of 'mkdir' in the makefile, the equivalent on Windows doesn't support making nested directories, so it errors out.
My Environment:
Compiler: n64chain version of GCC for Windows in a Windows Command Prompt
Editor:  Notepad++
I'd rather use VSCode or similar but that is probably easy with the right plugins, once the makefile works.
No WSL,, No Docker, No MinGW/MSYS (which is how I'd like to keep it)
Personal Opinion: MinGW/MSYS and Docker are hacky ways to run Linux inside of Windows. If I wanted to learn Linux, I'll learn Linux in a real system or a dedicated VM. When I just want to compile a ROM, I shouldn't have to learn Linux.

I agree, docker is a very good option... but... against that it also adds a mainainance burden on users (given that you have to clean up the containers regularly)... Also, I personally dont have space for docker or WSL...

The tools should not be a maintainance burden (or at least a very limited one) if considered correctly.

@fraser125 is learning make (and a few well known commands) is equivalent to learning linux as well? If not, with a docker container and an appropriate wrapper, you can build a rom with no additional linux specific knowledge IMO. Why do you think those are hacky solutions? Especially docker is used in production to a great extent. A considerable amount of online services are utilizing containerization.

Personal Opinion: MinGW/MSYS and Docker are hacky ways to run Linux inside of Windows. If I wanted to learn Linux, I'll learn Linux in a real system or a dedicated VM. When I just want to compile a ROM, I shouldn't have to learn Linux.

Docker is many things. One thing it is is a tool to run prepackaged software in pre-built images using Linux just as a common runtime interface.
The final experience would be that you install Docker on your system, then download a tool called libdragon.exe, cd into a directory containing your project and run "libdragon make". There is no Linux knowledge required.
The only point where this abstraction leaks is that if you try to do complex things in your Makefile, you need to use bash for that. But if you don't like that, you can still write your own build.cmd script in Batch or PowerShell that invokes "libdragon make" as one of the steps.
I think this very well crosses the dot of "no Linux knowledge".

As long as you are competent with using commands like docker image prune and/or the toolchain handles it e.g. docker container prune https://docs.docker.com/config/pruning/ (as well as the issues mentioned about diskspace being an issue...

Docker can consume considerable disk space though I admit that. Still the benefits might overweigh the cons and we can abstract away container maintenance.
There is still nothing wrong with maintaining lightweight executables somewhere else that can be downloaded and used but doing and maintaining it here is a little bit too much IMO.
At the end of the day, it boils down to the tools then, should we support MSVC out of the box so that someone can compile it for Windows and maintain it?

It sounds easy when you do it all the time, for a person new to N64 development it's another frustration and the possible loss of a new contributor.  The last time I was trying to setup a C development environment for N64. I finally found it easier to learn MIPS assembly language from scratch.
How about looking at the rest of my post where I got most of the environment working without ANY major changes to the codebase.

Pruning images is only required to reclaim disk space for users that heavily build new containers. In case of libdragon users, they would use a single image that does not inflate over time while building ROMs, and we can make sure the libdragon.exe tool always deletes the old image when it updates it to a new one. So really there should not be so much space required.

@fraser125 how do you compile the tools with little change? If that is possible, I think we should consider making those changes here.

When I need GCC for Windows EXE's I download from here: http://www.equation.com/servlet/equation.cmd?fa=fortran
It would be nice have a Tools Release for for Windows so the user doesn't have to download the GCC toolchain for Windows.

To be able to build the tools for Windows (at least for MSVC) we need changes here for compatibility. Still non MSVC builds can be done and uploaded somewhere, there is nothing preventing that.

One other point to consider... generally when building a ROM, you have done it against a specific version of libdragon (given changes to the lib are likely going to break things). If docker is the main point of entry, that needs to be carefully considered (especially in a CI environment)... but that is probably a different conversation...

To be able to build the tools for Windows (at least for MSVC) we need changes here for compatibility. Still non MSVC builds can be done and uploaded somewhere, there is nothing preventing that.

Only if the tools still rely on GCC extensions... Most of the issues are due to -Wall not being on. And those that do, should be carefully considered...

@rasky on Windows docker can be configured to use wsl2 and that results in an ever growing vhd image even if you clean the docker images etc. I'm not sure if this was addressed on docker yet or is there a similar issue for a macOS/linux host. So disk usage might be a real concern indeed. It shoukd get fixed/improved at some point though.

Prune is very necessary with me (on the W10 WSL2 computer that I use CrashOverrides lib on!)

I am OK to reduce GCC dependency for tools and improving compatibility without introducing too many define guards. For the library GCC extensions is necessary IMO.

With the tools, these are the current issues (I remember) and possible solutions:

The use of libpng (either change to using stb_image.h or warn that MVSC users will need to find one).
Byteswap flags using GCC extensions (this should really be made independent or abstracted).
use of dirent.h (really should be made independent, but if not just warn that the file needs to be found and added).
packing a struct (really should be independent, but it is maintainable to just abstract it).

I am OK to reduce GCC dependency for tools and improving compatibility without introducing too many define guards

I'm afraid the two goals are at conflict, generally speaking. For instance, today's review of Meeq on my PR suggested to use asprintf to clean up the code, but that is not available on MSVC. I also in the past resisted the temptation to use getopt_long in tools to greatly simplify option parsing just because a possible future MSVC port might get into trouble.
It's unfortunate that MSVC is stuck in the '90s with its C compatibility, but I'm wondering if it makes sense to restrain our capability to develop those tools, when 99% of libdragon users just need to be able to run n64tool.exe. So I can't see why using MinGW to compile n64tool.exe is a problem, given that end users won't require to use it.

I would not say MSVC is stuck in the 90's persay, but more GCC is bringing the C language into the 21st century ( 17 vs https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-160... C2x...)
portability wise == https://stackoverflow.com/questions/40159892/using-asprintf-on-windows).. however I am definitly not against MinGW to get passed it...

I am also in favor of making Windows builds as uncomplicated as possible. If we have CI doing builds, we can tell beginners to just use the binaries. Advanced users who want to do a build can figure out how to get MinGW installed.

I dont know the state of MSVC vs GCC if you think it will be difficult @rasky its not something I would want either. To keep builds clean we will also have to maintain its build pipeline here, which I think is not feasible in the long run. It will rot and get removed at some point to make the build pass. Even if I owned this repository that wouldn't be something I can promise to protect. Even with this relaxed setup PRs can take days to merge.
Dont get me wrong I'm 100% into adding those pipelines and checks making this a perfect environment but realistically I don't think we can make it. Still if we decide to commit and establish strict rules to merge something, like enforcing tests, cross platform support for tools, automated emulator tests, code style restrictions etc. I would not object although it might harm the library more than it improves it ATM. We can re-consider this after we decide we got enough traction though. What do you think?

I think we're converging on:

Tools: compile with GCC for Windows to have zero hassle with ifdefs. Build can be done on CI. Distribute as binaries for Windows users.
Toolchain + libdragon: try the docker option, with a new driver that's compiled native on Windows (libdragon.exe) so that no Docker/Linux knowledge is required, but at the same time we can reuse the build system based on make+bash.

Compiling with or under MSVC has never been a priority IMO. Its a nice ecosystem if you are developing Windows software but outside of that? Nah. The original toolchain for windows release was compiled using msys in a canadian cross compiler (compile on platform A, or linux, to generate executables on platform B, or windows, that targets platform C, or mips) setup and also statically linked so there was no dependency on an installed version. That ran on windows, used standard make and allowed the same code to work anywhere.
Docker is definitely an option, but the original long-outdated windows release at https://dragonminded.com/n64dev/ was almost standalone (just needed make for windows) and there's no problem bundling that for a one-stop download. We could even build that using CI so that there's just a download for windows users that doesn't need to be installed. This is how I've always done windows development on various homebrew platforms and it's been nice having no cygwin/msys dependencies and being able to extract and run out of the box.
Maybe this isn't how development gets done anymore though?

I think thats an option too... We will probably not support MSVC then. The next important question is in my opinion; should we maintain the build pipelines (whether it is docker or msys/mingw) here on this repository or not?

I think it makes sense to have them here as GitHub pipelines or similar CI, as there's easier too trigger for every new change.
I'm not opposed in building the toolchain as canadian cross. My only issue with that is that we should probably also build GNU make and then make sure that the default example Makefiles don't use any bashism (so not even a if), as otherwise they won't work on a native Windows terminal; I guess the CI can help with this as well.
Moreover, this solution isn't easy to use for Mac where distributing native binaries is hard nowadays.
I'm experimenting with a natively-compiled CLI tool: https://github.com/rasky/libdragon-cli that builds upon the experience of the NPM tool by @anacierdem. I think if we can make the docker flow work without people even knowing we are using docker, it might solve the cross platform issue while constraining us less while developing.

Also remember that we depend on dd which we may also need to distribute if we go that route.
Should we also include the docker wrapper here as well then? b/c we will also need to make sure it is built and published somewhere. Then it might be a good idea to have an additional repository collaborator as well so that we don't get blocked if we need changes.

It looks like we could replace usage of dd for byte-swapping with objcopy: https://stackoverflow.com/a/19288235

Just throwing it out there but I did a full setup for Windows with Docker here: N64 Windows Setup.  It'll give a good sense of the setup under Windows at the moment.  In my opinion the biggest frustration with setup on Windows is the lack of a good package manager for automating installs (ie: apt, brew).  I've reached for Chocolatey here to do automatic setup but its still quite cumbersome.
tldr In my opinion the suggestion to:

Toolchain + libdragon: try the docker option, with a new driver that's compiled native on Windows (libdragon.exe), so that no Docker/Linux knowledge is required

Would greatly simplify setup.  I've setup Libdragon for friends across MacOS, Linux and Windows and I think if it could be done as a one-click installer that would be ideal and remove what I think is the biggest barrier to entry into N64 homebrew using Libdragon and that is setup headaches.

Also should note that I do all my development inside the Docker container using VSCode Remote extension which is very stable (despite I think being in early access preview).  This means compat. with existing Libdragon setup/scripts and its just gcc with makefiles and no requirement for MSVC/Cygwin.

@werkn There is already a wrapper for docker which should be much easier than your experience in the blogpost. It uses NPM and docker desktop, both of which having easy to reach installers on Windows.
With a standalone executable, we will be able to get rid of NPM but in turn we will be loosing the ability to automatically register it to the path and dependency installation capabilities + it may also require git. @rasky is working on a version of it and I highly suggest trying it out when it is stable.

The new version is here:
https://github.com/rasky/libdragon-cli
Here you should find a Windows binary:
https://github.com/rasky/libdragon-cli/releases/tag/test10
(Everything is super WIP)
As mentioned by @anacierdem, this version requires manual installation on PATH and a separate installation of Git for Windows.
The first requirement could be dropped by wrapping the binary into a simple installer like those made by InnoSetup or WiX.
The second requirement is coming from a different design choice I'm experimenting with. Basically, @anacierdem docker images contain the full toolchain plus a specific version of libdragon. Whenever somebody commits on libdragon, the container image must be updated (it can be automated with CI). This also means that users must update Docker images to update libdragon.
In the new tool, the approach I'm thinking is using a docking container just for the toolchain which changes very rarely, and then vendoring libdragon within the ROM project. The tool supports vendoring via git submodule and git subtree, and hence the git requirement; this is done when the user runs "libdragon init" to initialize a new ROM project (which is also nice to get in one command a running main plus a working Makefile). When the user runs "libdragon update" the tool then updates libdragon by using the correct git incantation.
I think that in general the ecosystem will be better served with a vendoring approach, given how we already manages to break the API a few times (see how Flappy Bird was broken for many months). We don't want new developers to have troubles to recompile games released years or months before just because they don't know the correct libdragon/toolchain to use.
Another good effect of vendoring libdragon is that libdragon init would create a Makefile that builds both the vendored libdragon and the ROM project. This means that users can easily patch libdragon if they need, without changing their workflow.
A third good effect is that this approach rarely updates the docker image, which means that there will be fewer images in general and less disk space used (this was one of the concerns mentioned in this issue).
Now that I think of it, we might even drop the Git for Windows requirement if the tool supported a mode to vendor libdragon by downloading zip archives via HTTP and recording the version in some dot file. But is Git for Windows really such a hassle?

I don't think git is a hassle but I don't think NPM is one either. I'm totally ok with rebuilding libdragon locally rather than including it in the container as well. It is a thing we can achieve with npm as well, we already have versioning.


making updates to readme

Moved the wiki to README so more discoverable, added some info.  You can clarify if accurate 😄


Use in javascript

I am going to use this library in javascript.
Server will create only session and send it to client.
And in the client will get rows with the session. It is possible?

Can you expand on your question @luckyfanghe ? We have samples in Javascript for reading rows using the Storage Read API and write rows using the Storage Write API. Does those samples help ?


Added a new longest_match method

This method uses "farthest hash" to reduce check loops. The idea is based on algorithm described at:
http://www.gildor.org/en/projects/zlib
Benchmarked it with lzbench against Silesia's corpus. The performance gain can be at ~150% max. For most cases in level6-9 it can get 40%~60% compression speed up.

Hi guys.
Sorry for entering discussion.
The algorithm implemented in this PR provides performance benefit only when used for "lazy evaluation". I've described my algorithm on http://www.gildor.org/en/projects/zlib to be more "cleaver", I think. It boost performance for regular longest_match search as well. I'm switching to a different offset every time when match grows.
Why doing "own implementation" while there's already fully functional, optimized and tested code?
https://github.com/gildor2/fast_zlib
Thanks,
Konstantin (gildor)

Hi, Konstantin,
Really glad to have your comments here! And thanks for your idea and algorithm!
Yes, this implementation is different with yours, but also provides boost for both regular search(level1-3) and "lazy mode"(level4-9).
The boost for level1-3 comes from get_match_len which compares multiple bytes at one time(4bytes on 32bit and 8bytes on 64bit).
The boost for level4-9 comes from combination of get_match_len and your idea.
The reason I create my "own implementation" is based on the test result with lzbench(https://github.com/inikep/lzbench) against Silesia's corpus(http://sun.aei.polsl.pl/~sdeor/index.php?page=silesia). It is observed that for most Silesia's cases:

Compression speed: For level1-4, code-g(https://github.com/gildor2/fast_zlib) provides poorer performance than original zlib. The drop is about 2~3.x% for different case. For level5, code-g provides almost the same performance as original zlib. For level6-9, code-g provides big boost than original zlib, especially in level8-9.
For compress ratio, code-g provides similiar ratio as original zlib for 1 case(nci), while for other 11 cases it  produces larger files than original zlib. The difference is about 0.5%~3%.
For decompress speed, the stream produced by code-g are generally decompressed slower than stream created by original zlib.

So I created another implementation, tuned and tested with these corpus. The implementation in this PR provides better compression speed, almost the same compress ratio and slightly better decompress speed compare to original zlib in all levels. If you're instrested with the test, I can uploads the result, maybe provide a lzbench fork, so you can run the test.
Again, thank you for sharing us your idea and comments!

Hi,

I didn't test compression for levels below 5. My code shouldn't provide any benefit for it because zlib works in very different way for "fast compression" - this affects not just lazy matches, but also hash table manipulations. My code provides benefit only when it allows to iterate over smaller number of hash chains. But if deflate iterates over 5 chains, compression speed could be slightly slower because of the algorithm's complexity.

Worse compression. It's just a question of probability. My code iterates over different hash chains, this is heuristic. And perhaps sometimes it goes through hash chain which will give worse compression ratio, if this chain will be stopped before it finishes (low chain_length value). I used nearly 1Gb of real data for testing, and in average compression ratio is nearly the same as with original zlib. I didn't test smaller data blocks, like - 10Mb of data etc, just because of difficulty of catching difference, and doing accurate profiling. Plus, using larger data for testing could guarantee statistically better performance, not optimizing code just for some particular test suite.

Decompression speed. It heavily depends on number of LZ chains. When data contains lots of huffman codes for separate literals, decompression will be slower. Plus, some fortune, again. I believe compression algorithm should be optimized for faster compression speed, with compression ratio to be not worse than original code. But you're bothering about tiny performance drop with decompression.

I've tested decompressors as well, and I can say that its performance varies a lot from run to run. However zlib-ng (Win32/Visual Studio build) gives the worst compression and decompression performance, compared to original zlib, asm-optimized zlib (by Gilles Vollant), and my code.
 I think if you'll use the whole function from my git, you'll get better performance boost. Perhaps it's worth using different longest_match function for levels 1-5.

So, I decided to test my code with "silesia" data set. I used the whole tar file, without trying to pack every file separately. Test results are attached (screenshot of console window):

There are 5 results for levels 1,3,5,7,9. NewAsm - my assembly code, NewC - my C code, DLL - there are two: zlib-ng (marked with zlib-ng_32.dll) and original asm optimization (zlibwapi32.dll). And the last line is original C code. Note: there's no zlib-ng for level=1 just because application crashed somewhere inside zlib-ng (on memory deallocation).
You may see, that for levels < 5 my code always produces exactly the same result as original zlib. So, decompression time should match, but it differs - I mentioned that in my previous post. Compression performance is comparable with original zlib. I mentioned that because you told me that my code generates data which are slower to unpack.
Zlib-ng is significantly faster with compression on level 3. Its decompression speed is always slower (sorry, but this is always true in any of my tests).
My code starts to bring benefit in compression from level 5 - comparing to "original zlib" - just as it should (again, mentioned in previous post, that at levels < 5 my code works just like original one).
My code is a little bit slower than zlib-ng at level 5, but it provides a little bit better compression, so it is hard to compare. On higher levels, compression benefit grows.

Hi, Konstantin,
I've forked your fast_zlib repo (https://github.com/JunHe77/fast_zlib) and lzbench (https://github.com/JunHe77/lzbench) which I mentioned before.
Both your code in "Sources/match.h" and code in this PR are added to these two forks, so we can bench them with same base.
The binaries are built and tested on Ubuntu 16.04 (64bit version), GCC 5.4.0 running on Intel  E5-2650v3.
Test with Silesia:

Test with enwiki dump:

Test with Silesia using lzbench: (lzbench:original zlib, lzbench-p: zlib with code in this PR, lzbench-g: zlib with code in fast_zlib)

These results should clearly describe the points I mentioned in previous post.
As I don't have visualStudio build env, you may try my fast_zlib fork and see the difference between NewC and PR.

Hi (sorry, but I don't know your name)
I've tested your code with my test application. Adopted it for Visual C++ (inline -> __inline, __builtin_ctzl -> _BitScanForward). It still runs slower than my code. Much slower on higher compression levels. With my own test data, and with silesia. I even tested it with gcc (started Linux under VMWare) - still slower.
Important. I see some mess in your output. For some reason, "my" code produced results on levels 1-4 which differs from original zlib (and even worse that original zlib, in terms of compression ratio). It must be the same. And in my tests it is the same. I mean: on my PC resulting file size for lower levels is the same for my code, your code, and original zlib, and it equals to file sizes (for "siletsia") for "PR" and "Orig" tests. If everything is correct on your size, there's probably a bug in my code and it must be fixed. Compressed data should not depend on the machine.
Several questions. What did you put into "zlib" source directory? Which gcc version do you use? What CPU do you have (Intel/AMD/etc)?
Thanks,
Konstantin

May be there are other people who interested in helping with this, who reads this thread? Could anyone else test the code?

The build/test env is mentioned in previous comments:
"The binaries are built and tested on Ubuntu 16.04 (64bit version), GCC 5.4.0 running on Intel E5-2650v3."
As for zlib sources in fast_zlib, it is HEAD@https://github.com/madler/zlib

Sorry, I missed that specs.

I've found and fixed the problem, I think. The problem was with gcc/64: it treats "long" type as 64-bit, unlike Visual C++ which works with it like with 32-bit. I'm using 32-bit Linux on my machine, so the problem didn't appear to me. I've exactly reproduced your compression results when I replaced "ulg" in match.h with 64-bit integer type.
The fix is here: https://github.com/gildor2/fast_zlib/commit/3c0c4626a71a827a8e2d7dc98a365daff26078e9

Cool!
I'll merge the fix and make some tests.

Hi, Konstantin,
I updated https://github.com/JunHe77/fast_zlib with your fix and tested against silesia corpus on both 32bit Ubuntu and 64bit Ubuntu on Intel E5-2650v3. Here are the results:
32bit-ubuntu:

64bit-ubuntu:

One more thing, for Orig in both tests, they are built with "UNALIGNED_OK" defined.

Nice catch with UNALIGNED_OK. I was sure zlib defines it automatically, and was surprised that it is defined only for MSDOS :)
Regarding your tests. I didn't understand why your code still faster until I looked at your "fast_zlib" repository. I see that you use my longest_match code (1:1), with changed comments, reordered variable declarations and several renames of variables. The difference is only with use of very optimized version of match comparison (get_match_len). What's yours there now? :) If you did some optimizations to my algorithm, it is worth doing PR to my repository, but not posting this work here as if you re-created algorithm using my description. Sorry for criticism.

Hi, Konstantin,
Yes, the latest benchmark of "PR" is result of  64bit-optimized get_match_len and your distant search implementation combination. I did this to verify if there is a faster implementation as you have fixed the "long" type  bug on 64bit arch.
I'm very sorry for not point it out in the comment, and any misunderstanding that I re-create the algorithm. It's all your credit.
As for the original PR implementation benchmark, pls check following:
=====> Benching level-1 ....

 Would you like to create a PR for your implementation?

Hi Jun,
I did an attempt to push my changes to the stock zlib - https://github.com/madler/zlib/issues/231
However Mark Adler is very slow in response (he didn't do anything on GitHub for months), so I'm still waiting. Regarding pull request for zlib-ng, I'm ok if someone else will integrate my code - I mentioned that in zlib's issue which I open, and explained why someone else should do that :)
Thanks,
Konstantin


Document the extension protocol

inputs, outputs, etc.
For instance when you call getCredentials what is returned when a credential is selected?

closed with https://github.com/WebOfTrust/signify-browser-extension/issues/155


Lack of set function - porting proposal

I noted the lack of a set function (as here). I built a sort of set function in a project of mine. At the moment it works only on array, what do you think if I make a porting of my function on your project?
What are your general guidelines to make a pull request? Do you have any suggest?
Best Regards
Domenico Rizzo

@willypuzzle That would be great if you can create a PR.
Some useful info:

Delete the src/compiled.php file while creating the function and adding the unit tests
When you have completed the function and tests, run bin/compile before submitting the PR

Other than that, there are no other guidelines. You can create the PR and we can continue the discussion from there

doesn't he also need to run the php-cs-fixer ??

@pierredup, @willypuzzle,
It looks like there’s a baseSet method defined here: https://github.com/lodash-php/lodash-php/blob/master/src/internal/baseSet.php
Is this as simple as adding a set.php as a next door neighbor of get.php?

@pierredup, @willypuzzle,
It looks like there’s a baseSet method defined here: https://github.com/lodash-php/lodash-php/blob/master/src/internal/baseSet.php
Is this as simple as adding a set.php as a next door neighbor of get.php?


Can I fix keys with keycode 0 somehow?

I am now pretty happy with my current setup. I just miss a few keys that do not work. Is there even a way to get this done?
I'm using a windows server on barrier 2.4 and waynergy client configured to use uinput. I've set raw-input.offset to 8 which works well for ~75% of all my keys. I am notably missing the arrow keys (and a few more that don't bother me as much).
I've set my loglevel to 4, and I can see the keycodes that are received. My problem is: they are all 0. Is there even a way to fix this? I have no real idea how I would even start getting that in order. Even if I do not set offset, this happens, too.
Here I'm highlighting keys by how well they work (including offset=8):

🟢 green ones work exactly as they are supposed to work as far as I can tell.
🟠 orange ones return keycode 0 in the logfile.
⚪ gray ones show other weird behaviour, but I do not (yet) care about them enough to dig deeper.

I set barrier to be level Debug1, which includes keycodes sent to the client. here are the log lines for SUPER, UP, LEFT, RIGHT (all received as 0) and DOWN (received as 1):
// SUPER / WIN keydown
DEBUG1: hook: 0x0000005b 0x015b0001
DEBUG1: hook: 0x605b0000 0x015b0001
DEBUG1: hook: 0x705b0000 0x015b0001
DEBUG1: event: Key char=0, vk=0x5b, nagr=0, lParam=0x015b0001
DEBUG1: new mask: 0x2000
DEBUG1: new mask: 0x2010
DEBUG1: onKeyDown id=61419 mask=0x2010 button=0x015b
DEBUG1: send key down to "client-computer" id=61419, mask=0x2010, button=0x015b

// SUPER / WIN keyup
DEBUG1: hook: 0x0000005b 0x815b0001
DEBUG1: hook: 0x605b0000 0x815b0001
DEBUG1: hook: 0x705b0000 0x815b0001
DEBUG1: event: Key char=0, vk=0x5b, nagr=0, lParam=0x815b0001
DEBUG1: new mask: 0x2010
DEBUG1: new mask: 0x2000
DEBUG1: onKeyUp id=61419 mask=0x2000 button=0x015b
DEBUG1: send key up to "client-computer" id=61419, mask=0x2000, button=0x015b

// LEFT keydown
DEBUG1: hook: 0x00000025 0x014b0001
DEBUG1: hook: 0x60250000 0x014b0001
DEBUG1: hook: 0x70250000 0x014b0001
DEBUG1: event: Key char=0, vk=0x25, nagr=0, lParam=0x014b0001
DEBUG1: new mask: 0x2000
DEBUG1: new mask: 0x2000
DEBUG1: onKeyDown id=61265 mask=0x2000 button=0x014b
DEBUG1: send key down to "client-computer" id=61265, mask=0x2000, button=0x014b

// LEFT keyup
DEBUG1: hook: 0x00000025 0x814b0001
DEBUG1: hook: 0x60250000 0x814b0001
DEBUG1: hook: 0x70250000 0x814b0001
DEBUG1: event: Key char=0, vk=0x25, nagr=0, lParam=0x814b0001
DEBUG1: new mask: 0x2000
DEBUG1: new mask: 0x2000
DEBUG1: onKeyUp id=61265 mask=0x2000 button=0x014b
DEBUG1: send key up to "client-computer" id=61265, mask=0x2000, button=0x014b

// UP keydown
DEBUG1: hook: 0x00000026 0x01480001
DEBUG1: hook: 0x60260000 0x01480001
DEBUG1: hook: 0x70260000 0x01480001
DEBUG1: event: Key char=0, vk=0x26, nagr=0, lParam=0x01480001
DEBUG1: new mask: 0x2000
DEBUG1: new mask: 0x2000
DEBUG1: onKeyDown id=61266 mask=0x2000 button=0x0148
DEBUG1: send key down to "client-computer" id=61266, mask=0x2000, button=0x0148

// UP keyup
DEBUG1: hook: 0x00000026 0x81480001
DEBUG1: hook: 0x60260000 0x81480001
DEBUG1: hook: 0x70260000 0x81480001
DEBUG1: event: Key char=0, vk=0x26, nagr=0, lParam=0x81480001
DEBUG1: new mask: 0x2000
DEBUG1: new mask: 0x2000
DEBUG1: onKeyUp id=61266 mask=0x2000 button=0x0148
DEBUG1: send key up to "client-computer" id=61266, mask=0x2000, button=0x0148

// RIGHT keydown
DEBUG1: hook: 0x00000027 0x014d0001
DEBUG1: hook: 0x60270000 0x014d0001
DEBUG1: hook: 0x70270000 0x014d0001
DEBUG1: event: Key char=0, vk=0x27, nagr=0, lParam=0x014d0001
DEBUG1: new mask: 0x2000
DEBUG1: new mask: 0x2000
DEBUG1: onKeyDown id=61267 mask=0x2000 button=0x014d
DEBUG1: send key down to "client-computer" id=61267, mask=0x2000, button=0x014d

// RIGHT keyup
DEBUG1: hook: 0x00000027 0x814d0001
DEBUG1: hook: 0x60270000 0x814d0001
DEBUG1: hook: 0x70270000 0x814d0001
DEBUG1: event: Key char=0, vk=0x27, nagr=0, lParam=0x814d0001
DEBUG1: new mask: 0x2000
DEBUG1: new mask: 0x2000
DEBUG1: onKeyUp id=61267 mask=0x2000 button=0x014d
DEBUG1: send key up to "client-computer" id=61267, mask=0x2000, button=0x014d

// DOWN keydown
DEBUG1: hook: 0x00000028 0x01500001
DEBUG1: hook: 0x60280000 0x01500001
DEBUG1: hook: 0x70280000 0x01500001
DEBUG1: event: Key char=0, vk=0x28, nagr=0, lParam=0x01500001
DEBUG1: new mask: 0x2000
DEBUG1: new mask: 0x2000
DEBUG1: onKeyDown id=61268 mask=0x2000 button=0x0150
DEBUG1: send key down to "client-computer" id=61268, mask=0x2000, button=0x0150

// DOWN keyup
DEBUG1: hook: 0x00000028 0x81500001
DEBUG1: hook: 0x60280000 0x81500001
DEBUG1: hook: 0x70280000 0x81500001
DEBUG1: event: Key char=0, vk=0x28, nagr=0, lParam=0x81500001
DEBUG1: new mask: 0x2000
DEBUG1: new mask: 0x2000
DEBUG1: onKeyUp id=61268 mask=0x2000 button=0x0150
DEBUG1: send key up to "client-computer" id=61268, mask=0x2000, button=0x0150

here's a working log for the small latin letter "a" (which works fine and is received as keycode 38
// A keydown
DEBUG1: hook: 0x00000041 0x001e0001
DEBUG1: hook: 0x61410061 0x001e0001
DEBUG1: hook: 0x70410061 0x001e0001
DEBUG1: event: Key char=97, vk=0x41, nagr=0, lParam=0x001e0001
DEBUG1: new mask: 0x2000
DEBUG1: new mask: 0x2000
DEBUG1: onKeyDown id=97 mask=0x2000 button=0x001e
DEBUG1: send key down to "client-computer" id=97, mask=0x2000, button=0x001e

// A keyup
DEBUG1: hook: 0x00000041 0x801e0001
DEBUG1: hook: 0x61410061 0x801e0001
DEBUG1: hook: 0x70410061 0x801e0001
DEBUG1: event: Key char=97, vk=0x41, nagr=0, lParam=0x801e0001
DEBUG1: new mask: 0x2000
DEBUG1: new mask: 0x2000
DEBUG1: onKeyUp id=97 mask=0x2000 button=0x001e
DEBUG1: send key up to "client-computer" id=97, mask=0x2000, button=0x001e

Not sure if I decode this correctly, but my above log for "a" has "button=0x001e", which is decimal 30. Which would (+ offset 8) become keycode 38 in waynergy? is that correct?
The (non-working) buttons have these button hex codes => decimal codes => (esitmated incl 8 offset)
(SUPER) 0x015b => 347 => (355)
(LEFT) 0x014b => 331 => (339)
(UP) 0x0148 => 328 => (336)
(RIGHT) 0x014d => 333 => (339)
(DOWN) 0x0150 => 336 => (344)

after digging through wl_input.c for a while, I just decided to create a raw map instead, and it appears to be working:
[raw-keymap]
331=83
328=80
333=85
336=88

I got lucky for those four in particular, because my number block already did the "right" thing. I have no idea where I would have gotton those "target" mappings otherwise. Now I'm looking for SUPER, and if that works, I'm happy for now.
I should note that I was mapping the exact number from barrier to the exact number I wanted. Offset does not seem to play a role, here.

I learned about the tool xev which shows keycodes :-)
And that I probably had the wrong "target" keycodes above. Those are for the number block. Correct keycodes should be:
[raw-keymap]
331=113
328=111
333=114
336=116

in other words: there's no "simple" offset for these. Difference is 218, 217, 219 and 220 - coincidence?

Unfortunately the pattern doesn't really hold -- the keycodes sent by the various possible server platforms tend to align very poorly, especially once you move beyond alphanumeric keys.

Then I'll try to identify the remaining orange keys as best I can. But not tonight :-)

For a start, /usr/include/linux/input-event-codes.h can prove somewhat enlightening, with the caveat that any layout changes you've made in GNOME can throw things off (especially if you switch between the various national layouts).

Leaving this here for me for tomorrow:
Windows Key Ids ("button" as reported by barrier):

AltGr -> combines 0x1d (left ctrl) 0x138 (possibly right alt? not sure?) this key is always wonky on windows, though.
Super R -> 0x15c
Menu R -> 0x15d
Ctrl R -> 0x11d
PrintScreen -> 0x137
ScrollLock -> not sent, used to lock to one specific scren - nice, did not know about that!
Pause -> 0x45
Ins -> 0x152
Del -> 0x153
Pos1 -> 0x147
End -> 0x14f
PgUp -> 0x149
PgDn -> 0x151

eh... I finished it anyway. This is as far as I will probably take it, because I can not test the other keys on my laptop with much confidence.
[raw-keymap]
offset=8
#Left
331=113
#UP
328=111
#RIGHT
333=114
#DOWN
336=116
# Super L
347=133
# Super R - just using SUPER L here, i did not have a SUPER R to test and they do not differ.
348=133
# Ctrl R
285=105
# Pause
69=127
# Ins
338=118
# Del
339=119
# Pos1
327=110
# End
335=115
# PgUp
329=112
# PgDn
337=117

This is valid and tested for: Windows 10 running barrier as server and Ubuntu 21.10 running gnome with waynergy through uinput. Both machines have german keyboard layouts.
With the combination of barrier loglevel  Debug1 (look for "button=" and convert from hex to decimal) and waynergy loglevel 4 and the tool xev (look for keycode) pretty much everyone should be able to figure out further missing keycodes.

To make it slightly less tedious, it should be noted that the calls to strtol() all specify 0 as a base, so you don't need to bother with hex conversion as long as you prefix with 0x.

I'm not entirely sure how to proceed here. I could close this, because my immediate need is solved. I could put thin on a wiki if you think this might be valuable for other people. I could make an .ini from it, but it's not really complete, so I do not know if this is a good thing to do. It is really specific, but at the same time may save other people some time.

Under doc there is already a set of example xkb keycodes files contributed by others; supporting something like a config.ini.d directory would make including raw keymap snippets straightforward as well, so I'll get on implementating that.

For now I'll close this -- it's linked from the README -- though if anything else comes please do reopen

I updated the keymap so it works with current waynergy version and added some missing keys. Only tested with windows -> kwin (german layout)
Only missing AltGr and mouse buttons back and forward. Didn't found a solution for them yet.
[raw-keymap]
offset=8
offset_on_explicit=false

#Left
331=113
#UP
328=111
#RIGHT
333=114
#DOWN
336=116

# Super L
347=133
# Super R
348=134
# Ctrl R
285=105

# Pause
69=127
# PrtScn
311=107

# Ins
338=118
# Del
339=119
# Pos1
327=110
# End
335=115
# PgUp
329=112
# PgDn
337=117

# NumLock
325=77
# Num-/
309=106
# NumEnter
284=104

Is there a way to map extra mouse buttons? They come through in barrier logs just as:
[2022-05-17T17:57:15] DEBUG1: onMouseDown id=4 [2022-05-17T17:57:16] DEBUG1: event: button release button=4 [2022-05-17T17:57:16] DEBUG1: onMouseUp id=4


Add BertMesh to models so that we can tag in BioASQ

Description
Adds BertMesh in models by copying and not refactoring the experimental code in BertMesh. The reason being that at this point we want to maintain moving fast in experimentation while separating what we maintain for "production". As such we do not add code to train BertMesh as this happens still in experimentation mode. Once this becomes more stable we can do that.
DVC sort of up to date.
Checklist

[ ] Linked to Notion or GitHub issue
[x] Added tests
[ ] Updated README
[x] DVC up to date

The class is really nice, thanks for doing this. Can I be a massive pain and ask that you either add somewhere in the documentation the actual script/steps to tag (like the parameters passed to python scripts/tag_bioasq_test_data ? ) or add a dvc pipeline for that. Your choice.

Sure this is a good idea. Its kind of hacky at the moment.

This is ready to go. I will run the dvc pipeline on Monday to ensure it works smoothly in the latest batch and merge.


Add tvOS support, and clean up the project settings a little

This PR primarily adds tvOS support, but also includes cleanups to the build settings. I've moved all of the shared build settings back up to the project, and removed them from the targets where appropriate.

Ignore this — my master was out of date, and this will be a mongrel to merge.


Add boot stub env var to env-with-sim nix devshell

The Sonata simulator nix package includes a boot stub binary. This adds an environment variable to the env-with-sim nix devshell that gives the path to the stub binary.
This should only be merged when https://github.com/lowRISC/sonata-system/pull/102 has been merged and the flake.lock updated on this PR.

How do I test this? I know how to get the boot stub into the memory, but how do you specify the second elf?
This is the command I currently use:
./build/lowrisc_sonata_system_0/sim-verilator/Vtop_verilator -t --meminit=ram,./sw/cheri/build/tests/tag_test

You use the -E or --load-elf options.
./build/lowrisc_sonata_system_0/sim-verilator/Vtop_verilator -E $SONATA_SIM_BOOT_STUB -E /path/to/binary
Note this requires the changes in https://github.com/lowRISC/sonata-system/pull/102 to work

Ignoring the CI fail here, it's not related to the PR and I'd like to get this merged.


Implement threadsafe retries

The try package we were using is not threadsafe. This backoff package is, and can be used as a drop in replacement. The retry timing is slightly affected, but not significantly.

LGTM


infra: update knative.dev/net-istio from 0.39.0 to 0.39.1

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

Comparison is base (4ef5e77) 70.76% compared to head (ad37417) 70.76%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #214   +/-   ##
=======================================
  Coverage   70.76%   70.76%
=======================================
  Files           4        4
  Lines         195      195
=======================================
  Hits          138      138
  Misses         40       40
  Partials       17       17

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


Calendar in sidebar

I love the idea of having the calendar in day view in the sidebar as a daily agenda.
However, the calendar looks rather bulky when sized down to that size. Is it possible to make it integrate better into the sidebar?

The following CSS rules could fix that issue at least for the toolbar:
.fc .fc-toolbar {
	flex-wrap: wrap;
    margin-top: -0.375em;
    margin-bottom: -0.375em;
}

.fc .fc-toolbar-chunk {
	margin-top: 0.375em;
    margin-bottom: 0.375em;
}

Worst case:

Smallest normal toolbar:

Medium sized toolbar:

Thanks @MajorEnkidu
I also hope full- calendar could have suppose sideview.


DateTime array handling

Hello I need to work with DateTime arrays but so far the only option I see is using the MLCell array, which takes up too much disk space, would it be possible to implement a new array type for storing and reading DateTime values?

Hi,
I had the same issue and finally I store the datetime variables with format ole date (double) using the .NET function myDateTime.ToOADate().
In your MATLAB code you can invoke the .NET function that reconvert ole date to DateTime


Request Metrics

This adds support for sending request metrics to Honeybadger. Connect/Express support is native (via a new Honeybadger.metricsHandler middleware), or you can use Honeybadger.timing('app.request.NNN', 35) (where NNN is the status code (i.e. 200) and 35 is the duration in milliseconds) to send metrics from other frameworks or servers. It also adds a new metricsInterval config option which is 60000 (in milliseconds, e.g. 1 minute) by default.
Something to consider is that this introduces a new dependency on the mathjs package in order to do statistics. It wouldn't be terribly hard to remove this extra dependency by just writing our own stats functions (the code is already prepped for this). I just haven't done it because of time. :)

👍

Nice :)


fix(browse): Fix browse

You're right. I've removed it.

Coverage decreased (-0.03%) to 29.473% when pulling e7786fb8a66281068873f7ec6d14e48d4b772b8e on fix/browse into c02d4ecb97fc39f1b98d0e9ed85651f3a93fc843 on master.

Coverage decreased (-0.03%) to 29.473% when pulling e7786fb8a66281068873f7ec6d14e48d4b772b8e on fix/browse into c02d4ecb97fc39f1b98d0e9ed85651f3a93fc843 on master.


Detecting musl libc version

I see https://github.com/fastfetch-cli/fastfetch/commit/23d2cc3fdc1d1531174a67b0dd708b05a5cba43c was very recently commited and was wondering if there would be hope for running e.g. /lib/ld-musl-x86_64.so.1 (which would be the dynamic linker for fastfetch under relevant systems) which outputs for example:
musl libc (x86_64)
Version 1.2.4
Dynamic Program Loader
Usage: /lib/ld-musl-x86_64.so.1 [options] [--] pathname [args]

And parsing its output for the Version?
I can get the path to the linker via e.g. ldd /usr/bin/fastfetch (first line) but there's probably a smarter way to do that as well.

I'm also wondering if it makes sense to even hardcode the shown glibc version either, there may be cases where the program is compiled against, say glibc 2.36 and distro updates to 2.38 without the program requiring a recompile to keep running. In that case it would show a mostly irrelevant detail imho

The Version module was designed to print compile flags used / compiler used / libc used when fastfetch was compiling, because there were several issues filed before that running fastfetch in systems with old glibc version.
Detecting libc version that fastfetch running on, while should be possible, is a different topic.

Ah ok, thanks for explaining. I'll rename the issue accordingly

Why do you want that?

Now that I think of it the glibc/musl version for example are really just core things people don't really care about, they update in the background and whatever; now just knowing which one the distro is using is more interesting as https://voidlinux.org/ for example ships both glibc and musl images of the distribution (of course for most distribution this would be glibc similar to most having systemd while dinit, openrc etc also exists for init systems).


ASCII properties truncate to 7f while inverse or unassigned can be ff

This was something that was unclear to me at the time, but after digging into this more carefully, it is clear that we should limit Unicode properties, while in the ASCII mode, to the ASCII range, not the allowed character limit in byte strings.
So a property should yield characters within the accepted ASCII character range of 0x00-0x7f. Collections of unknown/unassigned characters can of course go up to 0xff and inverse properties can obviously count these "non-character" as well.

@gir-bot lgtm

@gir-bot lgtm


Basics of functions

Calculate the mean of a slice of integers
You're given a slice of integers.
Your task:
Return the mean of the dataset.
The calculation is performed as seen below:
x = [x1, x2, ..., xn]

n = len(x)

Sum(x) = x[1] + x[2] + ... + x[n]

Mean(x) = Sum(x) / n

Parameters:

numbers: A slice of integers.

Output:

float64, error: The mean or an error if the slice is empty.

Constraints:

An error should be returned if the numbers slice is empty.
Each integer can be either positive or negative.

Example 1:
Input: [4, 6, 9, 45, 8, 17, 3]
Return: 13.142857, nil

Example 2:
Input: []
Return: nil, "empty numbers" error

Just done


Update Catch2 to version 3

Update to the latest version solves the problem with error related to stack size.
In file included from /usr/include/signal.h:328,
from /symforce/third_party/catch2/include/catch.hpp:8152,
from /symforce/third_party/catch2/src/catch_amalgamated.cpp:15:
/symforce/third_party/catch2/src/catch_amalgamated.cpp:3580:54: error: call to non-'constexpr' function 'long int sysconf(int)'
3580 | static constexpr std::size_t sigStackSize = 32768 >= MINSIGSTKSZ ? 32768 : MINSIGSTKSZ;
|                                                      ^~~~~~~~~~~
In file included from /usr/include/x86_64-linux-gnu/bits/sigstksz.h:24,
from /usr/include/signal.h:328,
from /symforce/third_party/catch2/include/catch.hpp:8152,
from /symforce/third_party/catch2/src/catch_amalgamated.cpp:15:
/usr/include/unistd.h:640:17: note: 'long int sysconf(int)' declared here
640 | extern long int sysconf (int __name) __THROW;
|                 ^~~~~~~
/symforce/third_party/catch2/src/catch_amalgamated.cpp:3633:41: error: size of array 'altStackMem' is not an integral constant-expression
3633 | char FatalConditionHandler::altStackMem[sigStackSize] = {};

Unfortunately Catch v3 requires C++14, and I want to ensure C++11 is supported. I've upgraded to a higher version of Catch though in https://github.com/TartanLlama/expected/commit/b74fecd4448a1a5549402d17ddc51e39faa5020c


Add support enabling both fan out write and fan out read

Add support enabling both fan out write and fan out read

After research, the current fan out read is good enough.


BERT

Hello ,
I introduced some parameters to the text encoder (BERT) and trained for some epochs. Everything ran smoothly.
But when evaluating using the resultant checkpoint , I'm getting this warning about BERT new params:
"Some weights of Bert Model were not initialized from model checkpoint at bert-uncased and are newly initialized"
I think it will evaluate using the vanilla bert (without these newly added params). I guess that the trained params are loaded after loading the bert model which causes this warning.
So , what should I change in the config file in order to evaluate using BERT with these introduced trained params?
Thanks in advance !
cc : @aghand0ur

I ran into the same issue and made a few modifications to the way I load my fine-tuned BERT model. As far as I can tell, the newly initialized weights are only for the pooler-layer. In my case, I fine-tuned a BERT model using MLM, which doesn't train the pooling layer as it's not required for the task. In turn, when I save that model it doesn't include those parameters and when I re-load it it produces the error you mentioned.
From what I understand, the GD model also does not use the pooled output and uses the BertModelWarper() simply to access the outputs from each state more easily. In the GroundingDINO module (from models/groundingdino.py) in lines 267-269 the code uses the last hidden state and trains another linear layer on top of it, ignoring the pooling layer.
I think when loading a fine-tuned BERT model, only the pooler-layer weights are newly initialized, and not the fine-tuned parameters. So in theory, I think for using GD the warning doesn't really matter. For my own sanity to ensure at least nothing is initialized randomly, I implemented this function to load my fine-tuned BERT model and re-initialize the pooler weights with the ones from a pre-trained BERT model.
def mlm2bm(text_encoder_type, model_path):
    ''' Load fine-tuned MLM model as BertModel and replace the pooling layer
        weights with the original ones. MLM models don't require a pooling layer. '''

    original_model = BertModel.from_pretrained(text_encoder_type)

    print('Loaded original model')

    # Save the original pooling layer weights
    original_pooler_weight = original_model.pooler.dense.weight.clone()
    original_pooler_bias = original_model.pooler.dense.bias.clone()

    # Load fine-tuned MLM model as BertModel
    fine_tuned_model = BertModel.from_pretrained(model_path)

    # Replace the pooling layer weights with the original ones
    fine_tuned_model.pooler.dense.weight = torch.nn.Parameter(original_pooler_weight)
    fine_tuned_model.pooler.dense.bias = torch.nn.Parameter(original_pooler_bias)

    print('Replaced pooler weights!')

    return fine_tuned_model

Hope this helps!


Add Qovery option to deploy Flask

Hi the Flask maintainers,
I added docs on deploying Flask on Qovery. We already have more than 100 developers deploying their Flask app on Qovery. - feedback is welcome.
Romaric.

Do tests hooks are working?

Tests are working again as of ~9 hours ago, maybe you branched before then.
Thanks for looking at this, glad to hear about another service that supports Flask. However, I'm not currently adding more links to this section. I'm working on a general rewrite of these docs to emphasize software and configuration over specific services. The current list represents the most common services (at least that I've heard of), but I'll be evaluating that as well. I may consider adding sponsored links in the future, I'll keep you in mind.

Ty for your fast reply @davidism. Please let me know if we can support Flask in any way :)
Romaric.


Rebase unity bro exe onto master

Upon approval and being merged, this branch should replace unity_bro_exe
This PR is for taking our commits from the unity_bro_exe branch and applying them to the updated version of brotli (our master branch is already in sync with the updated version of brotli, and purposely excludes these Unity specific commits). The branch unity_bro_exe is the one that we reference in the editor as the brotli executable.
I did the following to test the changes:

Update unity_bro_exe to my branch name in: https://github.com/Unity-Technologies/emscripten-builder/blob/main/build_brotli.py
Build brotli: https://unity-ci.cds.internal.unity3d.com/project/949?nav=jobDefinitions
Manually copy the zip here: https://github.cds.internal.unity3d.com/unity/unity/tree/trunk/External/Compression/Brotli/Brotli
Create a new trunk build with the change and test out building and playing a game with brotli compression to make sure things look as expected

I only tested this on Mac so far, I plan to test on Windows but will reach out to QA for help testing Linux. Decompression fallback should also be tested.
These are the brotli builds I generated with my changes (step 2 above):

Windows: https://unity-ci.cds.internal.unity3d.com/job/25242712/artifacts
Mac: https://unity-ci.cds.internal.unity3d.com/job/25242710/artifacts
Linux: https://unity-ci.cds.internal.unity3d.com/job/25546483/artifacts

Before overwriting the old branch, it would be good to test the new Brotli against Unity web builds with brotli compression enabled.

Before overwriting the old branch, it would be good to test the new Brotli against Unity web builds with brotli compression enabled.

@juj Is there a difference between what you're saying here and the testing method I outlined in the PR description?

Ah right, no the description in the PR comment reads great. 👍

I didn't see this until review request now...

@brendan-duncan that's okay, thanks for reviewing it. This work is on hold anyways while I work on some higher pri tickets.


Insufficient documentation for Beta version of request

[Enter feedback here]
Would be very helpful if you displayed how these requests are to be made using the Graph Client in C# and other languages like on the non-beta docs.

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

ID: 7c59a30c-47c7-42d8-59a8-da11fa35243a
Version Independent ID: a2b14964-5512-9183-9cc8-ad00e55e146d
Content: reportRoot: getTeamsUserActivityUserDetail - Microsoft Graph beta
Content Source: api-reference/beta/api/reportroot-getteamsuseractivityuserdetail.md
Product: reports
Technology: microsoft-graph
GitHub Login: @sarahwxy
Microsoft Alias: MSGraphDocsVteam

@sarahwxy
The block types for the http examples are marked "ignored" preventing them from being picked up for snippet generation. Any chance you could confirm if this is intended?
https://github.com/microsoftgraph/microsoft-graph-docs-contrib/blob/0a1d2898c8ec41bc6a54bb90a034c429ffdc8896/api-reference/beta/api/reportroot-getteamsuseractivityuserdetail.md?plain=1#L128


Different behaviour between mockResolvedValue and mockImplementation

🐛 Bug Report
In the documentation mockFn.mockResolvedValue(value) is described as a simple sugar function for jest.fn().mockImplementation(() => Promise.resolve(value)), but I noticed a different behaviour when using ES2018 Promise finally().
The tests pass with mockImplementation() but fail with mockResolvedValue() and return this error: finally is not a function.
To Reproduce
Use ES2018 Promise finally() in your application (importing babel-polyfill for example) and try to test it with mockResolvedValue() and mockImplementation().
Expected behavior
The result should be the same with both implementations.
Link to repo
Here is a simple example.
Config
Node: 8.11.1
Jest: 23.2.0 (empty config)
Babel: 6.23.0 (babel-preset-env)
Babel-polyfill: 6.26.0

Is there a workaround for tests with code using finally() until this is resolved?

In my tests I imported babel-polyfill in the setupTestFrameworkScriptFile file and when I need to mock a function that returns a promise, I use the jest.fn().mockImplementation(() => Promise.resolve(value)) syntax instead of jest.fn().mockResolvedValue(value) .
I'm not sure it's the right way to do but it works.

A slightly shorter workaround is jest.fn().mockReturnValue(Promise.resolve(value)) - also works.

Been having this issue as well. I can add in a .finally polyfill, but mockResolvedValue seems to avoid it somehow.

I also have a similar issue (not obviously related to .finally though). I'm testing a React component that has several synchronous calls and mocking the return values of those calls.
When I use
mockedFunction.mockResolvedValue({ success: true })

the test fails (due to not actually waiting for the mocked promise to resolve), but when I use
mockedFunction.mockImplementation(() => Promise.resolve({ success: true }))

it works as expected.

Was a fix found for this?

@lgc13 I did this to get around it:
mockImplementationOnce(() => Promise.resolve("response"))

The solution for me was to start using Node 10+ which supports finally.


-f / --upstream_trainable not working in ER run_downstram

I tried using the -f/ --upstream_trainable  option during the downstream training ER task, however i get the error below

I would like to use this finetuned upstream to do inference

I got the same error, sir. How did you solve this problem?


[program-2022, token-client] Add confidential mint and burn support

Subsumed by https://github.com/solana-labs/solana-program-library/pull/7570 and https://github.com/solana-labs/solana-program-library/pull/7575. The token-client updates will follow in https://github.com/solana-labs/solana-program-library/pull/6881.


fixes a small typo

Issue #, if available:
Description of changes:
Fixes a small typo Postgre to Postgres
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thanks so much!


Add more ignore

.vscode
.idea
folders

The ones you mention are already .gitignored..

Aw snap, but they're not .npmignored... somehow I figured that .npmignore would be a superset of .gitignore but I now realize that's rubbish.

Next version will be a bit cleaner, thx!


Server Error: Error: resource of type taxonomy_term--team not found.

I have used (npx create-next-app -e https://github.com/chapter-three/next-drupal/tree/main/examples/example-webform) command to get the webform and followed (https://next-drupal.org/docs/guides/webform) for the installation. When i run the development server , i am getting this issue. Can anyone please help on this.

@bandita0907 The page is looking for a teams vocabulary to load the options. Have you created this on the Drupal side?

Visit /admin/structure/taxonomy.
Add a vocabulary named Team.
Add some terms.
Then run the Next.js site again.5.

Thank you so much for helping :) it got solved

@caroline-dsouza This looks like a different error. It looks like the next.js site cannot find the Drupal site. Can you check if you got everything configured as per the quick start?

@caroline-dsouza I'm going to close this as done/stale. Feel free to reopen if not. Thank you.


arm64 support

What problem could Sentry solve that it doesn't?
Unreal Engine supports both x64 and arm64 Linux dedicated server but looks like Sentry only works with x64 dedicated server. Can you please update the plugin to support arm64 too?

Fair request. We'll be looking into it!

I have the same problem and hope it gets fixed soon

@namnq-sipher @kestye Currently to use the plugin on Linux platforms we're relying on static sentry-native libs for which we currently don't have a proper mechanism allowing to build their arm64-compatible versions in GitHub CI environment.
However, we've been using dynamic versions of sentry-native libs in the past which should work for LinuxArm64 just fine. There is a branch support/linux-static-libs where those are still in place so you can try it out. The corresponding plugin packages can be downloaded here.
Please let us know whether the suggested workaround worked for you or if any other question regarding the above arise.

@tustanivsky It seems that the download above is broken. Could you link a new one please?

@slsewall Please try this download link. Also, note the support/linux-static-libs branch was updated to the current main state

Unfortunately that didn't work for me, I may need to drop Sentry for now until you guys get LinuxArm support out of the box as I don't really have time to diagnose this fully and it's insane to get non LinuxArm Linux servers on gamelift for some reason.

Thanks for the update. As it was mentioned earlier building sentry-native libs compatible with LinuxArm64 in our CI is somewhat challenging at the moment however I'll revisit this and see what other possible options we have.

Unfortunately that didn't work for me, I may need to drop Sentry for now until you guys get LinuxArm support out of the box as I don't really have time to diagnose this fully and it's insane to get non LinuxArm Linux servers on gamelift for some reason.

Thanks for the update. As it was mentioned earlier building sentry-native libs compatible with LinuxArm64 in our CI is somewhat challenging at the moment however I'll revisit this and see what other possible options we have.

Thanks that sounds great! I wish that I could just do x64 linux but unfortunately Gamelift is giving me grief on that front. If I can figure out how to make it work I'll let you know from my end as well.

Bump For LinuxArm64 Support

For context, from the marketplace:

We're looking at the GHA hosts on Linux arm64 so we can get this going. cc @mitsuhiko

I added a runner. Named ubuntu-latest-4-cores-arm64.

Currently, the new ubuntu-latest-4-cores-arm64 runner, which we're using to build sentry-native in CI to enable arm64 support for the UE plugin, has Ubuntu 24.04. This causes some compatibility issues between the produced binaries and the Unreal itself (even with UE 5.5 Preiew 1). Can we switch the arm64-runner to use Ubuntu 22.04 (recommended OS version) instead and see if it resolves the problem?
Current runner version: '2.320.0'
Runner name: 'ubuntu-latest-4-cores-arm64_1466ce6f6385'
Runner group name: 'Larger Runners for GDX'
Machine name: 'runner'
VM Image
  OS: Linux (arm64)
  Source: Marketplace
  Publisher: arm
  Offer: github_arm_linux_runner_2404
  Plan: github_arm_linux_runner_plan_2404
  Version: 1.0.4


Test against PHP 8.2

This PR adds test against PHP 8.2 in CI

@exussum12 could you please take a look when you'll have a time? Cheers


Add forward declare before dumpKey for toJson in jsony.nim

Fixes #88 with an error about forward declares.

This is confirmation of the fix working: https://github.com/Luyten-Orion/Supernovae/actions/runs/9423600338/job/25962330132

Sorry I don't understand why this is needed?

Sorry for the late reply: I'm not sure why the error actually happens, I assume it's due to some template magic that trips up Nim, in #88 I linked my repo to show the issue but couldn't figure out a reproducible example


panic: runtime error: index out of range encountered when deploying a chaincode

Description
I've encounter a bug:
This is what I do in command line:
./peer node start
./peer chaincode deploy -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Function":"init", "Args": ["a","100", "b", "200"]}'

then I get the stack trace:
15:35:46.812 [main] serve -> INFO 014 Starting peer with id=name:"jdoe" , network id=dev,
address=<IP_ADDRESS>:30303, discovery.rootnode=, validator=true
15:35:46.835 [rest] StartOpenchainRESTServer -> INFO 015 Initializing the REST service on <IP_ADDRESS>:5000, TLS is disabled.
panic: runtime error: index out of range
goroutine 28 [running]:
panic(0xd43b20, 0xc8200100d0)
    /opt/go/src/runtime/panic.go:464 +0x3e6
github.com/hyperledger/fabric/core/chaincode/platforms/golang.(*Platform).ValidateSpec(0x15439e8, 0xc82012d4f0, 0x0, 0x0)
    /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/platforms/golang/platform.go:56 +0x494
github.com/hyperledger/fabric/core.CheckSpec(0xc82012d4f0, 0x0, 0x0)
    /opt/gopath/src/github.com/hyperledger/fabric/core/devops.go:266 +0x261
github.com/hyperledger/fabric/core.(*Devops).getChaincodeBytes(0xc8201a58c0, 0x7f6882509430, 0xc8201fc660, 0xc82012d4f0, 0x100, 0x0, 0x0)
    /opt/gopath/src/github.com/hyperledger/fabric/core/devops.go:93 +0x24d
github.com/hyperledger/fabric/core.(*Devops).Deploy(0xc8201a58c0, 0x7f6882509430, 0xc8201fc660, 0xc82012d4f0, 0x0, 0x0, 0x0)
    /opt/gopath/src/github.com/hyperledger/fabric/core/devops.go:111 +0x78
github.com/hyperledger/fabric/protos._Devops_Deploy_Handler(0xde7b40, 0xc8201a58c0, 0x7f6882509430, 0xc8201fc660, 0xc8201fc750, 0x0, 0x0, 0x0, 0x0)
    /opt/gopath/src/github.com/hyperledger/fabric/protos/devops.pb.go:198 +0x132
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc82020e4e0, 0x7f6882509240, 0xc8201fe750, 0xc820096300, 0xc8201dda40, 0x1504bb0, 0xc8201fc630, 0x0, 0x0)
    /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:350 +0x847
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream(0xc82020e4e0, 0x7f6882509240, 0xc8201fe750, 0xc820096300, 0xc8201fc630)
    /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:467 +0x743
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).Serve.func2.1.1(0xc82020e4e0, 0x7f6882509240, 0xc8201fe750, 0xc820096300, 0xc8201fc630, 0xc82011ec80)
    /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:278 +0x49
created by github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).Serve.func2.1
    /opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:280 +0x5ac

Describe How to Reproduce
I installed hyperledger-fabric on ubuntu 14.04 on an Amazon web service EC2 m3.medium instance.
By manually running the hotfixed shell script in:
https://github.com/ghaskins/hyperledger-fabric/commit/10cd6f300b40616e0265a684ffe582a83d6322e1
and running ./devenv/setup.sh
both ./peer node start & ./peer node status succeeded with normal status. The above error is triggered when using the ./peer chaincode deploy, which also caused the node to be terminated.
Thanks a lot for any instructions!

@tribbloid can you let us know commit level of the fabric you are running with ?

closing this as there's been no response to @muralisrini question. Please repoen if the problem persists in a more current version, such as v0.5-developer-preview.

I encountered this same error as well.
I don't really know why, but GOPATH environment variable was not red correctly at runtime (it was empty) although I could access it in my terminal. It may be a Docker related issue.
I fix it by launching my peer this way :
GOPATH=$GOPATH ./peer node start

My Fabric environment was up to the commit 5cb39849ec2adc3505e523355684eb7370cc85 (august 16th)


Dot in route

Why i can't to serve this url? Can. :+1:  php -S does not.
$app->get('/manifest.json', ...);

had the same problem with php -S, can be fixed if you specify the php script:
php -S localhost:8080 index.php

The PHP internal server usage is documented here: http://silex.sensiolabs.org/doc/web_servers.html#php-5-4


SDK-87 -- Android InstallListener exception when not on UI thread

Reference
SDK-87 -- Android InstallListener exception when not on UI thread
Description
If an event is logged and the thread logging it is not the UI thread, there was an exception where the code is creating a new Handler() just to wait for 1500 milliseconds before reporting the install referrer.
This change uses a Timer instead.  Normally Timers should be avoided, but for this short of a duration it should not cause any issues.
Note
Note that there were lint warnings as well, so I cleaned those up while in here.
Testing Instructions

Sample app should continue to function.
Unit tests should all pass

I wrote a unit test (on a different branch) that proved the exception occurred before and is fixed afterwards.  Unfortunately that branch is now behind this one so unit tests were not checked in here.
Risk Assessment [LOW]
Most of the changes here were around getting the unit tests in the other branch to prove the issue exists, and prove the issue was resolved.

[X] I, the PR creator, have tested — integration, unit, or otherwise — this code.

Reviewer Checklist (To be checked off by the reviewer only)

[ ] JIRA Ticket is referenced in MR title
Correctness & Style

[ ] Conforms to Style Guides
[ ] Mission critical pieces are documented in code and out of code as needed

[ ] Unit Tests reviewed and test issue sufficiently
[ ] Functionality was reviewed in QA independently by another engineer on the team (clone for each required reviewer)

👍 makes sense to me


SecItemAdd status = -34018

I'm trying to store and read a value in a FlutterApp running on MacOS using prerelease 5.0.0-beta.4.
I just straight up create a storage then store a value and immediately try to read it.
Every time after the write  I get the log output SecItemAdd status = -34018 and the read value is null.
I couldn't find any information regarding this status code.
final storage = FlutterSecureStorage();
await storage.write(key: 'key', value: 'TEST');
print('READ: ${await storage.read(key: 'key')}');

I added Keychain Sharing as a capability to the Runner.
flutter doctor -v output:
[✓] Flutter (Channel stable, 2.2.3, on macOS 11.4 20F71 darwin-arm, locale en-DE)
    • Flutter version 2.2.3 at /Users/maxfornacon/development/flutter
    • Framework revision f4abaa0735 (7 weeks ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

[!] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/maxfornacon/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7281165)
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/macos#android-setup for more details.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5.1, Build version 12E507
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7281165)

[✓] Connected device (2 available)
    • macOS (desktop) • macos  • darwin-arm64   • macOS 11.4 20F71 darwin-arm
    • Chrome (web)    • chrome • web-javascript • Google Chrome 92.0.4515.159

! Doctor found issues in 1 category.

Couldn't test this on any other OS yet.

Can you try again with v5.0.0-beta.5?

Unfortunately, v5.0.0-beta.5 does't solve the problem for me. Maybe I configured something wrong.
I'm not very experienced developing apps for MacOS yet and your documentation to set up flutter_secure_storage isn't very specific about it.

I also am having the same issue on ^5.0.0-beta.5

It doesn't happen when I use:
flutter_secure_storage:
    git:
      url: git://github.com/openresearch/flutter_secure_storage.git
      ref: feature/macos_support

FYI

Doesn't work for me because the fork doesn't support null safety.

I just realised that I was editing the Xcode project for iOS instead of MacOS the whole time. Therefore I did add Keychain Sharing to the iOS capabilities but not for MacOS.
However, I can't confirm that it solved the issue yet because since I needed to activate code signing in Xcode I can't get the project to build successfully.
I get the following output.
error: Provisioning profile "MacBookProvisioningProfile" doesn't include the currently selected device "MacBook Pro" (identifier xxx). (in target 'Runner' from project 'Runner')
** BUILD FAILED **

But this is most likely not an issue of the package.

I can confirm now that it was an issue related to configuration problems in Xcode.


Update metrics-core to 4.1.19

Updates io.dropwizard.metrics:metrics-core from 4.1.18 to 4.1.19.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.dropwizard.metrics", artifactId = "metrics-core" } ]

labels: test-library-update, semver-patch

Superseded by #118.


Live metrics stops working when adding KeyedServices BEFORE AddApplicationInsightsTelemetry() in dotnet 8 rc2

List of NuGet packages and version that you are using:
Microsoft.ApplicationInsights.AspNetCore
Runtime version (e.g. net461, net48, netcoreapp2.1, netcoreapp3.1, etc. You can find this information from the *.csproj file):
net8.0 (sdk 8.0.100-rc.2.23502.2)
Hosting environment (e.g. Azure Web App, App Service on Linux, Windows, Ubuntu, etc.):
When running on Windows locally, but in Azure on Azure Container Apps with chiseled image: mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled (Linux)

Describe the bug
When using KeyedSingleton together with AddApplicationInsightsTelemetry(), depending on the order, the Live Metrics in Azure won't work. Expect this to not matter in what order, or to get an explanation for why this happens. This might be an issue that should be reported to the team working on dotnet 8 and KeyedServices instead.
To Reproduce
Simple repo to showcase the issue: https://github.com/westmatte/keyedsingleton-livemetrics-issue/tree/main
Needs to add the instrumentation key to an existing app insights in the appsettings.json to run of course.
Alternatively, create a new dotnet 8 minimal API. Add application insights to it. See that the Live metrics work. Add KeyedSingleton for whatever BEFORE the AddApplicationInsightsTelemetry(), Live metrics no longer works. In program.cs:
builder.Services.AddSingleton<StupidService>(); // old stuff, works perfectly fine
// builder.Services.AddKeyedSingleton("StupidServiceKeyed", new StupidService()); // if adding this here, Live Metrics wont work
builder.Services.AddApplicationInsightsTelemetry();
builder.Services.AddKeyedSingleton("StupidServiceKeyed", new StupidService()); // if adding this after AddApplicationInsightsTelemetry^, Live Metrics will work perfectly fine

We will close this issue if:

The repro project you share with us is complex. We can't investigate custom projects, so don't point us to such, please.
If we will not be able to repro the behavior you're reporting

We've just hit this. Right now it prevents targeting net8.0 without workarounds, and worse - it's enough if a project references Microsoft.Extensions.DependencyInjection.Abstractions v8 (which is supported on net6 as well), so simply by a dependency update (not retargeting to new framework) it can crash. Precondition of inserting Keyed registration is still required.

Just to add to this as i was about to type up a bug ticket for the same issue until i found this.
You can get past this for now by changing your DI ordering. If you do the application insights before you do the keyed service injections then it will work.
The reason this is failing is because of the internal "AddSingletonIfNotExists" extension method in the library which is looping through the already registered services.
If you take the example code below and change the order so Example2 is before Example1 you will notice it works as the extension method is not conflicting with keyed service that have already been registered. Its not a DI issue in itself, its more a bug with how they are looping over the pre-registered services when trying to register more.
I have abstracted the code below from the library which is causing the issue, to help show why its breaking, so people have an example to work from:-

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);
builder.Services.AddKeyedScoped<IExample, Example>("example");
builder.Services.AddSingletonIfNotExists<IExampleTwo, ExampleTwo>();//Breaks due to extension method

using IHost host = builder.Build();

public interface IExample { }
public class Example : IExample { }

public interface IExampleTwo { }
public class ExampleTwo : IExampleTwo { }

//Abstracted extension from Application Insights library
public static class Extensions
{
    public static void AddSingletonIfNotExists<TService, TImplementation>(this IServiceCollection services)
        where TService : class
        where TImplementation : class, TService
    {
        if (!services.Any(o => o.ImplementationFactory == null && typeof(TImplementation).IsAssignableFrom(o.ImplementationType ?? o.ImplementationInstance.GetType())))
        {
            services.AddSingleton<TService, TImplementation>();
        }
    }
}

I just spent a day debugging some changes unrelated to Application Insights that was hit by this bug. Luckily the changes never made it to production, since the application crashed on startup due to this setup in our Serilog config:
WriteTo.ApplicationInsights(services.GetRequiredService<TelemetryConfiguration>(), TelemetryConverter.Traces)

The TelemetryConfiguration was not registered due the exception thrown in AddSingletonIfNotExists.
After hours of debugging to figure out what I changed to cause this issue, I isolated it to adding resilience to an HttpClient with AddStandardResilienceHandler() from Microsoft.Extensions.Http.Resilience.
Either AddSingletonIfNotExists has to be updated to handle keyed services, or the ServiceDescriptor implementation has to be changed to not throw exception on property access.
The workaround of having to register Application Insights (or anything else not updated to handle keyed services) first, before anything using keyed service, is not acceptable in the long run. This will not scale as keyed services usage increases in the future.

@tore-hammervoll This was not meant as a permanent fix, it was simply to allow people to progress while the Microsoft team look into it and resolve the problem. My suggestion was to save people having to go through and look at the internal code just to get their setup working.
I do agree with you that in the longer term, this issue will need to be looked at but i would assume thats why this ticket is still marked as "open"?

@wc-whiteheadd My post was not intended as a response to the workaround, that was unintended. The workaround you posted has unblocked us from this bug, and is much appreciated.
I only intended to stress the importance of an actual fix, before this problem gets bigger when more third party packages (or official Microsoft packages) starts relying on keyed services. The consequences of this issue is a bug that is hard to debug, especially when it is triggered by completely unrelated changes. That coupled with the fact that it can even be hard to discover since the exception is caught in AddApplicationInsights(), and only manifests as live metrics not working in a running application (I suspect their are other potential issues caused by this, as there are several services that are not registered properly when this exception is thrown). I do not envy anyone finding out their live metrics (or whatever else) has not worked for days, weeks, or even months, and need to find out what caused it.

@tore-hammervoll that makes senses and i completely agree with you, this certainly needs fixing quite urgently. Hopefully our information will help their investigation into fixing it faster 😄

Wow, just spent hours trying to figure out why a simple application insights setup didn't work in my .net core 8 web api.
I put the application insights setup above the keyed services and its working now.
Get it fixed ASAP please.

I would like to bump this as well!
It is still a problem. It manifested in our case because we upgraded a totally unrelated nuget package, but because of this is de ordering of Services.Add... methods super important. This is completely illogical.
Please prioritize this

1+
Just hit this while working with Semantic Kernel, which have Keyed services in all their examples.