Can't parse spread operator

Hi Marijn,
I'm using acorn 3.0.2 with the plugin acorn-jsx 2.0.1, but acorn is throwing on the spread operator when used inside an object:
        var cleanField = {
          ...field, // this line throws
          config: {...field.config}
        };

Weirdly enough, this is totally fine
        var stuff = [...field];

Being part of ES6, the spread operator should be completely supported, right?
Can you spot something I'm doing wrong?
p.s. I'm not overriding options.ecmaScript, defaulting to 6

Spread in object literals is not part of any ECMA standard that Acorn can parse. Hence the error.

Holy cow, I thought it was in the standard, but you're totally right.
I suppose you have no interest in supporting that in acorn then.
Would you suggest using babylon instead to get the extra ES6 features?

Yep, works great once I enable the objectRestSpread plugin.
Thanks!

Would you suggest using babylon instead to get the extra ES6 features?

Not sure what you are asking. Acorn supports all ES2015/ES6 features. Babylon is integrated in Babel and therefore Babel's plugins (which support nonstandard, non-ES6 plugins like babel-plugin-transform-object-rest-spread). Acorn has its own plugin system.

Poor choice of words.
By "extra ES6 features" I meant those features that are not in the ES6 standard, but are still used in the wild, like the objectRestSpread which has been made very popular by React, but it's not standardised (yet)

@dmatteo As an option, you can write plugin for Acorn to support that.

@RReverser @dmatteo @TimothyGu here it is https://github.com/UXtemple/acorn-object-spread :). I basically brought it in from babylon. I also pushed a PR to buble https://gitlab.com/Rich-Harris/buble/merge_requests/44 to support it, hopefully it makes it in :).

@dariocravero Awesome, great work!

Worth noting that object-rest-spread is now supported natively in Node 8 out of the box. It may be worth adding since v8 has it implemented unflagged already.

Related to https://github.com/standard-things/esm/issues/14

@jdalton It is still stage 3 though, and Acorn accepts only stage 4 features for easier maintainance. Moreover, the latest syntactic change in the proposal has been committed only 3 days ago: https://github.com/tc39/proposal-object-rest-spread/commit/72deb7d27aea7615455519ce0c97e0b52d636f4b

It is still stage 3 though, and Acorn accepts only stage 4 features

Maybe an exception to the rule is called for since implementations are shipping this unflagged.

Maybe an exception to the rule is called for since implementations are shipping this unflagged.

Aren't they always doing this in stage 3? (as far as I remember, it's exactly for implementation feedback)

Implementations for feedback are usually flagged. Since this is unflagged though and on by default it's a bit more pressing.

Would love to see this fix land.

Again, I don't want to do extra work and complicate our backwards-compatibility story by tracking unstable proposals, and it would be great if you all could just get used to the 'use a plugin until it reaches stage 4' reality.
Drive-by comments like "Would love to see this fix land" we can also really do without.

@marijnh The reality is that support for object rest-spread is in stable versions of Chrome and Node and that existing plugins aren't to the bar they should be (it has 1 commit). I understand not wanting to take on the compatibility burden, but seeing as the work put in will not likely be wasted (as it's not a question of if the feature is landing wider, but when) it would be rad if there could be an official plugin (made by acorn core). That way folks could leverage a quality plugin, you all could get the jump on implementing the syntax while not taking on the compat burden.

@marijnh As a maintainer it's cool to know when users really want a feature or a fix (also, there are no reactions on the mobile version of GH, so I would have used that otherwise)

You can just use babylon until it's supported in acorn at Stage 4, the tools have difference use cases/times to implement.

You can just use babylon until it's supported in acorn at Stage 4

Unfortunately using babylon is not an option for me.

@jdalton

the existing plugin isn't to the bar it really should be (i.e. it has 1 commit)

So improve it or write a better one.

So improve it or write a better one.

I'm not a domain expert such as you and other Acorn core devs.
Is there a downside to doing an official plugin? It seems to me like a way to avoid the negatives you've stated earlier.

Update:
Seeing if Chrome team would be up for creating or updating a plugin since they now
also use Acorn in their dev tools.

@jdalton Small nit: looks like they used Acorn for ~2 years now https://github.com/auchenberg/chrome-devtools-app/tree/master/app/devtools/front_end/acorn, and now just widened its usage.

Node is now using Acorn to parse top-level await in the REPL:
https://github.com/nodejs/node/pull/15566

Chromium wants to pull its Acorn use:
https://bugs.chromium.org/p/chromium/issues/detail?id=756006#c7

Could one re-consider that? It is widely-adopted as of November 2017. Many environments support it -- Firefox, Chrome, NodeJS. Other tools as well -- babel, uglifyjs, etc.
Also, support in acorn blocks introducing this support in webpack that is somehow a show stopper. Without it you cannot pack JS code and deliver to the client.

a show stopper

Don't stop the show. Use https://github.com/victor-homyakov/acorn-object-rest-spread

By the way, it is Stage 3 proposal now https://github.com/tc39/proposals/blob/master/README.md
Stage 3 means "Candidate", i.e. close to be accepted.

Stage 3 is a pretty common place to be in and they are planning to get accepted in the next months. No need to rush anything.

@askoretskiy

Also, support in acorn blocks introducing this support in webpack that is somehow a show stopper. Without it you cannot pack JS code and deliver to the client.

It's not a show stopper for webpack.
@marijnh

Use https://github.com/victor-homyakov/acorn-object-rest-spread

The one by Acorn's own @adrianheine is more accurate (you may need the master branch of acorn):
https://github.com/adrianheine/acorn5-object-spread
@adrianheine
It would be nice if Acorn core could read the temperature a bit better, but I get it. Acorn is the best option in parsers at the moment, even with the lack of support for common things like object-rest-spread. I make due hacking together plugins until the feature meets their bar. By the way for folks just wanting to have parse support without concern for syntax validation object-rest-spread is pretty simple.


Support Windows 7

Describe the issue as clearly as possible:
Not working on Windows 7. It's seems working, but acutally can't access the Internet, while it's on.
Steps/code to reproduce the bug:
Install on Windows 7

Expected result:
It's actually working

Error message:
No response
Outlines/Python version information:
Latest
Context for the issue:
No response

This seems like an issue with your python environment. What does requests.get("https://python.org") return?


Doc: add step to Re-deploy VM of a dev cluster

Added the curl call to redeploy VM of dev cluster
using local RP.
Which issue this PR addresses:

Fixes
What this PR does / why we need it:

Test plan for issue:

Is there any documentation that needs to be updated for this PR?

Sure, will make the changes, it's good to have them.


Automated cherry pick of #5536: fix: 修复谷歌云 cloud-provider-clirc 显示错误问题

Cherry pick of #5536 on release/3.0.
#5536: fix: 修复谷歌云 cloud-provider-clirc 显示错误问题

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/3.0@a259eb1). Click here to learn what that means.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             release/3.0   #5538   +/-   ##
=============================================
  Coverage               ?   6.85%
=============================================
  Files                  ?     535
  Lines                  ?   91161
  Branches               ?       0
=============================================
  Hits                   ?    6251
  Misses                 ?   84390
  Partials               ?     520

Flag
Coverage Δ

#aFlag
6.85% <ø> (?)

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 a259eb1...439e9c2. Read the comment docs.

/lgtm

/approve


No Updates in Feeds anymore again

Hi @ajmaradiaga , can you check feed update again, please?

Sorry about this @abap-weasel. I've fixed it. I will work on a notification system to automatically check that everything is running fine so that this doesn't happen again


Why does YouTube-DL keep getting throttled by YouTube?

Checklist

[x] I'm asking a question
[x] I've looked through the README and FAQ for similar questions
[x] I've searched the bugtracker for similar questions including closed ones

Question

WRITE QUESTION HERE
Since the official YouTube-DL hasn't been updated in a year and half, I've been using the patched version. I don't use YT-DLP because I have an OLD computer and can NOT run it. The program will NOT execute on my system. At this time, it is a literal impossibility for me to use YT-DLP. This is why I use the patched version of YouTube-DL.
Can someone please explain to me in semi-technical terms why the patched versions get throttled by YouTube every other week or so?
It will be working fine, then one day I'll try to download a video, it throws up an error, says downloading might be throttled and sure enough, it downloads at a snail's pace. A couple days go by, with me downloading the newest release each night and usually after a couple of them, the issue goes away and it starts downloading videos at full speed again. It works for a week or two, then the same thing happens again. Sometimes it gives me an error and sometimes it just downloads very slowly.
Obviously I know something is changing that causes the throttling, what I'd like to know is what, and why YouTube-DL can't cope with it.
I have Opera 36.0.2130.80, which is 6-7 years old at this point, installed on this (OLD) computer, and it still views YouTube videos just fine.
So how is it that a browser that is over half a decade old can cope with whatever changes YouTube is making, but a current program that's updated nightly, breaks every couple of weeks?

Your oldish Opera has a reasonably capable JavaScript interpreter, although it probably barfs a lot on modern websites. YT doesn't seem to use the latest JS syntax, presumably because it would then fail to show ads on old mobile phone browsers that aren't updatable.
There is no third-party JS interpreter that can be reliably integrated or distributed with yt-dl (because of platform dependencies, functionality and licensing issues).
Therefore yt-dl has a JSInterp module that understands just enough JS to run the signature and n-sig processing. When, every so often, YT sends a new player with different JS code, it may use some syntax that we didn't support, or it may expose a bug in what the yt-dl JS module was supposed to support. You can study the relevant issues and commits to see examples of both cases. The test script may also be enlightening.
JavaScript was invented in a week by Brendan Eich at Netscape and combines what he was asked for (a scripting language that looks like Java) with what he wanted (Scheme, a then-fashionable Lisp dialect popularised in a classic MIT textbook (PDF)). If only he'd been allowed to use a plain Lisp, we'd all have been much better off.

Thank you for the explanation. You're also correct in that Opera has problems with a lot of web sites. In fact, even newer browsers that were back-ported to my old system, have problems on a lot of websites. Actually, that's probably the biggest problem I face in using an outdated system/OS.
I want something newer/faster, but don't have any spare money at the moment. I also don't particularly like my OS choices. I don't like the fact that Win10/11 gives MS carte blanche to change the OS as it sees fit, and I know nothing about Linux. Plus some of the programs and scripts that I use daily won't work in Linux.

