No anomalies detected

In the sample for phone calls anomaly detection we noticed that you won’t get any anomalies detected with version 5.5. Running the sample with version 5.3 works.
Not sure if this is an intended change in the library requiring an update of sample data or if this is due to a problem in the TimeSeries part?

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

ID: 5e6266e1-f8e5-d303-7ddc-be2d6e47f831
Version Independent ID: 2ae35df3-cf3a-ed1c-b466-a8be8a9729c3
Content: Tutorial: Detect anomalies in phone calls - ML.NET
Content Source: docs/machine-learning/tutorials/phone-calls-anomaly-detection.md
Product: dotnet-ml
GitHub Login: @luisquintanilla
Microsoft Alias: luquinta

Hi @robin-karlsson
Sorry to hear you ran into issues. Would you be able to share the output / error you're getting.
Thanks

Thanks for raising this issue @robin-karlsson. I was able to reproduce
1.5.2 Output
Detect period of the series
Period of the series is: 7.
Detect anomaly points in the series
Index   Anomaly ExpectedValue   UpperBoundary   LowerBoundary
0,0,36.841787256739266,41.14206982401966,32.541504689458876
1,0,35.67303618137362,39.97331874865401,31.372753614093227
2,0,34.710132999891826,39.029491313022824,30.390774686760828
3,0,33.44765248883495,37.786086547816545,29.10921842985335
4,0,28.937110922276364,33.25646923540736,24.61775260914537
5,0,5.143895892785781,9.444178460066171,0.843613325505391
6,0,5.163325228419392,9.463607795699783,0.8630426611390014
7,0,36.76414836240396,41.06443092968435,32.46386579512357
8,0,35.77908590657007,40.07936847385046,31.478803339289676
9,0,34.547259536635245,38.847542103915636,30.246976969354854
10,0,33.55193524820608,37.871293561337076,29.23257693507508
11,0,29.091800129624648,33.392082696905035,24.79151756234426
12,0,5.154836630338823,9.455119197619213,0.8545540630584334
13,0,5.234332502492464,9.534615069772855,0.934049935212073
14,0,36.54992549471526,40.85020806199565,32.24964292743487
15,0,35.79526470980883,40.095547277089224,31.494982142528443
16,0,34.34099013096804,38.64127269824843,30.040707563687647
17,0,33.61201516582131,37.9122977331017,29.31173259854092
18,0,29.223563320561812,33.5238458878422,24.923280753281425
19,0,5.170512168851533,9.470794736131923,0.8702296015711433
20,0,5.2614938889462834,9.561776456226674,0.9612113216658926
21,0,36.37103858487317,40.67132115215356,32.07075601759278
22,0,35.813544599026855,40.113827166307246,31.513262031746464
23,0,34.05600492733225,38.356287494612644,29.755722360051863
24,0,33.65828319077884,37.95856575805923,29.358000623498448
25,0,29.381125690882463,33.681408258162854,25.080843123602072
26,0,5.261543539820418,9.561826107100808,0.9612609725400283
27,0,5.4873712582971805,9.787653825577571,1.1870886910167897
28,1,36.504694001629254,40.804976568909645,32.20441143434886  <-- alert is on, detected anomaly
29,0,36.056960964529836,40.35724353181023,31.756678397249445
30,0,33.88234878237759,38.18263134965798,29.5820662150972
31,0,33.92784857369604,38.085121010124574,29.770576137267504
32,0,29.945506014510265,34.1027784509388,25.78823357808173
33,0,5.878525831440632,10.035798267869167,1.7212533950120967
34,0,6.252886214212062,10.410158650640597,2.0956137777835266
35,0,37.18404534222705,41.32872980034376,33.039360884110344
36,0,36.83107452935755,40.97575898747426,32.686390071240844
37,0,34.26556446342024,38.41024892153695,30.120880005303533
38,0,34.71284744107857,38.85753189919528,30.568162982961866
39,0,30.6318593911151,34.789131827543635,26.474586954686565
40,0,5.8421334626776575,9.999405899106193,1.6848610262491217
41,0,5.315133091466097,9.472405527894633,1.1578606550375614
42,0,34.87155077154678,39.019122600615404,30.723978942478155
43,0,35.56278990178399,39.707474359900694,31.41810544366728
44,1,33.06370143379212,37.208385891908826,28.91901697567541  <-- alert is on, detected anomaly
45,0,32.49251041707055,36.637194875187255,28.34782595895384
46,0,29.042343064117933,33.18702752223464,24.89765860600123
47,0,4.699873324239948,8.844557782356654,0.5551888661232418
48,0,5.25774359828668,9.402428056403387,1.1130591401699732
49,0,34.70382982079732,38.844173613357356,30.56348602823728
50,0,36.205476696654856,40.345820489214894,32.06513290409482
51,0,35.01806767666058,39.15841146922062,30.87772388410054
52,0,33.8621356196155,38.00247941217554,29.721791827055462
53,0,30.050263511910696,34.1949479700274,25.905579053793993
54,0,5.38360786974173,9.528292327858436,1.2389234116250236
55,0,5.319212934297795,9.463897392414502,1.174528476181088
56,1,34.35814874418968,38.43248334636359,30.283814142015764  <-- alert is on, detected anomaly
57,0,34.80435115782249,38.8786857599964,30.730016555648575
58,0,32.64542281055228,36.79010726866899,28.500738352435576
59,0,30.388031426358786,34.535603255427404,26.240459597290165
60,0,28.372553851863646,32.65208360455492,24.093024099172375
61,0,4.054080143996516,8.333609896687783,-0.22544960869475084
62,0,4.708195658058664,8.987725410749931,0.42866590536739757
63,0,34.596454086638985,38.74402591570761,30.44888225757036
64,0,35.324588715619726,39.47216054468835,31.1770168865511
65,0,33.738156132843564,37.849109348464836,29.62720291722229
66,0,33.210967276887935,37.28530187906185,29.136632674714022
67,0,29.552710321333503,33.62704492350742,25.478375719159587
68,0,4.799342685155514,8.873677287329429,0.7250080829815992
69,0,5.244467834526498,9.421400011959088,1.0675356570939076
70,1,35.22957940044675,39.50910915313802,30.950049647755485  <-- alert is on, detected anomaly
71,0,35.72010274618195,39.89703492361454,31.54317056874936
72,0,34.31525818437954,38.38959278655345,30.240923582205625
73,0,33.46142030440133,37.63835248183392,29.28448812696874
74,0,29.799690914683158,34.07922066737443,25.520161161991886
75,0,4.762673307392623,9.061342947775344,0.4640036670099015
76,0,5.041497330134712,9.359306858208885,0.7236878020605388
77,0,35.1453728688598,39.47845435705336,30.812291380666245

1.5.5 Output
Detect period of the series
Period of the series is: 7.
Detect anomaly points in the series
Index   Anomaly ExpectedValue   UpperBoundary   LowerBoundary
0,0,36.841787256739266,57.91634186966726,15.767232643811276
1,0,35.67303618137362,56.74759079430161,14.598481568445628
2,0,34.710132999891826,55.87815572801981,13.542110271763839
3,0,33.44765248883495,54.70914333216294,12.186161645506957
4,0,28.937110922276364,50.105133650404355,7.769088194148374
5,0,5.143895892785781,26.218450505713772,-15.930658720142208
6,0,5.163325228419392,26.237879841347382,-15.911229384508598
7,0,36.76414836240396,57.83870297533195,15.689593749475968
8,0,35.77908590657007,56.85364051949806,14.704531293642077
9,0,34.547259536635245,55.621814149563235,13.472704923707255
10,0,33.55193524820608,54.719957976334065,12.383912520078091
11,0,29.091800129624648,50.16635474255264,8.017245516696654
12,0,5.154836630338823,26.229391243266814,-15.919717982589166
13,0,5.234332502492464,26.308887115420454,-15.840222110435526
14,0,36.54992549471526,57.62448010764325,15.47537088178727
15,0,35.79526470980883,56.869819322736824,14.720710096880843
16,0,34.34099013096804,55.41554474389603,13.266435518040048
17,0,33.61201516582131,54.6865697787493,12.537460552893322
18,0,29.223563320561812,50.298117933489806,8.149008707633818
19,0,5.170512168851533,26.245066781779524,-15.904042444076456
20,0,5.2614938889462834,26.336048501874274,-15.813060723981707
21,0,36.37103858487317,57.44559319780116,15.296483971945179
22,0,35.813544599026855,56.888099211954845,14.738989986098865
23,0,34.05600492733225,55.13055954026024,12.981450314404263
24,0,33.65828319077884,54.73283780370683,12.583728577850849
25,0,29.381125690882463,50.45568030381045,8.306571077954473
26,0,5.261543539820418,26.33609815274841,-15.813011073107571
27,0,5.4873712582971805,26.56192587122517,-15.58718335463081
28,0,32.780765740881456,53.85532035380945,11.706211127953466
29,0,36.056960964529836,57.131515577457826,14.982406351601846
30,0,33.88234878237759,54.95690339530558,12.8077941694496
31,0,33.92784857369604,54.301676332224034,13.554020815168045
32,0,29.945506014510265,50.31933377303825,9.571678255982278
33,0,5.878525831440632,26.25235358996862,-14.495301927087356
34,0,6.252886214212062,26.626713972740053,-14.12094154431593
35,0,37.18404534222705,57.49619401275504,16.871896671699062
36,0,36.83107452935755,57.14322319988554,16.51892585882956
37,0,34.376155062464,54.68830373299199,14.064006391936012
38,0,34.71284744107857,55.02499611160656,14.400698770550584
39,0,30.6318593911151,51.005687149643094,10.258031632587105
40,0,5.8421334626776575,26.21596122120565,-14.531694295850333
41,0,5.315133091466097,25.68896084999409,-15.058694667061893
42,0,34.87155077154678,55.197847099674775,14.545254443418784
43,0,35.56278990178399,55.874938572311976,15.250641231255997
44,0,23.336790657536003,43.64893932806399,3.024641987008014
45,0,32.49251041707055,52.80465908759854,12.180361746542559
46,0,29.042343064117933,49.35449173464592,8.730194393589947
47,0,4.699873324239948,25.012021994767938,-15.61227534628804
48,0,5.25774359828668,25.56989226881467,-15.054405072241309
49,0,34.814013762209456,55.10489386313744,14.52313366128147
50,0,36.205476696654856,56.49635679758285,15.914596595726863
51,0,35.01806767666058,55.30894777758857,14.727187575732586
52,0,33.8621356196155,54.15301572054349,13.571255518687508
53,0,30.050263511910696,50.36241218243869,9.738114841382703
54,0,5.38360786974173,25.69575654026972,-14.928540800786259
55,0,5.319212934297795,25.631361604825784,-14.992935736230194
56,0,27.980095314481456,47.94754090020945,8.01264972875347
57,0,34.80435115782249,54.77179674355048,14.836905572094494
58,0,32.710506482464,53.02265515299199,12.398357811936009
59,0,30.127693840554183,50.453990168682175,9.801397512426192
60,0,28.372553851863646,49.34542297999164,7.399684723735653
61,0,4.054080143996516,25.026949272124504,-16.918788984131474
62,0,4.708195658058664,25.681064786186653,-16.264673470069326
63,0,34.596454086638985,54.92275041476698,14.27015775851099
64,0,35.324588715619726,55.65088504374772,14.99829238749173
65,0,33.738156132843564,53.885027089771555,13.591285175915573
66,0,33.210967276887935,53.17841286261593,13.243521691159941
67,0,29.552710321333503,49.52015590706149,9.585264735605513
68,0,4.5436067444814565,24.511052330209452,-15.423838841246537
69,0,5.244467834526498,25.714625191454488,-15.225689522401494
70,0,43.785900220354904,64.7587693484829,22.813031092226915
71,0,35.72010274618195,56.19026010310994,15.24994538925396
72,0,34.31525818437954,54.28270377010753,14.347812598651544
73,0,33.46142030440133,53.93157766132932,12.991262947473338
74,0,29.799690914683158,50.77256004281115,8.826821786555165
75,0,4.762673307392623,25.82932483552061,-16.30397822073536
76,0,5.041497330134712,26.201931258262704,-16.118936597993283
77,0,35.1453728688598,56.380636968187794,13.91010876953181

