193/194 build, dev slide, DSIGInfo tool, and some 2015 spec updates for OS/2 and CBDT/CBLC

Known issues are:

The DSIGInfo tool is not hooked up to be built by make yet - the build instruction is a long one-line at the top of the file itself. Also, none of README/dev slide mentions the DSIGInfo tool or related matter.

The OS/2 2015 spec update requires further action of rebuilding the help file and the resource file OTFontFileVal/OTFontFileVal.ValStrings.resources . Until then, if you test a font with a OS/2 table below 5, it would correctly warn that the version is not up to date, but mistakenly say the latest is 3.

The 5 commits at the top of HEAD, 3 of them bundled binaries for convenience, 1 for a small subset of Mono's code require for DSIGinfo (and a small modification of Mono's code on top from me), are not mine; but they do have a license compatible for re-distributing under the MIT license. Skip them if you are uncomfortable.

FontVal-RELEASE_2015_11_12 tarballs and binaries are finally without a password at
http://sourceforge.net/projects/hp-pxl-jetready/files/private-test-data/

Hi @HinTak, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

Quickly added the 41th commit which updates OTFontFileVal/OTFontFileVal.ValStrings.resources  - apparently I already done it on my HEAD so it is just a cherry-pick, just haven't rebuiit the help file yet.

Since it's MIT licensed, another option is to just fork the repo, merge your patches there without needing a CLA signed, and then we can all use that instead.

@pomax is the CLA a blocker for you to contribute on Mozilla time?

Well, it is already forked, so the question is really whether I want to become the de facto maintainer :-(.
There is also the tricky question of, if I (perversely) want to sign the CLA, do I then become the "by-pass" person to go to, where people who is unwilling to sign a CLA just give me their patches either publicly or privately and hope that I'd pass them on?
The CLA issue actually is somewhat affecting whether I am willing to pull non-trivial patches from people...

do I then become the "by-pass" person to go to, where people who is unwilling to sign a CLA just give me their patches either publicly or privately and hope that I'd pass them on?

That would not be wise.

I would not recommend that either. The CLA, while quite annoying, is designed to protect everyone involved that the content submitted is the creation of the person submitting it. By acting as a by-pass, you run the risk of being responsible for submitted content.

Mozilla will not pay me to work on font technologies (too far from the work I do for them), and I will not sign CLAs as a person for projects like thes, where the CLA seems to exist solely to pretect against litigation that may result from closing the source again.
A plain old CONTRIBUTORS.md that says "by contributing code to this project you agree to surrender any and all copyright" is more than enough.

@Pomax kindly I think your position is relevant to the CLAs of yesteryear, which were mainly about consolidating copyright assignment with a single corporate entity so that it would be possible for them to 'close the source again in the future.' That is not what the MS and Google CLAs do, you retain your copyrights.
Instead what they do is protect themselves - and all co-contributors and users - from attacks that attempt to make the software proprietary despite the MIT license. Copyright is only one of the monopoly rights available, and another big one is US software idea patents – which the MIT does nothing about.
With MIT, someone can submit code to a project that implements an idea they have applied for a US patent on, and then when the code is accepted and your patent granted, they can sue the users and co-developers for patent license fees. Apache is preferable to MIT for this reason, since it has patent protection built in (as do GNU licenses) which prevents co-developers from attacking each other in this way, although it doesn't stop non-contributors' attacks; the largest example of that is Microsoft extracting patent fees from Android OEMs, and I've read stories of that revenue being larger than Windows itself at this point.
This is one example of the way in which permissive licenses like MIT and Apache add cost and complexity to libre software development; I'm with HP CTO Martin Fink - https://lwn.net/Articles/660428/ - on the benefits of copyleft for removing the need for CLAs like this.

good link, good points, but the information required to fill out the CTA currently linked is more information I'm willing to hand over to Microsoft (or Google or Facebook or anyone else, really). Hopefully they switch from MIT to a better license in the nearby future.

Hopefully they switch from MIT with a necessity for a CLA to a better license in the nearby future.

This seems unlikely to me. The main question before us is if most people who want to contribute to the project will not do so if it is housed here because they refuse the CLA. It seems that may be the case.
I think if this repo doesn't see another commit and development moves forwards centered around Hin-Tak's repo, that's probably alright - at least the code is not longer rotting away and can progress again.

@HinTak
Why are you bundling freetype binaries in the source?

@moyogo: it is just convenience - I like the outcome to be immediately usable (and for windows) on build. You are free to clone/fork below that point. I re-ordered the commits for that reason.

I got the CLA notice, and I have filled in the form to receive it, but I have not looked at it yet. As for filling the form to receive it, if I remember correctly, it wasn't more information than I already gave to receive the (broken/stripped...) source bundle a few months ago; so it isn't more information to Microsoft than I have already given. Others' decision will obviously be different.
My decision of whether to sign the CLA depends on what it says exactly, of course. I'll write again if/when I finish reading it.

@moyogo: a slightly longer explanation of the 4+1 commits at the end of that 40 - two of them are win32/win64 binaries of freetype and its dependencies. If you don't care about windows, you can drop them. One is SharpFont - if you are willing to build the SharpFont from its git, you can drop that commit too.  That is only needed by the DSIGInfo tool; if you are not interested in DSIG, or absolutely do not want to take on code which is neither microsoft's nor mine, you an skip that too. You do not have to take them all - that's what 'git cherry-pick' is invented for.
What I posted is as close as to what I myself work on - i.e. minus ugly hacks and misc debug codes which I am too embarrassed to show - as possible. You do not need to accept them all. But all of them have a MIT-like license, or, in two cases, I think 'GPL with exceptions', the latter means AFAIK I am allowed to post them and re-distribute them as uncustomized dynamic libraries (dll's). I am allowed to post them; you don't have to take them.

@HinTak It’s bad practice to commit this kind of binaries in git. They’ll be in everybody’s copy of the git repository forever. Git is not a binary distribution system. This kind of binary should be in release packages. You already provide the sources which is enough.
The right way to do this is to link to the packages people need to download for convenience and add the platform specific patch to the Makefile for people who want to build themselves, not to include the binaries in the sources.

@HinTak MS or anyone is free to cherry-pick your commit as they wish. I’m just saying one wouldn’t have to do this if binaries are in convenient packages outside of git instead.

@moyogo: have you actually read the README? or tried ripped the binaries out and build your own? I provide them for the reason that they are not available elsewhere, nor easy to build. win64 freetype needs an additional patch than stock upstream release. SharpFont you will need to build from from their latest git, and you need not only mono, but the whole monodevelop (mono's GUI dev environment). I myself actually had problem building monodevelop myself, which is only on the way to build SharpFont! (and that'd because and before I contributed enhancement to SharpFont to make this project possible).
Don't blame me for trying to make other developers life easier.

@HinTak I think you’re misreading me. I didn’t mean to imply you’e done unnecessary work. On the contrary, thank you for all you work! I’m just saying binaries are better in packages, not in git.

@moyogo: actually SharpFont's guy did the same thing as I do, and arguably still do so now - he used to bundle them with his source, now  puts his bundled binaries in a git submodule. I am not using his git submodules, as I found a number of issues with them(reported to him), besides the fact that his freetype binary build are not as up-to-date as required Font Validator. Font Validator requires freetype 2.6.1 and no less, because a contributed patch from me went in after 2.6.0. FWIW, even fedora 23 which just comes out last week, ships freetype 2.5.5.

@HinTak Yes, I understand that up to date or patches libraries are required, there is no issue there. A binary package one can download and put in the right location, git annex, git lfs, or even a git submodule are better than keeping compiled binaries in the main source repository.
Anyway, I’ll stop there.

@moyogo: my suggestion is, if you feel strongly about this issue, clone up-to just below the binaries, (I re-ordered the commits for this reason), and provide detailed instructions to build the binaries, then push your binary-free fork out for other to use.
For me, the binaries sum to about 7MB, and I kept multiple past versions (before freetype was released, and I had to use snapshot versions; in fact even while the patches are revised) in my repo, and it does not bother me that I use git to store muitiple past versions of binaries.

One can use git filter branch to remove files from a git history btw

@HinTak @davelab6
7MB of convenient binaries out of a 22MB repository, that’s already 1/3 for binaries. Add 7MB next time the binaries are updated, that’s 1/2 for binaries, another 7MB each time after that.
After a few updates the binaires will make cloning the repository slow, checking-out branches will be slower, browsing the git history will be slower.
One can just make a fork, cherry-pick, filter and figure out how to prevent getting a bloated git history, instead of telling developper they can get the binary dll from a zip file.

@moyogo: why are you obsessed with this issue? It is a single binary drop. When a new Sharpfont release comes out with the required enhancement, we'll review the decision of using a single    tested/trusted snapshot. You bundle 3rd party things when only specific snapshot works. As for freetype, we have only stopped using snapshots only a short while ago. This may be the one and only binary we ever provide - although we anticipate further enhancement needs to go in for the rasterisation test, further down the road.

@moyogo: if you are obsessed with bundling binaries, I suggest you look at the resgen issue listed in README-extra.txt. We bundle auto-generated res files because they are difficult to make. And likewise, the chm file because it is difficult to make. You could contribute a non-Window chm compiler, for example.
This discussion is not constructive.

And the xsd issue also - all of them to do with bundling things which are difficult to make.

@moyogo: FYI, my Linux kernel repo tracks about 20+ upstream branches, and is 2GB+ bare. My mono repo is about 300MB bare. My wine repo 300MB bare. Both of the latter are directly related to FontVal dev. If I need another 7MB, I'll just go and run 'git gc' in either of those. You are losing your sense of proportion.

@moyogo: talking about the efficiency of browsing history with 40+ commits is bordering on insanity. My main dev branch alone contains 500+ commits, and that's just 1 branch of 3 quite diverse branches. In the course of this project I had to regularly search history in mono and wine, both of the have 15+ years of history. By comparison,  40+ commits is nothing.

This discussion is not constructive.

@HinTak Sorry. In the great scheme of things 7MB is nothing. Use git the way you see fit.

to be fair, binary updates will bloat the repository really quickly, so having the binary as external dependency instead of living on the repository itself is generally good project management. If the binary can be fetched from its official location during bootstrap instead (pegged to whatever version is necessary) then that's infinitely better than having it explicitly commited as files in the patch.

@Pomax: look, this is a single drop to get thing started. It is not a series of "binary updates". The whole point of bundling these blobs (not just the binaries, but also the res files, etc), is that they add dependences - sometimes very large ones, like the whole of dotnet SDK (where mono is insufficient), wine (to run dotnet SDK), monodevelop (to build SharpFont), a whole cross-compiler chain to build the win32/win64 binaries of FreeType. Adding wget and curl is just substituting one problem with another. Sorry.

@Pomax: if I go down the road of requiring wget and curl, why not the whole mingw32/ming64 gcc cross-compiler chain? After all, I do not intend to drop support for windows.

@Pomax: FYI, monodevelop itself is 45MB, and it requires gtk#. That's many times 7MB. And we are still actively filing and fixing problems in mono, which is 300MB bare, and needs up to 2.7GB disk space to build. It is in fact not even 7MB - git compresses and is capable of binary diff's also, in case you are not aware.

And what is the difference between a single drop in the repository and a one-off separate download? Nothing. All of it is so that people can spend their time on where it matters, instead of hunting down /building these not-interesting but necessary binary blobs. Wasting time on this 7MB discussion is not really not helpful.

I recognise that the 7Mb is trivial. I suggest though that part (perhaps
the majority) of the purpose of this discussion is for Denis and Michael to
get to know what it is like to work with you, how you accept suggestions
and deal with ideas you don't like. If you want people to send you ideas or
patches - or money - I suggest being more conciliatory :)

@davelab6: it goes both ways - I haven't seen any other contributions from  certain people except going on and on about one very insignificant issue in the grand scheme of things. I'll have a bit more patience towards people who had contributed something else, patches, etc, however little. In any case, I have a 300MB bare mono repo which blows up to 2GB, and filing and fixing bug on that, and 7MB somewhere is so not a concern. I'll like some of them to pick any of the bugs listed in readme-extra, and tackle it, for example. Some of the commenters do not appear to have read the readme.

All the bundles - not just the binaries, but also many of the generated files, like *.resources, the chm help files, the xsd file, - are there so that somebody can start looking at the font tests and where it matters, armed with only mono, GNU make, and an editor. No monodevelop, no donet sdk running under wine,  no Microsoft help workshop under wine, no c compiler targeting windows. Yes, to get to everything I pushed out, you need all of those 4 , in addition to mono and make. To be honest, if I had put everything that can be generated elsewhere, I am sure some people would ask "why can't I just do make or configure, make, and it just happens, and have to stare at cryptic messages, download 3-4 things elsewhere, install a few more things, before I start?".

I think my comment was misinterpreted. In terms of long term solution, make it an external dependency, but there is no reason to do that immediately as part of this patch.

The one that I just pushed, is a big part of 194/194 :-). It can now verify ttf digest correctly. (ttc is not yet implemented).