Sites like msfn.org may be relevant.

Just in case it wasn't clear, YouTube downloads are being throttled right now, and have been for the past couple weeks or so. I just tried today's release binary, but there's no change.
I'm not complaining, I understand the problem of trying to keep a program like this compatible with all the sites it supports, and I'm grateful that it exists at all, I just wanted to make someone was aware that it was happening. I know I can assume that someone else has mentioned it, but just in case they haven't...

No, show us the verbose log. If you're using the unofficial nightly build, it wasn't updating properly, but I set up an official one that does: see #31530.

Yes, I'm using the unofficial nightly build, AKA the "patched" version available here;
https://github.com/ytdl-patched/youtube-dl/releases
I tried reading the linked thread and got completely lost in the discussions about merges, pulls requests, fixes, yt-dlp, official versus unofficial builds etc. To be honest, Github somewhat confuses me.
Here's where I'm coming from:
I have an old system that can run YouTuve-DL, but cannot run YT-DLP, which is why I stick to YouTube-DL. For a long time I was using the official version, updating the Window binary as needed. Then the official releases stopped coming and downloads from YouTube got throttled. I got pointed to the link above, I downloaded that version, downloads got fast again. When downloads would get throttled, I'd download the latest nightly build and downloads would usually get fast again. A couple weeks ago downloads started getting throttled. I've been manually downloading the nightly builds each day in the hope that the issue would be fixed.
It's not complaining about not being able to extract the uploader ID. Instead it says "Unable to extract Initial JS player n function alias".
I tried to attach a log file created with the verbose option, but Github doesn't like my outdated browser. So I'll post it below;
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['https://www.youtube.com/watch?v=UGceYMpg5fM', '--verbose']
[debug] Encodings: locale cp1252, fs mbcs, out cp1252, pref cp1252
[debug] youtube-dl version 2<IP_ADDRESS>9 (single file build)
** This build is unofficial daily builds, provided for ease of use.
** Please do not ask for any support.
[debug] Python 3.4.4 (CPython x86 32bit) - Windows-XP-5.1.2600-SP3 - OpenSSL 1.0.2d 9 Jul 2015
[debug] exe versions: ffmpeg N-105053-gc417616-Reino
[debug] Proxy map: {}
[youtube] UGceYMpg5fM: Downloading webpage
[youtube] UGceYMpg5fM: Downloading player 1dda5629
WARNING: [youtube] Unable to decode n-parameter: download likely to be throttled (Unable to extract Initial JS player n function alias (Wsa[0]); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output. Traceback (most recent call last):
File "D:\a\youtube-dl\youtube-dl\youtube_dl\extractor\youtube.py", line 1672, in _n_descramble
File "D:\a\youtube-dl\youtube-dl\youtube_dl\extractor\youtube.py", line 1644, in _extract_n_function
File "D:\a\youtube-dl\youtube-dl\youtube_dl\extractor\youtube.py", line 1629, in _extract_n_function_name
File "D:\a\youtube-dl\youtube-dl\youtube_dl\extractor\common.py", line 1013, in _search_regex
youtube_dl.utils.RegexNotFoundError: Unable to extract Initial JS player n function alias (Wsa[0]); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
)
[debug] Default format spec: bestvideo+bestaudio/best
WARNING: Requested formats are incompatible for merge and will be merged into mkv.
[debug] Invoking downloader on 'https://rr5---sn-j5caxoxu-i2ol.googlevideo.com/videoplayback?expire=1688967855&ei=T0arZJm8Csaj_9EP09-vgAI&ip=<IP_ADDRESS>&id=o-AKgrGCuc3DXIqD3yFAi3HlXU8xVKmy1ChcBYCMJV5moN&itag=137&aitags=133%2C134%2C135%2C136%2C137%2C160%2C242%2C243%2C244%2C247%2C248%2C278%2C394%2C395%2C396%2C397%2C398%2C399&source=youtube&requiressl=yes&mh=Vs&mm=31%2C29&mn=sn-j5caxoxu-i2ol%2Csn-ab5sznzs&ms=au%2Crdu&mv=m&mvi=5&pl=22&initcwndbps=1537500&spc=Ul2Sqzix3F0TSVvR_vQJjoP7HMgkDdR7hZvBwmWxBQ&vprv=1&svpuc=1&mime=video%2Fmp4&ns=Ri-8O61n9t_zaJRVmrW_fzYO&gir=yes&clen=148007962&dur=753.040&lmt=1688925458337322&mt=1688945830&fvip=4&keepalive=yes&fexp=24007246%2C24363392&c=WEB&txp=5535434&n=O5oeuLYijyVvcpjw&sparams=expire%2Cei%2Cip%2Cid%2Caitags%2Csource%2Crequiressl%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cns%2Cgir%2Cclen%2Cdur%2Clmt&sig=AOq0QJ8wRAIgJ7nld763wv965-_S-slTSKhqpP8eU9g3nv4t6it56SQCIHIsDtR8CHHkgE4J742OuewmeXtTI5letPOjsaqSwtDI&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRQIhAMF98q_RNY6TascI_hpGFGeYxXT9f0EEyxcs7au0AR2LAiAc7NjmMSdaZynahYUW8-8zJRcZHoYYGRYEdF76XI_U9g%3D%3D'
[dashsegments] Total fragments: 15
[download] Destination: 10 Awful Plot Twists That Completely Ruined Great Movies-UGceYMpg5fM.f137.mp4
[download]   0.0% of ~150.00MiB at  3.76KiB/s ETA 11:19:59
[download]   0.0% of ~150.00MiB at 11.29KiB/s ETA 03:46:39
ERROR: Interrupted by user

In the text where you were directed to that repo, there is now a link to our new nightly build repo. Use that. See also #31585.
The fix needed for this player hasn't propagated to the unofficial nightly build despite the build date. The page extracts OK with master.

I have an old system that can run YouTube-DL, but cannot run YT-DLP, which is why I stick to YouTube-DL.

Sites like msfn.org may be relevant

@Rekrullurker , dirkf is very right! 👍 If you do subscribe there, you'll find a welcoming and non-judging community of users of older Windows systems (Win2k, WinXP, WinVista, Win7, etc.), and a whole new world will be opened to you with regards to browser options compatible with the modern, JS-bloated, monster of a web 😠 ...
There's no need to use the out-dated Opera 36 today - roytam1's browsers (New Moon 28, Serpent 52, Serpent 55) and the 360EE mods based on Chromium 86 are the way to go...
Also, @nicolaasjan provides (via links in his MSFN signature) constantly updated youtube-dl.exe win32 binaries (XP-compatible) and, what's more, he even provides XP SP3 compatible (SSE2 instruction set required) yt-dlp.exe builds; these use a community produced CPython 3.8 (soon 3.9) iterations compatible with XP SP3/Vista SP2; this isn't a plug to switch to yt-dlp, just a FYI as to your available options under WinXP 😄 ...
End-of-Life (EoL) is a term invented by the OS vendor, when it should have been End-of-Support (EoS); the OS doesn't have to stop "living" just because MS (and their partners) won't support it...


[Doc] Fix code example mistake

Coverage remained the same at 100.0% when pulling 2a780e028499e3656afb38496d1322e72be5ccbc on oltodo:patch-1 into 80da765a266cb7ff9d034a73bde0abe18d72d6de on terinjokes:master.

Merged as a9c55b9e6ff99a8d395fb1e82d0050c11c256483


when launching pilot-discovery with kubeconfig flag

i have to specify the full path of the .pem file in my kubeconfig file, else it can't be found.
probably needs similar fix as @ayj fixed in #5300

fixed ^^^


Halved value returned by gapBetweenThumbs function

Halved the gapBetweenThumbs value in order to allow the selection of smaller ranges (i.e., 31-32).
Fixes issue #7

Thanks @Sundin for using the project and contributing ! 👍


Support molecule selection

Confirm that this is necessary?
Interface: Second select tool? or maybe it should depend on the viewing mode... which ever layer is topmost is the one that gets selected?

I think we've discussed having both cell and molecule select APIs. It would be best to define both the APIs and the interfaces in a consistent way for both.
However, I would put low priority on molecule selection.


replace FileManager#getString

move FileManager#getString to FileManager#getMessage which returns a MessageComponent, then just call MessageComponent#sendMessage(Player)
won't be possible in every situation cause CommandSenders, but it should be used where possible to support markdown

I did this a while ago lol


Python 3.10 support

Python 3.10 support
closes https://github.com/nv-morpheus/Morpheus/issues/881
closes https://github.com/nv-morpheus/Morpheus/issues/876
Todo:

[ ] find a better way to include/add_subdirectory the cudf_helpers configuration that needed to be inlined due to changes in https://github.com/scikit-build/scikit-build/pull/871

Final changes now that everything is working:

Removal of the morpheus_utils.so library completely

Only TableInfoData was compiled into this library and it only had a single function. This was moved and now only the header is shared between cudf_helpers and libmorpheus

The library pyarrow was pinned to use cuda since it was defaulting to cpu for some reason.
The layout of the morpheus._lib package has been updated to remove most of the cmake files.

These files didnt do much and had longer copyright messages than implementations making it confusing

The morpheus/_lib/src/python_modules have been moved to their respective directories.

i.e. The common module moved from morpheus/_lib/src/python_modules/common.cpp to morpheus/_lib/common/module.cpp
This leaves morpheus/_lib/src to contain only source files from libmorpheus

The cudf_helpers CMake code has been brought into morpheus/_lib/CMakeLists.txt

This is mainly due to this issue https://github.com/scikit-build/scikit-build/pull/871. Will need to file an issue with them.

/merge


[cmap] Which cmap subtables are still relevant today?

This page documents a large number of cmap subtables that may have been relevant at some point in the past. It would be useful to also document which ones still matter today. As far as I know, the primary ones today are 3/1 (Windows / Unicode BMP) and 3/10 (Windows / Unicode full repertoire). Apple's CoreText system works fine with these two, so at least for rendering through Apple's platforms the Macintosh platform encodings are no longer needed.
Do any other platforms or applications still depend on other cmap subtables?

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