@guinao @michaelgsharp thoughts?

Hi @robin-karlsson
Sorry to hear you ran into issues. Would you be able to share the output / error you're getting.
Thanks

I saw that you managed to reproduce now. Please give me a ping if you need me for something else. I can confirm that my output looked very similar to yours.
Thanks

Hi @robin-karlsson apologies for the delay on this.
I just tried the latest version 1.6.0 to see if it works and the issue persist. This does not seem to be a documentation issue as you can get it working with version 1.5.2.
I've raised an issue on the dotnet/machinelearning repo to track this. In the meantime, I'll update the document to specify you need to use version 1.5.2 and close the issue. To track the progress of this, please see dotnet/machinelearning#5891
Thanks again for bringing this to our attention.


chore(deps): upgrade @percy/storybook to v4

Related Ticket(s)
No related issue
Description
This is a test to see how percy diffs look when upgrading to @percy/storybook v4.
Changelog
Changed

Upgraded @percy/storybook to v4

Closing this PR for now, reached out to the Browserstack Percy team the findings. Noted that enable javascript was turned on in the percy config file, and that there are a number of missing snapshots in both Web Components and React.

Hey @jeffchew! After some some digging the skipped stories are because of the Percy story config. For example:
https://github.com/carbon-design-system/carbon-for-ibm-dotcom/blob/d1f36c5328c599695456cacd1535791b9f4bb45a/packages/react/src/components/TabsExtended/__stories__/TabsExtended.stories.js#L16 or https://github.com/carbon-design-system/carbon-for-ibm-dotcom/blob/08eea4f1d7d36dbcc07739544f3acac2c7248cc5/packages/react/src/components/FeatureSection/stories/FeatureSection.stories.js#L17


Different n_gal for lenses and sources

At some point it would nice to implement a way of inputing different n_gal for the lens sample and the source sample, as the two will likely be different for the data analysis. Just writing this here to not forget it

Done! I already merged the changes to the masked_cov branch


Argentina route shields

Argentina’s national and provincial routes should be marked with shields that reflect the standard designs on directional signs. National routes are marked by a black-on-white pentagonal shield, while provincial routes are marked by a black-on-white rectangular shield.[^class] These designs are specified by the Manual de Señalamiento Vertical (2007). These simple shapes appear on both directional signs and as reassurance markers affixed to distance signs:

National routes also have a more elaborate shield for standalone reassurance markers, featuring the province’s name, “RA”, and the national flag. In some places, an oversized variant of this shield is even posted for tourists to take selfies with. Nonetheless, the simpler shapes are all that’s needed on a map, as this signposted map demonstrates.

All provincial route shields look alike and lack any indication of the province, but route numbers are only unique within a given province.
[^class]: There is a parallel system of classifying roads as trunk, secondary, and tertiary that is not reflected on signage, as far as I can tell; however, trunk roads carry national routes, and secondary roads carry provincial routes.

In 2016, Argentine mappers standardized on network=AR:national for national routes, network=AR:provincial for provincial routes, and network=AR:national:secondary for secondary provincial routes. (I haven’t seen any evidence that secondary provincial routes are signposted; they actually seem to be road inventory numbers rather than route numbers.)
In January 2021, one user switched quite a few provincial and provincial secondary routes over to a hierarchical format: AR:X or AR:X:secondary, where X is the province’s ISO 3166-2 code. This reflects the fact that provinces do not coordinate route numbering with each other, but there’s no documentation about this practice, other than a 2016 suggestion on the forum that was rejected in favor of the basic format. Unless the community affirms its acceptance of the hierarchical format, we should only support the one that’s documented on the wiki and somewhat more prevalent.
Unfortunately, virtually all ref tags on national and provincial route relations are prefixed with “RN” or “RP”, which is how the routes are identified on kilometer posts but not on shields. These prefixes are redundant on relation refs because network already distinguishes between national and provincial routes. Consistent with how the ref key has been documented for many years, this project intentionally doesn’t perform postprocessing on relation ref tags. In order for shields to look correct, the “RN” and “RP” prefixes will need to be removed from the relations’ ref tags while keeping them on the ways’ ref tags. For example, on autopistas, “RNA” would become “A”.


FR: Add support for React Native Web?

Hi, have you considered adding support for the Web as an additional platform? What work needs to be done to add an additional platform to ignite?
The most popular library that provide Web support for React Native code is:
https://github.com/necolas/react-native-web
Here is an example application that targets both Web, iOS and Android with the same code:
https://github.com/grigio/HAgnostic-News

Would love to explore with this.  Please report any findings if you research before me.

I'd love to see something like this come through.  It's probably a better fit as a plugin or generators.
It blows my mind how compatible react-native and react-native-web are.

https://github.com/zzz945/react-native-web-boilerplate
I added web support to Ignite app, sharing redux saga and other logic code.

@zzz945 That looks sweet!


Do we need store for all api

In this repo we are adding store for all API but do we need to add that. The data is not reused you can directly call the api and it should work. why add a store layer