:+1:

194/194 build: Finished testing and uploaded src tar ball and binary bundle as 11-21 to:
http://sourceforge.net/projects/hp-pxl-jetready/files/private-test-data/
Notable change is of course the DSIG test works!
Known differences with MS's DSIG are:

it doesn't validate trusted certificate chain [yet] - i.e. it will okay a valid signature signed with a toy certificate. (some might say that this is a good thing). I intend to warn on toy certificates, rather than summarily failing the test.

it now shows signer's info also, in addition to saying it passes. (definitely an improvement).

it attempts to validate TTC v1 signatures with a warning. MS's DSIG check ignores signatures in v1 headers - ironically Windows 8.1 still ships two fonts signed this way (the two korean ttc's), and their own tool claims that those two aren't signed...

Unexpectedly, I seem to have found a copyright violation while testing (a failed verification, and copyright in name table not agreeing with the signer's identity - looks like somebody re-branded a font as his own and forgot to strip the signature). Reported elsewhere. So that's a novel use of this code.
Currently known issue is that the TTC code does not calculate hashes correctly for rather old TTC's around the win98/ME/win2k time frame. This issue is known to affect these 4 specific fonts:
FontName="Batang" FontVersion="Version 2.21" FontDate="18/12/2000"
FontName="Gulim" FontVersion="Version 2.21" FontDate="18/12/2000"
FontName="MingLiU" FontVersion="Version 3.21" FontDate="17/05/1996"
FontName="MS Gothic" FontVersion="Version 2.30" FontDate="16/03/1998"
and known not to affect this
FontName="MS Mincho" FontVersion="Version 2.31" FontDate="22/06/2001"
nor later versions of these fonts in Vista. This issue isn't as serious as it sounds as MS's DSIG check does not even attempt to verify Batang and Gulim shipped with win 8.1. Please send me a copy of such old TTC's if it should verify but it isn't.
Special thanks to Cosimo.

+1 for not failing a font over a valid DSIG that happens to not be backed by an expensive authority =)

:100:

@aaronbell is this pull request ever going to be merged in upstream master?

@anthrotype Yes, as soon as @HinTak signs the CLA. :)

Thanks Aaron.

New hybrid build under:
http://sourceforge.net/projects/hp-pxl-jetready/files/private-test-data/stuff_special_usage_only/
I updated the hybrid branch since the wintrust DSIG hack in it can be removed.
There also seem to be a demand/interest on the MSIE-based XML viewer.

About the CLA, my thought is that it is simply unimportant whether I sign or not, until either (1) a sufficiently interesting enhancement from somebody else comes along, one that  isn't about removing tests/warnings/errors, but about adding support to new tables, new tests (and more information/warnings/errors), or new functionaiity, and need to decide where to merge, or (2) Microsoft or another party needs to package up/adopt some of it into a semi-proprietary version for their paying customers. Until either of these happens, people can just keep posting patch updates, as the current arrangements continue. People can comments on what goes on in each other's branch, and selectively adopt specific changes (or not) as they see fit.
I do have a look at the clone network graphs to see what goes on in others' branches, so that's not a problem; and so far nobody refrain from commenting on mine either :-).
There is no need to decide any time soon. One day when I make up my mind about signing the CLA or not, this thread can close.

I'm okay with that :)

I filed
https://github.com/Microsoft/Font-Validator/issues/8
as place holder for Updates to current 2015 spec.
Some community members can tackle some of the issues raised, by contributing code additions. Please add to the page, if any of you spots part not up to current spec, or add font sample URLs with new features, to help.
I'd suggest questions/suggestions/pulls about past codes go to Microsoft's issue tracker. I'd open my own issue tracker, so that I can receive suggestions and issues on the parts I added - the OS/2 multi-lingual code page support, the freetype backend, the DSIG check, the Makefile and the build system (there wasn't any - MS removed those before I got it) - I also added bug fixes, etc to specific fonts I see, etc, and questions about those changes can go there also.
Apologies about the small rebase of the last two commits. Adding new tags as known tables was easy and obvious, but the fix to mis-identifying TTC DSIG as garbage of last table of last member font wasn't well-tested. As it was only less than 24-hours since I pushed, I decided to merge the corrrection and rebase, rather than push the fix out separately. Hope nobody was affected.

Hm, I just compiled this PR on win7 pro x64, and get an interesting error:

That's correct. The xml viewer code based on it was never released, although the hybrid branch works around that by loading the relevant dolls from the 2003 binary and treat them as libraries. Read readme-hybrid.txt, and the first page of the pdf slide as well as the hybrid branch part.

A new source tar ball and binary bundle is at:
http://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/
And I have put out a new hybrid build also:
http://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/win32.hybrid/
Since the last update, it accepts the 2015 spec newly added tables (COLR/CPAL/MATH/SVG) as valid, but does not perform any check yet. The DSIG check prints the signing time (windows-only), as well as validating the certificates against known issuing authorities (non-windows-only; 'make USE_MONO_SECURITY=true' and a separate 'DSIGInfo-mono.exe' in the binary bundle). It also generates html files for reports on non-windows, since neither chrome nor firefox's noscript extension allows web pages to read local files, to load xsl style sheet for displaying xml.
Seeing as so many of you are interested in the GUI/visual aspect of the reports, I shall explain what the hybrid build is: some components of the Font Validator were not open-sourced - functionalities are missing. This limitation is worked around in the hybrid build by copying and re-using a few dll's from the 2003 binary. The missing functionalities currently consist of only the XML report viewer, and rasterization tests.
Thus besides implementing 2015 spec updates [1], I have made a place-holder for discussion on enhancing FreeType for the rasterization tests [2], XML report viewer [3], unifying/abstracting the security difference between windows .NET and mono for DSIG check [4]; and given the overwhelming interests from windows users, re-implementing building with MS visual studio [5], and an interesting side project, Mac OS X stand-alone executables (i.e. without needing to install mono)
[6].
At the moment, Mac OS X stand-along executable is perhaps easiest - just pending me having enough disk space to do it (the procedure creates some very large temporary files), but I'd like to defer that until some progress is made on non-windows XML report viewer (and fixing problems with the aging windows one).
MS visual studio build'able could benefit from Microsoft folks' input in the form of  supplying redacted version of the original...
I was not sure about auto-generating the html version of the report - how many are for (chrome needs it; really only IE allows loading local xsl style sheets), and against (redundant)?
Besides contributing code, or clicking on the donate button, some of you can help by identifying specific  areas of 2015 specs need implementing, or supplying font samples which actually make use of the latest features.
The donate button (
http://sourceforge.net/p/hp-pxl-jetready/donate/
)
at the top of the downloads do work - and please free to click! :)
[1] https://github.com/Microsoft/Font-Validator/issues/8
[2] https://github.com/HinTak/Font-Validator/issues/5
[3] https://github.com/HinTak/Font-Validator/issues/6
[4] https://github.com/HinTak/Font-Validator/issues/4
[5] https://github.com/HinTak/Font-Validator/issues/8
[6] https://github.com/HinTak/Font-Validator/issues/7