ID: 86923ff4-2b60-9144-e2b4-77cdb36fd698
Version Independent ID: ea221e53-f51a-8233-3c0b-d416e5360623
Content: cmap - Character To Glyph Index Mapping Table - Typography
Content Source: typographydocs/opentype/spec/cmap.md
Product: typography

Def only format 4, 10, 12, 13, 14 are relevant.  As to the plat/encoding, also, 3/1 and 3/10 are sufficient.  3/0 (symbol) is also used by hacky symbol fonts.

First issue… I would recommend clarity on multiple cmap subtables. Intended behaviour for multiple cmap subtables with the same format/encodingid is not specified AFAICT. Is an implementation supposed to maintain a ordered list of Format IDs, from which it uses the first it finds? One reading of the spec is that the only subtable format that is usable alongside other subtables is Format 14. Yet Format 13 (many-to-one) has obvious use cases as a supplemental mapping. Implementors of font creation tools may be tempted to use format 4 for Unicode IDs < 65536 and format 12 for IDs >= 65536 in the same font, yet the sentence in the Format 12 spec "This is the standard character-to-glyph-index mapping table for the Windows platform for fonts supporting Unicode supplementary-plane characters" hints that a Format 4 subtable also in the font might be ignored.
Assuming subtables are intended to be unified, then handling of overlaps in coverage must be considered too. "Undefined behaviour" is more useful than leaving implementors to figure it out.
Second issue… The meaning of "symbol font" in the statement "When building a symbol font for Windows, the platform ID should be 3 and the encoding ID should be 0." is not clear. I assume it refers to the old 8-bit character set of MS Symbol, which I think used "Unicode IDs" 32-255 without any 16-bit interlopers. @behdad mentions "hacky symbol fonts" above.
Some attempt should be made in the ‘cmap’ spec to explain how to map arbitrary sets of graphics to Unicode. PUA is the obvious place for them, if there are no relevant Unicode points, yet builders of such fonts often want to add handy alphabetic keystrokes to their fonts too. Which is hackier, the old-style 3/0 symbol fonts or pointing A,B,C… at arbitrary glyphs using 3/1?

Apple's cmap spec currently has this:

Many of the cmap formats are either obsolete or were designed to meet anticipated needs which never materialized. Modern font generation tools need not be able to write general-purpose cmaps in formats other than 4, 6, and 12. Formats 13 and 14 are both for specialized uses. Of the two, only support for format 14 is likely to be needed.

Curious as to whether format 6 is really still used.

Reportedly, format 6 is still often encountered in fonts embedded in PDF files.

#604 pertains to Mac platform (PID 1); see that issue for proposed changes in that regard.
Wrt formats, the following is a proposed addition in the Overview section, after other discussion of the various formats:

Of the seven available formats, not all are commonly used today. Formats 4 or 12 are appropriate for most new fonts, depending on the Unicode character repertoire supported. Format 14 is used in many applications for support of Unicode variation sequences. Application developers should anticipate that other formats may also be used in fonts.

I would recommend a table of contents introducing the Formats.

I'm not sure I understand. The site generates navigation links already (on the right), so a TOC would be duplication.

Of the seven available formats, not all are commonly used today. Formats 4 or 12 are appropriate for most new fonts, depending on the Unicode character repertoire supported. Format 14 is used in many applications for support of Unicode variation sequences. Application developers should anticipate that other formats may also be used in fonts.

I suggest you also call out Format 13, since it's a legit format and is not obsolete. Everything else I consider obsolete legacy.

Thanks @PeterCon, I’d never noticed that before :-O

Format 13 has its advocates but also its detractors. Is there more than a few fonts in the world that use it?
Even so...
Revised draft per feedback:

Of the seven available formats, not all are commonly used today. Formats 4 or 12 are appropriate for most new fonts, depending on the Unicode character repertoire supported. Format 14 is used in many applications for support of Unicode variation sequences. Some platforms also make use for format 13 for a last-resort fallback font. Application developers should anticipate that other formats may also be used in fonts.

Format 13 has its advocates but also its detractors.

It was added into OT in recent times. So unless we want to agree to deprecate it, I see it as an active format.

Is there more than a few fonts in the world that use it?

No. But that's exactly what it was added for: catch-all fallback-fonts.

This is one issue that would really benefit from distinguishing font producers and font consumers, as in:

Font producers should only produce subtables in the following platform/encoding/format combinations:

If the font supports only characters in the Unicode Basic Multilingual Plane: platform 3, encoding 1, format 4.

If the font supports characters in any supplementary plane: platform 3, encoding 10, format 12 or (for last-resort fonts) 13.

If the font supports variation sequences (see chapter 23.4 of the Unicode Standard): platform 0, encoding 5, format 14, in addition to one of the other two subtables.

To support characters or symbols that are not encoded in the Unicode Standard, Private Use Area code points must be used.
Font consumers should also support other platform/encoding/format combinations that have been used in fonts in the past.

There are several statements on the page that contradict these prescriptions and need to be deleted.

Agree with Norbert's assessment. I suggest using 0/3 instead of 3/1, and 0/6 instead of 3/10. Ie. use the Unicode platform, not Microsoft platform.
FWIW here's how HarfBuzz picks what subtables to use:
  const CmapSubtable *find_best_subtable (bool *symbol = nullptr) const
  {
    if (symbol) *symbol = false;

    const CmapSubtable *subtable;

    /* Symbol subtable.
     * Prefer symbol if available.
     * https://github.com/harfbuzz/harfbuzz/issues/1918 */
    if ((subtable = this->find_subtable (3, 0)))
    {
      if (symbol) *symbol = true;
      return subtable;
    }

    /* 32-bit subtables. */
    if ((subtable = this->find_subtable (3, 10))) return subtable;
    if ((subtable = this->find_subtable (0, 6))) return subtable;
    if ((subtable = this->find_subtable (0, 4))) return subtable;

    /* 16-bit subtables. */
    if ((subtable = this->find_subtable (3, 1))) return subtable;
    if ((subtable = this->find_subtable (0, 3))) return subtable;
    if ((subtable = this->find_subtable (0, 2))) return subtable;
    if ((subtable = this->find_subtable (0, 1))) return subtable;
    if ((subtable = this->find_subtable (0, 0))) return subtable;

    /* Meh. */
    return &Null (CmapSubtable);
  }

The change you're suggesting, effectively deprecating platform 3, is a major change that would need broad consensus. It should be a distinct issue from the one opened here, and is too big a change to put into a dot-dot version.

That still leaves my proposal on the table, and I think it would bring some much-needed clarity about current reality.

That still leaves my proposal on the table, ...

See proposed changes I've shown for #599, which also includes changes for some other related issues. I think it does a good amount of what, but doesn't come up with a short set of bullet points. It's a goal I think all would say is good, but I don't think we can quite get there yet: I think we need multiple vendors to agree on one set of platform/encoding. Right now, Apple recommends platform 0, while MS recommends platform 3. My changes for #599 have tried to steer a somewhat neutral course.

Where does Apple recommend platform 0 by itself?
I see a recommendation in their cmap description:

Font should all have a Unicode cmap, either with a Unicode platformID or a Microsoft platformID and appropriate platformSpecificID.

Which would mean that platform 3 works for all.

Adding this in the 'cmap' section of the Recommendations chapter:

New fonts should use Unicode encoding: either a Unicode platform encoding (e.g., platform 0, encoding 4), or a Windows platform encoding (platform 3, encoding 1 or 10). The Unicode encodings for the Windows platform are also widely supported in other software platforms.

Adding this in the 'cmap' section of the Recommendations chapter:

New fonts should use Unicode encoding: either a Unicode platform encoding (e.g., platform 0, encoding 4), or a Windows platform Unicode encoding (platform 3, encoding 1 or 10). The Unicode encodings for the Windows platform are also widely supported in other software platforms.

Minor suggestion: for platform 0, recommend encoding 6.

Revised:

New fonts should use Unicode encoding: either a Unicode platform encoding (e.g., platform 0, encoding 4 or 6), or a Windows platform Unicode encoding (platform 3, encoding 1 or 10). The Unicode encodings for the Windows platform are also widely supported in other software platforms.

It's not clear that the spec could recommend one particular platform 0 encoding since, from what I've seen, the platforms that support platform 0 aren't aligned on which encodings are supported.

Before the spec can recommend any Unicode platform encoding at all, it needs to specify which “encoding” values exist and what they mean.

Those are listed in the name table spec and referred to from cmap. I find
it bizarre as well.
On Thu, Sep 10, 2020, 7:42 PM Norbert Lindenberg<EMAIL_ADDRESS>wrote:

Before the spec can recommend any Unicode platform encoding at all, it
needs to specify which “encoding” values exist and what they mean.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/typography-issues/issues/269#issuecomment-690822690,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABC4K64QGB4WG5M5PRQP5TSFF6AZANCNFSM4IEMAOFQ
.

Are you suggesting that the same details should be listed in two places? Or that the details should only be in the cmap chapter?

I didn’t even notice the reference to the name table spec, because I was looking at the Windows platform section, which lists all the encodings, and then the Unicode platform section, which doesn’t.
Now looking at the name table documentation, I see that most of the Unicode platform section is actually about cmap. This is truly bizarre.
So yes, copy the content of that section into the cmap page, with edits:

Reduce the first paragraph after the table to “Encoding IDs 0, 1 and 2 are deprecated.”
Reduce the second paragraph to “Only the 'cmap' subtable formats listed in the table above may be used for the corresponding encoding ID.”
Delete the third and fourth paragraph.

There’s of course more to do to disentangle the two table specifications. I’ll write a separate bug for that.

I’m also wondering: Is there any situation where a Unicode platform cmap works better than a Windows platform cmap? Or is support for Unicode platform cmap tables just a matter of platform neutrality? And conversely: Are you sure that Unicode platform cmap tables are equally well supported as Windows platform cmap tables in all OpenType implementations?

I’m also wondering: Is there any situation where a Unicode platform cmap works better than a Windows platform cmap?

As long as they are picked up by the implementation, there's no difference whatsoever.