Store is a kinda opinionated mental model. And not a bad one. It allows to separate concerns of actions (or updaters in this case, as you use Component Store), effects (which aren't just server events but also modal windows, error catching, logging, and other side stuff), and observable selectors, which can be reused widely (with memoization, that's important) instead of creating new subjects (or anything similar) in each API consuming component.
So if you like such approach (I mean, you started to use it from the beginning, hadn't you) it's great to stick with this solid, well-documented and well-tested solution.
But it's definitely up to you (and/or other maintainers).

Yeah but as I'm using it I think I use the API one time. Te store is used for nothing. We need store if we are reusing data in some way but I'm fetching data once showing it once. So, I'm starting to feel I need not store it in anyway. Component store is a service with a subject. I would not have even used service with a subject for all this

Well that makes sense. Anyway, if you don't see any use of the stores in future and you feel much more comfortable without them, why not get rid of it. It's always the matter of personal preference. I personally agree with an opinion of a great guy Armen Vardanyan who says something like "if an application is large enough for Angular, it's large enough for NgRx" 😄
In this case it's not the question of size but rather a tool choice though.


Document Translation (No generated SRT file)

Hey there, when translating documentations and creating videobooks, I would love it we could include the actual documentation in there translated or having the option to have the original on one side and the translated one on the other side.
But my real issue is when I create audiobook, I would definitely need an SRT file, that would be generated when translating audio.
I know it's almost impossible because you have to define the amount of characters and since it's splitted in segmentations (let's pretend I've set the maximum characters to 200) it will be hard to generate a SRT file if the segments are not exactly as the actual documentation. But there has to be some ways to achieve this. This would be a game changer for my work! We work in IT Accessibility.
Thanks!

Hello,
That’s a good idea. While it can be challenging due to the need for precise segmentation and character limits, there are ways to make it work. I’ll keep this in mind, and feel free to submit pull requests if you have any contributions.

Honnestly, I have to say, you impress me so much. The amount of details you put into this is astonishing. Feel free to contact me for anything. I am pretty good with RVC, music production and IT technical background. If you feel like any of these compentencies may help you, please don't hesitate to contact me.
Here's my personnal email<EMAIL_ADDRESS>


Matrix32 scale methods use Vector2 instead of Size2

Matrix32 scale related methods use Vector2, for example:
Vector2 get_scale() const;

However most of the work involving scaling works with the Size2 type (i.g. Matrix32::set_rotation_and_scale, Node2d's stuff etc.)
This is not a big deal given Scale2 is just a typedef of Vector2. However it would be more consistent to fix this ;-)

fixed by aa5ade8


SPARKTA-100 CubeMakeSpec bug solved

Description
SPARKTA-100 CubeMakeSpec bug solved (#748). Code formatted. Dependencies sorted and revised to fix clean build issues. StreamingContextIT build solved.
Reviewer
@gserranojc
Test
Removed unused test, all green including AT
Coverage
Statement Coverage	57.52%
Branch Coverage	43.34%
Scalastyle
No info

Nice!!
java.sql.Timestamp!! jeje
+1 LGTM

We will merge the changes in another PR to master


Feature Request - Add playlist number to metadata

I've been using youtube-dl to download audio playlists. Instead of having to go through and manually add all the track numbers, it would be nice if youtube-dl could automatically add them to the file metadata.
(Not sure if this is the correct place to make a feature request, I'm not sure where else to put it.)

make a bash script, grep/find the data you want from the manifest, pipe it to key  "--add-metadata"

Post an example url and explain what command you are using and what do you want it to do.

Here's a URL of a YouTube playlist: https://www.youtube.com/watch?v=cgNXw8Qh67k&list=PLYwGqFKNm0YOgUAf9D-XpRAyDPripaXiB
What I would like is for the first track to have the number 1 set as it's track number with the --add-metadata option, 2 for the second track, 3 for the third, you get the idea.
So when I import them into iTunes or some other media player I won't have to manually add the track number to each one.

I came here for a similar feature request. I'm downloading entire video playlists and I would like to have the option to have the number of the video appended to the beginning of the file name. So I can have them sorted by the sequence in the playlist.
For example:
youtube-dl https://www.youtube.com/playlist?list=PL8dPuuaLjXtMczXZUmjb3mZSU1Roxnrey
Gets files like this:
The Big Bang - Crash Course Big History #1-tq6be-CZJ3w.mp4
What I have in mind:
youtube-dl --append-playlist-number https://www.youtube.com/playlist?list=PL8dPuuaLjXtMczXZUmjb3mZSU1Roxnrey
To save files like this:
001 - The Big Bang - Crash Course Big History #1-tq6be-CZJ3w.mp4

@mohsend your request is unrelated and already implemented: output template, playlist_index.

As @dsftw says, you can use playlist_index. Should this be closed?

@mohsend's question is different from @M-W99's.

Sorry, didn't notice that. But what @M-W99 is asking for is still possible, if a extractor return a value for track_number it will be added as metadata to the file if using --add-metadata. But I guess that isn't possible with YouTube, even with the -x option.

Whaat @M-W99 is not talking about is not track_number but the index of individual videos/audios in a playlist.

My question is answered and the feature I wanted is already present. So closing would depend on @M-W99  's opinion.

As far as I can determine, the original issue remains unresolved and mohsend's question was a bit of a highjack: he wanted to add numbers to the filename, M-W99 and I wanted to add track numbers to the metadata for each file.

Opened pull request #14991 which I believe may support the OP request


Don't tag Submariner SG as cluster-owned

Setting the Submariner SG as cluster-owned results in multiple SGs being found for load-balancer services, which isn't supported. This was previously fixed in commit 54e25267a87e ("Remove the cluster owned tag from submariner sg") in the Submariner project.
See https://github.com/kubernetes/kubernetes/issues/73906 and https://bugzilla.redhat.com/show_bug.cgi?id=2139477
Signed-off-by: Stephen Kitt<EMAIL_ADDRESS>

It looks UT are failing.


deep merge traits or alternative

I have a model with an array attribute.  I was trying to make a set of traits that would allow me to mix and match the entries of the array, but because this line does a shallow merge, they instead overwrite each other.
What is the recommended way to handle this?  Or should this be a feature-request for deep-merging traits?

(For now I'll try an afterMake approach instead...)

mmm .. normally the traits override each other ( last one wins ) .. there may  be a way to do what you are trying to do .. in simpler way .. but not sure. need to see models and your factories .. ( an example ) .. also using ember-data-model-fragments might help too make this simpler to do.
not sure what your arrays look like though

  traits: {
    /* These overwrite each other rather than mix: */
    dxt1: {
      views: [
        {
          format: 'dxt1',
          width: 8,
          height: 8
        }
      ]
    },

    dxt5: {
      views: [
        {
          format: 'dxt5',
          width: 8,
          height: 8
        }
      ]
    },

    rgb: {
      views: [
        {
          format: 'rgb',
          width: 8,
          height: 8
        }
      ]
    },

    rgba: {
      views: [
        {
          format: 'rgba',
          width: 8,
          height: 8
        }
      ]
    },

    png: {
      views: [
        {
          format: 'png',
          width: 8,
          height: 8
        }
      ]
    }
  },

  /* ...so I did it this way: make('image', { makeViews: ['dxt1', 'png'] }) etc. */
  afterMake (image, attrs) {
    if (attrs.makeViews) {
      image.set('views', attrs.makeViews.map(format => ({ format, width: 8, height: 8 })))
    }
  }

if you used model fragments you could do this much much more elegant-o-lisiously.
you could set up views as a fragmentArray
set up the view types in the factory for view ( fragment )
and then you could add the view fragments much much simpler
  let views = buildList('view', 'png', 'dxt1').get();
  let image = make('image', {views});
 // done!

True, but in this case, image has views: DS.attr() - it's not a relationship.  Tho I guess that would still work in a similar fashion.
The afterMake way means I just need the one line of setup.

correct .. it is not a relationship .. but using fragments allows you to pretend at no cost to you.
It is way cleaner than what you are doing.  and though your setup might be less NOW .. if you write the setup as fragments the test setup will be LESS and  in the long run the tests will be more understandable .. up to you .. but you know my vote

let me know if you still have more questions @GufNZ .. or else can you close this one?


[web] When input is focused, hovering over it throws exceptions

I'm seeing this in Chrome 131 on MacOS Sequoia.
Stacktrace:
Uncaught DartError: Assertion failed: org-dartlang-sdk:///lib/_engine/engine/pointer_binding/event_position_helper.dart:80:10
targetElement == domElement
"The targeted input element must be the active input element"
    at Object.throw_ [as throw] (errors.dart:307:3)
    at Object.assertFailed (profile.dart:117:39)
    at Object._computeOffsetForInputs (profile.dart:117:39)
    at Object.computeEventOffsetToTarget (event_position_helper.dart:38:14)
    at [_convertEventsToPointerData] (pointer_binding.dart:1117:30)
    at pointer_binding.dart:1045:9
    at pointer_binding.dart:965:7
    at loggedHandler (pointer_binding.dart:558:9)
    at Object._callDartFunctionFast1 (js_allow_interop_patch.dart:224:27)
    at ret (js_allow_interop_patch.dart:84:15)

Code sample:
import 'package:flutter/material.dart';

void main() {
  runApp(MaterialApp(
    home: Scaffold(
      body: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        children: [
          Padding(
            padding: const EdgeInsets.all(24.0),
            child: TextField(),
          ),
        ],
      ),
    ),
  ));
}

Repro steps:

Click the text field to activate it.
Hover over the text field.
See errors thrown in the console.

This is happening because the target on the original event is different from the target on the coalesced events. Chrome bug filed: https://g-issues.chromium.org/issues/382473107


SIGSEGV on ZBarrier::mark_barrier_on_oop_slow_path

Please provide a brief summary of the bug
I have experienced this crash across 2 x microservices in the same cluster, randomly there is a crash with the reported error:
V  [libjvm.so+0xf32adb]  ZBarrier::mark_barrier_on_oop_slow_path(unsigned long)+0x8b
Please provide steps to reproduce where possible
Unable to reproduce manually, has occurred randomly over the past week 4 times across 2 services.
Expected Results
no crash and normal operation
Actual Results
java crashes, kubernetes liveness probe fails and pod restarts.
What Java Version are you using?
JRE version: OpenJDK Runtime Environment Temurin-17.0.3+7 (17.0.3+7) (build 17.0.3+7)
What is your operating system and platform?
Microservice pod running from base image "amd64/eclipse-temurin:17.0.3_7-jdk-alpine"
Running in a GKE Kubernetes 1.23 cluster
How did you install Java?
Used the amd64/eclipse-temurin:17.0.3_7-jdk-alpine image from docker hub
Did it work before?
we have used this version for 6+ months - first recorded instance we've noticed but cannot discount previous events occurring - we have only 30 days of logs

Did you test with the latest update version?
no

Did you test with other Java versions?
no

Relevant log output
Apr 14, 2023 @ 12:18:21.003	# Problematic frame:
Apr 14, 2023 @ 12:18:21.003	#  SIGSEGV (0xb) at pc=0x00007f6ef61b2adb, pid=7, tid=13
Apr 14, 2023 @ 12:18:21.003	# JRE version: OpenJDK Runtime Environment Temurin-17.0.3+7 (17.0.3+7) (build 17.0.3+7)
Apr 14, 2023 @ 12:18:21.003	#
Apr 14, 2023 @ 12:18:21.003	# A fatal error has been detected by the Java Runtime Environment:
Apr 14, 2023 @ 12:18:21.003	# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (17.0.3+7, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-amd64)
Apr 14, 2023 @ 12:18:21.007	# Core dump will be written. Default location: /core.%e.7.%t
Apr 14, 2023 @ 12:18:21.007	# //hs_err_pid7.log
Apr 14, 2023 @ 12:18:21.007	#
Apr 14, 2023 @ 12:18:21.007	# V  [libjvm.so+0xf32adb]  ZBarrier::mark_barrier_on_oop_slow_path(unsigned long)+0x8b
Apr 14, 2023 @ 12:18:21.007	# An error report file with more information is saved as:
Apr 14, 2023 @ 12:18:21.009	 metadata       [0x00007f6ee8d65b68,0x00007f6ee8d66138] = 1488
Apr 14, 2023 @ 12:18:21.009	 stub code      [0x00007f6ee8d65a00,0x00007f6ee8d65b08] = 264
Apr 14, 2023 @ 12:18:21.009	 scopes pcs     [0x00007f6ee8d69728,0x00007f6ee8d6da38] = 17168
Apr 14, 2023 @ 12:18:21.009	 dependencies   [0x00007f6ee8d6da38,0x00007f6ee8d6dc00] = 456
Apr 14, 2023 @ 12:18:21.009	 relocation     [0x00007f6ee8d5ef70,0x00007f6ee8d5f4a0] = 1328
Apr 14, 2023 @ 12:18:21.009	 total in heap  [0x00007f6ee8d5ee10,0x00007f6ee8d6e2c0] = 62640
Apr 14, 2023 @ 12:18:21.009	 scopes data    [0x00007f6ee8d66138,0x00007f6ee8d69728] = 13808
Apr 14, 2023 @ 12:18:21.009	 handler table  [0x00007f6ee8d6dc00,0x00007f6ee8d6e0f8] = 1272
Apr 14, 2023 @ 12:18:21.009	 nul chk table  [0x00007f6ee8d6e0f8,0x00007f6ee8d6e2c0] = 456
Apr 14, 2023 @ 12:18:21.009	Compiled method (c2) 6896098 33692   !   4       org.springframework.web.servlet.DispatcherServlet::doDispatch (543 bytes)
Apr 14, 2023 @ 12:18:21.009	 main code      [0x00007f6ee8d5f4a0,0x00007f6ee8d65a00] = 25952
Apr 14, 2023 @ 12:18:21.009	 oops           [0x00007f6ee8d65b08,0x00007f6ee8d65b68] = 96
Apr 14, 2023 @ 12:18:21.012	 oops           [0x00007f6ee8d65b08,0x00007f6ee8d65b68] = 96
Apr 14, 2023 @ 12:18:21.012	 nul chk table  [0x00007f6ee8d6e0f8,0x00007f6ee8d6e2c0] = 456
Apr 14, 2023 @ 12:18:21.012	 relocation     [0x00007f6ee8d5ef70,0x00007f6ee8d5f4a0] = 1328
Apr 14, 2023 @ 12:18:21.012	 dependencies   [0x00007f6ee8d6da38,0x00007f6ee8d6dc00] = 456
Apr 14, 2023 @ 12:18:21.012	Compiled method (c2) 6896101 33692   !   4      org.springframework.web.servlet.DispatcherServlet::doDispatch (543 bytes)
Apr 14, 2023 @ 12:18:21.012	 total in heap  [0x00007f6ee8d5ee10,0x00007f6ee8d6e2c0] = 62640
Apr 14, 2023 @ 12:18:21.012	 handler table  [0x00007f6ee8d6dc00,0x00007f6ee8d6e0f8] = 1272
Apr 14, 2023 @ 12:18:21.012	 stub code      [0x00007f6ee8d65a00,0x00007f6ee8d65b08] = 264
Apr 14, 2023 @ 12:18:21.012	 metadata       [0x00007f6ee8d65b68,0x00007f6ee8d66138] = 1488
Apr 14, 2023 @ 12:18:21.012	 scopes data    [0x00007f6ee8d66138,0x00007f6ee8d69728] = 13808
Apr 14, 2023 @ 12:18:21.012	 main code      [0x00007f6ee8d5f4a0,0x00007f6ee8d65a00] = 25952
Apr 14, 2023 @ 12:18:21.012	 scopes pcs     [0x00007f6ee8d69728,0x00007f6ee8d6da38] = 17168
Apr 14, 2023 @ 12:18:21.042	# If you would like to submit a bug report, please visit:
Apr 14, 2023 @ 12:18:21.042	#   https://github.com/adoptium/adoptium-support/issues
Apr 14, 2023 @ 12:18:21.042	#

Looking at APM tracing it looks like it is locking up on ZGC garbage collection:

@kimattree please update to 17.0.7 and report back here if you still see the crash

@karianna I have updated to 17.0.6_10 as there is no 17.0.7 in eclips-temurin in docker hub:
https://hub.docker.com/r/amd64/eclipse-temurin/tags?page=1&name=17.0.7

17.0.7 should be out in the next couple of working days.

Just had the same SIGSEGV on an upgraded pod/image running 17.0.6_10

Thanks, are you able to send in the log from the 17.0.6 run?  I'll open a bug upstream.

@karianna I was able to capture a full log as well as a Z-Worker core dump from 2 pods running in the cluster - they are pretty big 3Gb and 10Gb whats the preferred way to get these to you ?

@kimattree Are those full application logs or the hs_err_pid7.log ?

the .log files are ErrorFile, and the core files are from CoredumpOnCrash:
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/ -XX:+CrashOnOutOfMemoryError -XX:+CreateCoredumpOnCrash -XX:ErrorFile=/java_error.log

@karianna the new error logs have a lot more information in them, seems we've tracked it down to APM Java Agent:
`RAX=0x0000000000000768 is an unknown value
RBX=0x000003227503c420 is an unknown value
RCX=0x00007f2282eb8068: <offset 0x0000000001370068> in /opt/java/openjdk/lib/server/libjvm.so at 0x00007f2281b48000
RDX=0x00007f2282e60140: <offset 0x0000000001318140> in /opt/java/openjdk/lib/server/libjvm.so at 0x00007f2281b48000
RSP=0x00007f226a92f6e0 points into unknown readable memory: 0x000010009e040198 | 98 01 04 9e 00 10 00 00
RBP=0x00007f226a92f710 points into unknown readable memory: 0x00007f226a92f760 | 60 f7 92 6a 22 7f 00 00
RSI=0x0000080048ed9da0 is a good oop: java.lang.String
{0x0000080048ed9da0} - klass: 'java/lang/String'

string: "co.elastic.apm.exception"`

There is an open task with elastic to investigate:
https://discuss.elastic.co/t/sigsegv-jvm-crash-with-zgc-garbage-collection/337269

Still an open bug, but some changes:

Changed base image from alpine to ubuntu, to test musl/glibc compatibility issues

But crashes still occurring.

Removing APM agent resolves the crashes - closing ticket. Ongoing investigation with Elastic Here: https://discuss.elastic.co/t/sigsegv-jvm-crash-with-zgc-garbage-collection/337269/3


Adding the German language to the Addon

Add the support for german language

thanks for the contribution!

Thanks for your great work. :)


[5.7]Preparation for location aware diagnostics in the compiler.

(Cherry-pick #321 into swift/release/5.7)
Moving libswiftLexRegexLiteral() and libswiftParseRegexLiteral() to
the compiler repository because these functions are basically just
briding the compiler to the actual lexing/parsing function.

Make some Lexing error APIs public.
Make LocatedErrorProtocol public and expose the location property
Shift the location of LocatedError in parseWithDelimiters so the
client can get the valid string indices of the passed-in literal string.

@swift-ci Please test

Integration test (without swift changes) triggered https://github.com/apple/swift/pull/35202#issuecomment-1108778521


cmd/go: run does not close its own os.Stdout when the underlying process does so

What version of Go are you using (go version)?

go version go1.14.2 darwin/amd64

Does this issue reproduce with the latest release?
✔ ( fails the same way on multiple go versions )
What operating system and processor architecture are you using (go env)?
macos Mojave
What did you do?
I have applications needing to communicate over multiple FIFO's in turn (due to boring/non-negotiable external requirements). The dance looks like:
$ ProducerProgram ... --outv0-xargs | xargs -0 ConsumerProgram

Where:

ProducerProgram creates a number of named pipes, prints their names, closes STDOUT, and starts writing to each FIFO in turn
xargs sees the EOF, starts the ConsumerProgram with the FIFOs as args and it proceeds reading from each FIFO in the same order

The trouble is that go build; ./ProducerProgram ... |  works, while go run ./. ... | does not, as go run does not propagate the closure of os.Stdout until program exit... which can never happen because the FIFO reading never starts.
Below find a complete program that exhibits the problem as:
# this works
$ go build -o pipehang ./ ; ./pipehang | xargs -0 cat | wc -c
 33554432

# this hangs
$ go run ./ | xargs -0 cat | wc -c

Standalone program to reproduce
package main

import (
	"fmt"
	"log"
	"os"

	"golang.org/x/sys/unix"
)

func main() {
	ec := make(chan error)
	go errorHandler(ec)

	defer os.Remove("fifo1")
	defer os.Remove("fifo2")

	// do it again :(
	// AN ASIDE - it would be great if I could mkfifo with "force" instead of having to cleanup ahead of time
	os.Remove("fifo1")
	os.Remove("fifo2")

	ec <- unix.Mkfifo("fifo1", 0600)
	ec <- unix.Mkfifo("fifo2", 0600)

	// AN ASIDE/maybe another bug: if I open with O.WRONLY on macos - everything hangs on this line
	fh1, err := os.OpenFile("fifo1", os.O_RDWR, 0)
	ec <- err

	fh2, err := os.OpenFile("fifo2", os.O_RDWR, 0)
	ec <- err

	_, err = fmt.Fprintf(
		os.Stdout,
		"%s\x00%s\x00",
		"fifo1",
		"fifo2",
	)
	ec <- err

	// THIS IS THE BUG - we signal to xargs "we are done", but
	// go run will not close its own Stdout in turn
	ec <- os.Stdout.Close()

	sixteenMegs := make([]byte, 16*1024*1024)
	_, err = fh1.Write(sixteenMegs)
	ec <- err
	ec <- fh1.Close()

	_, err = fh2.Write(sixteenMegs)
	ec <- err
	ec <- fh2.Close()

	return
}

func errorHandler(c <-chan error) {
	for {
		err, chanOpen := <-c
		if !chanOpen {
			return
		}
		if err != nil {
			log.Fatal(err)
		}
	}
}

One problem: os.Stdout is assignable, so there's no guarantee that it would close file descriptor 1.

Note that go run is just a convenience wrapper that builds to a temporary file and launches the binary. It's not supposed to work exactly like running the actual binary, and I also don't think you should use it in production or for serious stuff. Especially when you care about things like the process return codes or pipes working correctly.

Yeah, if go run doesn't work for you, I would definitely recommend using go build x && ./x instead.

Acknowledging go run is not something to use for production purposes, isn't this just a bug in whatever implements the fork/exec or whatever it is that go uses?
I could dig further into this to find what exactly needs fixing, I just ran out of time figuring the initial cause. What I would like to hear first is whether this is something that the core team considers an actual error in behavior.
P.S. In my specific case I will have to devise some sort of workaround in any case, because telling users "check out this repo and play with it, but oh wait, you can't use go run, for reasons" is too far on the "lose their interest" scale.

It's not a bug in the implementation of fork/exec, which in this case is the os/exec package (https://golang.org/pkg/os/exec).  That lets you set standard output to whatever you want.  go run just sets the standard output of the child process to its own standard output, and does nothing else.
As you say, that doesn't work for programs that expect to be able to close their own standard output and have that close be seen by processes later in the pipeline.

P.S. In my specific case I will have to devise some sort of workaround in any case, because telling users "check out this repo and play with it, but oh wait, you can't use go run, for reasons" is too far on the "lose their interest" scale.

It seems to me that you're over-blowing this... You wanted to write:

cd into the project folder, then run

$ go run ./. ... | xargs ...

Instead, you have to write:

cd into the project folder, build the program an then run it:

$ go build
$ pipehang | xargs ...

I even like the 2nd version better! I find the go run ./... pattern quite ugly, IMO once you have a multiple-files project go build should be preferred. I only use go run when I can write go run main.go; otherwise I always build.

@ianlancetaylor looking through the code more I see what is happening... It is a really unfortunate design decision that go run was not implemented through a real execve(), but I appreciate that changing this at this stage is no longer tenable. I'll close the ticket.
@ALTree the "you are holding it wrong" tone is really unnecessary. The project in question requires/invites the user to tweak the source. The extra go build step, is just that - an extra step. The answer is an "time-to-first-write" timeout with a helpful error message "did you run it that like X? That unfortunately doesn't work, use the verbose Y instead, sorry!"


It doesn't really validate it?

Hi guys,
Found this package when looking for a swedish ssn validator. However, it does not validate the validity of the number, only the format? You're not doing any checksum validations at all?
You should either add checksum validation too, or update the readme stating what you actually validate

Hi @molteber.
This is something that's being worked on. Feel free to open a PR to speed up the process!

Awesome, looking forward to it :) Went for another package for this project, but might tune into this the next time :+1:

Should be fixed with Pull Request #6 . :)

Thanks so much @Mr1BitL8r, greatly appreciated!
@molteber maybe could test it to see if it fits his search parameters for the perfect SSN validator package?


Spooky Behavior getting values from a CLIMutable Record Type

Please provide a succinct description of the issue.
This is proving difficult to reproduce but I will do my best here to show what's happening. We're updating an F# CLIMutable object with an auto incrementing Id when it's added to the database with EntityFramework. The impact is that downstream from this we use the value and it is incorrect.
This is occurring in F# 4.0, VS 2015 Update 3.
Core <IP_ADDRESS>
Target .Net Framework 4.5.2
Output Type Class Library
Occurs with optimization on, and works correctly with it turned off.
Repro steps
Provide the steps required to reproduce the problem
Code looks like this. It's updated on the call to SaveChanges()
let generatedFeed =
    let baseFeed : Feed =
           { Id = 0
             ListName = "EiAugTestList1"
             FeedDate = now
             PreviousFeedDate = Nullable()
             GeneratedOn = Nullable()
             FileName = "File1"
             FileSize = 0L
             ImportEndTime = now
             InsertedOn = now
             FeedImporter = "EiAug"
             FeedType = "D"
             ParseFailures = 0
             MapFailures = 0
             EntityChanges = 0
             EntityDeletes = 0
             EntityPurges = 0
             ValidationFailures = 0
             TotalRecords = 0 }

    use stagingContext = createStagingContext()
    stagingContext.Database.Log <- fun x -> stdout.WriteLine(x)
    stagingContext.Add(baseFeed)
    stagingContext.SaveChanges() |> ignore

    Console.ForegroundColor <- ConsoleColor.Yellow
    let feedId = baseFeed.Id
    printfn "feed = %A" baseFeed
    printfn "feed.Id = %d" baseFeed.Id
    printfn "feedId = %d" feedId

Strange Output:
feed = {Id = 1;
 ListName = "EiAugTestList1";
 FeedDate = 8/3/2017 12:34:05 PM;
 PreviousFeedDate = null;
 GeneratedOn = null;
 FileName = "File1";
 FileSize = 0L;
 ImportEndTime = 8/3/2017 12:34:05 PM;
 InsertedOn = 8/3/2017 12:34:05 PM;
 FeedImporter = "EiAug";
 FeedType = "D";
 ParseFailures = 0;
 MapFailures = 0;
 EntityChanges = 0;
 EntityDeletes = 0;
 EntityPurges = 0;
 ValidationFailures = 0;
 TotalRecords = 0;}
feed.Id = 0
feedId = 0

It looks like the IL is just loading zero to print? So strange.
    L_0089: call void [mscorlib]System.Console::set_ForegroundColor(valuetype [mscorlib]System.ConsoleColor)
    L_008e: ldstr "feed = %A"
    L_0093: newobj instance void [FSharp.Core]Microsoft.FSharp.Core.PrintfFormat`5<class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<class [XurDb.Staging]XurDb.Staging.Feed, class [FSharp.Core]Microsoft.FSharp.Core.Unit>, class [mscorlib]System.IO.TextWriter, class [FSharp.Core]Microsoft.FSharp.Core.Unit, class [FSharp.Core]Microsoft.FSharp.Core.Unit, class [XurDb.Staging]XurDb.Staging.Feed>::.ctor(string)
    L_0098: stloc.s format
    L_009a: call class [mscorlib]System.IO.TextWriter [mscorlib]System.Console::get_Out()
    L_009f: ldloc.s format
    L_00a1: call !!0 [FSharp.Core]Microsoft.FSharp.Core.PrintfModule::PrintFormatLineToTextWriter<class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<class [XurDb.Staging]XurDb.Staging.Feed, class [FSharp.Core]Microsoft.FSharp.Core.Unit>>(class [mscorlib]System.IO.TextWriter, class [FSharp.Core]Microsoft.FSharp.Core.PrintfFormat`4<!!0, class [mscorlib]System.IO.TextWriter, class [FSharp.Core]Microsoft.FSharp.Core.Unit, class [FSharp.Core]Microsoft.FSharp.Core.Unit>)
    L_00a6: ldloc.0
    L_00a7: callvirt instance !1 [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<class [XurDb.Staging]XurDb.Staging.Feed, class [FSharp.Core]Microsoft.FSharp.Core.Unit>::Invoke(!0)
    L_00ac: pop
    L_00ad: ldstr "feed.Id = %d"
    L_00b2: newobj instance void [FSharp.Core]Microsoft.FSharp.Core.PrintfFormat`5<class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<int32, class [FSharp.Core]Microsoft.FSharp.Core.Unit>, class [mscorlib]System.IO.TextWriter, class [FSharp.Core]Microsoft.FSharp.Core.Unit, class [FSharp.Core]Microsoft.FSharp.Core.Unit, int32>::.ctor(string)
    L_00b7: stloc.s format2
    L_00b9: call class [mscorlib]System.IO.TextWriter [mscorlib]System.Console::get_Out()
    L_00be: ldloc.s format2
    L_00c0: call !!0 [FSharp.Core]Microsoft.FSharp.Core.PrintfModule::PrintFormatLineToTextWriter<class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<int32, class [FSharp.Core]Microsoft.FSharp.Core.Unit>>(class [mscorlib]System.IO.TextWriter, class [FSharp.Core]Microsoft.FSharp.Core.PrintfFormat`4<!!0, class [mscorlib]System.IO.TextWriter, class [FSharp.Core]Microsoft.FSharp.Core.Unit, class [FSharp.Core]Microsoft.FSharp.Core.Unit>)
    L_00c5: ldc.i4.0
    L_00c6: callvirt instance !1 [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<int32, class [FSharp.Core]Microsoft.FSharp.Core.Unit>::Invoke(!0)
    L_00cb: pop
    L_00cc: ldstr "feedId = %d"
    L_00d1: newobj instance void [FSharp.Core]Microsoft.FSharp.Core.PrintfFormat`5<class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<int32, class [FSharp.Core]Microsoft.FSharp.Core.Unit>, class [mscorlib]System.IO.TextWriter, class [FSharp.Core]Microsoft.FSharp.Core.Unit, class [FSharp.Core]Microsoft.FSharp.Core.Unit, int32>::.ctor(string)
    L_00d6: stloc.s format2
    L_00d8: call class [mscorlib]System.IO.TextWriter [mscorlib]System.Console::get_Out()
    L_00dd: ldloc.s format2
    L_00df: call !!0 [FSharp.Core]Microsoft.FSharp.Core.PrintfModule::PrintFormatLineToTextWriter<class [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<int32, class [FSharp.Core]Microsoft.FSharp.Core.Unit>>(class [mscorlib]System.IO.TextWriter, class [FSharp.Core]Microsoft.FSharp.Core.PrintfFormat`4<!!0, class [mscorlib]System.IO.TextWriter, class [FSharp.Core]Microsoft.FSharp.Core.Unit, class [FSharp.Core]Microsoft.FSharp.Core.Unit>)
    L_00e4: ldc.i4.0
    L_00e5: callvirt instance !1 [FSharp.Core]Microsoft.FSharp.Core.FSharpFunc`2<int32, class [FSharp.Core]Microsoft.FSharp.Core.Unit>::Invoke(!0)
--

Expected behavior
Should print the actual value, not 0.
Actual behavior
Prints 0
Known workarounds
If I move let baseFeed : Feed = ... to the top scope of the module it works correctly.
Related information
Provide any related information

Operating system
Branch
.NET Runtime, CoreCLR or Mono Version
Editing Tools (e.g. Visual Studio Version)
Links to F# RFCs or entries on https://github.com/fsharp/fslang-suggestions
Links to performance testing scripts
Indications of severity

I can reproduce it, but only with VS 2015, NOT VS 2017.
Library1.zip
Output of VS2015 in Release:

Maybe it's already fixed. Best was to check is creating a test out of it
Am 03.08.2017 6:47 nachm. schrieb "Lukas Rieger"<EMAIL_ADDRESS>
I can reproduce it, but only with VS 2015, NOT VS 2017.
Library1.zip
https://github.com/Microsoft/visualfsharp/files/1197956/Library1.zip
Output of VS2015 in Release:
[image: image]
https://user-images.githubusercontent.com/4236651/28933056-150bc050-787c-11e7-95b1-5ef886c917a4.png
[image: image]
https://user-images.githubusercontent.com/4236651/28933079-2245cfcc-787c-11e7-94b8-a69524ca51d1.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/3416#issuecomment-320026110,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNAibQHAAQyO18CnpSONtpvZYtihRks5sUfmGgaJpZM4OssiU
.

@forki @Rickasaurus https://github.com/Microsoft/visualfsharp/pull/2263

Closing as this was fixed by @vasily-kirichenko.


Intermittent etcdhttp: got unexpected response error (etcdserver: request timed out)

Hi all,
I'm running a single node etcd 2.2.0 (e4561dd) cluster on Ubuntu 14.04 on OpenStack, with options name, listen-client-urls, listen-peer-urls, advertise-client-urls, initial-cluster-master, initial-advertise-peer-urls and data-dir set.
It's backing a single-node test Kubernetes cluster that has scheduled a couple dozen pods, but isn't changing much. Every few minutes, I see
2015-11-13_22:08:10.35486 2015-11-13 22:08:10.354738 E | etcdhttp: got unexpected response error (etcdserver: request timed out)

in the logs. Sometimes I see a few in succession, and during those times etcdctl ls can fail with
Error:  client: etcd cluster is unavailable or misconfigured
error #0: client: endpoint http://<IP_ADDRESS>:4001 exceeded header timeout
error #1: client: endpoint http://<IP_ADDRESS>:2379 exceeded header timeout
error #2: client: endpoint http://<IP_ADDRESS>:2379 exceeded header timeout
error #3: client: endpoint http://<IP_ADDRESS>:4001 exceeded header timeout

I can make it happen more frequently by writing something substantial to etcd in a loop:
while true
do
  etcdctl set /blarg $(etcdctl get /registry/pods/default/redis-controller-q4948) > /dev/null
done

The machine has plenty of spare memory and cpu. etcd's position in iotop is spiky. It's usually relatively low, but sometimes reaches 99%. The stress-test script above pushes etcd higher in iotop, I usually see 5-7 threads under 5%.
I also have a 292kb strace of the etcd process taken while the stress test was running & etcd was periodically logging the timeout message, and would be happy to grep it for anything that might shed light on the situation.
Thanks,
Anand

@apatil Do you have access to any cloud environment? If you can reproduce the issue there, it would be very helpful.

@xiang90 I do, yes. I'll try to get you a simple repro.

@apatil Great. Thanks!

Is this issue superseded by/redundant with https://github.com/coreos/etcd/issues/3812 ?

no they are different. it is important to find out why this happens to a one member cluster with mid load.

I still haven't managed to come up with a simple repro case, but I have gotten some more information.
In addition to 2.2.0, this happens with versions 2.0.13 and c4672ced3e0a0dc2232af3194d00d869516866f1 . I'm able to convince myself that it's less frequent with c4672ced3e0a0dc2232af3194d00d869516866f1 , but couldn't swear to it.
Also, I took a look at traffic with the new etcd-top tool. In most seconds there are <5 requests, but every 10s there is a spike. The spike is usually 50-60 requests, the most I've seen is 68 requests per second. The breakdown is as follows:
Top 10 most popular http requests:
Total Sum  Period Sum Verb Path
     2566      22 GET /v2/keys/registry/pods/default
     1713      16 GET /v2/keys/registry/controllers/default
     1712      16 GET /v2/keys/registry/daemonsets/default
      850       2 GET /v2/keys/environment
      356       0 GET /v2/members
      318       0 GET /v2/keys/registry/minions
      202       0 GET /v2/keys/registry/minions/localhost
      108       0 GET /v2/keys/registry/namespaces/default

So most of the traffic seems to be Kubernetes heartbeating. No pods were scheduled and no API objects were changed, created or deleted during this test.
Strangely, the timeout messages don't seem to be correlated with the spikes. The overwhelming majority of the spikes go by without problems, and I have seen timeout messages right in the middle of the cycle, in seconds where there were zero requests.

Also of interest, it looks like kube-apiserver is using the go-etcd client: https://github.com/kubernetes/kubernetes/blob/54706661ad72d62ea0b494112a74e0467093c9f4/cmd/kube-apiserver/app/server.go#L52 . The default timeout seems to be 1s: https://github.com/coreos/go-etcd/blob/de3514f25635bbfb024fdaf2a8d5f67378492675/etcd/client.go#L79 .

@apatil The error comes from server-side, not client-side. Have you managed to reproduce it on a single member etcd cluster? We are aware that this might happen to a multi-member cluster when the cluster is under high load.

We're seeing request timeout errors as well and resulting 50x server errors with single-node etcd clusters, from etcd 2.1.2 up to 2.2.2.
On the etcd server side, we see one or more of these logged about 30-60 seconds after server start:
2016/01/4 12:55:11 etcdhttp: got unexpected response error (etcdserver: request timed out)

As best as I can tell, this isn't at a watch limit boundary (1000) or a snapshot boundary (10000). At the same time that occurs, the etcd client gets a 501 error. It reacts by retrying the request, thinking a leader election was in progress. If the request is one that would fail on a retry (like a delete or a conditional update/create), the request then fails.
Running a loop with curl doing PUTs against etcd alongside the tests:
while true; do curl -v -s -X PUT "http://<IP_ADDRESS>:44001/v2/keys/_curltest" >> curletcd.log 2>&1; done

it looks like the etcd server is stuttering, maybe during a garbage collect? It averages 200 PUTs/second, then hits a 6 second gap, a 500 error, a few more 3-4 second gaps, then is back to 200+ PUTs/second
grep -E " 500 |Date:" curletcd.log | awk -f dedup.awk

< Date: Tue, 22 Dec 2015 22:20:37 GMT
... repeated 237 times
< Date: Tue, 22 Dec 2015 22:20:38 GMT
... repeated 191 times
< Date: Tue, 22 Dec 2015 22:20:39 GMT
... repeated 182 times
< Date: Tue, 22 Dec 2015 22:20:40 GMT
... repeated 175 times
< Date: Tue, 22 Dec 2015 22:20:41 GMT
... repeated 301 times
< Date: Tue, 22 Dec 2015 22:20:42 GMT
... repeated 219 times
< HTTP/1.1 500 Internal Server Error
< Content-Type: application/json
< X-Etcd-Cluster-Id: a176fdba55eb9204
< X-Etcd-Index: 0
< Date: Tue, 22 Dec 2015 22:20:48 GMT
< Content-Length: 100
<
{ [data not shown]
* Connection #0 to host <IP_ADDRESS> left intact
{"errorCode":300,"message":"Raft Internal Error","cause":"etcdserver: request timed out","index":0}
< Date: Tue, 22 Dec 2015 22:20:48 GMT
< Date: Tue, 22 Dec 2015 22:20:53 GMT
< Date: Tue, 22 Dec 2015 22:20:56 GMT
... repeated 149 times
< Date: Tue, 22 Dec 2015 22:20:57 GMT
... repeated 337 times
< Date: Tue, 22 Dec 2015 22:20:58 GMT
... repeated 334 times
< Date: Tue, 22 Dec 2015 22:20:59 GMT
... repeated 336 times
< Date: Tue, 22 Dec 2015 22:21:00 GMT
... repeated 329 times

Related issue/comments:
https://github.com/openshift/origin/issues/6065#issuecomment-166651844

@apatil @liggitt
The server side error that you see in etcdserver: request timed out can happen in 2 cases:

Propose(ctx, data) to append log got timed out.
ProposeConfChange(ctx, cc) to propose configuration change got timed out.

I tried in a single node etcd cluster, extensively with verstion 2.1.2, 2.2.2,
master branch, but I couldn't reproduce this error.
It might have been timed out from gc pause, but we need GC trace to find that out.
Could you reproduce this reliably in a cloud environment?  If you have simple configs and commands that are reproducible in our side, it would be very helpful.
Thanks,

For our issue, we tracked it to the fsync system call and a super-slow disk issue (ec2 blocked the fsync call for 10-30 seconds while silently resizing the supposedly local and supposedly pre-allocated SSD volume).

The server side error is not related to disk issue, I think. Did that issue affect the CPU or anything else?

@gyuho It is highly related to disk since etcd needs to do fsync before committing. @liggitt Thanks for the update. I feel we can close this actually.

@xiang90 is right. Sorry about the wrong information.
The raft implementation calls fsync before committing an entry and if there were disk issues,
the propose operations in raft could have timed out.

That's good to know. Thanks @liggitt for the info. I agree that this can be closed, will investigate fsync performance on our side and open a different issue if necessary.

We keep seeing these errors in the logs.  What are the current timeouts and is there a way to adjust the timeouts ?
We are using 3 node cluster in ec2 created using cloudformation template:
https://s3.amazonaws.com/coreos.com/dist/aws/coreos-stable-hvm.template
CoreOS: 1185.3.0

From https://github.com/coreos/etcd/blob/master/etcdserver/config.go#L137 it's defined as return 5*time.Second + 2*time.Duration(c.ElectionTicks)*time.Duration(c.TickMs)*time.Millisecond. If you want to increase the request timeout that means changing the --election-timeout flag passed to etcd.


wasm64 support

It's possible to exhaust the memory of the interpreter (4GB) by throwing a ton of concurrent queries at it. Using wasm64 should fix this.

Hmm, maybe wasm64 not supported by WASI yet? https://github.com/WebAssembly/wasi-sdk/issues/185
That's a bit of a show stopper.


Possibly modality being ignored in Source typechecker

The Source typechecker (Icicle.Source.Checker.Constraint) should compute Possibilities; Possibly or Definitely.
Possibility is a bit simpler than Temporality, because Possibility is a full lattice (right?): there is always a meet and a join; Possibly U Definitely = Possibly and so on.
(Whereas Temporality is not; Element U Aggregate = {} or something)
Anyway, we need a new constraint for getting the upper bound of two possibilities. Something like
PossibilitiesUpperBound Definitely d = d
PossibilitiesUpperBound Possibly _ = Possibly
PossibilitiesUpperBound p q = PossibilitiesUpperBound q p

This can be added to Icicle.Source.Type.Constraints.
Now, the return possibility of most things will be the upper bound of all its arguments. Look at filter, for example
filter Definitely ~> Definitely   : Definitely
filter Possibly ~> Definitely   : Possibly
filter Definitely ~> Possibly   : Possibly

filter x ~> c : PossibilitiesUpperBound x c

This is quite different from temporality, where filter requires its expression to be Element and the return to be Aggregate.
For function application the idea is the same as for temporality.
If the expected (function type) and the actual (argument type) possibility are the same, function application is as normal.
If the expected and actual are different, either:

Expect Definitely, actual Possibly: the function must be modified to return a Possibly. Think of this as unboxing the argument, then reboxing the result of function application.
Expect Possibly, actual Definitely: application as normal

For Case expressions, any variables you bind in a pattern have the same possibility and temporality as the scrutinee.
For example, if you have
case (xs : Element Possibly (List Int))
 | Cons one rest -> …

here, one and rest are also Element Possibly.
The return possibility is the upper bound of the scrutinee and all the alternatives.
Lets just use the possibility of the "in" body. It is much simpler than temporality for lets.
Primitives can just be Definitely, because any Definitely can be converted to a Possibly. It is basically pure. Note that in Icicle.Source.Checker.Prim, the primitives are just bare, unmoded types. This is fine because "canonT" and "decomposeT" which are used to check the modes in Checker.Constraint will convert them to Definitely.

bit late to ask.... but what exactly is Possibility modality? I'm running into this in the source type checker and I'm getting unification variables in the result type for this modality thing.

oh... it's like an (Either error) monad. well, Possibly = Either error, Definitely = Identity.
what do you mean, running into it while implementing something other than this? you should, for now, be able to ignore Possibility - or if not ignore it, you can explicitly set types to definitely with
definitelyT t = canonT $ Possibility Definitely t

I mean, during type checking the Source, I might get something like Aggregate t$5 Int, where the variable is some "possibility", and wasn't sure how to make it go away.

I have fixed this


SeriesProvider don't removes handleSeriesAdded Event when component will unmount

handleSeriesAdded is called after a Series is unmounted, because the registered Event (in providerSeries) isn't removed after the component is unmounted.
 Highcharts.addEvent(getChart(), 'addSeries', this.handleSeriesAdded);
This will do the trick:
    componentWillUnmount() {
        const { getChart } = this.props;
        Highcharts.removeEvent(getChart(), 'addSeries', this.handleSeriesAdded);
    }

When not doing this, react will warn you (because you can't set states on unmounted components)
Warning: setState(...): Can only update a mounted or mounting component.
This usually means you called setState() on an unmounted component.
This is a no-op. Please check the code for the SeriesProvider(t) component.

Hi, sorry I've been on holiday the past few days. Looking into these issues now.

Good spot! And thank you for the detailed bug report and suggested fix. I'll need to add you as a contributor 😄

Thanks for your efforts, gonna check your all your fixes right now. I think react-jsx-highcharts is a very good library and I am glad I found this. Very solid implementation. Id be glad to help you on this since I am heavily using the highcharts with very complex scenarios.

That's good to hear! Thank you very much, I look forward to it.


Command runs with adb but doesn't work with this plugin

I am running this command from my computer
$ adb shell input keyboard 26

and it's working perfectly ( turning the phone off ).
but when I try to execute this command using the plugin :
$ input keyboard 26

it doesn't work.
Thank you in Advance

facing same issue. It does not support adb.
let us know if any other plugin support it.


Trouble with migration from marthoc deconz to official deconz adon

I tried to migrate to official deconz and what I have done:

Backup up at Phoscan app all lights etc.
Stoped marthoc addon installed.
Restarted HA
Installed official aaddon 3.1 version.
Started and looks ok, webui (phoscan) setup new password and name. And restored from backup. Restarted addon, restarted HA.

[17:18:34] INFO: Starting the deCONZ gateway... [17:18:34] INFO: Running the deCONZ OTA updater... [17:18:34] INFO: Running the IKEA OTA updater... [17:18:34] INFO: Running Hass.io discovery task... {"uuid":"f810487dcb11420280ff011b4aae55f2"} [17:18:34] INFO: Success send discovery information to Home Assistant [17:18:34] INFO: deCONZ is set up and running! libpng warning: iCCP: known incorrect sRGB profile This plugin does not support propagateSizeHints() This plugin does not support propagateSizeHints() This plugin does not support propagateSizeHints() 17:18:35:132 HTTP Server listen on address <IP_ADDRESS>, port: 40850, root: /usr/share/deCONZ/webapp/ 17:18:35:215 CTRL. 3.16.217:18:35:633 COM: /dev/ttyUSB0 / serialno:  17:18:35:633 COM: --dev: /dev/ttyUSB0 (ConBee) 17:18:35:634 ZCLDB init file /data/.local/share/dresden-elektronik/deCONZ/zcldb.txt 17:18:35:831 parent process bash 17:18:35:831 gw run mode: docker/hassio 17:18:35:832 GW sd-card image version file does not exist: /data/.local/share/dresden-elektronik/deCONZ/gw-version 17:18:35:832 sd-card cid: 1b534d454231515430ffffffff01253f 17:18:35:834 DB sqlite version 3.16.2 17:18:35:835 DB PRAGMA page_count: 59 17:18:35:835 DB PRAGMA page_size: 1024 17:18:35:835 DB PRAGMA freelist_count: 1 17:18:35:835 DB file size 60416 bytes, free pages 1 17:18:35:835 DB PRAGMA user_version: 6 17:18:35:835 DB cleanup 17:18:35:836 DB create temporary views 17:18:35:854 don't close database yet, keep open for 900 seconds 17:18:35:864 started websocket server at port 40860 17:18:35:870 discovery updated announce interval to 10 minutes 17:18:35:875 found node plugin: libde_rest_plugin.so - REST API Plugin 17:18:35:880 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin 17:18:36:935 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin 17:18:37:271 COM: /dev/ttyUSB0 / serialno:  17:18:37:271 COM: --dev: /dev/ttyUSB0 (ConBee) 17:18:37:405 Device firmware version 0x26330500 17:18:37:416 unlocked max nodes: 200 17:18:37:705 Device protocol version: 0x010B 17:18:37:728 new node - ext: 0x00212effff017192, nwk: 0x0000 17:18:37:897 don't close database yet, keep open for 900 seconds 17:18:37:897 LightNode 1: Hallway light added 17:18:38:020 don't close database yet, keep open for 900 seconds 17:18:38:021 LightNode 4: Floor lamp added 17:18:38:022 SensorNode 9 set node 0x00158d00024919de 17:18:38:024 SensorNode 8 set node 0x00158d00024919de 17:18:38:110 don't close database yet, keep open for 900 seconds 17:18:38:111 LightNode 3: Reading lamp added 17:18:38:111 SensorNode 7 set node 0x00158d0001fa21b7 17:18:38:112 SensorNode 6 set node 0x00158d0001fa21b7 17:18:38:178 SensorNode 13 set node 0x00158d000215cb22 17:18:38:259 SensorNode 10 set node 0x00158d00030a049c 17:18:38:259 SensorNode 11 set node 0x00158d00030a049c 17:18:38:259 SensorNode 12 set node 0x00158d00030a049c 17:18:38:506 Current channel 15 17:18:38:593 CTRL ANT_CTRL 0x03 17:18:38:730 Device protocol version: 0x010B 17:18:38:781 scan skip host .18 17:18:38:923 Current channel 15 17:18:38:987 CTRL ANT_CTRL 0x03 17:18:41:231 GW update firmware found: /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26330500.bin.GCF 17:18:41:231 GW firmware version: 0x26330500 17:18:41:231 GW firmware version is up to date: 0x26330500 17:18:42:161 Announced to internet 17:18:42:161 discovery server date: Tue, 02 Jul 2019 07:18:41 GMT 17:18:42:162 	 local time seems to be ok 17:18:42:162 discovery found version 2.04.35 for update channel stable 17:18:48:330 New websocket <IP_ADDRESS>:51968 (state: 3)  17:18:52:455 Websocket disconnected <IP_ADDRESS>:51968 (state: 0)  17:19:00:062 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task 17:19:03:860 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task 17:19:07:563 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task 17:19:11:361 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task 17:19:15:062 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task 17:19:18:862 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task 17:19:22:563 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task 17:19:26:362 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task 17:19:28:386 scan skip host .250 17:19:28:593 scan finished 17:19:30:097 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task 17:19:33:878 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task 17:19:34:952 Current channel 15 17:19:34:984 Device TTL 6033 s flags: 0x7 17:19:37:581 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task 17:19:41:379 0x0017880104E85ABA error APSDE-DATA.confirm: 0xE1 on task

HA discovered a new device, went to and:

I have to zigbee gateway now!?
Click first form the to to integrate (opened on Phoscan for authentication):

Cliked second one:

Different popup but submit and seems to OK, I have deconz integrated:

But there is nothing in that integration?
And yeah Phoscan is running weird, I can not edit group names, or add or remove lights from group.
What went wrong?

I have un

installed official deconz and installed marthoc one add I  have 4 gateway now, what the heck?

Make backup of deconz data
Remove add-ons
Remove integration
Restart Home Assistant
Install add-on
Add integration

That should do the trick.

That did the trick, indeed, thx @frenck.

Glad you got it resolved @eskimos2000! 👍

Make backup of deconz data
Remove add-ons
Remove integration
Restart Home Assistant
Install add-on
Add integration

ok, everthing works finde after this steps. There is a "deCONZ Zigbee Gateway: deCONZ-0000000000000000" integration with the sensor daylight.
But after restoring the backup my old devices are not there. Also sensor daylight is no longer available. In Phoscon the old zigbee network is there and can be used. Is there a way to switch from marthoc deconz to official deconz and keep the zigbee network?


to have calls satisfying bug with sinon v7.2.4

Hi,
I have this failing build with sinon v7.2.4 (it was passing with v7.2.3):
TypeError: Cannot read property 'length' of undefined
      at /home/travis/build/knorm/knorm/node_modules/unexpected-sinon/lib/unexpected-sinon.js:155:39
      at Array.forEach (<anonymous>)
      at recordSpyCalls (node_modules/unexpected-sinon/lib/unexpected-sinon.js:153:11)
      at Object.handler (node_modules/unexpected-sinon/lib/unexpected-sinon.js:658:38)
      at executeExpect (node_modules/unexpected/build/lib/Unexpected.js:1300:65)
      at Unexpected.expect (node_modules/unexpected/build/lib/Unexpected.js:1304:18)
      at expect (node_modules/unexpected/build/lib/Unexpected.js:929:23)
      at Context.<anonymous> (test/Field.spec.js:118:9)

PR for that build here

The test:
describe('without a column name configured', function() {
  it("calls getColumnName to set the field's column name", function() {
    class Foo extends Model {}
    const stub = sinon
      .stub(Field.prototype, 'getColumnName')
      .returns('the column name');
    const field = new Field({
      name: 'bar',
      model: Foo,
      type: 'string'
    });
    expect(stub, 'to have calls satisfying', () => {
      stub('bar');
    });
    expect(field.column, 'to be', 'the column name');
    stub.restore();
  });
});

I'm not sure but it looks like these changes might be causing the issue https://github.com/sinonjs/sinon/pull/1975.
Let me know if I should provide any more info.

Thanks! Fixed in 10.11.1.
You were right that it was due to the enumerability change.


Sort notes

Added a config option to set the order used for displaying notes.

Awesome! Thanks for the PR! Merged it and released it in version 1.5.6.
My only question is that maybe the field should render according to the display order? If it's ascending, maybe it should be at the bottom? Or how do you feel about that? Thanks again and good luck!

Hi,
I'm not sure what you mean by 'at the bottom'.
Simon Barrett | Digital Implementation Officer | Tel: | Mob: | Fax: | Web: http://www.acttraining.org.uk/


[FLOC 3650] Update the intro to the API User Cert doc

Fixes 3650
The current wording allowed the user to believe that generating API User Cert was optional. This PR rewords the intro to make it clear all users must do this step.

All good. Thanks!


Change version 5.9.0-preview1

Coverage decreased (-0.08%) to 76.692% when pulling 4ddb937c0b577004277dc5616b2b107a407edac3 on yitam:version590 into 00fe340a45f58312e9af28c4c68d6f2afb7b2700 on microsoft:dev.


Version 0.2

The goal is to enhance the Design API to all of the design algorithms. While all of the algorithms are available in v0.1, the Design API provides a higher level interface for users to interact with. The interface makes it simpler to select which design algorithm to use.

[ ] Increase coverage of tests
[ ] Provide descriptions of examples via README files
[ ] Add bi-rectangular with cutout functionality to Design
[ ] Add polygonal bi-rectangular with cutout to Design

This was inadvertently created as an issue and is going to be moved to Milestones.


GitLab support

Started to work on GitLab (issue #327) support for NuKeeper based on https://docs.gitlab.com/ee/api/
What's already there:

Implementation of settings reader + some barebones tests
Basic implementation of gitlab rest client and token authentication
GetCurrentUser api call

Looking for some initial feedback.
I see quite some duplication in client implementations for Azure/Bitbucket and co. I thought first to focus on bringing Single repository support for GitLab and continuing with a cleanup a bit later. What do you guys think?

Alright, almost there!
Doing some cleanup and the first semi functional version should be reviewable.

Great stuff! We are getting there! Had some comments on the code and still some a lot spot that are not implemented yet. If you have questions are want some feedback we are also on gitter: https://gitter.im/NuKeeperDotNet/Lobby


ngMocks.guts() does not create mocks for declarables exported from other modules

ngMocks.guts() does not create mocks for declarables exported from other modules.
This happens when a module is imported that exports a declarable (a component, directive or pipe) that it does not declare in itself.
This leads to the following error:
Error: Can't export pipe MockOfTranslatePipe from MockOfMyTranslateModule as it was neither declared nor imported!
Reproduction steps:
@NgModule({
  declarations : [
    AppComponent
  ],
  imports : [
    BrowserModule,
    MyTranslateModule // <- This module exports TranslatePipe but does not declare it!
  ],
  providers : [],
  bootstrap : [AppComponent]
})
export class AppModule {
}

@NgModule({
    imports: [TranslateModule],
    declarations: [],  // <- TranslatePipe is NOT declared because it is imported from TranslateModule
    exports: [TranslatePipe],
})
export class MyTranslateModule {}```

Hi @wvankoppen,
thanks for the report, a good catch, its fix will be release with the next version.

Hi @wvankoppen,
I hope this finds you well.
might you verify the fix? ng-mocks.zip
Thanks in advance!

Hi @satanTime,
Thanks for your quick reply!
I'm happy to see that the fix works like a charm!
Please let me know when the new release is coming :)
Regards Wouter