Given sourceforge's amazing adware in their installer, does it make sense to do use github's releases (using tags)?

:+1: for using Github Releases.

The conflict is intentional - I have done the XSL change to support non-IE based XML viewer in a slightly different way. (i.e.  I'd like Microsoft to unmerge moyogo/fval ).
Most people probably follow
http://typedrawers.com/discussion/1222/microsoft-font-validator-lives/
anyway, but here is a rehash. This latest group of changes does two things - The first thing is re-written the XML report viewer code. Now it continues to use IE on windows, but webkit under linux and gecko on wine. This is mostly done to use support Mac OS X better, since Safari has a webkit back end - but the XML report viewer does not work on Mac OS X yet, though it works on linux now! The 2nd thing is to make it possible to build the font validator as a native Mac OS X executable without depending on mono.
There is a FontVal-MacOSX-*.tgz under
(current 2016-01-06):
http://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/
As I wrote before Christmas, it is a standalone mac os X command line binary, no need to install mono separately. If you have an up to date freetype, you just run it plain. If you have a vanilla mac os X box without homebrew/macport etc , you set DYLD_LIBRARY_PATH to where you unpack the "Darwin" sub-directory - there are just 3 files, the binary, and up to date freetype dylib, and libpng (which freetype depends on).
Please feel free to click http://sourceforge.net/p/hp-pxl-jetready/donate/ to donate...

@Pomax : as for github vs sourceforge, I don't know what the reference to an "sf adware installer" is about - it is a web site with a set of fairly good transparent mirrors across the world; you just use a web browser for sf?
Anyway, it is mainly just familiarity - I have been on sf for 15 years, and github less than 6 months. In the last 15 years, a few others had come and gone (Google Code shutting down soon, Microsoft's Codeplex winding down). github doesn't seem to let me tag...

Oh, this is another important milestone, as another piece which Microsoft did not release (the XML report viewer) got replaced/re-written. There is just the rasterer left. I don't know how many find that part of the hybrid build useful - I know the 2003 raster cannot cope with about 20% (!) of current mac os x shipped fonts - , so there isn't any incentive to continue the hybrid build any more.

@HinTak sourceforge a while back decided to add installer adware into their more popular open source downloads, it kind of blew up when they did it with the Gimp (see http://www.theregister.co.uk/2015/06/03/sourceforge_to_offer_only_optin_adware_after_gimp_grump/ and a google for related terms will generate a lot of hits, it was pretty ... amazing, really. No one loved them for it). They were dragging their feet on the "opt-in" thing, still having it bundled in people's downloads without permission, so that was pretty much the point where I permanently stopped with sourceforge. Github offers the same functions, just under different buttons, so "browse source" is just GH's main view, and downloads are under github's "releases" tab. If you tag any commit in git (with git tag -a "tag description"), and push that up to github (with `git push branchyouareon --tags") then github will automatically turn that entire commit into a packed archive so people can download it with a single click. It's pretty convenient!

@Pomax : thanks for the tips - I was just missing the "--tags" in the push :-). I'll go back and re-tag them and push soon.
I haven't downloaded anything from sf for a while (been busy on you-know-what...!) - and I tend not to download binaries anyway :-). A pity about sf, but then, OS developers have billls to pay, etc, and very few people can survive on donations only Richard Stallman style...
and rather unsubtle hints: please do click the donate button if you feel that Font Validator should continue...

Actually 'git push --follow-tags' is the correct answer. The difference between --follow-tags and --tags is that the former only pushes tags reachable by the refs/commits being pushed, whereas the latter is every tag not in the far side (i.e. including tags in totally unrelated local/private/remote branches, etc). I think --follow-tags (all tags in the commits/refs being pushed) is I always want, so I did 'git config --global push.followTags true'.

2016-01-22 was tagged,
http://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/
Compared to the last (2016-01-06), there are many Mac OS friendly improvements on the native executable - this is the 2nd release snapshot built for mac os X to run without mono. Also for the first time since being open-sourced, new tests are added: 6 tests on SVG table are added, which makes the total number of tests 200 now. There is also a new SVGInfo tool, which can pretty-print SVG table data for further detailed manual examination.
It does a fairly comprehensive checking of the SVG table, and support transparent decompression of the SVG data, as well as trying to load them as XML to check for syntax errors.
Also minor addition to supporting newer GDEF table.
Please do make a donation (
http://sourceforge.net/p/hp-pxl-jetready/donate/) if you find this useful. I am still exploring how this might continue. It does take a good amount of effort and time.

@aaronbell any chance that for this incredibly substantial amount of work the CLA requirement gets waived? This project has taken on a bit of a life of its own, and got incredibly better because of it.

@Pomax I don't fully understand why @HinTak isn't agreeing to the CLA...

It just isn't a priority to spend time reading the CLA . It is only useful to merge when there is something else to merge to.

even if it's just to "Set up a new branch with all this code, on github", that'd be worth it honestly. I'll be happy to donate towards a new printer if it gets your code into this repository =)

@Pomax - all the code is on github. And I see that github is taking my git tags and using them to provide download tar balls. I just just sf for posting binaries. The instruction for packaging the mac os X native executables is a rather tedious and messy manual process and my notes is just getting tidied up, but otherwise everything is on github.
FWIW, I already have 4 printers - two of them are unwanted and unopened gifts from the Linux Foundation, actually, and one of them (an HP color laser printer capable of printing 46 pages per minute with duplex unit and possibly also network access , and worth about £1200 or $1800US retail) still in the original box. I actually have permission from my Linux Foundation contact to sell it to recover the sale, so if you are anywhere near South East England, I am more than happy to sell and even do the delivery. It is a 38 kg beast which I like to get rid of.

wow. I mostly mention printer because that's what the link you gave seems to be for =)

@Pomax - that's how I got into fonts - to print. Two decades ago, trying to print chinese in postscript to western printers without built-in chinese fonts was really difficult... and so I even went as far as writing my own printer drivers.

That's certainly one way to roll into it! Sounds like it might be worth changing the "purpose" for the paypal donation link to read something like "more font technology development by Hin Tak". As for the github thing: aye, the code's on github, but right now it's mostly tracked through this PR, which makes it a little harder to have people discover it; most people into fonts are not all that much into programming beyond maybe scripting for their design applications, so the idea that someone else's fork is actually where all the real code lives is not going to occur to them, so there'd be value in getting the code landed as a branch here that you get to merge to, with the github settings for the project set to mark that branch as the "main" branch when people visit the repository URL. As software authors, we know how to get the "real" code, but there's plenty of people who won't, and that feels a bit like leaving the font community missing out on an awesome upgrade to the MS (although... at this point, is it still MS?) Font Validator

BTW, I have turned from the latest tables and started on CFF, the oldest which Microsoft didn't do, and already have a new tool called "CFFtool" written to examine postscript data structures. This was mentioned in my mailing list posts to various, at the end. Just in case somebody is also working on that (!).
This would be somewhat old territory - almost two decades ago I took the trouble to read the 900-page postscript reference cover to cover, to get better postscript CJK printing. Did not understand some of it then, obviously... The understanding comes a little later.

If I could make a recommendation: focus on only parsing modern CFF rather than going back to PostScript, as modern CFF-OT has pretty much nothing to do with PostScript other than "some of the same ideas".
The Tech Notes for both the CFF and Type2 specification (Adobe Tech Note 5176 and 5177) are short and easy to work with (think <100 pages combined instead of 900!) so if you have font parsing experience, which it's safe to say you absolutely do, it should be much easier than it may have been in the past =)
Can I also again request you change the purpose of the donate link you give? If you want people to donate towards continued development on this validator, having them see "Continued development of Font Validator" as donation purpose makes a big difference (especially to people who are on the fence about making a donation).

Yes, the CFF and Type 2 specs are fairly short and sweet by comparison. Actually PLRM and Adobe specs are rather more readable than the MS opentype specs :-).
Thanks for the suggestion about the donation link. It is not that I am unwilling to change what it says on the donation link - apparently, I had a donation link because I had set it up some years ago, but that feature isn't enabled in newer registered projects (I have actually registered a sf project for this also :-)). This is due to some policy changes between sourceforge and paypal. I looked it up and tried.

You could set up a plain paypal donate outside of sourceforge for this? If you run through the "create a donate button" process on paypal, After you've picked all the options, and you create the button, you get two versions: the button HTML in the "button" tab, but there's also an "email" tab, which is the link straight to the paypal donation page that you just created a button for, too.
You can then use that link instead of the hp printer link.

As for when it will stop being "Microsoft" Font Validator, I just see one scenario - I have been trying to ask for a more up-to-date binary for private reference to implement the rasterisation test. I know it exists because the code itself says Microsoft updated it after 2003. But I have not had any success so far.
I have tried to explain to the Microsoft folks that it is for their benefit - rasterisation with freetype is ultimately different from rasterisation with the MS font rasterer; that it works with freetype is meaningless whether it works with windows. So the only way it is beneficial to them, is to make freetype matches my font rasterer's behavior. I have no intention of seeing that part of the source code, but I need to be able to match the "outcome", i.e. Shows the same errors/warnings under the same circumstances. The 2003 binary is too buggy to worth matching for  - it is like beating up a cripple, no honor in that :/ .
So if I ever start spending time implementing the rasterisation tests without access to a more up-to-date binary, I would/should consider withdrawing this pull request, as everybody else (linux, android, even mac os X ships freetype in CoreGraphics) uses freetype, and font validator only tells you compatibility about non-windows!
I made the offer to help them to match ms rasterer's behavior. If they won't take the offer, it is not my fault.

@Pomax Sorry for the late reply! I've been sick :(
In any case, I've asked Legal several times and tried to find out if there are any mechanisms for waiving the CLA requirement. Unfortunately there are none. I don't think our OSS guidance was set up with this sort of scenario in mind.

2016-02-08 was tagged on github ( https://github.com/HinTak/Font-Validator ).
Code snapshots (-src-), mono/.net binaries (-bin-) and Mac OS X disk images (.dmg) are at:
http://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/
Compared to last (SVG addition on 2016-01-22), the main addition is the long-overdue addition of CFF checking. This flags errors in quite a few fonts from well-known vendors: Adobe's Arno fonts, Mozilla's Fira fonts and two font sets from the TeXLive distribution for having non-ascii strings in the String INDEX , and two fonts from Apple's OS X for using obsolete dictionary keys (removed 16 years ago). And possibly many more. Please contact the relevant vendors if/when you see CFF errors flagged.
So it looks like this work is much needed - and there are a few more CFF checks to add; I 'll put an github issue entry up for further work.
There is a small GDEF update to check additional fields introduced in v1002, and workaround to two mono bugs to shof correct build version under "about..." in the GUI.
Please do make a donation (
http://sourceforge.net/p/hp-pxl-jetready/donate/) if you find this useful. I am still exploring how this might continue.
Interested parties, from the large corporations like Microsoft, Adobe, Google, Apple, to smaller schools and universities teaching typography/font design, foundaries, please consider commissioning part of the continual development.
Oh, and Happy Chinese New Year!!!!

I have a achievable plan to begin to make rasterization test working:
https://github.com/HinTak/Font-Validator/issues/5#issuecomment-182210815
So that's next. It will probably be months though. People can contribute with code, comission/donation, etc.
Added SVG and CFF further work issues and notes -
https://github.com/HinTak/Font-Validator/issues/12
https://github.com/HinTak/Font-Validator/issues/13
If others want to have a go at some of those also.

I have been thinking about withdrawing the pull request for a while.
There are many ways Microsoft folks can contribute: of course they can put some dev resources and hours to it, or commission outsiders (not necessarily me, but that would be welcomed) doing some work; two unique ways they can contribute is (1) supplying a less-antique binary than 2003 - https://github.com/HinTak/Font-Validator/issues/5 - I know they updated the code as recent as after the 2009 2nd edition opentype spec, (2) help fix visual studio building so that more Window centric devs can contribute -https://github.com/HinTak/Font-Validator/issues/8 - . There are about 20 opened issues at the moment, some involves updating the build instruction docs, reading the specs and documenting what needs to be done . Many do not require a lot of special knowledge, just time.There are discussions going on in the Opentype mailing list they can participate, and there are past design decision they can clarify.
And while it isn't useful for practical purposes, providing binaries based on the stock august 11 upload, just to demonstrate that they can cope with using the open mono + GNU make build chain, instead of visual studio which they had been doing for 13 years, would be assuring too.
Hopefully we would see better participation from Microsoft folks.
There exists an implementation of the rasterisation test in my hard disk, and a few other bits on CFF also.

This year's Google Summer of Code is starting to accept student application in a week or two. For those who are unfamiliar with it, GSoC is a scheme where Google sponsors about 1000 students around the world each year - for just over 10 years now - to work on a project of the student's choice, under the guidance of an expert in that area, for about 3 months in the summer. (I think the students get $5000 US, which is not bad for amy summer job, especially when it doesn't even require leaving the house!)
The Linux Foundation has been a mentoring organization for almost every year, and is in this year. I mentored a few students under the open-printing initiative for a few years, as well as a couple of students working on various parts of the linux kernel in the past also.
The Microsoft Font Validator can go under Linux Foundation's openprinting. The Mono Project was a mentor organization in the past, so if they are in this year also, student can apply under the mono project too.
It is allowed to apply under two orgs, which can increase the student's chance of being accepted.
So if you work for an educational organization, or know students with suitable skills interested in that, please forward.

Cool - please post on typedrawers, etc :)

Re-reading some of the e-mails, I am reminded by @davelab6 , , who is honest but kind in the best possible way, that maybe I have not explained and communicated well to @aaronbell why I really want a more "recent" internal binary, whichever 'more recent' means.
The issue I am facing from my experience with FreeType vs MS renderer on LTSH/hdmx/VDMX is that there are going to be differences. Some maybe my lack of understanding of freetype, (e.g. I was initially very excited by freetype giving perfect "hdmx" calculations, until I learned that freetype is optimized to just read the table and tell me, unless told not to, so of course the agreement was perfect!), bugs in freetype, bugs in my new code, and bug in the 2003 binary, bug in the specific font, or just "behavior differences". But I need to understand and account for all the differences until I am happy that all the differences are well-understood. If I get a 'close enough' answer, I can move to the next task. If they differ, I 'll dig.
Having a buggy 2003 binary actually means wasting me time debugging the 2003 binary to make sure that the difference is because I am correct with the new freetype code, and the old 2003 binary is wrong. So it takes extra time.
Besides causing me extra time, if microsoft is afraid that I might learn something I shouldn't, denying me a more recent and less buggy binary will result in exactly what they are afraid of: I may have to dig inside the proprietary 2003 binary to understand that it is buggy, and how buggy in exactly what way, after exhausting the other possibilities like modifying my own new code etc. So putting me in a scenario where I need to dig inside the proprietary 2003 binary to understand why and in what way it is buggy, may actually lead me to learn something I should not. If the new implementation agrees with the old, and the old is correct , I have no reason to dig. The worst is a 3-way disagreement: freetype said one thing, the old binary says another, and the built-in LTSH/hdmx/VDMX tables in the font says a 3rd answer (which should be 'correct' according to the last font editing apps that wrote them). There are indeed 3 way disagreements, even now, of those tables, on the common platform fonts. I keep notes about which of the three is correct, and try to tick the disagreements off one by one.
And I do not look forward to a 3-way disagreement in rasterisation, which is far more complex than calculating the tables.
So, I hope this is a better explanation why I really like a less antique binary for private reference.

dig inside the proprietary 2003 binary

What does the binary EULA say about that?

presumably "reverse engineering is illegal", which is likely technically overruled by the law that protects reverse engineering for public research purposes, but could equally well lead to lawsuits.

could equally well still lead to lawsuits

Indeed. Even if not, that kind of thing certainly makes rightsholders unhappy. Even just publicly discussing that kind of thing as a possibility is hostile.
Since Hin-Tak's goal is to be given something by a rightsholder, then doing things that make them less than joyful undermines the possibility the goal can be achieved at all.

I hope this is a better explanation why I really like a less antique binary for private reference

It does explain why your life would be improved by MS sharing the binary, but it isn't clear how MS benefits. I can't see anything in your comment about the benefits to MS of releasing the binary.
There is also a wider context to your request: Since you have - so far - not co-operated with MS, by not signing their CLA, then I am not sure anyone at MS is going to think too hard on any suggestion you make.

Hmm, okay, I thought the message was meant to make the situation better, not worse. Anyway, my goal is to make the new code covers no less than all the grounds that the old covers; at least judging from some of the reactions of the users over the last few months, 'why isn't X there?' , where X had been the XML report viewers a few times, and the rasterization test at least once as I can recall. (despite both being mentioned as 'not included' both initially and repeated a few times there after).
Perhaps the new code is too similar to old that users' expectation seems a bit high :-(.

I would also like to say it again that, reading lengthy legal document is hard work; reading a lengthy legal document with sufficient attention to details to decide whether to agree with it or not, is even harder work. So being handed a piece of legal document to read, feels a lot like piling on more home work, and unnecessary one too, as a punishment for being hard-working.

And I hope nobody is suggesting one should sign any legal documents without reading every word carefully, and thinking about it.

@davelab6 , @Pomax : ask a Mozilla developer who has ever tried to figure out why the Adobe flash plug-in crashes firefox, for example. He or she might know a thing or two that Adobe does not want people know. The process is just called 'debugging proprietary plug-ins without the source'. It is not a pleasant process, and few people are motivated or have the skills to do it. If the proprietary plug-in is not buggy, there is no need to spend time on it. And as long as there are users who want to watch flash movies, and as long as the Adobe flash plug-in is the only plug-in to provide that functionality, there is a need to go in that direction. Please do not try to call the process a different name.
As for the CLA situation: 5 months ago ( https://github.com/Microsoft/Font-Validator/pull/1#issuecomment-159311953 ) I already said, it is not important, and it is waiting for another interesting fork. If somebody comes up with interesting enhancements that I like to include, and he/she is unwilling to sign the CLA. That would polute my fork, then I have to forfeit the CLA too. If Microsoft comes up with interesting enhancement I like to include, and the CLA allows a merge, it would go in the other direction. Until another interesting enhancement happens outside of my fork that I need to merge, it is simply not important for me to read the CLA. And not reading the CLA means not deciding. If you want me to make a decision whether to sign the CLA or not, come up with an interesting enhancement that I like to have. Keep on asking will not change to situation.

it isn't clear how MS benefits

Please do answer this

I already said, it is not important

This is the problem, Hin-Tak. What is important is not for you to dictate, but emerges out of the shared values of the people involved. Aaron tried to see if the MS CLA could be avoided, and it could not. It is important to him that contributors sign the CLA, and your unwillingness to do so shows that you don't care about his needs; so it is no wonder that he appears uninterested in caring about your needs.

Putting my enhancement out there is already a significant contribution. Extra work reading a lengthy legal document is extra work.
Microsoft folks can help a merge by adding enhancements that are worth merging with. Other contributors may have enhancements I like to incorporate with, and that are in conflict with a CLA. Until another interesting fork happens, both of these are still possible - @davelab6 : I am not dictating, I am leaving the options open. The possibility that others may contribute which are in conflict with my CLA, is slightly higher than Microsoft contributing to the future development, although both are small.
As @Pomax already responded, he cannot contribute while signing a CLA; and I cannot take on his possible change if I have a CLA in place; so this is leaving the option open for him to contribute: I am allowed to take up his change, if the change in interesting enough, and I do need to worry about the joint branch poluting and violating my CLA.

Please try not to use words like 'unwilling', 'dictate' or other emotionally charged labeling like 'threats' etc. Not deciding is simply that, not deciding, and leaving the options and possibilities open. I have been trying to explain how and when an decision can be made, and it is quite tying.
FWIW, I have been asking for code contributions from the community too, not just Microsoft; and trying to make it easier for people to contribute too, like reviving the support for building with the more common visual studio. I don't personally use MS VS, but there are people who uses it daily, fair more than mono. So I am still waiting for an interesting enhancement outside of my fork to happen.

Not deciding is simply that, not deciding

That's not how social reality works.

I certainly know how frustrating it can be to seemingly get ignored while having the best intentions, but one thing to remember is that Microsoft is not people. It's easy to forget when we're discussing on Github in a PR with comments by Microsoft employees, but @aaronbell, the awesome person, doesn't really get a speak for Microsoft, the company who owns the Font Validator code, when it comes the kind of legal questions you have, @HinTak.
It would be incredibly valuable if you could have a look at the newer code to see if oddities you're seeing in a three-way parsing difference can be disambiguated, but this is not something Microsoft, the company, can easily do. As a multi billion dollar company, even if Aaron wanted to, Microsoft is so large that it has to go with what its lawyers say they can do, or they would open themselves up to all kinds of IP losses. That's where good faith comes in.
I won't sign a CLA as an individual, because I am not willing to operate on the legal level required for this project. In consequence, I haven't contributed any code, and am unlikely to. However, if I were as driven as you were to fix up the Font Validator to conform to the modern spec, then I probably would sign that CLA because the world as a whole benefits from that far more than I am inconvenienced by it. But then of course I would also ask that my code be reviewed not just as code but also from a legal standpoint, because I do not have the resources to guarantee everything I wrote was IP unencumbered.
I would, in that position, also love to see Microsoft's newer code to solve the problem you're having, but asking for that, without showing good will first (companies are terrified of the pandora's box that gets opened when a traditionally closed source project goes open source) and making them feel like my contributions are valuable to their company. Not just the people in the team whose repository I'm contributing to, but the actual company itself. They need to see that the work I did, for free, for my benefit, benefits them, too, and companies don't value words much: a CLA, a signature on an NDA, an agreement of collaboration, etc. are the kind of things that open the doors behind which the people can be found that might help.
Is it frustrating that this is how things work? Absolutely. Should we change that? As a bit of an idealist yes, I think we should. Should we force that? As a realist, no. Making demands, forcing hands, without showing willingness to cooperate in a language that companies (not people) understand just gets great ideas shut down, so in this case I'd suggest a brief respite to gather some thoughts, see if for the amount of work you did you might be willing to sign the CLA, and allow me to make that more interesting for you: I would be happy to send another donation if it makes the difference between the development you've put in so far getting cut off over this, and showing Microsoft that not just you, by I as well, want to make an effort to meet them where they are, so that we can find a way forward that is beneficial to everyone, not just "everyone except Microsoft".

That's not how social reality works.

Not sure what you mean by that. I am, however, quite tired of being the only person making interesting enhancements on this project. If forfeiting the CLA is a direction to encourage contributions from people who are against it to contribute, that's an option and possibility I'd like to leave open.
Again, this is not a "threat". Signing the CLA to merge with a Microsoft enhancement, or merge with somebody else's contribution who is against the CLA, are the two future possibilities. Until another interesting fork happens, still there. Until then, there is no need to spend time reading a lengthy legal document to decide.

Font Validator gains python scripting ability, and ttc-splitter/merger scripts.
Announcement on
http://typedrawers.com/discussion/1558/microsoft-font-validator-gains-python-scripting-ability-and-ttc-splitter-merger-scripts
binary:
[1] https://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/FontVal-empy-bin-2016_05_07.zip/download
code:
[2] https://github.com/HinTak/Font-Validator/tree/embedding-ironpython

I have re-implemented (part of) the last missing piece, the rasterization test, which tests for hinting problems. One announcement is up at -
http://typedrawers.com/discussion/1673/font-validator-with-rasterization-i-e-hinting-test-out-now
code and binaries at the usual places, and please feel free to click the donate button above the download links. I'll prepare a Mac OS X package in a couple of days.

On 10 July 2016 at 23:58, HinTak<EMAIL_ADDRESS>wrote:

I'll prepare a Mac OS X package in a couple of days.

Will you take in the commits that are on Georg Seifert's branch?

I realized that the need for a more up-to-date binary is only to create quality analysis reports on fonts of my choice to look at (versus many bogus warnings/errors from the 2003 binary). If I cannot have quality, large quantity of interesting, if many bogus, reports would do too:
http://typedrawers.com/discussion/1658/old-ms-fontval-reports-to-spare-or-computer-time-to-make-new-ones
and even that isn't needed - to get interesting reports, it isn't necessary to analyze on all sizes - the interesting hinting errors are in the smaller sizes, and one (out of size 4 to 72 plus a few above) would do very well.
Thus I have cut possibly 3-4 weeks of test run time of all 2000 fonts on a typical linux system down to 7 hours. Am collecting reports on Apple shipped fonts now, and there are many more interesting reports to look at.
FYI, only about 2/3 of linux shipped fonts pass (expected to be a bit lower than microsoft's own, around 4/5). And quite interestingly, The proportion of Apple shipped fonts are lower.
The current list of interesting errors with accompanying interesting fonts to look at - i.e. potential hinting errors that could be detected - are up at ( https://github.com/HinTak/Font-Validator/issues/5 ).

The process of implementing the rasterization test is simply looking at the analysis report from the older binary, which says exactly which byte at which glyph is problematic. Then look at how FreeType behaves around those bytes at those glyphs. Some of the reports are wrong, but so far, most of the analysis are correct, and they turn out to be (silent) workaround for buggy fonts in FreeType's code through out past history - half of it corresponds to bug reports submitted to FreeType's bug tracker e.g. - "I have this buggy font which causes FreeType to choke - can you have a look?"
So nothing like cool reverse-engineering going on there re-implementing the rasterization test. Just looking at interesting reports which say a font is problematic at a particular glyph at a particular byte with a particular problem, and see how FreeType behaves there. Often enough, I saw a comment in FreeType code at exactly that spot, with a comment 'some fonts are so brain-damaged, we try to cope this way'. My diagnostics patch is just a 'tell me about it at this spot'.

I have tagged and uploaded another version, 4 days after the last one - it is mostly about exciting major enhancement that you should have ASAP.

July 14 was b41. I have tagged and signed for the first time b54 as "FontVal-2.0.0".
dotnet/mono binaries, also signed (hurray!)
https://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/
When I get round to build the mac os x binaries I'd write properly.

Cut-and-paste and repeating my own writing isn't much fun, so I'd just say I have gpg-signed the 2.0 commit tags, (there are two, one on the py branch) , and am serious about it.
I refer people to the sort-of release overview:
http://typedrawers.com/discussion/1717/font-validator-2-0-arrived
and the summary test result on the libre font part of ~5000 fonts
http://typedrawers.com/discussion/1716/libre-font-test-results-and-hall-of-shame-list
and the details up at
http://htl10.users.sourceforge.net/tmp/FontVal-test-results-2016July/
And the usual, please make a donation at https://sourceforge.net/p/hp-pxl-jetready/donate/ , and if you use it for work, please consider asking your employers to.
For @schriftgestalt mostly : you want the "FontVal-2.0.0-py-osxbin.tgz" and extract ".bin/FontValidator" as well as the stand-alone libfreetype (I don't do libpng.dylib any more) from
https://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/misc/
and presumably you want to update and offer "+raster-tests" up. Other than those two (no more libpng.dylib, and the "+raster-tests") it should work like it did. While you are at it, you want "FontVal-2.0.0-helpsrc.zip" also - there are a dozen additional figures and docs for the glyf test, since the last time you got hold of the unpacked help src.


Remove version from Supermarket

How does one remove a specific cookbook version from the supermarket using stove?

https://github.com/sethvargo/stove/blob/92457331b91bd990a501dff93494a020f04088eb/features/plugins/community.feature#L22-L37


[BUG] Closing stale open session for new outgoing prekey bundle / Closing session: SessionEntry

Describe the bug
I have a server with 15 connected whatsapp users.
I find this on the log from time to time:
Closing stale open session for new outgoing prekey bundle
Closing session: SessionEntry {
  _chains: {
    xxx: { chainKey: [Object], chainType: 1, messageKeys: {} }
  },
  registrationId: 149285497,
  currentRatchet: {
    ephemeralKeyPair: {
      pubKey: <Buffer xx xx xx ...>,
      privKey: <Buffer xx xx xx ...>
    },
    lastRemoteEphemeralKey: <Buffer xx xx xx ...>,
    previousCounter: 0,
    rootKey: <Buffer xx xx xx ...>
  },
  indexInfo: {
    baseKey: <Buffer xx xx xx ...>,
    baseKeyType: 1,
    closed: -1,
    used: xxx,
    created:<PHONE_NUMBER>273,
    remoteIdentityKey: <Buffer xx xx xx ...>
  },
  pendingPreKey: {
    signedKeyId: 7192122,
    baseKey: <Buffer xx xx xx ...>,
    preKeyId: 1310
  }
}

I know this is printed by libsignal, I guess these lines are the culprits:

https://github.com/adiwajshing/libsignal-node/blob/11dbd962ea108187c79a7c46fe4d6f790e23da97/src/session_builder.js#L46
https://github.com/adiwajshing/libsignal-node/blob/11dbd962ea108187c79a7c46fe4d6f790e23da97/src/session_record.js#L273

To Reproduce
Steps to reproduce the behavior:
Don't know how to reproduce, it happens from time to time on a server with 15 connected whatsapp users.
Expected behavior
No errors on the log
Environment (please complete the following information):

Is this on a server? yes
What do your connectOptions look like?

const { version, isLatest } = await fetchLatestBaileysVersion()
const { state, saveCreds } = await useMultiFileAuthState('myPath')
const msgRetryCounterCache = new NodeCache()

        async function getMessage(key)  {
            if(store) {
                const msg = await store.loadMessage(key.remoteJid, key.id)
                return msg?.message || undefined
            }
            // only if store is present
            return proto.Message.fromObject({})
        }

 makeWASocket({
            version,
            logger,
            printQRInTerminal: false,
            mobile: false,
            auth: {
                creds: state.creds,
                keys: makeCacheableSignalKeyStore(state.keys, logger),
            },
            msgRetryCounterCache,
            generateHighQualityLinkPreview: true,
            // ignore broadcast and newsletter messages
            shouldIgnoreJid: jid => !jid || isJidBroadcast(jid) || isJidNewsletter(jid),
            // implement to handle retries & poll updates
            getMessage,
            shouldSyncHistoryMessage: () => true,
            markOnlineOnConnect: false
        })

Do you have multiple clients on the same IP? yes, 15 clients
Are you using a proxy? no

Additional context
Using baileys v6.7.5

These bugs may be related
https://github.com/WhiskeySockets/Baileys/issues/885
https://github.com/WhiskeySockets/Baileys/issues/886
https://github.com/WhiskeySockets/Baileys/issues/887
https://github.com/WhiskeySockets/Baileys/issues/888

I don't understand why was the issue closed.

I don't understand why was the issue closed.

i think he closed due to duplicate

Any solution?

Same, using SQL

+1

hello I have this problem too.

I'm experiencing the same issue and have an additional question: Where in the library is this log being generated? When I initialize the socket, I set the logger level to silent using the pino module to prevent any logs from being printed to the terminal:
const sock = makeWASocket({
  auth: state,
  version: currentVersion,
  printQRInTerminal: true,
  logger: pino({ level: 'silent' }),
});

However, this specific error is still being printed. What part of the library is outputting this log and ignoring the silent parameter?

I know this is printed by libsignal, I guess these lines are the culprits:

https://github.com/adiwajshing/libsignal-node/blob/11dbd962ea108187c79a7c46fe4d6f790e23da97/src/session_builder.js#L46
https://github.com/adiwajshing/libsignal-node/blob/11dbd962ea108187c79a7c46fe4d6f790e23da97/src/session_record.js#L273

Sorry, I hadn't seen that part of your post. I went into those files and simply commented out those lines, because those logs aren't interfering with the bot's operation, they're just polluting the terminal I use to see messages from my own code.
Developers could check if those logs are necessary maybe.
Thanks!

i found that solution, you just don't use (level: 'silent') on pino, just use another level.

i found that solution, you just don't use (level: 'silent') on pino, just use another level.

But some messages are ignored and not answered.

i just commented every single "console.something" (log, error, warn, info...) line from js files inside node_modules/libsignal/src folder.
and i had to, because my application uses a readline-based menu and custom logs. any library log messes things up.
but i still don't know why pino settings doesn't affect logs from libsignal library. 🤷♂


bugfix:修复operate_node节点审批失效问题

Codecov Report

Merging #323 (390d99a) into V2.6.0.x (2496189) will not change coverage.
The diff coverage is 39.13%.

@@            Coverage Diff            @@
##           V2.6.0.x     #323   +/-   ##
=========================================
  Coverage     51.27%   51.27%
=========================================
  Files           692      692
  Lines         36608    36608
=========================================
  Hits          18769    18769
  Misses        17839    17839

Impacted Files
Coverage Δ

itsm/ticket/models/ticket.py
48.28% <0.00%> (+0.04%)
:arrow_up:

itsm/openapi/ticket/serializers.py
78.91% <40.90%> (-0.97%)
:arrow_down:

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 2496189...390d99a. Read the comment docs.


Booklist #Issue222

Description
Added a suggested books list webpage under More on the navigation bar using HTML and CSS
Please include a summary of the change and which issue is fixed.
Fixes # (issue)
#222
List any dependencies that are required for this change
Type of change

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

How Has This Been Tested?
UI /UX changes
Attach gif or screenshot for changes.

Before :
- After :

Checklist:

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

I have made some changes via new commits which includes adding footer, giving meaningful name to the background image and updating the css files and image files. I am not sure about updating the header.
Can you check if these files have been uploaded or I need to make another pull request?

Is there any problem with the new commits or any other changes required? If there are please do let me know, I will work on it.

Okay I am working on them.

I have updated and added the new footer social icons

I am reusing the styles as in index.html

I have updated the URL

Please let me know if there are any mistakes. I am new to this and hence I am making a lot of mistakes. Hope to get better at this soon. Thank you for all your help.

I have made a new pull request and merged it. Can you check once?

I have made a new pull request and merged it. Can you check once?

What is the PR id?

Pr id is #306

Moved to #306


More than 3 has been identified as 2

After running the program, the effect is not good. The background is solid, but it seems that there is a lot of white noise in the subtracted background binary image, only 1 and 2 are recognized, and 3 or more has been identified as 2

It should recognize 3 as well.
Have you try to change the thresholds? plz post some images or I can't help you figure out what's wrong.


WIP chore(faq): Added dedicated router section

@escardin @ericmartinezr Please review

Beautiful :clap: :clap: :clap:

Awesome! Do you want this merged or do you want to wait?

I'll add a few more answers, then it can be merged.

Ok, this PR is ready for final review

@brandonroberts Thanks a lot for helping! Beautiful work!


Fixing IE10=< event issues

IE10=< will not understand this e.pageX, but he will this e.originalEvent.pageX

e.pageX and e.pageY are supported by jQuery.

I can't get this to work in IE, this PR fixed that problem.
Could you maybe guide me to a solution?

What's version of your IE? The Cropper supports IE8/9/10/11.

I have tried IE8/9/10/11, it only works in 11.
I used BrowserStack for testing. The bug is that the cropping selection will not resize in IE10 and less

You can try IETester.

BrowserStack is a real Windows OS running a real IE in a virtual machine... so it will provide a real MouseEvent.
I also see that others have had this problem as well https://github.com/fengyuanchen/cropper/issues/377

So, just find a real IE, and test it yourself (your hand exactly), not by machine. #377 is not the same issue as yours.

OK here is what I did.
I found a real computer with real IE10.
I ran your demo (http://fengyuanchen.github.io/cropper/). It did not work.
Then I cloned your repo, created an index.html page and added this:
<!doctype html>

		<link  href="/dist/cropper.css" rel="stylesheet">

Next I tried it with jQuery v1.9.1, v1.11.3 and v2.1.4. It did not work.
Then I hopped into the debugger to see what was going on.
This is the stack for onDragStart. As you can see, startX and startY is undefined, 'cause e has no pageX and pageY.

Next I changed e.pageX to originalEvent.pageX and e.pageY to originalEvent.pageY and added a breakpoint on the same line.
Now everything worked. this has its startX and startY values set.

I don't know why this happens and why e does not have it's pageXand pageY properties set.
I was wondering if IE is using its global event object and not the argument passed to the function here:
dragmove: function (event) {
      var options = this.options,
          originalEvent = event.originalEvent,
          touches = originalEvent && originalEvent.touches,
          e = event, //< ---- here
          dragType = this.dragType,
          dragMoveEvent,
          touchesLength;

anyways... by using the original event, I can get this to work. I guess I'll just use my fork for my project.
thanks for all your help and replies.

I get the same issue, cannot move the crop handles in IE10.

I test on real IE 9, 10, 11. Original code works on IE9 and IE 11 but not IE 10.
After I change e.pageX to e.originalEvent.pageX;
IE 10 works, I can move crop, but it is broken in ios devices.
e.pageX works on every platform except IE10
e.originalEvent.pageX works on every platform except IOS
The real solution is change
e.pageX to e.pageX || e.originalEvent.pageX
e.pageY to e.pageY || e.originalEvent.pageY
it works on all platform.

@billsliu did that pass in the qunit  tests as well?

+1 for this fix!
So far, the last release version is "0.10.1" and this fix is not part of it. Any idea when will be the next release?
Thx!

@fgodet: this PR has been closed by @fengyuanchen, so I guess that this will not go into master...

oh right :/
But still looks like a real issue to me ... I don´t understand why it was closed ...


folly on Windows CMake Error BUILD_FAILED

I execute the following cmd: ( Windows  8.1 vs 15 with Update 3 )
C:\vcpkg>./vcpkg install folly:x64-windows
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\vcpkg>.\vcpkg install folly:x64-windows
The following packages will be built and installed:
folly:x64-windows
Starting package 1/1: folly:x64-windows
Building package folly:x64-windows...
-- CURRENT_INSTALLED_DIR=C:/vcpkg/installed/x64-windows
-- DOWNLOADS=C:/vcpkg/downloads
-- CURRENT_PACKAGES_DIR=C:/vcpkg/packages/folly_x64-windows
-- CURRENT_BUILDTREES_DIR=C:/vcpkg/buildtrees/folly
-- CURRENT_PORT_DIR=C:/vcpkg/ports/folly/.
-- Warning: Dynamic building not supported yet. Building static.
-- Using cached C:/vcpkg/downloads/facebook-folly-v2<IP_ADDRESS>.tar.gz
-- Testing integrity of cached file...
-- Testing integrity of cached file... OK
-- Extracting done
-- Applying patch C:/vcpkg/ports/folly/fix-static-linking.diff
-- Applying patch failed. This is expected if this patch was previously applied.
-- Applying patch C:/vcpkg/ports/folly/fix-static-linking.diff done
-- Applying patch C:/vcpkg/ports/folly/fix-malloc.diff
-- Applying patch failed. This is expected if this patch was previously applied.
-- Applying patch C:/vcpkg/ports/folly/fix-malloc.diff done
-- Applying patch C:/vcpkg/ports/folly/fix-MSG_ERRQUEUE.diff
-- Applying patch failed. This is expected if this patch was previously applied.
-- Applying patch C:/vcpkg/ports/folly/fix-MSG_ERRQUEUE.diff done
-- Applying patch C:/vcpkg/ports/folly/fix-histogram.diff
-- Applying patch failed. This is expected if this patch was previously applied.
-- Applying patch C:/vcpkg/ports/folly/fix-histogram.diff done
-- Configuring x64-windows-rel
-- Configuring x64-windows-rel done
-- Configuring x64-windows-dbg
-- Configuring x64-windows-dbg done
-- Build x64-windows-rel
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:43 (message):
Command failed: C:/vcpkg/downloads/cmake-3.9.5-win32-x86/bin/cmake.exe;--bui
ld;.;--config;Release;--target;install;--;-v
Working Directory: C:/vcpkg/buildtrees/folly/x64-windows-rel
See logs for more information:
C:\vcpkg\buildtrees\folly\install-x64-windows-rel-out.log
C:\vcpkg\buildtrees\folly\install-x64-windows-rel-err.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_build_cmake.cmake:62 (vcpkg_execute_required_process)
scripts/cmake/vcpkg_install_cmake.cmake:24 (vcpkg_build_cmake)
ports/folly/portfile.cmake:51 (vcpkg_install_cmake)
scripts/ports.cmake:72 (include)
Error: Building package folly:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: folly:x64-windows
Vcpkg version: 0.0.96-2017-11-07-387c5477e5a3c89a560c0c642123aeb9f48dfea3
Additionally, attach any relevant sections from the log files above.

Hi, could you please attach the following logs?

C:\vcpkg\buildtrees\folly\install-x64-windows-rel-out.log
C:\vcpkg\buildtrees\folly\install-x64-windows-rel-err.log

yep , thanks
the rel err is empty ...
install-x64-windows-rel-out.log

I've got the same error (except, the callstack, but seems similar).

Package: folly:x64-windows
Vcpkg version: 0.0.99-unknownhash

Call Stack (most recent call first):   scripts/cmake/vcpkg_build_cmake.cmake:63 (vcpkg_execute_required_process)   scripts/cmake/vcpkg_install_cmake.cmake:24 (vcpkg_build_cmake)   ports/folly/portfile.cmake:51 (vcpkg_install_cmake)   scripts/ports.cmake:72 (include)
As I see, Folly has an error:
C:\project\vcpkg-master\buildtrees\folly\src\head\folly-master\folly\IPAddressV6.cpp(441): error C2666: 'inet_ntop': 2 overloads have similar conversions
This is the only error in my install/x64/windows/rel/out.log file.

Hi @danielTechn @BuzaL  , thanks for post this issue, that's makes vcpkg better!
This issue should be fixed in nearly PR. Can you update and rebuild it?
Thx.

Hi @danielTechn @BuzaL , thanks for post this issue, that's makes vcpkg better!
This issue should be fixed in nearly PR. Can you update and rebuild it?
Thx.

Sorry, I havn't got that buildsystem and currently not planning to reconstruct it. Thanks the fix anyway.


[DNM]log: make name param explicit

Rather than having some implied name for the logging name, explicitly
pass it in the macros LOG_MODULE_REGISTER & LOG_MODULE_DECLARE.
Signed-off-by: Kumar Gala<EMAIL_ADDRESS>

Codecov Report

Merging #9450 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #9450   +/-   ##
=======================================
  Coverage   52.17%   52.17%
=======================================
  Files         212      212
  Lines       25892    25892
  Branches     5561     5561
=======================================
  Hits        13508    13508
  Misses      10126    10126
  Partials     2258     2258

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 ebc3ce3...b3f5e63. Read the comment docs.

@galak: The logger does not need LOG_MODULE_NAME. What you really need is a pointer to static and dynamic logger data is needed.
What about the following solution:

In the _LOG_MODULE_REGISTER(_name, _level) and _LOG_RUNTIME_MODULE_DECLARE(_name) add the following:

static inline const struct log_source_const_data *__log_current_const_data_get(void)
{
    return & LOG_ITEM_CONST_DATA(_name);
}

static inline struct log_source_dynamic_data *__log_current_dynamic_data_get(void)
{
    return &LOG_ITEM_DYNAMIC_DATA(_name);
}

Instead of using &LOG_ITEM_DYNAMIC_DATA(LOG_MODULE_NAME) and &LOG_ITEM_CONST_DATA(LOG_MODULE_NAME) use the __log_current_dynamic_data_get() and __log_current_const_data_get().

The compiler should optimize out these functions and you will get something local to current compilation unit.

@galak, @pizi-nordic proposal looks good imo.

@pizi-nordic do you want to go head and make the change you suggested?

@galak, @pizi-nordic is on vacation. I've applied his suggestion by modifying last commit on my fork (https://github.com/nordic-krch/zephyr/commits/logging). Not sure how to proceed with that?

@galak, @pizi-nordic is on vacation. I've applied his suggestion by modifying last commit on my fork (https://github.com/nordic-krch/zephyr/commits/logging). Not sure how to proceed with that?

Thanks, I pulled your changes into my tree and made a few updates.

Is it possible to use logger after this commit with module_foo from a static inline routine in module_foo.h, as well as with module_bar from module_bar.c, where module_bar.c includes module_foo.h?
I am guessing the previous way 'ought' to work, possibly with some warnings for redefining the macro, but I'm less sure about the effect this PR would have on that. @galak, can you clarify?

Is it possible to use logger after this commit with module_foo from a static inline routine in module_foo.h, as well as with module_bar from module_bar.c, where module_bar.c includes module_foo.h?

I'm thinking of situations like this. What should the behavior be in general (with or without implicit names)?
/******************************************************************************
 * in module_foo.h:
 */

#define LOG_MODULE_NAME foo
#include <logging/log.h>
LOG_MODULE_REGISTER();

static inline void module_foo_func(void)
{
	LOG_INF("hello from foo");
}

/******************************************************************************
 * in module_bar.c:
 */

#include <module_foo.h>
#define LOG_MODULE_NAME bar
#include <logging/log.h>
LOG_MODULE_REGISTER();

void module_bar_func(void)
{
	module_foo_func();
	LOG_INF("hello from bar");
}

@mbolivar it's not only after this commit but in general using log in head it risky. I haven't yet into that but probably we would need to preceed every #define LOG_MODULE_NAME with #undef LOG_MODULE_NAME and use LOG_MODULE_DECLARE() in header and LOG_MODULE_REGISTER in C file.

I haven't yet into that but probably we would need to preceed every #define LOG_MODULE_NAME with #undef LOG_MODULE_NAME and use LOG_MODULE_DECLARE() in header and LOG_MODULE_REGISTER in C file.

Is that type of approach compatible with the changes @galak is suggesting? Naively it doesn't seem so, since the idea is to delete LOG_MODULE_NAME usage.

Is that type of approach compatible with the changes @galak is suggesting? Naively it doesn't seem so, since the idea is to delete LOG_MODULE_NAME usage.

Yeah, we should assume magic #defines being set, thus me merging this.


Target Window Options

Give the ability to specify the target window to display hurl output in.

floating window (current)
vertical split
horizontal split
tab
current window

This issue is the enhancement spawned from the question in issue #2

Ok, so the plan is going to be to use https://github.com/MunifTanjim/nui.nvim to help implement the ui. I'm going to make it an optional dependency though, so if it isn't installed we'll fall back on the current method and not support the newer features.


Additional Properties for Invoke any deploy.ant.xml target

The Additional properties in the Invoke Deploy.ant.xml target, I’m trying to invoke “certificate-from-definition” ANT target, As part of it, I would like to pass two additional properties crypto.dir and cert.file:
Additional Properties: crypto.dir=${p:cert.dir} cert.file=${p:dpDefintionsFile}
but, it appears to me like these properties are treated as malformed properties while executing the process step.
I receive this error:
!!! Ignoring malformed additional property: crypto.dir=/opt/ucd/agent/var/work/DP/certs cert.file=/opt/ucd/agent/var/work/DP/defintions.xml

Multiple name values pairs in the Additional Properties in the Invoke any deploy.ant.xml target step are separated by a ~ tilde character.
Therefore, your Additional Properties input should look like this: crypto.dir=${p:cert.dir}~cert.file=${p:dpDefintionsFile}
Note the ~ character separating the two pairs.
I've made updates in v16 of the DataPower plugin to better describe this requirement and it will now trim the property names and values.

Separating pairs with a ~ is supported in versions prior to 16.


Chronos Credential Support

To use the credentials in chronos:

Run mesos-master with the credentials flag and the path to file with authorized users + their secrets.
--credentials=/path/to/credential/file

Each line in the file should be a principal space separated with their password.

$ cat /path/to/credential/file
principal secret
principal2 secret2

Run chronos with the --mesos_authentication_principal flag and optionally with the
--mesos_authentication_secret_file flag that contains the secret.

The secret file cannot have a trailing newline. To not add a newline simply run:

$ echo -n "secret" > /path/to/secret/file

Thanks very much @tamarrow, could you please add your description to the actual readme file?

Minor comments on the error logging, also we want the documentation on the main readme page. Other than that LGTM!  Any further comments @brndnmtthws, @adam-mesos?

Looks good. Can you please squash and rebase your commits into one?
Here's a guide: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

@brndnmtthws squashed

I think it still requires a rebase on master.

should be good now

hey @tamarrow, could you respond to @adam-mesos' comments? I would like to merge this soon if you have time.

@adam-mesos all your changes should be updated!
cc @elingg

@adam-mesos, could you take a look when you have a chance? I want to merge this ASAP since we are working on a Chronos release.

Looks great. Minor style suggestions, and a request to use the PosixFilePermissions API instead of a regex on a toString. Other than that it's very close to shippable.

thanks @adam-mesos! pushed the latest changes

Looks great! Thanks for responding to all my (nit-picky) feedback. :+1: :ship:


Certificate checkbox removes certificate from list

Expected Behavior
Clicking a checkbox in the Client Certificates list should check/uncheck a certificate
Actual Behavior
Clicking a checkbox now removes the certificate from the list with no confirmation!
Reproduction Steps

Go to Settings
Select Client Certificates
Click the checkbox of any existing certificate
Notice that the certificate is immediately removed

Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No response
Insomnia Version
2023.5.2
What operating system are you using?
Windows
Operating System Version
Windows 10 version 19044.3208
Installation method
Download
Last Known Working Insomnia version
2023.5.0?

Thanks for the catch!


clone.localeData is not a function crash on calendar popover

Checklist

[X] I've looked through the README
[X] I've verified that  I am running react-big-schedule version 4.2.0 or above.
[X] I've searched the existing issues and discussions for a similar question
[X] I've provided relevant code snippets or error messages
[] I've included steps to reproduce the issue
[X] I've checked the browser console for any errors
[X] I've tested the issue with the latest version of react-big-schedule

Please make sure the question is worded well enough to be understood
I am currently getting crashes when I try to open the calendar popover, I have set the locales as well according to the documentation but that didnt work and I have done it without it as well. It has been fairly temperamental because very rarely it did work fine, I cant recreate or remember what the situation was when it was working fine sadly.
I have noticed that it works fine in react-big-scheduler-stch, but it crashes the website in here, presumably because of the addition of dayjs, below is my code:
  const dispatch = useDispatch();

  const schedulerParentRef = useRef();
  var today = new Date();
  var date = today.getFullYear() + "-" + (today.getMonth() + 1) + "-" + today.getDate();
  let schedulerData = new SchedulerData(
    date,
    ViewType.Day, // Change the status of daily, weekly or monthly
    false,
    false,
    {
      eventItemPopoverPlacement: "bottomRightMousePosition",
      responsiveByParent: true,
      besidesWidth: window.innerWidth <= 1600 ? 100 : 350,
      startResizable: false,
      endResizable: false,
      schedulerContentHeight: "100%",
      weekResourceTableWidth: window.innerWidth * 0.1,
      dayResourceTableWidth: window.innerWidth * 0.1,
      monthResourceTableWidth: window.innerWidth * 0.1,
      yearResourceTableWidth: window.innerWidth * 0.1,
      weekCellWidth: 80,
      dayCellWidth: 40,
    }
  );
  schedulerData.setResources([]);
  schedulerData.setEvents([]);

    const prevClick = (schedulerData) => {
    schedulerData.prev();
    schedulerData.setEvents(Events);
    dispatch(setViewModel(schedulerData));
  };

  const nextClick = (schedulerData) => {
    schedulerData.next();
    schedulerData.setEvents(Events);
    dispatch(setViewModel(schedulerData));
  };

  const onViewChange = (schedulerData, view) => {
    schedulerData.setViewType(view.viewType, view.showAgenda, view.isEventPerspective);
    schedulerData.setEvents(Events);
    dispatch(setViewModel(schedulerData));
  };

  const onSelectDate = (schedulerData, date) => {
    schedulerData.setDate(date);
    schedulerData.setEvents(Events);
    dispatch(setViewModel(schedulerData));
  };

      {displayTimeline && (

          <Scheduler
            parentRef={schedulerParentRef}
            schedulerData={viewModel}
            prevClick={prevClick}
            nextClick={nextClick}
            onSelectDate={onSelectDate}
            onViewChange={onViewChange}
            eventItemClick={eventClicked}
            viewEventClick={ops1}
            viewEventText="Details"
          />

      )}

Below is the crash error:

What would I have done incorrectly here? Any help is appreciated.

Hi @AsifDaum thank you for trying and using our library.
Can you share your package.json file

Thank you for responding, below is the complete package.json file:
{
  "name": "stepsapi",
  "version": "0.1.1",
  "private": true,
  "dependencies": {
    "@craco/craco": "^6.4.3",
    "@headlessui/react": "^1.4.3",
    "@heroicons/react": "^1.0.5",
    "@react-three/drei": "^9.79.4",
    "@reduxjs/toolkit": "^1.8.5",
    "@stripe/react-stripe-js": "^1.7.0",
    "@stripe/stripe-js": "^1.22.0",
    "@testing-library/jest-dom": "^5.11.4",
    "@testing-library/react": "^11.1.0",
    "@testing-library/user-event": "^12.1.10",
    "@xeger/quill-image-actions": "^0.7.1",
    "@xeger/quill-image-formats": "^0.7.1",
    "@zxing/library": "^0.20.0",
    "animate.css": "^4.1.1",
    "apexcharts": "^3.35.3",
    "autoprefixer": "9",
    "axios": "^0.21.1",
    "connected-react-router": "^6.8.0",
    "country-state-city": "2.2.0",
    "file-saver": "^2.0.5",
    "formik": "^2.2.9",
    "history": "^5.2.0",
    "pigeon-maps": "^0.21.0",
    "postcss": "7",
    "qrcode.react": "^3.1.0",
    "react": "^18.0.2",
    "react-apexcharts": "^1.4.0",
    "react-big-schedule": "^4.2.5",
    "react-calendar": "^3.7.0",
    "react-circular-progressbar": "^2.0.4",
    "react-cookies": "^0.1.1",
    "react-dnd": "14.0.5",
    "react-dnd-html5-backend": "14.0.1",
    "react-dom": "^18.0.2",
    "react-facebook-login": "^4.1.1",
    "react-flow-renderer": "^9.1.2",
    "react-google-login": "^5.2.2",
    "react-icons": "^4.3.1",
    "react-image-gallery": "^1.2.8",
    "react-quill": "^2.0.0",
    "react-redux": "^7.2.2",
    "react-router-dom": "^6.2.1",
    "react-router-redux": "^4.0.8",
    "react-s3": "^1.3.1",
    "react-scripts": "4.0.1",
    "react-select": "^5.5.0",
    "react-stripe-checkout": "^2.6.3",
    "react-table": "^7.7.0",
    "react-three-fiber": "^6.0.13",
    "redux-saga": "^1.1.3",
    "sweetalert2": "^11.3.3",
    "tailwindcss": "npm:@tailwindcss/postcss7-compat",
    "three": "0.124.0",
    "tw-elements": "^1.0.0-alpha13",
    "typescript": "^4.9.5",
    "web-vitals": "^0.2.4",
    "xlsx": "^0.18.5",
    "yup": "^0.32.11"
  },
  "scripts": {
    "start": "craco  start --openssl-legacy-provider",
    "build": "GENERATE_SOURCEMAP=false CLIENT_ENV=production craco build",
    "test": "craco test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
  "devDependencies": {
    "@types/react-router-dom": "^5.1.7"
  }
}

Please install antd and dayjs and try it will solve your problem

Same issue, it sadly didnt help.

Can you try to create same issue in code sandbox

When I recreated it in codesandbox, I was unable to get it to crash.
https://codesandbox.io/s/inspiring-visvesvaraya-mm897m?file=/src/App.js
It didnt need Dayjs nor antd in those codesandboxes either, Ive for now reverted to hbtallah's one in the meantime.
I'll investigate it more, is there anything I should look for in particular?

Which node version are you using

I am currently using v18.17.1

instalando rc-picker se soluciona. La libreria internamente usa "rc-picker" , no te viene instalado porque podes no usarlo al desplegable. Instalando rc-picker se me soluciono

Instalando rc-picker no funciono.


add indent in init command. Closes #303

I think WrapString might still be nice for later, less manual management but works for now!