Or is support for Unicode platform cmap tables just a matter of platform neutrality?

It seems like both are equally supported by the major implementations. So, no real difference there.

And conversely: Are you sure that Unicode platform cmap tables are equally well supported as Windows platform cmap tables in all OpenType implementations?

Definitely can't talk to "all". But all major are.

It's not clear that the spec could recommend one particular platform 0 encoding since, from what I've seen, the platforms that support platform 0 aren't aligned on which encodings are supported.

Peter, can you elaborate on the misalignments you’ve seen?

Peter, can you elaborate on the misalignments you’ve seen?

Based on info about Harfbuzz provided 3 days ago (above), and the list of supported platforms in Apple's doc'n.

Are you suggesting that the same details should be listed in two places? Or that the details should only be in the cmap chapter?

Like Norbert said, the section on Unicode encoding in name table talks about cmap subtable formats... I do believe cmap is a better place if we don't want to duplicate. But I also don't see any problem with duplication if can't be moved to a third page.
I see Norbert opened https://github.com/MicrosoftDocs/typography-issues/issues/615
One thing I just note here: when we removed all non-Unicode encoding supports from Fontconfig, had to add back support for English MacRoman in the name table strings, because (at least some versions of) AppleColorEmoji used MacRoman English name. Which makes sense for ASCII strings given that MacRoman is a single-byte encoding and all Unicode encodings available are 2byte or more. So that's the only non-Unicode encoding, and only in the name table, that I think we should endorse still supporting.
I also want to document another anomaly in the name table. We've seen, and I think is the name-table recommendation as well, that in symbol fonts, that is, those with 3/0 cmap, the English name strings also use 3/0 instead of 3/1. That's bizarre but definitely something in the wild that might have even been endorsed by the spec.

Based on info about Harfbuzz provided 3 days ago (above), and the list of supported platforms in Apple's doc'n.

See discussion from https://github.com/MicrosoftDocs/typography-issues/issues/599#issuecomment-690675822 and on.

I also want to document another anomaly in the name table. We've seen, and I think is the name-table recommendation as well, that in symbol fonts, that is, those with 3/0 cmap, the English name strings also use 3/0 instead of 3/1. That's bizarre but definitely something in the wild that might have even been endorsed by the spec.

Can you open a separate bug against the name table specification for that?

Updated proposal for addressing this issue:

Add the following text after the Overview section of the cmap table specification:

Requirements
New fonts must only contain subtables in the following platform/encoding/format combinations:

If the font supports only characters in the Unicode Basic Multilingual Plane: Either platform 3, encoding 1, or platform 0, encoding 3; using format 4.

If the font supports characters in any Unicode supplementary plane: Either platform 3, encoding 10, or platform 0, encoding 4; using format 12.

If the font is designed as a font of last resort: Platform 0, encoding 6, format 13 instead of any of the subtables listed above.

If the font supports Unicode variation sequences: platform 0, encoding 5, format 14 in addition to one of the subtables listed above.

To support characters or symbols that are not encoded in the Unicode Standard, Private Use Area code points must be used.
Applications must support the platform/encoding/format combinations mentioned above, and may support additional ones as needed to handle older fonts.

Delete the following text sections from the cmap table specification:

Unicode Variation Sequences supported by the font should be specified in the 'cmap' table using a format 14 subtable. A format 14 subtable must only be used under platform ID 0 and encoding ID 5.

When building a font that will be used on the Macintosh, the platform ID should be 1 and the encoding ID should be 0.

When building a Unicode font for Windows, the platform ID should be 3 and the encoding ID should be 1. When building a symbol font for Windows, the platform ID should be 3 and the encoding ID should be 0.
Microsoft strongly recommends using Unicode 'cmap' subtables for all fonts. However, other non-Unicode encodings are also used in existing fonts with the Windows platform.

When building a symbol font for Windows, the platform ID should be 3 and the encoding ID should be 0.
Fonts that support Unicode BMP characters (U+0000 to U+FFFF) on the Windows platform must have a format 4 'cmap' subtable for platform ID 3, platform-specific encoding 1.
Fonts that support Unicode supplementary-plane characters (U+10000 to U+10FFFF) on the Windows platform must have a format 12 subtable for platform ID 3, encoding ID 10. To ensure backward compatibility with older software and devices, a format 4 subtable for platform ID 3, encoding ID 1 is also required. The characters supported in the format 4 subtable must be a subset of the characters in the format 12 subtable and should include all of the Unicode BMP characters supported by the font.

Replace for format 4:

This is the standard character-to-glyph-index mapping table for the Windows platform for fonts that support Unicode BMP characters. See Windows platform (platform ID = 3) above for additional details regarding subtable formats for Unicode encoding on the Windows platform.

with:

This is the standard character-to-glyph-index subtable format for fonts that support only Unicode Basic Multilingual Plane characters (U+0000 to U+FFFF).

Replace for format 12:

This is the standard character-to-glyph-index mapping table for the Windows platform for fonts supporting Unicode supplementary-plane characters (U+10000 to U+10FFFF). See Windows platform (platform ID = 3) above for additional details regarding subtable formats for Unicode encoding on the Windows platform.

with:

This is the standard character-to-glyph-index subtable format for fonts supporting any Unicode supplementary plane characters (U+10000 to U+10FFFF).

Delete the recommendations for the cmap table from the Recommendations page.

Some of what you propose is new requirements, in particular:

Applications must support the platform/encoding/format combinations mentioned above,

I'm not comfortable putting that into a dot-dot release or adding it without knowing there is very broad consensus. Having a recommendation, however, would be fine IMO.

I'm OK with some of the other suggestions that don't add any new constraints on implementations, and will work on that.

I noticed your comment in #599 that Windows doesn’t support format 13; so we probably need an exception for that. Do you see anything else that you think might not be universally supported at this point?

A survey of CoreText and Harfbuzz is hardly the same as universally supported. If fonts ship with only 0/4 or 0/6 cmaps, how can we possible know how many libraries or apps they might not work in? How many printer drivers they won't work in? Whether they work in TT rasterizers but not in CFF rasterizers? There are just way too many unknowns. "Must" is saying that all of those things that have worked for years are not conformant. (Yes, we could say "conforming to version N", but that is not going to help many people in the real world.) "Should" would be fine; but I think "must" is too strong.

Some of the changes you propose were already in my current draft. At any rate, here's the revised draft for format 4 and format 12 sections:
format 4:

This is the standard character-to-glyph-index mapping table for the Windows platform for fonts that support Unicode BMP characters. See [Windows platform (platform ID = 3)][3] above for additional details regarding subtable formats for Unicode encoding on the Windows platform.This is the standard character-to-glyph-index mapping subtable for fonts that support only Unicode Basic Multilingual Plane characters (U+0000 to U+FFFF).

Note: To support Unicode supplementary-plane characters, format 12 should be used.

format 12:

This is the standard character-to-glyph-index mapping tablesubtable for the Windows platform for fonts supporting Unicode character repertoires that include supplementary-plane characters (U+10000 to U+10FFFF). See [Windows platform (platform ID = 3)][3] above for additional details regarding subtable formats for Unicode encoding on the Windows platform.
Fonts that include a format 12 subtable can also include a format 4 subtable for compatibility with older applications. This is not required, however. See the Recommendations chapter for additional information.

Here's the current draft for the 'cmap' section in the Recommendations chapter:

'cmap' Table
### Windows 'cmap' Table
When building a font for Windows, a 'cmap' subtable for platform ID 3 should be included. When building a Unicode font, encoding ID 1 should be used for this subtable. (This subtable must use format 4.) When building a symbol font for Windows, encoding ID 0 should be used for this subtable.
When building a font to support Unicode supplementary characters (U+10000 to U+10FFFF)), include a 'cmap' subtable for platform ID 3, encoding ID 10. (This subtable must use format 12.) To provide compatibility with older software, a subtable for platform 3, encoding ID 1 should also be included. Depending on application support and the content of text being displayed, either the 3/1/4 or 3/10/12 subtable may be used. Therefore, glyph mappings for characters in the range U+0000 to U+FFFF must be identical between the 3/1/4 and 3/10/12 subtables. Also note that the characters mapped in the 3/10/12 subtable must be a superset of the characters mapped in the 3/1/4 subtable.
Remember that encoding records must be stored in sorted order by platform ID, then by encoding ID.
### Macintosh 'cmap' Table
When building a font containing Roman characters that will be used on the Macintosh, an additional subtable is required, specifying platform ID of 1 and encoding ID of 0 (this subtable may use 'cmap' formats 0, 2, 4, or 6).
In order for the Macintosh 'cmap' table to be useful, the glyphs required for the Macintosh must have glyph indices less than 256 (since the 'cmap' subtable format 0 uses uint8 indices and therefore cannot index any glyph above 255).
The Apple 'cmap' subtable should be constructed according to Apple guidelines.
New fonts should use Unicode encoding:

If the font supports only characters in the Unicode Basic Multilingual Plane (U+0000 to U+FFFF): either platform 3, encoding 1; or platform 0, encoding 3. With either encoding, use a format 4 subtable.

If the font supports any characters in a Unicode supplementary plane (U+10000 to U+10FFFF): either platform 3, encoding 10; or platform 0, encoding 4. With either encoding, use a format 12 subtable.

If the font supports Unicode variation sequences: platform 0, encoding 5, with a format 14 subtable. This is in addition to a format 4 or format 12 subtable with encodings as listed above.

If the font is designed as a font of last resort, using single glyphs for entire Unicode character ranges: platform 0, encoding 6, with a format 13 subtable. A last-resort font should not use any other encodings or subtable formats.

When creating a font to support Unicode supplementary-plane characters, a format 4 subtable can be included, as well as a format 12 subtable, to provide compatibility with older applications might not support a format 12 subtable. This is not required, however. If both are included, either subtable may be used in different contexts, and so the glyph mappings for characters in the range U+0000 to U+FFFF should be identical. The format 12 table should include all BMP and supplementary-plane characters supported by the font. For each subtable, use the encodings indicated above.