Hi @vespertilian,
thanks for the feedback. It will be released on Saturday / Sunday.

Wonderful, thanks!

v11.2.0 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.


Cleanup disk metrics

Addresses #4 by:

Removing the pre-averaged metrics
Removing metrics that aggregate read and write into a single metric (since those are exposed separately)
Converting free_megabytes to free_bytes
Removing the *_base metrics, and fixing the percent-metrics

Because of how the percent metrics are calculated (percent_metric_name / percent_metric_name_base), they get "fake precision" when getting close to zero, eg wmi_perf_percent_disk_write_time{volume="HarddiskVolume3"} 2.931438995229291e-11.
Possibly we should truncate to zero at some point? @brian-brazil - any recommendations here?

Also, just re-read the recommendations for writing exporters and about not exposing percentages. Fix coming.

Looks great. Waiting for @brian-brazil to comment before merging

I did some more cleanup, primarily cosmetic stuff on the metric names, as well as updating the help texts from perfmon.
I also changed from percentages to ratios. I'm not fully satisfied with the names, but not sure how to make them better. idle_time doesn't sound like a ratio, I'd expect seconds. Any ideas?

It also seems that some of the data we get might actually be counters rather than gauges - the ones with CounterType 272696320 (eg reads_per_sec) in the documentation seem to be strictly increasing, despite the help text indicating that it is a rate...

