Simplifying Triggers for Locale Regex

I was wondering what the overall feeling would be to do away with matching the locale regex for logs and instead matching on broader regex. For example:
14:3FF1:Leviathan starts using Tidal Wave:
14:3FF1:Leviathan starts using Tidal Wave on person:143918:1092
14:3FF1:利维亚桑 starts using Tidal Wave:
14:3FF1:Leviathan starts using Flutwelle:
14:3FF1:Léviathan starts using Raz-De-Marée:
14:3FF1:リヴァイアサン starts using タイダルウェーブ:

can all be matched with 14:3FF1:.+? starts using .+?: and can be extended to include (on \y{Name}) as well, if we wanted. Mechanic names and boss names can similarly be substituted out if we wanted that functionality as well.
This, combined with a rudimentary dictionary of common Cactbot phrases plus their translation counterparts (I'm envisioning copy/paste, but it could ultimately live in a map within the code as well), could probably reduce the translation time and effort necessary for fights. An example would be standardizing all raidwide damage to be "aoe" and its non-English equivalents, etc.
The biggest drawback I immediately see is that the ids of the triggers themselves would have to be consistently good, since the mechanic name is no longer within the trigger regex itself. Additionally, anyone looking for タイダルウェーブ wouldn't find it since it's now just .+? and I'm expecting that the trigger ids will never be non-English just due to tradition at this point.

Agreed on trigger ids just not being non-English.
I think I usually put the ability name in the trigger, mostly for readability and less for the actual trigger text, if that make sense.
I think I would prefer something like / 14:3FF1:Leviathan/ in these cases.  I think there are cases where two enemies can use the same ability id? And I think there are some cases of overlap between players and mobs, but maybe I'm mistaken.  Having the name explicitly also makes the regex cheaper, because it doesn't have to backtrack ever and is just a literal string match.  All of the timeline syncs are all of the form /:Leviathan:3FF1:/ for 15/16 lines and /:3FF1:Leviathan/ for 14 lines, so cactbot alreayd depends on the "short" version.
I'm not sure what to do to make it more readable.  Maybe the trigger id is enough? Maybe there should be a comment after the regex of // starts using Tidal Wave? but that'd be hard to enforce.  Do you have thoughts here?

It's a hard line to walk between readability and ease of use -- I guess I don't fully know how difficult it is to translate everything, but it does seem tedious to have to add the regex lines in for every mechanic. However, I don't know that lowering that tediousness actually makes the barrier to entry low enough, since whoever would do the translation would have to either know the ability id or at least the ability name in English still (assuming the id of the trigger is well-written). It was just an idea I was playing around with in my head to hopefully get participation barriers lower and get releases to the other locales faster. But, I don't know if sacrificing readability really helps with that -- especially since the barrier is at least as high as knowing JavaScript, git, and GitHub.

The translations are mostly automatic.  There's a script that pulls things from fflogs and will generate that block at the bottom and then add regexes from that.
Some of them have capitalization issues though (esp French), and so maybe dropping the skill name would help a lot on that end.

Oh I see; so, it's still dependent either way on people coming in for the translation of the alert text. I should have git blamed before making assumptions. If that's the case, then to me it seems like the regular expressions are roughly as cheap as they're going to get with the added bonus of readability.
Also, on the French note: I assume that it's not possible to titlecase everything since it would take someone fluent enough in French to determine the casing on the moves. Although, it looks like this might be the approach taken by fflogs, since Multi-taillade Chaotique in E2S has the T capitalized on fflogs and its source, garlanddb, has it all lowercase. And, since https://github.com/quisquous/cactbot/pull/531 looks to have specifically targeted the capitalization of one word and not the other, I'm assuming this shotgun approach does not work.
If we dropped the spell names, how would we account for starts using <spell> on <player>? With .*? The only other major option I can see currently is adding an i modifier to the regular expressions so that you can translate automatically and have it run case-insensitive. If we took this approach we'd probably want to see about getting the u modifier in as well, for unicode upper/lower-casing, which has only recently been ubiquitously supported.

I looked into regexes.js and messed around with the modifiers. I added the ignore case and it worked fairly well across all triggers. It looks like JavaScript supports the Unicode modifier, too; so, we would be able to cover French characters with their capitalized counterparts.
Are there any cases you could think of where this wouldn't be a possible boon? Assuming the speed of the regex isn't hurt too much.

I think I would want to measure a little bit and understand the performance impact of case insensitivity before just turning it on everywhere.

Forgive the awfulness of this test:
import time
import re
from pathlib import Path
from collections import defaultdict

test = Path('C:/FFXIVLogs/Network.log')

regexes = {
    "ignore-case": r'(?i)20\|.*\|leviAthan\|3ff[12]\|tidal wave\|',
    "normal": r'20\|.*\|Leviathan\|3FF[12]\|Tidal Wave\|'
}

lines = test.read_text(encoding="utf8").splitlines()

totals = defaultdict(float)
counts = defaultdict(int)

runs = 100

for k, v in regexes.items():
    for i in range(runs):
        start = time.time()
        for line in lines:
            if re.search(v, line):
                counts[k] += 1
        end = time.time()
        totals[k] += end - start
    print(f'{k}: {totals[k]/runs} average seconds per run, {counts[k]//runs} average matches per run across {runs} runs')

returned
ignore-case: 0.19668999910354615 average seconds per run, 4 average matches per run across 100 runs
normal: 0.1958699893951416 average seconds per run, 4 average matches per run across 100 runs

The file in question has 266,070 lines.
Also, just for fun:
import time
import re
from collections import defaultdict

regexes = {
    "ignore-case": r'(?i)20\|.*\|leviAthan\|3ff[12]\|tidal wave\|',
    "normal": r'20\|.*\|Leviathan\|3FF[12]\|Tidal Wave\|'
}

totals = defaultdict(float)

runs = 10000

for k, v in regexes.items():
    for i in range(runs):
        start = time.perf_counter_ns()
        re.search(v, '20|2019-09-06T16:32:41.2490000-07:00|40009077|Leviathan|3FF2|Tidal Wave|40009077|Leviathan|9.70||14ca551f11c3c2eeed8d4feaa72b43b4')
        end = time.perf_counter_ns()
        totals[k] += end - start
    print(f'{k}: {totals[k]/runs} average nanoseconds per run across {runs} runs')

gives
ignore-case: 1300.69 average nanoseconds per run across 10000 runs
normal: 1122.71 average nanoseconds per run across 10000 runs

granted, this test is hardly good enough to prove anything; I'd like to think I have a decent computer and also it's not the same language that cactbot is even written in (although regex should be language agnostic, buuut)
Still, fun to code up. I'd like to see if we could get something closer to reality, but this actually makes me feel better than I was feeling when proposing the idea of ignore case modifiers.

Talked with @quisquous a bit more on this subject:
var regex = / 14:4105:Titan starts using Weight Of The Land/;
var regex2 = /^.{14} 14:4105:(?:|Titan starts using Weight Of The Land)/;

var testGood = '[03:25:42.637] 14:4105:Titan starts using Weight Of The Land on Titan.';
var testBad = '[03:25:42.633] 15:106E60D1:Chip Chippy:4095:Glare:40016136:Titan:750003:415F0000:1C:40958000:0:0:0:0:0:0:0:0:0:0:0:0:56289349:59121560:10000:10000:0:1000:99.96179:92.14917:2.384186E-07:3.132101:78699:78699:8630:10000:0:1000:109.2089:92.05762:0:-1.562527:.';

var testBad2 = '[03:25:39.365] 1A:106BD324:A Player gains the effect of Physical Vulnerability Up from Titan for 4.00 Seconds.';

function testRegex() {
  var start = window.performance.now();

  for (var i = 0; i < 1; ++i) {
    regex.test(testGood)
    for (var j = 0; j < 100; ++j) {
      regex.test(testBad);
      regex.test(testBad2);
    }
  }

  console.debug(' 14:4105:Titan starts using Weight Of The Land', window.performance.now() - start + 'ms');
}

function testRegex2() {
  var start = window.performance.now();

  for (var i = 0; i < 1; ++i) {
    regex.test(testGood)
    for (var j = 0; j < 100; ++j) {
      regex.test(testBad);
      regex.test(testBad2);
    }
  }

  console.debug('^.{14} 14:4105:(?:|Titan starts using Weight Of The Land)', window.performance.now() - start + 'ms');
}

testRegex();
testRegex2();

Gets me:
" 14:4105:Titan starts using Weight Of The Land" "0.21500000002561137ms"
"^.{14} 14:4105:(?:|Titan starts using Weight Of The Land)" "0.06999999823165126ms"

It seems like ^.{14}   is a fairly ideal prefix for most regular expressions that Cactbot comes across, given that every log will start with a timestamp and that it can enhance performance by a large margin.
Additionally, ^.{14} 14:4105:(?:|Titan starts using Weight Of The Land) performs marginally better than ^.{14} 14:4105:Titan starts using Weight Of The Land and can preserve the readability aspect of the regular expressions for people while not sacrificing anything if the translation is less than perfect (looking at you XIVAPI/FFLogs/everything that doesn't match with the FFXIV plugin)

I am still torn on how to convert regular expressions to use this, though:

just be explicit: ^.{14} 14:4105:(?:|Titan starts using Weight Of The Land)
^ implicitly means ^.{14} : ^14:4105:(?:|Titan starts using Weight Of The Land)
all regular expressions include ^.{14} , meaning something like bows to the striking dummy must now be .*bows to the striking dummy, but everything else is just 14:4105:(?:|Titan starts using Weight Of The Land)
a modification of 2, with a different regex vs legacyRegex where regex behaves like 2 above but legacyRegex behaves like the current behavior

I think I'm kind of inclined towards 3, along with just fixing everything up to match that.  It seems easy to document, and seems better than pretending ^ is what it's not.
I think all the timeline regular expressions, e.g. /:4105:Titan/ and :Titan:4105: could be detected via heuristics and then turned into the above form as well if they match as an optimization.

I was running through the code, prefixing spaces to already valid triggers in an effort to make the "bad" triggers more visible, and I ran into two cases that I personally hadn't considered:

Timeline triggers; these can be easily dealt with, but they will likely never want a time prefix. There's a lot of possible solutions here. The ones that immediately stand out to me:

When you're in the timelineTriggers struct, don't prefix the regex value

The inverse of this logic may be more profound: only prefix the regex values when they're within triggers

Explicitly renaming the regex to timelineRegex

I think both have their merits, I'm possibly more in favor of the latter since zoneRegex != timelineRegex != regex (or maybe triggerRegex? To be continued...)

Users with custom triggers; I can't think of a way to deal with these cleanly without adding some logic to figure out if the line "should have a prefix" unless we're fine to introduce breaking changes on the users end or if we treat user triggers as separate beasts entirely

I think a good way to possibly deal with both of these issues is maintain the legacy regex while moving optimized regular expressions to triggerRegex or something similar.

This sounds great.  timelineRegex definitely does not want a time prefix ever, as it's matching against the text in a timeline entry.  Similarly, it never needs a translation as it always matches against the English text.  They're handled by different parts of the code, so this shouldn't be an issue.
I like the idea as well of triggerRegex vs regex as a way to transition without breaking anybody.  We could even have some deprecation warnings for people using them and maybe eventually get rid of that path.
Having different words for regexes that have different semantics seems like a great direction, and the fact that it doesn't break anybody is also a plus.

Just to add to this conversation for the purpose of /iu for case insensitive and unicode support. I took the test from above and played with some different data. The first has both flags enabled, compared to the second, with neither flag enabled:
" 14:3FF1:Leviathan starts using Tidal Wave" "0.12500002048909664ms"
" 14:4105:Titan starts using Weight Of The Land" "0.10999990627169609ms"

Additionally, however; it might not be necessary for this due to ^.{14} 14:4105:(?:|Titan starts using Weight Of The Land) matching everything, and the text just being for readability. As I started to look through these a little more, I did notice cases like:
 14:4116:Titan starts using Stonecrusher on (\y{Name}) so it's possible we would not be able to conform everything to this other standard. Additionally, things like / 1[56]:\y{ObjectId}:Bomb Boulder:4142:Bury:.*:(\y{Float}):(\y{Float}):\y{Float}:\y{Float}:[^:]*:?$/, have the entity's name in them, which would still be problematic for case sensitivity.
Also, big note:
The value here for the Weight Of The Land regex is a better benchmark than the one I have above, as I did not originally pre-warm the regexes, so the first one was taking a slight hit. Doesn't change that the optimized one is still better, just not as dramatic.

Collecting some other thoughts from conversations elsewhere.
I think it's inconsistent to have regex, regexDe, regexFr etc but then infoText can return a dictionary of languages.  I think it'd be much simpler to just have regex with a dictionary.  The translation scripts would need to be updated to handle this.
Mostly, there's a concern just about how much repeating there is in regexes.  It seems maybe better to have something like a set of functions, where a trigger could look like:
regex: {
  en: Regexes.startsUsing('3A52', 'Neo Exdeath'),
  // etc
},

I think I would still want to support "general" regexes but would want to turn as many as possible into functions like this.  The list off the top of my head would look something like:
gamelog
  seals zone?
  unseals zone?
  npc rp text
starts using
starts using on
ability
ability on
ability with position
headmarker
tether
adds combatant
adds combatant with position
removes combatant
gains effect on, for time
loses effect on

I think there's some confusion on my part of how capturing would work in such a model.  Would every parameter to a startsUsingOn automatically capture, so that matches[1] is ability id, matches[2] is mob name, and matches[3] is whoever it is on? Would you have to specify capturing yourself, e.g. Regexes.startsUsing('3A52', 'Neo Exdeath', '(\y{Name})'),? and then matches[1] is who it is on? Would it be better if matches had names? Like, matches.abilityId and matches.targetName? An unfounded concern is that most things don't match, and maybe auto matching groups is slower? Maybe you need CaptureRegexes.startsUsing('3A52', 'NeoExdeath') if you want capturing or some such? A bit more thought needed here.
On a similar note, it might be good to have canned conditions and canned responses? Condition-wise, there's a lot of repeated "do I care about tankbusters" or "do I care about aoes" or "is this on me".  Response-wise, there's plenty of translations that we could build in and just have a function like Responses.getOut() or ResponsesStackOn(matches[1]).
I'm not sure I have all the answers here, but it does just seem that sort of adding more testing so that regexes are precise is not the answer, and it might be better to have another layer of abstraction here.

Along with the optimization to have every log line start with ^.{14}  as discussed above.  Then we would also more easily know that a line was a 14/15/16/1B line, and then could only test the regexes that were of those particular types against that line, rather than every regex against every line.  We could almost already do this now as well for anything that started with a space.

Thanks for pointing this out in 670, I had missed that there was more happening on this one.
For me, as a not-as-experienced contributor, I'm fully in favor of canned conditions/responses. That's a LOT of boilerplate that shows up in pretty much every piece of content in Heavensward on. Having something like this would be AMAZING. When I have more time tonight, I'll go through and make a list of what I've typically found... not painful, precisely, but annoying, in terms of "blah, this is the same stuff again".
The one concern I might have is that abstracting all this could cause issues for newer contributors. (As an example, Responses.stackOn([TARGET]) might be a pitfall in the case of tank-only markers, or markers where [ROLE] shouldn't stack. As a parallel example, you might remember that there was a time when data.role was split into tank, healer, dps-melee, dps-ranged, and dps-caster. I hadn't dug deeply enough into how data.role was implemented, and just tried a condition like data.role != 'dps'. It was caught during review, but it wasn't obvious to me at all until pointed out. Not insurmountable by any means, but definitely needs consideration.)
On regexes-as-functions, I think it's probably worth auto-capturing unless there's a significant performance hit. From the perspective of the contributor, it's irrelevant whether something gets matched but never used, while consistency in indexing for each element seems like a significant benefit. (So for instance, if I were putting together a standard 14: trigger, knowing that the target will always be matches[INDEX] seems like it would make things easy for contributors. It might also make errors easier to catch at review or even programmatically, because we would know that an ability code match should only ever be at such-and-such an index in matches.) The downside is that we wouldn't have that consistency across different log lines, but I think it's still worthwhile.

Alright, crawled through my contributions to date and came up with a short list of the stuff that I've experienced as being annoying boilerplate. First, some basic complete canned triggers:
Basic_Casttime_Tank_Buster(Skill_ID)
Basic_Instant_Tank_Buster(Timeline_Regex)
Basic_Casttime_Raid_Damage(Skill_ID)
Basic_Instant_Raid_Damage(Timeline_Regex)
Basic_Everyone_Spread_Marker(Marker_ID)
Basic_Everyone_Stack_Marker(Marker_ID)
Basic_Gaze_Attack(Skill_ID)

I can't think of an encounter that doesn't incorporate at least one of these, and combined with appropriate boilerplate responses these should be relatively simple to put together.
Next, the most common responses I've had to write in (apologies for these maybe not being formatted quite as we would want):
Responses.standardTankBuster()
Responses.cleavingTankBuster()
Responses.raidDamage()
Responses.spread(Targets)
Responses.stack(Target)
Responses.moveAround()
Responses.stopActions()
Responses.interruptCast(Target)
Responses.killAdd(Target)

I think that alone would go a long way toward reducing the annoyance of compiling triggers. Maybe make the responses take a popup_level parameter for infoText, alertText, or alarmText?
One other response that's really common but at the same time is complex is Responses.moveToPositionRelativeToBoss(), and I'm not sure what the best way to handle it is. Maybe make it take a parameter? So something like:
moveToPositionRelativeToBoss(Left)
moveToPositionRelativeToBoss(Behind)
moveToPositionRelativeToBoss(FrontOrBack)
moveToPositionRelativeToBoss(In)

Is it fair to say that all 14:\y{Boss Name} starts using log lines have a target? I haven't done an exhaustive search, but the ones I did pull up had the boss casting on themselves for most casts.

I thiiiink so? I wonder if it's possible to have an empty target.

Here's a proposal: https://github.com/quisquous/cactbot/compare/regexes.  Opinions welcome!
This differentiates startsUsing and startsUsingCapture.  I'm still not 100% sure if this is worth doing vs always capturing.
We could also arguably ignore abilityName by default too and just always accept anything.  That's an easy enough tweak.

i would say ignore abilityName by default sounds better as it would make translate trigger way quicker and easier.
Honestly can't think of a situation where you really need the ability name and where you couldn't use ability id  (i think 15/16 are the only ones where we don't habe the id in the log line, maybe worth asking rhavan to include it)

I agree with ignoring abilityName on 14/15/16 lines so long as it appears in the trigger somewhere. (Maybe add abilityName as an optional trigger property that could be populated similarly to timeline translations?) For newer contributors, it's potentially helpful to be able to associate a name with an ID immediately without having to look it up.
On capturing, I don't think it's really worth differentiating as far as performance goes, but I do like the implementation defined here. (It would also make it easier for newer contributors who maybe don't understand how capture groups work. I know this would have been helpful for me when I started submitting triggers.)
That all being said, I really like this proposal. In particular, defaulting to capture groups being named properties of the match rather than bare indices just makes sense.

@JLGarber
i would put the name of the skill as part of its id instead inside the startsUsingCapture, otherwise i would not really see the point of doing the rework at all (as it would not really simplifing creating trigger at all). I mean usually we do it already like in HadesEx Shadow Spread
Also in my eyes this rework is also not for newbies, but more for people who maintain the data in gereal. This rework makes it way harder for a newby to get started as i will not know where the data in  Regexes.startsUsingCapture('Phantom Train', '28A3', 'Doom Strike'), is comming from as he will not see it in the logs themself
For newbies we would like a Guide page which explains all the functions + where to find the data and how to "convert" them into the new format.

@Akurosia That's a fair point on ending up with no saved effort on the regexes themselves. I guess for me having things clearly labeled is important, since I tend to be really bad at it. But you're correct that labeling things outside the trigger ID is almost always duplicated effort.
I agree that this is going to be one more level of abstraction that new contributors have to get through, and of course it is worth it in the sense that the change will save regular contributors time. Within that framework, though, I think we should extend as much consideration as possible to newer users and how they might experience the rework, even if we do understand that this isn't specifically for them.

Ok, I put up a pull request for what I think is a reasonable way to have canned regexes.  You can optionally specify particular fields per helper if you want something specific there (other than "matches everything").  These all capture by default with the same names as the fields you specify.
Please take a look and let me know what y'all think.
Re: regex translations.  I think what I would like to do is to try to automatically convert from old style to this new style.  Then, once things are there, I would like to try using the timelineReplace block directly at runtime for triggers.  In other words, you would have a regex: Regexes.startsUsing({ name: 'Phantom Train', id: '28A3' }), line and then in the timelineReplace block, you would just specify what Phantom Train was in that language, and the regexes would "just work".  We could test that every name in a regex has a translation as well as part of linting.


Add network module

#11  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ksharma-xyz and the rest of your teammates on  Graphite


Update types and branding

update to use type bundles from @polymeshassociation/polymesh-types
replace polymath logo with polymesh logo
update to polymesh color gradient

@quinndiggitypolymath For the colors I'd prefer if we could use a different color for testnet and mainnet. (staging will default to a different color already). Would it be possible to have this added to the ENV variables instead of hard coding?
mainnet = 'linear-gradient(197deg, #FF2E72, #4A125E)'
testnet = '#43195B'

@F-OBrien I pulled the same changes in from the Polkadot-apps repo in my PR here #17


Update read the docs

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

Comparison is base (3bf1fd1) 84.97% compared to head (e69f530) 85.03%.
Report is 11 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #31      +/-   ##
==========================================
+ Coverage   84.97%   85.03%   +0.06%
==========================================
  Files          13       13
  Lines        3101     3101
==========================================
+ Hits         2635     2637       +2
+ Misses        466      464       -2

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


ignore client version warning

if using tailscale client built from source (or tailscale-git from archlinux repo), you may get a message:
% tailscale ip -4
Warning: client version "1.17.12-tb382161fe" != tailscaled server version "1.17.8-t5d6198ade"
100.xxx.xxx.xxx

The server warning message should be ignored so the IP can be properly output in https://github.com/mattn/tailscale-systray/blob/097938eaa163c002de1066649ac989e975b22be4/main.go#L82-L95

Fixed in last change. Could you please it?

What about
$ tailscale ip -4 2> /dev/null


🐞 [Bug] TFRobot: Better error message for wrong config file content

What happened?
Update the message error to make it easily understandable to the user. Here the error was the wrong file content, but the error message wasn't really helpful.

which network/s did you face the problem on?
Dev
Twin ID/s
No response
Node ID/s
No response
Farm ID/s
No response
Contract ID/s
No response
Relevant log output
.

I just added a line anywhere:
  "network": "dev",
  "max_retries": 5,
  "test: 'gi',
}

Now it shows the failed parts

The duplicate line is still not validated anymore; two networks are on the same config file.

@A-Harby Any duplicated field, the parser will skip the fields and parse only the last one, will add note about that in the docs

Validation:
added note about duplicated fields in the docs


systemd: Uprev from 234 to 237

Patches are still needed as confirmed by the fact that anything beyond
dom0 would not correctly start.
Signed-off-by: Jason Wessel<EMAIL_ADDRESS>

merged


Broken link to Jacksonhacks SPPT example files

Dear friend, the link to example files by Jasonkacks with explanations of the PowerPlayInfo table code seems to be broken.
This repo is a very very big work, continually growing and offering more and more information. Thank you.

Thanks for the info. The link is fixed.


[AutoRelease] t2-compute-2023-04-19-46616(can only be merged by SDK owner)

https://github.com/Azure/sdk-release-request/issues/4058
Live test success
https://dev.azure.com/azure-sdk/internal/_build?definitionId=978
BuildTargetingString
azure-mgmt-compute
Skip.CreateApiReview
true

issue link:https://github.com/Azure/sdk-release-request/issues/4058


Extension - Do not allow entering Amount without selecting an account in the Stake, Unstake screen

Describe the bug
Do not allow entering Amount without selecting an account in the Stake, Unstake screen

Refer to issue #1905

Actual : Can input Amount without selecting an account

Expect : Do not allow entering Amount

Don't fix => Close issue


Remove Bitcoin XT

Bitcoin XT developers have announced that they will not be implementing the upgrade, and that the software should be considered obsolete as-of May 15th.
https://honest.cash/dgenr8/xt-wont-follow-may-19-bch-fork-4313

@dgenr8 @dagurval FYI


clean up Cody CLI

Clean up entrypoint
Move cody chat/repl to repl subcommand (which is the default subcommand). The chat is still run if you omit the repl subcommand, though, so the CLI API does not change.
Factor out client creation code.
Other cleanups.

Test plan
The CLI is experimental, so just confirming that pnpm -C cli run start works is sufficient.

@mrnugget Saw you added this a while ago. Feel free to just stamp if you don't care about the code.  This cleanup is what I have that WIP branch based on.


feat request: Track announces via autobrr/IRC for racing

This is a continuation of a discussion that got a bit off-topic in a PR. I'm making this on behalf of @zivkovic to keep the discussion isolated from the PR.
See the first part here

In response to the last post....
I think the most effective and consistent way to implement this would be to use the {{.Artists}} macro, in tandem with maybe omegabrr to filter out the unnecessary announces (because much like with cross-seed, you will be hit with ALOT of music that is basically unnecessary, on the order of hundreds or thousands a day without filtering) - this can further be refined with format/quality settings in the filter itself. If setup incorrectly, especially if you're doing any comparisons that require snatching (I strong urge that you do not do this, as you know @moleculekayak that is pretty paramount to fertilizer and why cross-seed doesn't support music) you do so sparingly.
You should be able to - off the artist alone - get a list of potential candidates from the torrent directory that is rather slim, and narrow it down further off tokens such as format and quality to find potential candidates. There would be many ways to do this lookup. If you need ideas for this, although I don't think you would, let me know.
So basically the flow would be something like this, @zze0s may also have some input and potentially could help with some of this.

Filter with format and quality you would expect to have + omegabrr artist filtering
send {{.Artists}} and some other information without snatching the torrent - I suppose {{IndexerName}}, and a guid if you want
lookup the artist locally for any torrents
compare all candidates for matching criteria
decide how to create or snatch the torrent if you find a match

The reason i say potentially you could match is, if this is done properly, there would be no hit or problem snatching a torrent you are almost certainly going to seed that I'm aware of, however if possible this could be done entirely locally in the same manner it is now.

For now, as it is simpler, an action to run once a day(configurable) would be nice, to catch every not yet cross-seeded torrent and start cross seeding it, as you suggested.


Mismatched font weight for weigths 400/500

This is a tracking issue for the bug described in #40, opened since the mentioned PR was auto-closed.
A patch on top of v0.11.2 is available at https://github.com/RazrFalcon/fontdb/pull/40#issuecomment-1409120554.
Alternatively, a refactoring/rewrite of the querying logic is being considered, for which a separate PR will be opened once it's ready.

Fixed via https://github.com/RazrFalcon/fontdb/commit/db3d1abb017665833244fd09d92a740e7282a2cb


Hardware Configuration for MediaPipe (Pose, ...) on Chrome

Hi,
I'm looking for Hardware recommendation to run MediaPipe on Chrome to perform live Pose Estimation, Face Augmented Reality, for Digital Signage usecase (SmartMirror, Fitting Room, Sports Coach, etc ...)
My current SmartMirror use a Chromebit (HDMI Key on ChromeOS) small and great device no longer supported by Google. It's a ARM Cortex A17 1.8Ghz. But it's slow as hell on Pose Estimation might be few FPS / second at best. It's smooth on a Razer Laptop Core i7...
What target processor / configuration should run smoothly MediaPipe Pose or Face on Chrome ?

I target ChromeOS because it's fast / simple / accurate compared to a multitool windows or a DIY linux (but may be it's a mistake ?)
I target a small form factor like HDMI Key or small box because let's be honest MediaPipe is about user interraction (aka Didital Signage you can't use a Gaming Laptop or GTX30x to make it run IRL ;-)
I understand a MediaPipe usage is app on end user's mobile phone (for instance AR Makeup) but I rather use a regular computer for a SmartMirror

Any advice, pointer, help would be awesome if core team have some prefered/target devices/processor in mind ?

I looked deeper into processor and according to benchmarks :

Chromebit == RPi4 == ChromeCast Box
Chrome Box Celeron is x2 better
Chrome Box Corei3 is x6 better (half my Laptop CPU)
Chrome Box Core i5 is x10 better

It's only the CPU, I assume MediaPipe in Chrome rely a lot on GPU also ?

CPU Mark is a decent proxy for performance. Another proxy would be GPU performance.
When MediaPipe runs in Chrome, it uses both CPU/GPU in this way:
input image > GPU pre-processing > CPU model inference > GPU post-processing > GPU rendering
The most demanding part would be model inference, but that is only half of the picture.
I have an 8-core celeron chromebook , and with https://codepen.io/mediapipe/full/jOMbvxw i get around 12fps running the 'lite' model.

More and more RK3588 popup these weeks

with strong TPU
good video processing
fanless, 8nm

Does anyone give a try ? For my SmartMirror I'm looking for a low-cost, small form factor device to Run Android/Chrome with MediaPipe / TFJS and  Canvas/ThreeJS
ChromeBit was so good, but Google no longer maintain it. And it's a little too weak and old in 2022 to run all these processing.

Hello @JpEncausse,
We are upgrading the MediaPipe Legacy Solutions to new MediaPipe solutions However, the libraries, documentation, and source code for all the MediaPipe Legacy Solutions will continue to be available in our GitHub repository and through library distribution services, such as Maven and NPM.
You can continue to use those legacy solutions in your applications if you choose. Though, we would request you to check new MediaPipe solutions which can help you more easily build and customize ML solutions for your applications. These new solutions will provide a superset of capabilities available in the legacy solutions.


create new project flutter packages get cupertino_icons is very very slow

this is spend time，I have used vpn

Are you in China?
This looks like a network problem.

@mrerhuo
Network issue.
If you're in China, refer : https://flutter.io/community/china.


no .NET: New Project

URL
https://dotnet.microsoft.com/en-us/learn/dotnet/hello-world-tutorial/create
Operating system
windows
More information about your system
W10 x64
Description
There is no .New: New project option
dotnet --info
PS C:\Users\petel> dotnet --info
.NET SDK:
Version:           8.0.303
Commit:            29ab8e3268
Workload version:  8.0.300-manifests.c915c39d
MSBuild version:   17.10.4+10fbfbf2e
Runtime Environment:
OS Name:     Windows
OS Version:  10.0.19045
OS Platform: Windows
RID:         win-x64
Base Path:   C:\Program Files\dotnet\sdk\8.0.303\
.NET workloads installed:
There are no installed workloads to display.
Host:
Version:      8.0.7
Architecture: x64
Commit:       2aade6beb0
.NET SDKs installed:
8.0.303 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Other architectures found:
None
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
PS C:\Users\petel>

Hi, can you send a screenshot of what you see when you do the following steps inside visual studio code:

Open the command palette by pressing CTRL + SHIFT + P
Type .NET: New Project

update:

Can you confirm if you have the C# Dev Kit installed?
Navigate to Extensions (Ctlr + Shift + X) and type the name of the extension.
Confirm that is installed

OH, apparently not, though I can still run dotnet. I think what happened is some Windows 11 upgrade failed, preventing the PC from booting (twice) and eventually it "rolled back", one/both of which must have clobbered it. The reinstall is in progress.

It's there now, closing this.


GitHub Action Setup

[WIP]
This error in macOS:
https://github.com/yuki-koyama/elasty/runs/516591387?check_suite_focus=true#step:6:305
seems a bug in bgfx and it was solved in this PR:
https://github.com/bkaradzic/bgfx/pull/1834

I just finished the setup of GitHub Actions for macOS and Ubuntu 16/18.
It was really tricky, however. Updating bigg will cause errors in macOS, and not updating bigg will cause errors with GCC 7+ in Ubuntu. bigg is independently managed, so it is not easy to update bigg immediately. (Of course, sending a PR is an option.)
Thus, I did not update bigg at this moment and decided to use GCC 6 in Ubuntu 16/18.


Class 'Doctrine\DBAL\Driver\PDOMySql\Driver' not found when running migration that change a column

Laravel Version: 7.29
PHP Version: 7.4.16
Database Driver & Version: MySQL 5.7

Description:
Folks, im facing Class 'Doctrine\DBAL\Driver\PDOMySql\Driver' not found exception when running php artisan migrate:fresh --seed on a project that was shifted from Laravel 6 to 7.
After some research on google about the issue, i've found that some people resolved the problem by downgrading the doctrine/dbal package to version ^2, but i don't feel confortable to do that without a solid explanation.
And even if the solution found on other forums is right, isn't it the case to change the laravel 7 composer.json to require doctrine/dbal ^2?
Steps To Reproduce:

Create a migration that modify a column on a table
Run php artisan migrate:fresh --seed
Exception pops out when the artisan migration command try to run the migration with modifying function

  Class 'Doctrine\DBAL\Driver\PDOMySql\Driver' not found

  at vendor/laravel/framework/src/Illuminate/Database/MySqlConnection.php:64
    60|      * @return \Doctrine\DBAL\Driver\PDOMySql\Driver
    61|      */
    62|     protected function getDoctrineDriver()
    63|     {
  > 64|         return new DoctrineDriver;
    65|     }
    66| }
    67|

      +8 vendor frames
  9   database/migrations/2020_02_27_132227_alter_parts_table_change_serial_field_length.php:18
      Illuminate\Support\Facades\Facade::__callStatic("table")

      +32 vendor frames
  42  artisan:37
      Illuminate\Foundation\Console\Kernel::handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))```

     Thanks in advance!

Hey there,
Unfortunately we don't support this version anymore. Please check out our support policy on which versions we are currently supporting. Can you please try to upgrade to the latest version and see if your problem persists? We'll help you out and re-open this issue if so.
Thanks!


[CVAT][Exchange Oracle] Unit and integration tests

Description
Need to add more unit and service tests to Exchange Oracle
Motivation
To improve code test coverage.
Implementation details

Add tests for cron jobs.
Add unit tests for /src/modules/cvat/helpers.py

duplicate of #672


Mac: setting

If mac has enabled the setting "Reduce Motion" the animation isn't showing

Hi Enrico, this is an intentional feature that we added recently.
What do you think the ideal behavior would be when the "prefers reduced motion" setting is enabled? Maybe you want the animation to play but at a slower speed.

yes it this could be a nice feature

After referencing this article, we have disabled the translation animation if a user has the prefers-reduced-motion setting enabled. This will help users with motion sensitivity to use react-loading-skeleton safely.
If there is enough interest, we can add an option to allow the animation even if prefers-reduced-motion is enabled.

Closing since the currently-implemented behavior seems correct. (no animation when the user prefers reduced motion)


Hi I have a questions about experiments

First, Thanks for good research and i'm interested in skin cancer lession classification task.
So i want try reproduce your experiments but i only got 94% accuracy on HAM10000 dataset.
I execute 01_Skin_Distinction.ipynb, 02_Aug_img.ipynb, 03_Svd_Blend.ipynb to make datasets and i make 54292 images to train and 828 images to validation.
And i use FixCaps_HAM_24.ipynb to train and validate FixCaps model but I got 94% accuracy.
Is there any train methods or I did some mistakes?
And another question is about random seed.
I tried to fix seeds to use
np.random.seed(10)
torch.manual_seed(10)
torch.cuda.manual_seed(10)
these three codes but i can't fix result.
Is there any other methods?
Thank you

I'm glad you're interested in my research.
You can try my newly uploaded code(FixCaps_HAM-29.ipynb).
There are two factors that extremely influence the performance.
One is the preprocessing of the data, the relevant code is derived from[32](C. Zhao etal, "Dermoscopy Image Classification Based on StyleGAN and DenseNet2"). The data for the test set were randomly drawn from a specially selected set of 4501 samples(like the "lesion_id_HAM_0000005").
Another major factor is the random initialization of the weights. David Picard's work (" Torch.manual_seed is all you need On the Influence of Random Seeds") should help you.
And it is undeniable that the final choice of hyperparameters has a certain impact on the final performance of the model.
The robustness of the model does need to be improved, and recently I've been experimenting with new ideas. However, due to the difficulties of various trifles, the progress of the research is not particularly smooth. If I have further results, I will publish them on github or in a new paper.

We can communicate by email (caisongbai@126.com).

I have identified the factors that cause model instability: FractionalMax pooling, Squash function, random seeds, BatchSize, etc., and have overcome these flaws. I will post the code when the paper on FixCaps-V2 is published.

I make a sense your explanation
Very thank you for your careful explanation
2022년 11월 30일 (수) 오후 8:33, Woodman718 @.***>님이 작성:

I have identified the factors that cause model instability: FractionalMax
pooling, Squash function, random seeds, BatchSize, etc., and have overcome
these flaws. I will post the code when the paper on FixCaps-V2 is published.
—
Reply to this email directly, view it on GitHub
https://github.com/Woodman718/FixCaps/issues/1#issuecomment-1332012973,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASHBKDUAWI7MS5HEGTZEFKLWK43QRANCNFSM6AAAAAARXZISJM
.
You are receiving this because you authored the thread.Message ID:
@.***>

--

Hey can i get tensorflow version of fixcaps model?

Sorry, we currently have no plans to provide a TF version.

Brother in 02_Aug_img.ipynb how can i create or find the directory name 525_train etc . . .


Only bumping up patch versions in pipeline

Describe the bug
After migrating from standard-version, when running in a CloudBuild pipeline, my package version only gets bumped as a patch version every time. Doing a dry-run in my local works as expected, but for some reason the pipeline doesn't recognise the commits.
I used to have this issue before with standard-version, and fixed it by doing a git pull --tags beforehand, although now simply swapping libraries seems to start failing again, even with the pull.
Current behavior
bumps up only patch version, no matter if the latest commits include feat: ...
Expected behavior
bumps up the package with a minor version
Environment

commit-and-tag-version version(s): v12.4.1
Node/npm version: node 18.20
OS: cloud build pipeline (not sure what they use, but a node:18 docker image is mounted there)

Possible Solution

Additional context
Add any other context about the problem here. Or a screenshot if applicable

There’s nothing different between the two tools that should cause this- are you sure it’s not a cloudbuild setting causing the pull to not work correctly?

🤔 not really, since it was working before within cloudbuild... I'll keep investigating and see if I can find the issue

Can you confirm which is the last version that currently works? A current test will eliminate whether or not it's a cloudbuild setting.
(the versions of commit-and-tag-version and standard-version are equivalent)

Sidenote: I checked the docs for cloudbuild - it does a shallow clone with --depth 1. Unless I'm missing something, I don't think you can use git pull --tags to get the rest of the commits - if it was working before, I'd guess (something like) cloudbuild didn't previously do a shallow clone, something has changed between git versions, or some other process was unshallowing the checkout for you.
You can verify this by cloning a repository with git clone --depth 1 <some repository url>, changing to that directory, and
then doing git pull --tags - you'll see that yes, all the tags come down, but git log will show that the past commits aren't there.
I think you'll instead have to use git fetch --unshallow - which is also what's recommended by the codebuild docs.

Ah thanks for this, it gives me a better insight. I'll try a few things and let you know

Right, after a few tests, git fetch --unshallow --tags fixed the thing.
git fetch --tags as you mentioned, would only bring the last commit so the version will be based on that single commit message
git fetch --unshallow would bring all commits, but create a version taking ALL of them into account, ignoring previous versions.
git fetch --unshallow --tags brings all the necessary info to generate the correct version and tag
Not sure where, when, how this broke since the pipeline had been working for about 2 years and the only change I had was migrate to this package in the last month or so (although I might have missed something, or maybe it was something in the cloud build ecosystem).
Thanks a lot for the help, and sorry for taking your time 🙂

No worries at all! Glad you got it working


Add Moderation to chat requests

when not issuing commands to local outcomes, add moderation to chat requests, see documentation, it should be free from openAI
Moderation Documentation
Additionally, what we would want to do is take the response types, and maybe have GPT create a response that is about MyLife values, philosophy and mission

unclear if this is now baked into product or can still leverage... would like to leverage for reasons described above, such that we could in fact point people towards more empathic, self- and other-, outcomes


How to filter columns in the Version Tracking tool.

How do I add filters for the columns that are available in the version tracking matches. Eg I want the following filter.
votes >= 1, #conflicting <= 0, Multiple Source Labels <= 0
Eg I do not want to have to manually sort each column 1 by 1, then apply markup over and over (ultimately this will be scripted however it would be nice for the UI to have a simple filter function).

Am I missing something? There seems to be a few filters you can set up, but not a simple "hide these columns" like you'd see in any common grid control control.

Also what are tags and what are they used for?

This issue is related https://github.com/NationalSecurityAgency/ghidra/issues/6066

Version Tracking is an old soul.  Most Ghidra tables now have the ability to perform custom filtering on any column.  VT was not updated to use this feature.   Using the 'More Filters' button you can tweak more column filters than are on the bottom of the widget.  But, not all columns are filterable at this time.
Tags are a simple markup mechanism that allows users to mark matches.   There are filters for tags as well.

Using the 'More Filters' button you can tweak more column filters than are on the bottom of the widget. But, not all columns are filterable at this time
How do I add more items? Everything is selected and all I can see is the following

How do I add more items? Everything is selected and all I can see is the following

What you see is the current list of available items for filtering.

We have added Column Filters to the Version Tracking matches table.  You can use these column filters to do most of the filtering requested in this ticket.


ts-jest not picking up modules from .d.ts file resulting in "module not found" error

🐛 Bug Report
I currently have a module inside of a .d.ts file which has been included as part of my tsconfig.json. VS Code/TypeScript seems to pick up the types for this module normally through my tsconfig includes, however when I go to run the tests I get "Cannot find module '@test/utility' from 'api/TestApi.ts'".
Full error:
src/root.component.test.tsx
  ● Test suite failed to run

    Cannot find module '@fsg-saturn/advised-utility' from 'api/TestApi.ts'

    Require stack:
      api/TestApi.ts
      root.component.tsx
      root.component.test.tsx

    > 1 | import { sendApiRequest } from "@test/utility";
        | ^
      2 | import { TestMessage } from "../feature/testMessage/TestMessage";
      3 |
      4 | export const getTestMessage = async (): Promise<TestMessage> =>

      at Resolver.resolveModule (../node_modules/jest/node_modules/jest-resolve/build/resolver.js:311:11)
      at Object.<anonymous> (api/TestApi.ts:1:1)

To Reproduce
My tsconfig looks like this:
{
  "extends": "ts-config-single-spa",
  "compilerOptions": {
    "esModuleInterop": true,
    "module": "esnext",
    "allowSyntheticDefaultImports": true,
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "lib": [
      "dom",
      "es5",
      "scripthost",
      "es2015",
      "es2015.promise",
      "es2016.array.include",
      "es2018"
    ],
    "noEmit": true,
    "jsx": "react",
    "strict": true
  },
  "include": ["src/**/*", "@types/**/*"]
}

My jest.config.js looks like this:
module.exports = {
  rootDir: "src",
  transform: {
    "^.+\\.jsx?$": "babel-jest",
    "^.+\\.tsx?$": "ts-jest",
    ".+\\.(css|styl|less|sass|scss)$": "jest-css-modules-transform",
  },
  transformIgnorePatterns: ["node_modules/?!(@material)/"],
  setupFilesAfterEnv: [
<EMAIL_ADDRESS>  ],
};

The .d.ts file looks like this (utility.d.ts found at /@types/):
declare module "@test/utility" {
  import { sendApiRequest } from "@test/utility/api/ApiUtils";
  export { sendApiRequest };
}

declare module "@test/utility/api/ApiUtils" {
  type QueryData = {
    [key: string]: string | number | boolean;
  };
  export const sendApiRequest: <T>(
    path: string,
    query?: QueryData
  ) => Promise<T>;
  export {};
}

The test looks like this:
import React from "react";
import { render } from "@testing-library/react";
import Root from "./root.component";

describe("Root component", () => {
  it("should be in the document", () => {
    const { getByText } = render(<Root />);
    expect(getByText(/Testapp is mounted!/i)).toBeInTheDocument();
  });
});

The reference to the test looks like this:
import { sendApiRequest } from "@test/utility";
import { TestMessage } from "../feature/testMessage/TestMessage";

export const getTestMessage = async (): Promise<TestMessage> =>
  await sendApiRequest<TestMessage>("hello-world-message");

Steps to reproduce the behavior:
Run npm run test
Expected behavior
The tests run successfully.
envinfo
System:
    OS: Mac OS (latest)
    Node version: v14.16.0

Npm packages:
    jest: 27.0.4
    ts-jest: 27.0.3
    typescript: 4.1.2

The error Cannot find module is Jest runtime error. To be precise, it is Jest module resolution error that Jest cannot find the module with the path.
The only way to solve it is using moduleNameMapper, you can check https://kulshekhar.github.io/ts-jest/docs/getting-started/paths-mapping


Allow for Runner to be set more than once

Allows daft.context.set_runner_* to be called more than once per Python session, for demos and tutorials

Closing - cache invalidation is too difficult for this to be a safe operation for the user


IAsyncCodeLensDataPoint with immediate action without details window

The example CodeLensOopProvider as well as the existing CodeLens features only show how an additional details window is opened, from where further actions are invoked. Is it possible to execute something just by clicking on a CodeLens IAsyncCodeLensDataPoint item?

@AmadeusW do you know?

I believe that you can't execute an arbitrary command. The API allows you to display string or tabular data in the popup, using CodeLensDetailsDescriptor.
This class allows you to define CodeLensDetailPaneCommands, perhaps you'll be able to accomplish what you need with this?
Keep in mind that part of the Code Lens API is internal, which means that extensions don't have the same capabilities as default Code Lens items that come with VS.

I understand that, but I wish I could at least do the same as the model in VSCode provides. That is very desirable and from my point of view nothing too complex :)

CodeLensDetailPaneCommand is not really what I’m looking for.


drivers: flash: spi_nor: unconditionally provide config pointer

Information about which block protect bits are set on power-up is not inferable from SFDP content, so we need the devicetree config pointer to get the has-lock property value even when SFDP data is read at runtime.
Fixes build error with CONFIG_SPI_NOR_SFDP_RUNTIME=y.
Fixes #34716
Signed-off-by: Peter Bigot<EMAIL_ADDRESS>

Hi @pabigot,
Thanks for taking care of this bug.
This patch is not good enough. You also need to move the has_lock member out of the #ifndef CONFIG_SPI_NOR_SFDP_RUNTIME statement in struct spi_nor_config.
Else, with your current patch, we have the following error when CONFIG_SPI_NOR_SFDP_RUNTIME is enabled:
drivers/flash/spi_nor.c: In function 'spi_nor_configure':
drivers/flash/spi_nor.c:1073:9: error: 'const struct spi_nor_config' has no member named 'has_lock'
  if (cfg->has_lock != 0) {
         ^~
drivers/flash/spi_nor.c:1080:36: error: 'const struct spi_nor_config' has no member named 'has_lock'
    rc = spi_nor_wrsr(dev, rc & ~cfg->has_lock);

#34716

This patch is not good enough. You also need to move the has_lock member out of the #ifndef CONFIG_SPI_NOR_SFDP_RUNTIME statement in struct spi_nor_config.

@simonguinot Thanks; fixed, and build checked against variant:
#CONFIG_SPI_NOR_SFDP_MINIMAL=y
#CONFIG_SPI_NOR_SFDP_DEVICETREE=y
#CONFIG_SPI_NOR_SFDP_RUNTIME=y


spi: stm32: Correctly apply CPOL and CPHA settings

SPI_MODE_GET() returns a bitfield. It is thus wrong to test if a bit is
set using the equality operator. The bit-wise AND operator must be used
instead.
This can be tested by setting the SPI in mode 3 (CPOL + CPHA). Currently
both tests will fail and the result is a SPI configured in mode 0. This
was confirmed using an oscilloscope. Applying the patch fixes the
polarity.

Commit 17f4dd8b6096946e56fb33b94d18dbb6a9bfdf05 in PR #5413 is already addressing the issue.

@ydamigos Sorry I missed your patch, as the title of your PR was advertising only the F1 support. So you can disregard my PR.

@vaussard it's my bad. I didn't update PR's message after pushing this commit.

I removed the same change from PR #5413.


Add alpha APIs for creating Seequent EVO tilesets

This PR adds a new concept of TilesetCreators and UrlProviders:

The UrlProviders/ directory contains files with functions that call external services such as the mesh export service and Seequent EVO visualization service to retrieve urls to 3D tilesets
The TilesetCreators/ directory contains files with functions that create/initialize tilesets using these urls

A pair of new files in these directories are GeoscienceUrlProvider.ts and GeoscienceTileset.ts. GeoscienceUrlProvider.ts contains getGeoscienceTilesetUrl which retrieves a url to a 3D Tiles tileset.json from Seequent, as described above. GeoscienceTileset.ts contains createGeoscienceTileset which uses that url to create and attach a reality model using Viewport.displayStyle.attachRealityModel.
All of these APIs are marked as @alpha because they are experimental in collaboration with Seequent. Only APIs within GeoscienceTileset.ts and GeoscienceUrlProvider.ts are exported from frontend-tiles.ts because they are necessary for the demo Seequent is working on.

/azp run iTwin.js

/azp run iTwin.js Docs - YAML

/azp run iTwin.js Integration - GitHub

@pmconne This is our fix for PR #6913 based on your conversation with @danieliborra, everything new is now alpha and the rest of frontend-tiles is not changed

/azp run iTwin.js

/azp run iTwin.js Docs - YAML

/azp run iTwin.js Integration - GitHub

I feel like refactoring this graphics provider/graphics service code and introducing alpha APIs for seequent have become very coupled when they don't need to be. Andre and I have discussed it, and we think it might be cleaner to remove all the new "__UrlProvider" and "__Tileset" files except the geoscience ones, and save those changes for a later conversation. @danieliborra let me know what you think of this option.

I feel like refactoring this graphics provider/graphics service code and introducing alpha APIs for seequent have become very coupled when they don't need to be. Andre and I have discussed it, and we think it might be cleaner to remove all the new "__UrlProvider" and "__Tileset" files except the geoscience ones, and save those changes for a later conversation. @danieliborra let me know what you think of this option.

After the discussions on this PR, we have decided to pare this PR down to only include changes necessary to set up access to the seequent service marked as alpha. The files including this functionality have been moved to within GraphicsProvider for clarity, while they are still under url-providers and tileset-creators as this is the direction we most likely want to go in the future when further refactoring happens. There are no changes to any beta or public API's or their dependencies, only new alpha API's for the seequent connection.


add school graduateinstitute.ch

Official URL : http://graduateinstitute.ch
long-term programme : http://graduateinstitute.ch/fr/home/study/academicdepartments/international-economics/studying-economics/master.html
course catalogue -> statistics : http://graduateinstitute.ch/files/live/sites/iheid/files/sites/cours2018-2019/docs/course-catalogue.pdf
email for studentes : http://graduateinstitute.ch/fr/home/students/infoadmin/it/comptes-it.html
accredited higgher education : https://www.swissuniversities.ch/en/higher-education-area/recognised-swiss-higher-education-institutions/

@samuel-sobrino Pull request merged. Thank you!


Library release removal request

Library name
Mosiwi-basic-learning-kit-for-arduino
Version to remove
v1.0.0

Hi @Mosiwi. You must delete the tag from the library's repository before we can remove the release. I see that it has not yet been removed.
I'll provide instructions you can follow to do that:

Click the following link to open the web page of the tag:
https://github.com/Mosiwi/Mosiwi-basic-learning-kit-for-arduino/releases/tag/v1.0.0
Click the Delete button on that page.
Click the I understand, delete this tag button.
Comment here to let me know that the tag has been deleted so that I can proceed with removing the release from Arduino Library Manager.

Hello, v1.0.0 has now been deleted.

Thanks! I am confirming your request.
Unlike submissions, this type of request is still handled manually. The Library Manager index maintainer occasionally comes through to clear all the outstanding requests and closes those issues and pull requests when it is done. You will get a notification from GitHub at that time.
After that, you can monitor the indexing of the library via its dedicated logs web page.
Information about that here:
https://github.com/arduino/library-registry/blob/main/FAQ.md#can-i-check-on-library-releases-being-added-to-library-manager

Hello, I updated the code of the library, changed the version number, and released the new tag. Why is the Arduino library manager still not updated?

The problem is reported here on the dedicated logs webpage we publish for each library in the Arduino Library Manager:
http://downloads.arduino.cc/libraries/logs/github.com/Mosiwi/Mosiwi-basic-learning-kit-for-arduino/
2022/06/26 02:22:36 Checking out tag: v2.0.0
2022/06/26 02:22:37 Release Mosiwi_Basic_Learning_Kit:2.0.0 has wrong library name, should be Mosiwi Basic Learning Kit

You changed the value of the name field in your library.properties metadata field from the one the library was registered under ("Mosiwi Basic Learning Kit"):
https://github.com/Mosiwi/Mosiwi-basic-learning-kit-for-arduino/blob/v2.0.0/library.properties#L1
name=Mosiwi_Basic_Learning_Kit

As explained here, we do not accept any releases under a different name because this is the unique identifier for the library:
https://github.com/arduino/library-registry/blob/main/FAQ.md#update-requirements

Hello, it has been changed to the correct name, thank you for your help.


Claiming the UFW lesson

I've had experience writing UFW before, so I can "claim" this page to let everyone know it's being worked on, and draft a quick write-up on it.
I'm planning on three rough sections right now -- where to get it, how to use it, and maybe a few best practices how it might be used for servers.
If anyone has ideas on what I should focus on beyond that, LMK.

I was thinking that I can write up a quick overview on IP just so that UFW can make more sense.
I think having that as a separate lesson/page would help.
Thoughts?

That's a good idea! The draft I have right now (#24) currently focuses less on IP addresses, but rather restricting to whatever ports you want the internet to access (and ufw makes it even easier since you can say "SSH" or "WWW Full" over memorizing the numbers 22 or 80,443), so while it won't be a primary prerequisite to ufw, it makes a good supplement.
Hmm, maybe the article should explain what exactly ports are.

Related PR merged


⚠ Bofrost.de has degraded performance

In 6a21f1b, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1025 ms

Resolved: Bofrost.de performance has improved in 4cf8a41 after 1 hour, 19 minutes.


[Hub Generated] Review request for Microsoft.Cache to add version preview/2023-05-01-preview

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

What's the purpose of the update?

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

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

Contribution checklist (MS Employees Only):

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

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

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

Change to data plane APIs
Adding new properties
All removals

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

[x] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

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

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

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

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

/azp run unifiedPipeline

        }

202 status should not normally return a payload, schema should just be omitted.

Refers to: specification/redis/resource-manager/Microsoft.Cache/preview/2023-05-01-preview/redis.json:1817 in 4a3cacc. [](commit_id = 4a3cacc7988118145f00547f7fdf468631e6e9c9, deletion_comment = False)

        }

same, not needed

Refers to: specification/redis/resource-manager/Microsoft.Cache/preview/2023-05-01-preview/redis.json:2028 in 4a3cacc. [](commit_id = 4a3cacc7988118145f00547f7fdf468631e6e9c9, deletion_comment = False)

        }

is it also possible to disable non-aad-auth?

Refers to: specification/redis/resource-manager/Microsoft.Cache/preview/2023-05-01-preview/redis.json:2246 in 4a3cacc. [](commit_id = 4a3cacc7988118145f00547f7fdf468631e6e9c9, deletion_comment = False)

@koderjoker Please fix CI checks errors (LintDiff, Acocado), you can refer to this comment or https://aka.ms/ci-fix on how to fix it.

@v-xuto please ignore these errors, the avacado errors are irrelevant to this api version and the Lintdiff errors are due to an issue with the pipeline as quoted here https://github.com/Azure/azure-rest-api-specs/pull/23406#issuecomment-1496788714

@TimLovellSmith we got CI failures for not returning a payload so we had to add it. authnotrequired was in the previous swagger version as well so we should allow customers to do so without aad

@qiaozha Please help review JS breaking change.
@raych1  Please help review Go breaking change.

@live1206 Please help review azure-sdk-for-net-track2 error.

@live1206 Please help review azure-sdk-for-net-track2 error.

It failed due to breaking changes, but not introduced in this PR.

@live1206 The breaking changes, for addition of regex pattern validation, are approved. So what else needs to be done?

e got CI failures for not returning a payload so we had to add it. authnotrequired was in the previous swagger version as well so we should allow customers to do so without aad

Authnotrequired doesn't mean aad-auth only, it turns off authentication completely.

@koderjoker

we got CI failures for not returning a payload
Where?

@koderjoker

we got CI failures for not returning a payload
Where?

Sorry, misunderstood the previous statement as removing it from the specification only. Removed the body from delete 202 response now. Thanks for pointing this out @TimLovellSmith

@live1206 @raych1 could you please help us get the approved labels?

@raych1 Please help review Go breaking change.

@koderjoker  Please resolve the conflict.

@v-xuto resolved the conflict


Added region hierarchy and unique naming reference for RegionBlocks in SCFGs

As titled,
This PR makes the following major changes:

It adds a region hierarchy by the use of SCFG.parent_region and SCFG.regions
For any SCFG that we create independently, a 'meta-region' is generated automatically which can be used to refer to the graph as a whole.
During transformations like loop_restructuring and branch_restructuring every new region created has itself declared as the parent_region in the corresponding subregion SCFG.
loop_restructuring and branch_restructuring now take regions (RegionBlock) as arguments instead of graphs (SCFGs). To do the transformation on an entire graph, we can simply provide the meta-region of the graph instead.
RegionBlocks are now referred to using their own independent names. They are no longer referred using the header block's name. Hence RegionBlocks can now be treated as essentially independent blocks.
SCFGs now have a .view() method that renders a quick preview of the current state of the SCFG. (assuming it's valid)

Note that currently RegionBlocks share jump targets with their corresponding exiting blocks. Hence any updates made to jump targets of a RegionBlock, need to be made recursively to their corresponding exiting blocks as well.

@kc611, I discovered a bug:

reproducer:

from numba_rvsdg.core.datastructures.byte_flow import ByteFlow
from numba_rvsdg.rendering.rendering import ByteFlowRenderer

def sum1d(s, e):
    c = 0
    for i in range(s, e):
        c += i
    return c

byteflow = ByteFlow.from_bytecode(sum1d.__code__)
bcmap = byteflow.scfg.bcmap_from_bytecode(byteflow.bc)
byteflow = byteflow.restructure()

bfr = ByteFlowRenderer()
bfr.bcmap_from_bytecode(byteflow.bc)
byteflow.scfg.view("scfg")

@kc611, is https://github.com/numba/numba-rvsdg/pull/61/commits/53291b85a0c0ff44093880825b5d1190e412c783 fixing https://github.com/numba/numba-rvsdg/pull/61#issuecomment-1572791281? Let's make sure we have test for it as well.

As of https://github.com/sklam/numba/commit/2c84e4b47cf49add64924cabdc2740ca9954617e, the numba rvsdg-frontend branch is fully working with this PR.

I found a file with trailing whitespace:

Please double check all the files touched by this PR and remove any trailing whitespace, thank you.

I've currently fixed the trailing whitespaces from the entire project using pre-commit from the experimental branch locally.

@kc611 this is fine now thank you. As a last request, please include the following test:
from numba_rvsdg.rendering.rendering import render_func

def scc(G):
    preorder = {}
    lowlink = {}
    scc_found = set()
    scc_queue = []
    out = []
    i = 0  # Preorder counter
    for source in G:
        if source not in scc_found:
            queue = [source]
            while queue:
                v = queue[-1]
                if v not in preorder:
                    i = i + 1
                    preorder[v] = i
                done = True
                for w in G[v]:
                    if w not in preorder:
                        queue.append(w)
                        done = False
                        break
                if done:
                    lowlink[v] = preorder[v]
                    for w in G[v]:
                        if w not in scc_found:
                            if preorder[w] > preorder[v]:
                                lowlink[v] = min([lowlink[v], lowlink[w]])
                            else:
                                lowlink[v] = min([lowlink[v], preorder[w]])
                    queue.pop()
                    if lowlink[v] == preorder[v]:
                        scc = {v}
                        while scc_queue and preorder[scc_queue[-1]] > preorder[v]:
                            k = scc_queue.pop()
                            scc.add(k)
                        scc_found.update(scc)
                        out.append(scc)
                    else:
                        scc_queue.append(v)
    return out

render_func(scc)

And add it such that it behaves like the other test_fig tests. Just execution when run under pytest and rendering if run as a regular Python file.


ensure fake locker for fake rescue

I have no idea why the tests fail right now. This works locally. Moving on.


[2.1.1] Fix JsonHubProtocol error message when too many arguments (#2312)

Port #2312 to release/2.1
⚠⚠⚠ DO NOT MERGE ⚠⚠⚠
release/2.1 has not yet been opened for servicing fixes.
⚠⚠⚠ DO NOT MERGE ⚠⚠⚠

Declined for 2.1.1


An easier way to send customization parameters to stylesheets

See this thread for an use-case.
When making customizations to the DITA OT XSLT stylesheets some developers feel the need to take in the stylesheets different choices (or do use different values) depending on custom parameters which they set to the ANT process.
Unfortunately setting a new system property to the ANT process is not enough, they also need to modify the build files and pass that new parameter to the XSLT stylesheets. Then the XSLT stylesheets need to be modified in order to add a new xsl:param which will receive the value from the build process.
I think this approach could be simplified. For example in XSLT the method system-property(string) can be used to obtain the value of a system property. Unfortunately the <xslt> task does not seem to pass by default system properties from the ANT process to the stylesheets.
But the ANT <xslt> task seem to be able to receive a <syspropertyset> which could specify that all command line parameters could be passed as system properties to the transformer.
I have not tried this but the end result would mean that the user would pass an additional param to ANT and the param would be read in the stylesheets using system-property(string).
Maybe this would also mean that future parameters which are used for XSLT customization would not need to be specified in the ANT build files and defined as xsl:param in the stylesheets.

The approach Radu suggested would have the benefit of making it easy to use any number of Ant properties in DITA-OT stylesheets, without having to add a <param> element for each one as described in Passing parameters to existing XSLT steps.
For example, let's say I have a Java property file with an arbitrary number of parameters I want to pass to the stylesheets of my PDF plugin:
foo = bar
baz = quux
. . .

With the current implementation, to use foo and baz in my stylesheets, I would need to know the name of each property and add a corresponding <param> element for each of them in insertParameters.xml:
<dummy>
  <param name="foo" expression="${foo}" if="foo"/>
  <param name="baz" expression="${baz}" if="baz"/>
  . . .
</dummy>

It would be nice to avoid having to do that. However, setting system properties has the parallel-processing problem @jelovirt mentioned in #1859.
I guess the only solution I can think of is to make it possible to do something like <paramref prefix="foo"/> in insertParameters.xml, which would retrieve all Ant properties with the prefix fooand generate an XSLT parameter for each one — kinda like Ant's <propertyref>. Haven't looked into how big of an effort that'd be, yet, though.


Add replayer for capture files

This PR adds a command line utility that you can point at a PCAP file in order to easily debug messages that were captured during a Zwift session.
Should save a lot of sweat trying to analyse or reproduce issues ;-)

Was you intention to abandon this PR? It seems like you re-worked some of these changes into #29

Yeah I think it’s better to close this one. Sorry I didn’t think about that sooner!


Seperate Volley and Retrofit Library

Volley version is at https://github.com/seventhmoon/ipapi-volley


Fix Japanese handling

This changes the Japanese tokenizer to use versions of mecab-python3 1.0
or greater. This means the package will work on Windows.
However, since the Japanese tokenizer pulls in heavy dependencies and
isn't necessary unless you're dealing with Japanese, I moved it to
optional dependencies. You can install sacrebleu with Japanese support
like below:
pip install sacrebleu[ja]

That will install mecab-python3 and ipadic.
This also includes basic tests to check that the tokenization is as
exepcted for IPAdic.
You may need to make changes to your automated testing setup to install the Japanese dependencies.

I made the necessary changes to Travis and it looks like the tests are passing now.

So pip install sacrebleu[ja] does a full install with mecab, right?

That's correct.

Thanks for the PR. I will test this tomorrow a bit further and then @mjpost could do a release to fix Windows installation issue.

@polm why does tagger.version() still returns 0.996? Shouldn't this reflect MeCab' version?

That's the version of the underlying C++ library, which is not the same as the version number used for mecab-python3, the Python wrapper.


Implementation of ranking evaluations

The ranking evaluations include MAP, NDCG@k, P@K, MRR, and so on.

just copy -> paste this piece of code :)


Pass extra terser options through the angular.json

🚀 Feature request
Command (mark with an x)

- [ ] new
- [x] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Description
Right now I can't just add these extra terser options to a custom webpack config and expect it to work because the "bundleOptimizer: true" option would just overwrite the whole thing. (Given the nature of the config I'm not expecting that this would be possible anytime, hence this proposal:) If I'd to disable that, I'd need to re-implement the whole thing just to change one option. And when I do it naively with a simple setup it straight up fails. (Probably because ng8 now builds both legacy and modern bundles and would require different setups, as I've seen that in this repo where the default config is assembled. But I have no way differentiating that in a custom config file.)
Describe the solution you'd like
Add a terserOptions config option -- which accepts an object -- into the project's angular.json config (under architect.build.configurations.production). And merge it into the default terserOptions object if exists. (This one here: https://github.com/angular/angular-cli/blob/74f2ee68d6d166903d5ef571d8a793bd4994e142/packages/angular_devkit/build_angular/src/angular-cli-files/models/webpack-configs/common.ts#L284)
Use-case
I'd like to have the terser option "keep_classnames" turned on (set to a set of classes which are to be persisted) because of a serialization/deserialization mechanic that resolves the class that belongs to a JSON (stored in a database) by the name of the class. If the name of the class is minified,  these persistent, serialized objects would not be cross-compatible between dev and prod builds. Also there's no guarantee that between different prod versions these minified class names wouldn't change over time.

Duplicate of #3861 and #11910


BZ 64260: Clean up install target

Remove bin/, include/, lib/pkgconfig/ from install target since they serve no
purpose for the outside world and rather might confuse people. libtcnative is
solely intended to be loaded dynamically from within the JVM and not be used
as a library for other C clients.
The archive cannot be easily removed w/o restructuring configure.ac and
Makefile.in. The conceptual flaw is to rely on libtool generated for APR,
rather than generating a libtool in-place with *_DISABLE_STATIC/*_PROG_LIBTOOL
through autoreconf. A proper approach is taken by Subversion's build/ac-macros/apr.mk.
Works flawlessly in-tree and out-of-tree build on FreeBSD, will test on HP-UX and RHEL 7.

Works flawlessly on RHEL 7 and HP-UX 11.31.

I will test this soon on Linux ARM64!

I will test this soon on Linux ARM64!

Looking forward too.

Everything works fine on my Ubuntu 18.04.4 ARM64!
The changes also look good to me but I am not an expert in this area.

@martin-g Thanks. I will wait a couple of days for the other to look over eventually and will merge in April.


Monitoring outgoing transactions // importing key images

Would it fit mnp's scope to have it detect outgoing transactions and handle the corresponding key images?
The idea is to have a firewalled hot wallet monitor spends. When one occurs, it should transfer the corresponding key images to a watch-only wallet on the Internet, which in turn should import them - effectively allowing the exposed wallet to have up-to-date wallet data while protecting against theft.
mnp came to mind for this while designing a way to maximize usability by simplifying the tools end-users are required to employ (think "swiping a card").
There's more detail in this thread:
Offline Signing Library for XmrSigner Production
(The hot wallet in question would talk to the "public key device" depicted in the sequence diagram.)

mnp was developed to monitor incoming transactions, with the idea of utilizing the potential of a Unix environment to simplify this task. The typical application would be to automate things using a shell script. For example, auto send an e-mail when receiving a Monero payment. I haven't thought about monitoring outgoing transactions yet - just to keep it simple.
I will have a think about the problem, but it doesn't seem so trivial to me.


There is no release

Would be really nice to have a UnityPackage installer for this to easily add this to a project.

Yeah I'm a big fan of the packages. This is a good suggestion, but I'm now recommending that people use Odin Inspector instead. Hopefully that's an option for you. It's well worth the money.
I'm gonna leave this open, as it's still relevant. But it's unlikely we will do anything on this ourselves.


Customize jiti options

Is your feature request related to a problem? Please describe.
My Nuxt server middleware relies on custom babel options. With Nuxt 2.15 and jiti my setup is broken.
I would like to be able to pass custom jiti options object (such as { transformOptions: ... }) to fix that, however, currently Nuxt doesn't allow that. jiti is unilaterally called without any options whatsoever:
https://github.com/nuxt/nuxt.js/blob/2ec62617ced873fef97c73a6d7aa1271911ccfd5/packages/utils/src/cjs.js#L5-L7
Describe the solution you'd like
I would like a new section in nuxt.config.js, either top-level jiti or build.jiti, with jiti options. This is similar to build.babel for that matter.
Example:
const config: NuxtConfig = {
  build: {
    jiti: {
      transformOptions: {
        babel: {
          babelrc: true,
        },
      },
    },
  },
}

Describe alternatives you've considered
I'm going with this at the moment:
const config: NuxtConfig = {
  createRequire: p => {
    return jiti(typeof p === 'string' ? p : p.filename, {
      transformOptions: { ... }
    }
  }
}

This is:
a) undocumented
b) needs boilerplate copy/paste and unneeded knowledge about p.filename
c) possibly unreliable and/or will need more boilerplate for production build

Jiti is internally used in several places is also for loading nuxt.config itself. Supporting jiti customization in config can lead to caching issues and other problems since babel is only internally used and might be replaced in future versions with esbuild or swc transpilers. So I'm afraid we can never support this option. And specific use cases can be handled by replacing createRequire implementation.
The latest jiti release should cover declaration field support (https://github.com/unjs/jiti/issues/33) but feel free to open more feature requests in jiti repo if anything else missing.

Jiti is internally used in several globay places is also for loading nuxt.config itself.

Yes, and that's a pity, honestly. (I remember old times when I was able to simply run NODE_OPTIONS='-r whatever-loader/register' and Nuxt wasn't breaking this with its own runtime magic.)
Anyhow, as you've mentioned it, having optional jiti.config.js with global options (applied for loading nuxt.config.ts in particular) would be great then.

babel is only internally used and might be replaced in future versions with esbuild or swc transpilers

Yes, I realise that, that is why I suggest to pass the entire jiti options and not only jiti babel options.

However, jiti is designed to be an opinioned solution that works out of the box (similar to prettier), supporting jiti.config makes sense :) Made https://github.com/unjs/jiti/issues/34 track.


problem with adding typescript to project

Version
5.0.4
Environment info
System:
    OS: macOS 12.1
    CPU: (8) x64 Apple M1 Pro
  Binaries:
    Node: 14.18.2 - ~/.nvm/versions/node/v14.18.2/bin/node
    Yarn: Not Found
    npm: 8.12.0 - ~/.nvm/versions/node/v14.18.2/bin/npm
  Browsers:
    Chrome: 102.0.5005.61
    Edge: Not Found
    Firefox: Not Found
    Safari: 15.2
  npmPackages:
    @element-plus/icons-vue:  1.1.4
    @vue/babel-helper-vue-jsx-merge-props:  1.2.1
    @vue/babel-helper-vue-transform-on:  1.0.2
    @vue/babel-plugin-jsx:  1.1.1
    @vue/babel-plugin-transform-vue-jsx:  1.2.1
    @vue/babel-preset-app:  4.5.17
    @vue/babel-preset-jsx:  1.2.4
    @vue/babel-sugar-composition-api-inject-h:  1.2.1
    @vue/babel-sugar-composition-api-render-instance:  1.2.4
    @vue/babel-sugar-functional-vue:  1.2.2
    @vue/babel-sugar-inject-h:  1.2.2
    @vue/babel-sugar-v-model:  1.2.3
    @vue/babel-sugar-v-on:  1.2.3
    @vue/cli-overlay:  4.5.17
    @vue/cli-plugin-babel: ~4.5.0 => 4.5.17
    @vue/cli-plugin-eslint: ~4.5.0 => 4.5.17
    @vue/cli-plugin-router: ~4.5.0 => 4.5.17
    @vue/cli-plugin-typescript: ~5.0.0 => 5.0.4
    @vue/cli-plugin-unit-jest: ~4.5.0 => 4.5.17
    @vue/cli-plugin-vuex: ~4.5.0 => 4.5.17
    @vue/cli-service: ~4.5.0 => 4.5.17
    @vue/cli-shared-utils:  4.5.17 (5.0.4)
    @vue/compiler-core:  3.2.36
    @vue/compiler-dom:  3.2.36
    @vue/compiler-sfc: ^3.0.0 => 3.2.36
    @vue/compiler-ssr:  3.2.36
    @vue/component-compiler-utils:  3.3.0
    @vue/devtools-api:  6.1.4
    @vue/eslint-config-standard: ^5.1.2 => 5.1.2
    @vue/preload-webpack-plugin:  1.1.2
    @vue/reactivity:  3.2.36
    @vue/reactivity-transform:  3.2.36
    @vue/runtime-core:  3.2.36
    @vue/runtime-dom:  3.2.36
    @vue/server-renderer:  3.2.36
    @vue/shared:  3.2.36
    @vue/test-utils: ^2.0.0-0 => 2.0.0
    @vue/web-component-wrapper:  1.3.0
    eslint-plugin-vue: ^7.0.0 => 7.20.0
    jest-serializer-vue:  2.0.2
    vue: ^3.2.36 => 3.2.36 (2.6.14)
    vue-demi:  undefined (0.13.1)
    vue-eslint-parser:  7.11.0
    vue-gtag: ^2.0.1 => 2.0.1
    vue-gtag-next: ^1.14.0 => 1.14.0
    vue-hot-reload-api:  2.3.4
    vue-jest: ^5.0.0-0 => 5.0.0-alpha.10 (3.0.7)
    vue-loader:  15.9.8 (16.8.3)
    vue-meta-info: ^0.1.7 => 0.1.7
    vue-router: ^4.0.0-0 => 4.0.15 (2.8.1)
    vue-style-loader:  4.1.3
    vue-template-es2015-compiler:  1.9.1
    vue-the-mask: ^0.11.1 => 0.11.1
    vue3-json-viewer: ^2.2.2 => 2.2.2
    vuex: ^4.0.0-0 => 4.0.2
  npmGlobalPackages:
    @vue/cli: 5.0.4

Steps to reproduce
vue add typescript
 WARN  There are uncommitted changes in the current repository, it's recommended to commit or stash them first.
? Still proceed? Yes

📦  Installing @vue/cli-plugin-typescript...

up to date, audited 2807 packages in 5s

130 packages are looking for funding
  run `npm fund` for details

56 vulnerabilities (1 low, 11 moderate, 31 high, 13 critical)

To address issues that do not require attention, run:
  npm audit fix

To address all issues possible (including breaking changes), run:
  npm audit fix --force

Some issues need review, and may require choosing
a different dependency.

Run `npm audit` for details.
✔  Successfully installed plugin: @vue/cli-plugin-typescript

? Use class-style component syntax? Yes
? Use Babel alongside TypeScript (required for modern mode, auto-detected polyfills, transpiling JSX)? Yes
? Convert all .js files to .ts? No
? Allow .js files to be compiled? No
? Skip type checking of all declaration files (recommended for apps)? Yes

What is expected?
Typescript will be added to the project
What is actually happening?
🚀  Invoking generator for @vue/cli-plugin-typescript...
ERROR  Error: Cannot find module<EMAIL_ADDRESS>from '/Users/anatoly/Documents/work/ndfl_all/node_modules/@vue/cli-plugin-typescript/generator/template/src/views'
Error: Cannot find module<EMAIL_ADDRESS>from '/Users/anatoly/Documents/work/ndfl_all/node_modules/@vue/cli-plugin-typescript/generator/template/src/views'
at Function.resolveSync [as sync] (/Users/anatoly/.nvm/versions/node/v14.18.2/lib/node_modules/@vue/cli/node_modules/resolve/lib/sync.js:111:15)
at renderFile (/Users/anatoly/.nvm/versions/node/v14.18.2/lib/node_modules/@vue/cli/lib/GeneratorAPI.js:518:17)
at /Users/anatoly/.nvm/versions/node/v14.18.2/lib/node_modules/@vue/cli/lib/GeneratorAPI.js:303:27
at processTicksAndRejections (internal/process/task_queues.js:95:5)
at async Generator.resolveFiles (/Users/anatoly/.nvm/versions/node/v14.18.2/lib/node_modules/@vue/cli/lib/Generator.js:310:7)
at async Generator.generate (/Users/anatoly/.nvm/versions/node/v14.18.2/lib/node_modules/@vue/cli/lib/Generator.js:204:5)
at async runGenerator (/Users/anatoly/.nvm/versions/node/v14.18.2/lib/node_modules/@vue/cli/lib/invoke.js:111:3)
at async invoke (/Users/anatoly/.nvm/versions/node/v14.18.2/lib/node_modules/@vue/cli/lib/invoke.js:92:3)

Was there a fix for this? Getting the same issue.

At the moment I can't say for sure. But the solution was to fix the package versions

I got it, vue add automatically does the latest version, so it added v5, but the rest of my app was on v4 so it was incompatible. Had to vue add typescript@4


Adds Listener for AccountService

This will allow a means to update the interested parties for any new/changed accounts.
Test: clean build

Codecov Report

Merging #722 into master will increase coverage by 0.03%.
The diff coverage is 94.28%.

@@             Coverage Diff              @@
##             master     #722      +/-   ##
============================================
+ Coverage     65.78%   65.81%   +0.03%
- Complexity     3798     3803       +5
============================================
  Files           328      328
  Lines         25147    25177      +30
  Branches       3156     3158       +2
============================================
+ Hits          16542    16571      +29
  Misses         7721     7721
- Partials        884      885       +1

Impacted Files
Coverage Δ
Complexity Δ

...om/github/ambry/account/AccountServiceMetrics.java
100% <100%> (ø)
1 <0> (ø)
:arrow_down:

...b/ambry/account/InMemoryUnknownAccountService.java
92.3% <100%> (+2.83%)
11 <2> (+2)
:arrow_up:

.../com/github/ambry/account/HelixAccountService.java
89.15% <92.3%> (+0.19%)
31 <2> (+4)
:arrow_up:

....github.ambry.clustermap/StaticClusterManager.java
75.11% <0%> (-1.85%)
77% <0%> (-1%)

.../com.github.ambry.router/GetBlobInfoOperation.java
79.86% <0%> (-1.39%)
30% <0%> (-1%)

...ava/com.github.ambry.router/NonBlockingRouter.java
81.66% <0%> (-0.84%)
34% <0%> (ø)

...in/java/com.github.ambry.store/BlobStoreStats.java
85.13% <0%> (-0.24%)
93% <0%> (ø)

...ain/java/com.github.ambry.router/PutOperation.java
89.9% <0%> (-0.23%)
69% <0%> (-1%)

.../main/java/com.github.ambry.store/HardDeleter.java
80% <0%> (+0.32%)
41% <0%> (+1%)
:arrow_up:

...m.github.ambry.clustermap/HelixClusterManager.java
94.3% <0%> (+0.71%)
33% <0%> (+1%)
:arrow_up:

... and 2 more

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 d68f05d...0a57091. Read the comment docs.

@xiahome : can you fix the merge conflicts

@cgtz @nsivabalan Have made some changes according to yoru comments.

@cgtz @nsivabalan Have made some changes for your comments.

LGTM. Merging.


Integration Test - Release - 2022/06/28 10:34:50

Auto create for integration test. IssueCommandFlow

@prmerger-dev-3 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Version Extension

Related Issue(s): #615, #557, #635
Proposed Changes:

Removed version field from Collections
Added Version extension with two fields: version, deprecated

PR Checklist:

[ ] This PR has no breaking changes.
[x] I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.
[x] API only: I have run npm run generate-all to update the generated OpenAPI files.

@m-mohr I think the linking part belongs to best practices and should not be part of this conversation. This other PR does that.

@scisco I made some more changes to make clear that this extension does not propose a structure or behavior, but just defines a list of potential fields and relation types to be used. For behaviour and best practices I refer to your best practices document. Also, I changes the name to "Versioning Indicators" to make clear the fields only indicate a version number and the deprecation. Does this help to resolve your confusion, @scisco ?


Remove APIs that were deprecated and moved to AppUI repo

This PR removes previously deprecated APIs related to AppUI from @itwin/appui-abstract.

@mergifyio backport release/4.0.x