We know that the text we’re working on will be presented to ISO for inclusion into an ISO standard. The purpose of a standard is interoperability. The cmap table is essential to OpenType; a font is unusable if font and rendering system don’t agree on it. If we offer both font developers and implementers a range of options, but don’t require anything to be supported, we have failed to provide interoperability. Yes, that standard has failed to do so for at least 13 years, but that doesn’t seem like a good justification for failing again.
That’s why I think there has to be a statement that starts with “Applications must support the platform/encoding/format combinations...” followed by something that is sufficient for general-purpose full-Unicode fonts. I’m OK if last-resort fonts are not covered.

I completely agree that interoperability should be the aim. But if our aim is really to provide guidance that is most likely to produce interoperability with the widest range of fonts and the widest range of platforms, libraries and applications, then I think the best way to do that would be to say:

BMP-only fonts: use 3/1/4
BMP/SMP fonts: use 3/10/12

Considering that 3/1/4 has been in use for 30 years and 3/10/12 for almost 20 years, there's extremely high likelihood that those are close to universally supported.
But saying that apps must support 0/3 or 0/4 is only likely to mean a lot of software or devices can't claim conformance. I don't think it particularly helps drive interoperability.

Here's the current draft for the 'cmap' section in the Recommendations chapter:

Why should this remain hidden away in the Recommendations chapter, and not be directly in the cmap table specification?

to provide compatibility with older applications might not support a format 12 subtable.

In Apple’s documentation I found this recommendation linked to Windows XP, which Microsoft formally abandoned six years ago. Is there any “application” that’s still relevant and requires this workaround?

BMP-only fonts: use 3/1/4
BMP/SMP fonts: use 3/10/12

That would take us back to something close to my earlier proposal. What do you think is the situation for 0/5/14?

Why should this remain hidden away in the Recommendations chapter, and not be directly in the cmap table specification?

This amount of detail strikes me more like implementation guidance than format specification. If there were short requirement statements, those clearly would belong in the cmap chapter.

to provide compatibility with older applications might not support a format 12 subtable.

In Apple’s documentation I found this recommendation linked to Windows XP, which Microsoft formally abandoned six years ago. Is there any “application” that’s still relevant and requires this workaround?

I'm not personally strongly attached to this. However, (i) I don't think that guidance ("if you do this, make sure that...") does any harm to have. And (ii) XP still shows up >0 in usage stats, and who knows how many XP devices in Asia aren't getting reported. Given the app back compat situation for some platforms, it may be a valid concern. I don't think it should be removed without input from platforms that might have that back compat concern, particularly in this case MS.

BMP-only fonts: use 3/1/4
BMP/SMP fonts: use 3/10/12

That would take us back to something close to my earlier proposal. What do you think is the situation for 0/5/14?

I was only commenting on those two in contrast to 0/3/4 and 0/4/12. Of course, 0/5/14 is essential for variation sequences, and 0/6/13 for last-resort fonts.
The fastest route to convergence would be to require 3/1/4, 3/10/12 and to deprecate 0/3/4, 0/4/12. But any such deprecation would be out of scope for OT 184 and should be done with broad consensus.

This amount of detail strikes me more like implementation guidance than format specification. If there were short requirement statements, those clearly would belong in the cmap chapter.

The current cmap specification runs to 21 pages when printed in Safari. I’d think adding half a page that informs readers which of those 21 pages are relevant today and which ones aren’t is a good investment.
Also, I don’t know how many people have read the OpenType spec cover to cover. I haven’t. The spec needs to be organized so that readers looking for specific information can easily find it. cmap table information belongs into the cmap table specification page.

I'm not personally strongly attached to this. However, (i) I don't think that guidance ("if you do this, make sure that...") does any harm to have. And (ii) XP still shows up >0 in usage stats, and who knows how many XP devices in Asia aren't getting reported. Given the app back compat situation for some platforms, it may be a valid concern. I don't think it should be removed without input from platforms that might have that back compat concern, particularly in this case MS.

Information about old implementations can be useful if it clearly identifies them. If the note starts with “For compatibility with Windows XP”, then readers can at that point consider to what extent Windows XP still matters to their business, and proceed based on that.
Without that identification, I think the note is harmful: It forces people to research what those “old applications” are, or add a subtable to fonts that will be useless in almost all cases, or (for tools developers) add an option that forces their customers to make that decision.

Take 3 on the requirements:

Requirements
New fonts must contain subtables in the following platform/encoding/format combinations:

If the font supports only characters in the Unicode Basic Multilingual Plane: Platform 3, encoding 1, format 4.

If the font supports characters in any Unicode supplementary plane: Platform 3, encoding 10, format 12.

If the font is designed as a font of last resort: Platform 0, encoding 6, format 13 instead of any of the subtables listed above.

If the font supports Unicode variation sequences: platform 0, encoding 5, format 14 in addition to one of the subtables listed above.

To support characters or symbols that are not encoded in the Unicode Standard, Private Use Area code points must be used.
Applications must support the following platform/encoding/format combinations:

Platform 3, encoding 1, format 4.
Platform 3, encoding 10, format 12.
Platform 0, encoding 5, format 14.

Applications should also support the following platform/encoding/format combinations:

Platform 0, encoding 3, format 4.
Platform 0, encoding 4, format 12.
Platform 0, encoding 6, format 13.

Applications may support additional platform/encoding/format combinations as needed to handle older fonts.

This is designed to guarantee interoperability for most fonts (not for last-resort fonts) while minimizing the number of applications that would be declared out of compliance.

The current cmap specification runs to 21 pages when printed in Safari. I’d think adding half a page that informs readers which of those 21 pages are relevant today and which ones aren’t is a good investment.

That's taken care of by text added in the overview section:

Of the seven available formats, not all are commonly used today. Formats 4 or 12 are appropriate for most new fonts, depending on the Unicode character repertoire supported. Format 14 is used in many applications for support of Unicode variation sequences. Some platforms also make use for format 13 for a last-resort fallback font. Other subtable formats are not recommended for use in new fonts. Application developers, however, should anticipate that any of the formats may be used in fonts.

Information about old implementations can be useful if it clearly identifies them. If the note starts with “For compatibility with Windows XP”...

I only mentioned XP in the discussion because you had mentioned it. There's really no way of knowing what applications have the limitation in question, though it's reasonable to believe there are some such applications in use.

It forces people to research what those “old applications” are...

With a font format that has maintained forward compatibility for 30 years of software, I'm not sure how that can be avoided for this or several other app-compat caveats.
Several hours have already gone into this chapter. If more work is to be done on it in the near term, I think #615 would have greater benefit. In the meantime, there are yet other issues that need to be considered that would have as much or greater impact, and so I won't prioritize more time on this until after other work is done, unless there's something egregiously wrong in the current draft.


Wont clean up socket on shutdown leading to "Address is already in use." error on next start.

Versions

nuxt: 2.14.0
node: 14.9.0

Steps to reproduce

Use nuxt configured with socket endpoint:

server: {
  socket: '/tmp/nuxt.socket'
}

Start nuxt (either nuxt or nuxt start);
Close nuxt;
Start nuxt again;

What is Expected?
Nuxt starts.
What is actually happening?
   ╭───────────────────────────────────────────────────────────────────╮
   │                                                                   │
   │   ✖ Nuxt Fatal Error                                              │
   │                                                                   │
   │   Error: Address `$redacted$` is already in use.                  │
   │                                                                   │
   ╰───────────────────────────────────────────────────────────────────╯

Ok, it expects the socket to be in /tmp and to be cleaned up by the os.

@h0m3us3r how did you managed to solve this?


Platformio-ide-terminal Installation Error

[ ] I have reset Atom to defaults prior to submitting report.
[ ] I have not reset Atom to defaults prior to submitting report.

Description

Steps to reproduce

Expected behavior:
Actual behavior:
Reproduces how often:
Versions

> atom --version