Regarding help texts, I think it's a good idea to keep the WMI names in there too, to make it meaningful for users to understand what the measure is derived from.
From the prometheus docs:
When you’re transforming metrics it’s useful for users to be able to track back to what the original was, and what rules were in play that caused that transform. Putting in the name of the collector/exporter, the id of any rule that was applied and the name/details of the original metric into the help string will greatly aid users.

https://prometheus.io/docs/instrumenting/writing_exporters/#help-strings

Yes, agreed. What do you think about this format?

The number of requests outstanding on the disk (derived from LogicalDisk.CurrentDiskQueueLength)

That would be great, also "The number of requests outstanding on the disk (LogicalDisk.CurrentDiskQueueLength)" works :)

Done!

By the way, feel free to rename perf.go to logical_disk.go in this PR

Now that we've mostly figured out the type system, we should start a wiki page or something documenting the mapping from the various "Counter" types to Prometheus Metrics.

Hm, the rename wasn't very good, now all the comments are hidden away in other diffs :/

I'm still perusing the docs, but I have a crazy idea.
It looks like it's possible to get to CounterType with WMI (though we'll need to use a different WMI library). Given that and presuming that metric naming is relatively consistent we may be able to fully automate the transformation of metric names and the user would only have to provide a WMI class name. We'll likely still need some hardcoded rules to fix e.g. bytes->megabytes.
I also note we cannot completely rely on documentation alone for CounterTypes - several of the ones in this PR changed in Windows 2000 (which means this won't quite work on XP).

@brian-brazil Interesting idea! We could just have a mapping list that depends on the OS version, for compatibility. Plus some utility functions for standard unit conversions in case they are not fully standardized.
Along with the discussion re IIS/SQL server metrics, if those should become separate exporters maybe such automatic transformation and conversion could form the base for a wmi exporter library that can be used to easily build new exporters?

@brian-brazil I think I've addressed all the comments now, and the numbers look reasonable from what I can see

The counter types is what changed between versions.
What I'd see happening for IIS/SQL is that you'd run the WMI exporter but with different flags just pulling in IIS/SQL metrics.

Hm, maybe need to rebase this branch. Appveyor is complaining it is unmergable without conflicts now.

Yep, just pushed :) (Very nice work adding it, btw!)