```1.29.0

apm --version

OS name and version:
Platformio-ide-terminal version:
Windows 10 Home Basic

### Additional Information
<!-- Add any additional information like screenshots, gif captures,
configuration, data or other Atom package lists, that might be necessary to reproduce the issue. -->
![image](https://user-images.githubusercontent.com/19245260/63220558-e52ad700-c1a7-11e9-834c-147323c7f665.png)

[2019-08-18T00_00_13_165Z-debug.log](https://github.com/platformio/platformio-atom-ide-terminal/files/3512714/2019-08-18T00_00_13_165Z-debug.log)

Thank you for reaching out with this bug report.
You are getting this reply because the issue template was not filled in its entirety, overwritten,  or some portions were partially left out.
This issue template contains important information to be able to provide any kind of support, and will help us triage or reproduce the issue. Without reproduction no workaround or fix can normally be derived...
Copy and paste the template located at https://raw.githubusercontent.com/platformio/platformio-atom-ide-terminal/master/.github/ISSUE_TEMPLATE.md and fill in all fields. Logs / Errors / other information should be added at the bottom in the Notes portion of the issue template.
Tickets without this information may be closed and labeled invalid at our discretion.
Thank you for your understanding.


inviteUnauthorized

Hi, I'm new to zrok, but very interested to try it out. Said that, I'm trying to understand how account/invite works. By default zrok is configured to use api.zrok.io end-point. But, the invite command through the following:
./zrok invite

enter and confirm your email address...
...
[_Submit_]

there was a problem creating an invitation!

you are trying to use the zrok service at: https://api.zrok.io

should you be using a --token? check with your instance administrator!

you can change your zrok service endpoint using this command:

$ zrok config set apiEndpoint <newEndpoint>

(where newEndpoint is something like: https://some.zrok.io)

[ERROR]: error creating invitation ([POST /invite][401] inviteUnauthorized)

Well, it seems that using email is not enough, the account should be in place. And, if I visit api.zrok.io there is a login prompt but there is no sign up page. So, my questions are the following:

do we need to create account first, if so where is sign up page
otherwise, if we do not need an account then why invite fails with unauthorized error.

we're still in an "invite only" mode. If you shoot an email over to<EMAIL_ADDRESS>- someone will reply to you :) if that's cool, close this issue out once you get your invite :)

Saw your email and replied, so I'll close this out. Welcome to zrok! :)


Tanks and Temples Cams_1/ file data

The 00000000_cam.txt camera file for the Family scene in the tanks and temples intermediate test set is as follows:
extrinsic
0.999914 -0.000314413 -0.0130934 -0.0371895
6.96597e-06 0.999724 -0.0234745 -0.127538
0.0130972 0.0234724 0.999639 0.570572
0.0 0.0 0.0 1.0
intrinsic
1167.35 0.0 962.678
0.0 1167.35 541.296
0.0 0.0 1.0
0.394995 0.874995
The last line has the depth_min value = 0.394995  and the depth_max value is 0.394995
How was the depth_max value calculated given I already know the depth_min value?
Thanks

The depth range in 00000000_cam.txt comes from the output of COLMAP SfM, please refer to MVSNet input from SfM output and the corresponding script for more information.

I ran colmap on one of the scenes from the intermediate test set of tanks and temples. After which I ran the script. The resultant cams file has different depth_min, depth_interval values. The extrinsics are also varying widely.
extrinsic
-0.5881633085624604 -0.16835001444728442 0.7910260394553769 -0.2083889597104861
-0.03307577633315584 0.9822831302399821 0.1844609581074039 -0.9169789870213997
-0.8080655390999046 0.0823293670663239 -0.58331120325058 4.010675698779487
0.0 0.0 0.0 1.0
intrinsic
1160.1059371040562 0.0 978.5
0.0 1160.1059371040562 542.5
0.0 0.0 1.0
2.807188 0.439042 192.000000 86.664167
The above is an example 000000_cam.txt that I generated for the Family scene in tanks and temples intermediate test set.


Make 2D navigation mesh baking parse all TileMapLayers

Makes 2D navigation mesh baking parse all TileMapLayers.
This lifts the limitation of the 2D navigation mesh baking only parsing the first TileMapLayer, due to popular demand.
Solves https://github.com/godotengine/godot/issues/85798 and all the other billion linked issues of the same kind.
Note that this change is intended to enable workflows where users have their parsed polygons on another TileMapLayer than the first. The 2D navigation mesh baking still treats the Tilemap data as if it is done with a single TileMapLayer, it only now parses data from all TileMapLayers, picks the first valid data for a cell found, and combines them all together.
The parsing process will try to block the most common user errors by ignoring all TileMap cell keys that already had a navigation mesh or collision shape that fits the collision mask parsed and print a warning instead.

Having navigation mesh for the same cell on 2 or more TileMapLayers is an error.
Having collision polygons with the parsed collision mask for the same cell on 2 or more TileMapLayers is an error.

For navigation polygons the build and placement rules are no surface overlap at all is allowed on the same navigation map. The only thing that can "overlap" between 2 navigation meshes are unique pairs of edges in order to merge them.
For collision polygons the build and placement rules are no overlap if it has a physics layer bit that is parsed by the NavigationPolygon collision mask. This means if users have 2 TileMapLayers with collision polygons placed in the same cell, 1 intended  for the navigation mesh parsing and 1 intended for e.g. gameplay the gameplay TileMapLayer should not have a matching bit on the collision layer with the NavigationPolygon parse collision mask, else it will be treated as duplicates with errors and rejected cell data.

Just out of interest. Why aren't you first combining (union in Clipper) all the layer-polygons before using them for navmeshbaking?

Thanks!

Thanks, Bug this  new  TilemapLayer node is  not working(https://github.com/godotengine/godot/pull/89179),The new TilemapLayer node cannot yet cooperate with NavigationRegion2D and cannot bake navigation polygons.Can this function be synchronized on the new node?

Does this PR solves the long standing TileMap navigation meshes "cutout" issue? I tried TileMapLayer a bit and it seems not the case.

Does this PR solves the long standing TileMap navigation meshes "cutout" issue? I tried TileMapLayer a bit and it seems not the case.

If you click to bake, will it be successful?

Does this PR solves the long standing TileMap navigation meshes "cutout" issue? I tried TileMapLayer a bit and it seems not the case.

If you click to bake, will it be successful?

I'm not using NavigationRegion2D at all. There has been a long standing issue where tilemap navigation layers unable to be "cut out" by physics layers in other tilemap layers. Looking at this PR, I'm getting the impression of 1 TileMapLayer with navigation layer can parse multiple TileMapLayers with physic layers to do the "cutout". I tried it on myside and it doesn't seemed to be the case.

Does this include changes for tilemap Physics Layers?
At the moment in 4.2 it appears as though no matter the collision mask parsed by the NavigationPolygon, only the first collision mask is used.
As an example, I currently have two collision layers used in my tilemap: one for preventing ground navigation, one for preventing flying. My first Physics Layer has just the ground nav collision, while the second has ground and flying, and the third has just flying. When attempting to bake the nav polygon for walking it seems to only bake according to that first Physics Layer, and ignores the second one.

I checked many navigation issues in the official forums, and the conclusion is that the 2D navigation layer is just a series of polygons, without the concept of layers, including the physics layer。
so even if it is solved, it is only by cutting off all merged physical layers before merging the navigation？
This fix only fixes the problem that only the first navigation layer on multiple tilemap layers is effective, and it is achieved by merging the navigation polygons in all navigation layers on the tilemap. This is my understanding.


Auto merge auto-update-weights-for-dev-e8bb50e73147f1d3b954e7361c453e7af8a673eb to dev

Codecov Report

Merging #1072 (3868fde) into dev (d5d424a) will not change coverage.
The diff coverage is 85.48%.

@@           Coverage Diff           @@
##              dev    #1072   +/-   ##
=======================================
  Coverage   74.94%   74.94%
=======================================
  Files          75       75
  Lines       10675    10675
=======================================
  Hits         8000     8000
  Misses       2675     2675

Impacted Files
Coverage Δ

pallets/creditcoin/src/weights.rs
86.41% <84.21%> (ø)

pallets/offchain-task-scheduler/src/weights.rs
100.00% <100.00%> (ø)

pallets/rewards/src/weights.rs
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


fix: topologySpreadConstraint fields in structured logs

There is a problem with the log display due to the use of non-exported fields：
https://github.com/kubernetes-sigs/descheduler/blob/f0f7ebbe9af680b338709391cf1c0da7c2270ce5/pkg/framework/plugins/removepodsviolatingtopologyspreadconstraint/topologyspreadconstraint.go#L220
Without this patch the tsc is printed as empty {}:
I1212 08:34:36.666387       1 topologyspreadconstraint.go:230] "Skipping topology constraint because it is already balanced" constraint={}

With this patch:
I1212 08:41:10.178744       1 topologyspreadconstraint.go:221] "Skipping topology constraint because it is already balanced" constraint={"MaxSkew":1,"TopologyKey":"topology.kubernetes.io/zone","Selector":[{}],"NodeAffinityPolicy":"Honor","NodeTaintsPolicy":"Ignore","PodNodeAffinity":{},"PodTolerations":[{"key":"node.kubernetes.io/not-ready","operator":"Exists","effect":"NoExecute","tolerationSeconds":300},{"key":"node.kubernetes.io/unreachable","operator":"Exists","effect":"NoExecute","tolerationSeconds":300}]}

/approve

/lgtm

Thank you for your contribution @SataQiu 🏆


How to install efficientdet?

None of the pypi installation methods will install efficientdet, the user has to manually install it via pip install git+..., but this is not mentioned anywhere in the documentation
Since it's in the core of our library to have soft dependencies, maybe it's a good idea to have a section in the docs explaining what you have to install if you want to use X. Say in the near future we add support for yolo, we need a section explaining the steps to install it (or point to the original installation instructions). This goes well with #245
@oke-aditya @paras-jain @ai-fast-track , what are your thoughts?

This is not exactly soft dependency as model definition is very important to our package, we cannot let it go away from the package.
We can add this to our repo only if we get .egg file from the repositories. Also, we need to check what dependency these repositories use, if they are minimal we can package them.

It's a soft dependency, mantis does not fail to import if you don't have efficientdet
Let's say you only want to train faster_rcnn, you shouldn't have to install efficientdet for that. And this should be true for every new model that we add

What if we get .egg file from this repo after a few months. Can we bundle it together ?

Getting the .egg files just seem to hacky, we don't want to deal with that
It's actually easier to have instructions on how to install the package

The problem is when we ship for release 0.1. The package from github repo may get updated and hence incompatibly with release. Suppose we lock our dependencies when it was working fine, then we receive an update from these packages that break stuff.
So it is safer to ship it with the corresponding .egg file.

The efficientdet dependency will also be locked to a specific version on our release, why are updates going to break stuff?

How will we lock efficient det version ? Do we lock to some commit stamp?

We lock a commit stamp, yes

Can we build a wheel for that commit stamp and provide as assets with our repo ?

My answer is: I don't know, and it should not be our priority now, not for 0.1.0
I'll start a 0.2.0 roadmap and add this there

Let's stick with adding installation instructions for efficient for this release, I'll close this one once we do that

Efficient is now installed with [all] =)


WIP: Upgrading Next from 12 to 13

What is the purpose of the change
The goal is to upgrade next to the latest release in order to enable the new features and also take advantage of the new benefits for DX (as they have improved the dev server as well).
In addition, by updating next, we also have the new version of React, which allows us to access the new features as well as being able to use the new library releases.
Brief Changelog

Upgrade next from v12 to v13
Upgrade React from v16 to v18
Re-rendering fixes

Testing and Verifying
This change has been tested locally by rebuilding the website and verified content and links are expected.
Definitely more testing needs to be done, to make sure there are no bugs around, especially related to re-rendering.

@DavideSegullo If this is still WIP, let's change this PR to a draft.

@JoseRFelix  I did other tests and it seems to works fine, can you review it? Thank you! Maybe we can also try to deploy a test version, to also check that vercel ci/cd ecc works fine

Will need to have a test deploy for QA. We tried to do this a couple of months ago but found many bugs caused by the upgrade. We abandoned it because we got busy, but we definitely need this upgrade.
@DavideSegullo

Will need to have a test deploy for QA. We tried to do this a couple of months ago but found many bugs caused by the upgrade. We abandoned it because we got busy, but we definitely need this upgrade.
@DavideSegullo

I can help with that, we can try to deploy and if there is any errors, I'll try to fix it!

Will need to have a test deploy for QA. We tried to do this a couple of months ago but found many bugs caused by the upgrade. We abandoned it because we got busy, but we definitely need this upgrade.
@DavideSegullo

I can help with that, we can try to deploy and if there is any errors, I'll try to fix it!

Thanks!

Will need to have a test deploy for QA. We tried to do this a couple of months ago but found many bugs caused by the upgrade. We abandoned it because we got busy, but we definitely need this upgrade.
@DavideSegullo

I can help with that, we can try to deploy and if there is any errors, I'll try to fix it!

Thanks! FYI I'll authorize the vercel deploy to preview

Your deploy is working, did you find any issues?
I tried also the build, i think I'm missing some parameters (Sentry, maybe something for the swap tool, actually it doesn't work in dev mod on "stage" branch too),pages etc. are fine you can check here: https://osmosis-frontend-fix-web.vercel.app

@DavideSegullo I did some quick QA and found an issue. When trying to change the language, the change is delayed and the user has to refresh the page to see the change.

@DavideSegullo I did some quick QA and found an issue. When trying to change the language, the change is delayed and the user has to refresh the page.

Thank you, I'll check that

@DavideSegullo I did some quick QA and found an issue. When trying to change the language, the change is delayed and the user has to refresh the page.

Thank you, I'll check that

The solution was to replace "react-multi-lang" with a homemade, react 18-compatible solution; the library used some old workarounds that are no longer usable.
I also took the opportunity to improve it, you will also find an autocomplete of keys when using the "t" function.
This modification allows you to continue working as you did before, but I would suggest migrating to a more full-bodied library that also supports i18n for next (so you can use sub-paths).
This way we also have one less dependency, and we should also recover some KB, the hook weighs much less.

@DavideSegullo does this mean we can remove react-multi-lang from the package.json?

@DavideSegullo does this mean we can remove react-multi-lang from the package.json?
We should probably use something like react-intl I would think? Wouldn't it make sense to just do that instead of custom rolling the useMultiLanguage hook?

Exactly, I didn't use a new library, because we can integrate that in another branch, so we can also integrate sub-path using one of the library suggest by next: https://nextjs.org/docs/pages/building-your-application/routing/internationalization.
In addition, sub-paths will allow us to index the site in multiple languages and perhaps eliminate the need to have a key in local storage (We would only manage it by uri and not with the state manager)
Ye I removed 'react-multi-lang' here: https://github.com/osmosis-labs/osmosis-frontend/pull/2232/commits/cc8467462340a47bef7f9315bdd8595f7845dc04

@DavideSegullo Was there a specific rationale for renaming useTranslation to useMultiLanguage? I felt the original name conveyed its purpose well. Perhaps we could consider rolling it back minimizing changes to this PR?

@DavideSegullo Was there a specific rationale for renaming useTranslation to useMultiLanguage? I felt the original name conveyed its purpose well. Perhaps we could consider rolling it back minimizing changes to this PR?

Yes, because "useTranslation" used to return only the "t" function, and there were several separate methods to access the information, now "useMultiLanguage" returns all the state with a single hook, so it is no longer strictly related to "t".
Do you want to bring back the modification of the new hook? And then migrate to a new language system with another pr?
I had thought of doing a separate one, but if we merge without this change there are bugs on the multilingual, if you prefer I can create another branch from this one to fix.
How would you prefer to proceed?

Although useMultiLanguage offers more than just the t method, I still believe useTranslation is a more descriptive name. My thought process is that useTranslation suggests it encompasses all aspects required to translate a string, including its state. On the other hand, useMultiLanguage gives me the impression that it only includes the available languages or the current selected language.

Although useMultiLanguage offers more than just the t method, I still believe useTranslation is a more descriptive name. My thought process is that useTranslation suggests it encompasses all aspects required to translate a string, including its state. On the other hand, useMultiLanguage gives me the impression that it only includes the available languages or the current selected language.

Ye, It seems legit, I'll rename it to make it more descriptive, maybe "useMultiLanguage" can be a bit confusing!

Closed in favor of https://github.com/osmosis-labs/osmosis-frontend/pull/2237


Can't capture exceptions, passphrase/pfx

Hello,
I'm using request 2.55.0 and I'm having problems capturing one exception.
This is my code using https:
var https = require('https');
var options_https = {
	hostname: 'one_url',
	port: 443,
	path: '/',
	method: 'POST',
	headers: {
		'Content-Type': 'text/plain'
	},
	maxattempts: 1,
	body: 'one body',
	pfx: {
		type: 'Buffer',
		data: [0, 130, 17, 128, 2, 1, 3]
	},
	passphrase: 'one_passphrase'
};

options_https.agent = new https.Agent(options_https);

var req;
try {
	req = https.request(options_https, function (res) {
		console.log('this is the response:', res);
	});
	req.end();
} catch (e) {
	console.log('THIS IS WERE I CAPTURE THE EXCEPTION', e);
}

This is my code using request:
var request = require('request');
var options = {
	url: 'https://www.one_url.com',
	method: 'POST',
	body: 'one body',
	headers: {
		'Content-Type': 'text/plain'
	},
	agentOptions: {
		pfx: {
			type: 'Buffer',
			data: [0, 130, 17, 128, 2, 1, 3]
		},
		passphrase: 'one_passphrase'
	}
};

console.log(options);

request(options, function (err, result, body) {
	console.log('this is the err ', err);
	console.log('this is the result ', result);
	console.log('this is the body ', body);
}).on('error', function (exception) {
	console.log('this is he exception, plese dont bury ', exception);
});

Am I doing something wrong? in the request example I don't capture the exception created:
_tls_common.js:130
      c.context.loadPKCS12(pfx, passphrase);
                ^

Error: Unable to load BIO
    at Error (native)
    at Object.createSecureContext (_tls_common.js:130:17)
    at Object.exports.connect (_tls_wrap.js:958:21)
    at Agent.createConnection (https.js:73:22)
    at Agent.createSocket (_http_agent.js:174:16)
    at Agent.addRequest (_http_agent.js:143:23)
    at new ClientRequest (_http_client.js:133:16)
    at Object.exports.request (http.js:31:10)
    at Object.exports.request (https.js:163:15)
    at Request.start (/Users/jesus/git/postmen.worker/node_modules/request/request.js:963:30)

Jesus

Seems already published in: https://github.com/request/request/pull/2164
so need 2.7.1


Add wildcard to tag on HtmlTargetElement

In a project, I would need to add functional logic on an unknown range of taghelpers. Why unknown ? just because I have a TagHelper on a homemade framework which contains mandatory logic. This framework is referenced by several projects.
On these several projects, We can write new TagHelpers but those new TagHelpers must call the TagHelper from the framework.
To reach our goal, the easiest way would be to apply our "framework tag helper" to every tags which begins by something
For instance, I'd like to apply my framework taghelper to every tag helpers beginning with "mytag-*". So i think allowing wildcard to "tag" parameter in HtmlTargetElement would be a great idea. It's already posible with the attributes

@DamianEdwards / @NTaylorMullen - any initial thoughts on this?

I can see value in having something like this. It'd be useful in the case where you want to provide attributes on every framework tag but not on random tags.

Hi @marcusien. The suggestion @rynowak has provided should satisfy the requirements you have described.

So what's gonna happen next ? Anything planned or done about this requirement ?


[opentelemetry-demo] Account for recent changes in load-generator

Now that this issue in opentelemetry-demo repo has been resolved, the helm chart needs to be changed. to account for these changes.

#330 addresses this issue, and should be ready to merge after new images for opentelemetry-demo are built and deployed.


A quest ,not bug

why rel/preview1 Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions project not auto create
like System.Buffer files? so compline error, can someone anwser me?  Thanks.

like that , not auto generate by dotnet restore or  dotnet build.

Not sure what you're asking. Those files come from an internal package that Kestrel is using. The package has a bunch of source files that are imported at restore time from a nuget package.

I have dotnet restore this project .

but i cann't see them in my project . my project after restored like this:

and  what's wrong? i can't understand.
restore failed?
but , i use preview2 project , it's right.

Is it just Visual Studio that doesn't "see" the Microsoft.AspNetCore.Server.Kestre.Internal namespace? Does the project still build using dotnet build? What versions of VS are you running? What's the output of dotnet --info?

@halter73
PS D:\tmp\KestrelHttpServer-rel-2.0.0-preview1> dotnet --info
.NET Command Line Tools (2.0.0-preview1-005977)
Product Information:
Version:            2.0.0-preview1-005977
Commit SHA-1 hash:  414cab8a0b
Runtime Environment:
OS Name:     Windows
OS Version:  10.0.15063
OS Platform: Windows
RID:         win10-x64
Base Path:   C:\Program Files\dotnet\sdk\2.0.0-preview1-005977\
Microsoft .NET Core Shared Framework Host
Version  : 2.0.0-preview1-002111-00
Build    : 1ff021936263d492539399688f46fd3827169983
yes, not found Microsoft.AspNetCore.Server.Kestre.Internal  namespace.
and use visual studio build or dotnet build  both failed.    vs is
vs 2017 version 15.3.0 preview 2.1

@davytitan Can you build the dev branch with a preview2 version of the CLI? The build.cmd script will automatically install a working CLI into ~/.dotnet/x64.
I would not put too much effort into trying to build an old prerelease branch.

yes~  preview2 version is right.  ok~ i will use the newst version project. Thank you~~~ and i will close this question @halter73


support real multiarch build.

What this PR does / why we need it:
resolve: IBM/operand-deployment-lifecycle-manager#241
depends on: https://github.com/IBM/test-infra/pull/146
We have add power and s390x cluster to the prow, now we can support real multi-arch build, this PR is to replace the old QEMU simulation way.
/hold
/dot-not-merge
until the stakeholder approve this to avoid build CI jobs down.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes  https://github.com/IBM/operand-deployment-lifecycle-manager/issues/241
Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Release note:

/assign @gyliu513 @chenzhiwei @DanielXLee @horis233

/lgtm
Leave to @chenzhiwei @horis233 @DanielXLee for approve.

@morvencao uses the real arch node to build ppc64le and s390x,  is it means we can delete qemu-ppc64le-static and qemu-s390x-static from dockerfile?

@DanielXLee Oh, yes, I forget that.

Emmmm... the power cluster is slower.

Update dockerfiles, PTAL @odlm-maintainers

Now we use one dockerfile for all three platforms, since the base image is also multiarch image.


[Request] Add support of Clang 18

As you can see below, LLVM v18 was released:
https://github.com/llvm/llvm-project/releases
So, I would be appreciated if this is supported.

Not sure if this repository is still being actively maintained, but I created this PR: https://github.com/egor-tensin/setup-clang/pull/21
It turns out Clang versions up to 18 and Ubuntu release 24.04 LTS (Noble Numbat) can be used with this action already. My PR only tests this and makes it more explicit.


sample code keep crashing on start

Hi,
I've downloaded the sample code. however, when I build the package and run it on actual samsung s4 the app keeps crashing on start. I tried to see with logcat. here's the log. for what I see this is the error
Time	Device Name	Type	PID	Tag	Message
07-11 09:54:18.977	Samsung SGH-I337M	Warning	1045	System.err	java.io.FileNotFoundException: /data/app/com.altusapps.zxingnetmobile-1: open failed: EISDIR (Is a directory)
at libcore.io.IoBridge.open(IoBridge.java:456)
at java.io.FileInputStream.(FileInputStream.java:76)
at android.content.pm.PackageParser.getHashValueOfPackage(PackageParser.java:5071)
at com.android.server.pm.PackageManagerService.saveHash(PackageManagerService.java:18033)
at com.android.server.pm.PackageManagerService.access$5100(PackageManagerService.java:325)
at com.android.server.pm.PackageManagerService$21.run(PackageManagerService.java:18018)
07-11 09:52:38.919	Samsung SGH-I337M	Debug	1045		TIMA: QCOM_send_command--int8_t QCOM_send_command(TIMA_handle_t, void*, uint32_t, void*, uint32_t, uint32_t)

Thanks for reporting this issue!  Unforunately it took me way too long to respond 😭.  Sorry, I apologize!  Recently the source code for this project was completely refactored to modernize it.  Many PR's were included in this effort, and many bugs were hopefully fixed.  Please try out the latest 3.x series of NuGet packages (currently in prerelease).  To try and make the project more maintainable in my spare time going forward, I've decided to close all existing issues to start with a clean slate.  If you're still experiencing this issue on the newest version, please open a new issue with as much detail as possible.  Thank you for your patience and understanding!  Happy scanning!


ADR on Product image selection

ADR22 on design of operators to accept custom images

I want to link this ticket: https://github.com/stackabletech/issues/issues/141 as it is relevant

I did a quick test with an untagged enum https://github.com/stackabletech/operator-rs/blob/image_version_crd/src/commons/image.rs (dont mind the names, i did not use the ADR names yet).
This leads to problems. First of the Custom and Auto variants get confused when deserializing, which causes the tests to fail. Secondly i cannot apply a CRD using this as all:
[customresourcedefinition.apiextensions.k8s.io/zookeeperznodes.zookeeper.stackable.tech](http://customresourcedefinition.apiextensions.k8s.io/zookeeperznodes.zookeeper.stackable.tech) created
The CustomResourceDefinition "zookeeperclusters.zookeeper.stackable.tech" is invalid:
* spec.validation.openAPIV3Schema.properties[spec].properties[version].anyOf[0].properties[productVersion].type: Forbidden: must be empty to be structural
* spec.validation.openAPIV3Schema.properties[spec].properties[version].anyOf[0].properties[repo].default: Forbidden: must be undefined to be structural
* spec.validation.openAPIV3Schema.properties[spec].properties[version].anyOf[0].properties[repo].type: Forbidden: must be empty to be structural
* spec.validation.openAPIV3Schema.properties[spec].properties[version].anyOf[0].properties[stackableVersion].type: Forbidden: must be empty to be structural
* spec.validation.openAPIV3Schema.properties[spec].properties[version].anyOf[0].type: Forbidden: must be empty to be structural
* spec.validation.openAPIV3Schema.properties[spec].properties[version].anyOf[1].properties[custom].type: Forbidden: must be empty to be structural
* spec.validation.openAPIV3Schema.properties[spec].properties[version].anyOf[1].properties[productVersion].type: Forbidden: must be empty to be structural
* spec.validation.openAPIV3Schema.properties[spec].properties[version].anyOf[1].type: Forbidden: must be empty to be structural
* spec.validation.openAPIV3Schema.properties[spec].properties[version].type: Required value: must not be empty for specified object fields

@teozkr said this could probably be fixed in kube-rs. But until then, our proposed solution does not work unless we actually use the enum variant names in the CRD (not using untagged), which will be another breaking change when trying to move back to the untagged version.

Thanks @maltesander!
I feared the same thing, so we have to use a complex enum I'd say

We also want a new attribute called pullSecrets similar to imagePullSecrets in spark-k8s setting https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-pod-that-uses-your-secret
  pullPolicy: IfNotPresent # String. defaults to IfNotPresent
  pullSecrets:
    - name: regcred # reference to secret in same namespace

@sbernauer done

bors merge


Add Text Block feature

It would be great to have a feature where a text block can be shown before, in between or after a task when collecting data with the Ground Android app.
This was identified as a useful addition for SERVIRs Ghana campaign to provide instructions to data collectors or to show/ read out statements to farmers about what is being done on their fields.
To jump to the next task, one has to press an 'OK' button.
This feature request relates to the Ground platform request https://github.com/google/ground-platform/issues/1991.

Just saw this new implementation in the app:

This is pretty much what we are looking for. If now only it became possible to add such a textbox to your survey with your own text.

This screen is specifically for "data sharing consent", not sure
user-defined instructions. I think a custom task would be the right thing
here.
On Tue, Aug 27, 2024 at 8:39 AM Jonas Spekker @.***>
wrote:

Just saw this new implementation in the app:
image.png (view on web)
https://github.com/user-attachments/assets/add88ddc-a2ee-44d7-a9fe-ce2396b28cdf
This is pretty much what we are looking for. If now only it became
possible to add such a textbox to your survey with your own text.
—
Reply to this email directly, view it on GitHub
https://github.com/google/ground-android/issues/2690#issuecomment-2312452684,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABXVURRZGFYDM4L6CVWKHLZTRXRXAVCNFSM6AAAAABNAT7KD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSGQ2TENRYGQ
.
You are receiving this because you are subscribed to this thread.Message
ID: <google/ground-android/issues/2690/2312452684 <(231)%20245-2684>@
github.com>

--
Gino Miceli
Developer Relations Engineer
Google Earth Engine

@gino-m @kenstershiro @jabramowitz5
Can we make this P1?

[@gino-m](https://github.com/gino-m) @kenstershiro @jabramowitz5
Can we make this P1?

We prioritize issues at the monthly product sync. I'll tag for review so it gets discussed.

@gino-m  would something like this work?

Nice, thanks! I'd suggest fontsize++ to make the instructions easier to read when in the field. @amegantz for the "Okay" button label.

This one is using the largest body size of 16pts!

This one is using the largest body size of 16pts!

LGTM! Thanks!

@amegantz Ok to use "Next" here to proceed instead of "Okay", as in other tasks?


Neither user {some id} nor current process has android.permission.READ_PHONE_STATE

When trying to use autoSend method, we see failure with this message Neither user {some id} nor current process has android.permission.READ_PHONE_STATE as failure message. This is not listed as one of the permission required, not sure why should this fail in that case?

I'm also getting this same error while doing this from an actual device. (added READ_PHONE_STATE access in the  Manifest file also)
Failed with this error: Neither user 10192 nor current process has android.permission.READ_PHONE_STATE.
And when doing from an emulator it's showing message sent successfully but haven't received anything.
@briankabiro can you please suggest how to tackle this.

@mdipanjan , look like this is an open issue here: https://issuetracker.google.com/issues/66979952, unfortunately, this is tagged as wontfix.


Tutorials Update

cc @willingc @jasongrout I took a pass through the tutorials.

Great improvements - thanks!

Thanks @blink1073 and @jasongrout :sunny:


conform static error pages to haproxy standards

add header
change filename to end with .http according to the haproxy guidelines
minify the html/css to stay within the 16kb limit to avoid truncation

https://cbonte.github.io/haproxy-dconv/1.6/configuration.html#4-errorfile
bsc#1080636
Signed-off-by: Maximilian Meister<EMAIL_ADDRESS>

Hi, this could break the assets. See kubic-project/velum#579

the static pages are not precompiled, this should not influence the asset issue. but let's get it fixed first, and then come back here

closing in favor of https://github.com/kubic-project/velum/pull/582 as we decided that static pages are not branded


Problem with run example model from cli in zsh

I have been following this guide https://mlem.ai/doc/get-started/applying#applying-from-cli, when I tried to run a command in zsh
mlem apply rf new_data.csv -i --it pandas[csv] -o prediction
I got an error
(base) ╭─maverchenko@datalab-gpu ~/test_mlem
╰─➤  mlem apply rf new_data.csv -i --it pandas[csv] -o prediction
zsh: no matches found: pandas[csv]

After that error I tried to run this command in bash shell and it works!
maverchenko@datalab-gpu:~/test_mlem$ mlem apply rf new_data.csv -i --it pandas[csv] -o prediction
⏳ Importing object from new_data.csv
⏳ Loading model from .mlem/model/rf.mlem
🍏 Applying `predict` method...
💾 Saving data to .mlem/data/prediction.mlem

Can you try escaping the []? or quoting it?

Yeah, I found that is common problem with zsh shell. Other commands like pip install dvc[s3] aren't work in this shell.
Solution is here https://github.com/jhollinger/otr-activerecord/issues/8


[Refactor] Seperate starcache from staros to avoid build staros modules if unnecessary.

What type of PR is this:

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)


raftstore: check uninitialized destroy for merge

What is changed and how it works?
Issue Number: Close #12048
What's Changed:
When a peer is destroyed without being initialized, it will store
itself to peer list and the region epoch is missing. In merge if
such state is detected, it should abort merging instead of panicking.

Related changes

Need to cherry-pick to the release branch

Check List
Tests

Unit test

Release note
fix panic when target peer is replaced with an destroyed uninitialized peer during merge

/merge