Need to squash before merging as well

@brian-brazil interesting idea, indeed. there is hundreds of WMI sources, but I'm not sure most of them is very usable. Let's discuss that in a separate issue #12

:+1:
I'd suggest squashing commits.

Done!

Great work!

collectors/logical_disk.go | 265 ++++++++++++++++++++
collectors/perf.go         | 593 ---------------------------------------------

i love this diff :) thanks for all the work


Added localization to OptionSetMetadataAttribute

I extended the code generate to add multiple OptionSetMetadataAttribute to the Enum Types. One OptionSetMetadataAttribute per localization configured. This is needed if you want to show the translations in applications that uses the XrmContext (and dont want to contact CRM to get the translations).
Unfortunately this is a breaking change for anyone that depends on a single OptionSetMetadataAttribute being present, as AllowMultiple was previously set to false. So could be that the feature should be hidden behind a commandline arg.

Update the PR to only use this new functionality when the commandline argument localizations is present, otherwise the old behavior still applies.
To define which languages you want to include localizations for you can use /localizations=1033,1030 which would include  english and danish translations as in the previous screenshot.


Calls to other Java plugins

Calling other Java plugins (e.g. WorldGuard) will be needed sooner or later. Needs a replacement for Package.getPackage(), and some work to generate types for the desired plugins.

Actually this was already done. Forgot to close...


Cache request improvements

IMPORTANT WIP 🙏
Model weights at full speed 🚀 I think this is a great differentiator over monolithic gguf

[ ] closes https://github.com/mlc-ai/web-llm/issues/280
[ ] closes https://github.com/mlc-ai/web-llm/issues/289

https://github.com/mlc-ai/relax/assets/414967/9e6998f3-7ef8-4c4a-b15e-c1a4c420fff1
@CharlieFRuan @tqchen
Loader Logger must be changed to report once the file is downloaded and not in advance.

This is great, really appreciate the changes! Could you make a PR to TVM's main branch instead? We can review there!

This is great, really appreciate the changes! Could you make a PR to TVM's main branch instead? We can review there!

Of course!
I need to clone https://github.com/apache/tvm right? At what point is it going to be merged and deprecate this one?

Yep, it's that repo! It will be picked to this relax repo soon once it's merged there.