Add possibility to check if string is a valid int/long/boolean/etc

I thought it may be worth considering to add several methods that verify if the given string is a valid int/long/etc. On multiple occasions, I wrote something like this: Try(s.toInt).isSuccess which is more than inconvenient and suboptimal.

I don't know if its really worth to add it
I can add docs and tests once general idea is accepted
I didn't know if this should go to collections or collections-contrib

In general, I will be happy to apply any changes needed, just let me know.

TBH I don't think this deserves a place in the standard library. There are lots of things that "would be nice" to have, but we should place the bar much higher than "nice to have", or we're going to end up again with zillions of stuff nobody uses like scala.text.

On the one hand, I agree, its always nice to have the minimal amount of code, but on the other hand...
I can see 3 main pain points of adding something to std lib:

maintenance cost - someone has tao do bugfixes
complexity cost - "product is perfect if there is no more to remove"
evolution slowdown - std lib release cycle is not so fast as ecosystem libraries

With this PR there is no maintenance cost because the amount of code is extremely samll and I cannot imagine how it could change. Even if the parsing logic changes these helpers will stay the same. The same applies to evolution slowdown - this code will not require any evolution.
Regarding complexity cost, I think its compensated by the frequency of usage. These SO questions: link1, link2, link3, link4 have over 70 thousands views together. And that's only from people who didn't know the answer by heart - I googled it once but used dozens of times after that.
So I have to argue that the chance of these being classified as "stuff nobody uses" is rather small.

Given the fact that the implementation of these is to actually convert them, and see if it worked, it's not clear to me what the major use case is. Presumably you actually want the value out of the string in most cases, in which case using these methods just ends up converting the string twice.

Its hard for me to come with particular use case as its been a while since I needed it, but something like this seems probable:
str match {
  case a if a.isInt =>
  case a if a.isLong =>
  case a if a.isDouble =>
  case a if a.isBoolean =>
  case a =>
}

And even if you parse it n times readability increases.

You can do something like:
object IntishString {
  def unapply(str: String): Option[Int] = Try(str.toInt).toOption
}
/* ... */
str match {
  case IntishString(intval) => /* ... */
  /* ... */
}

for that use case, which I think is somewhat more idiomatic and avoids double-parsing. I'd agree with Sébastien that these are a bit niche for the stdlib; having .toInt return Option[Int] would be a different (and more justifiable IMHO) change, but I recall there being a discussion some time back with good arguments against that, as well.

You really don't want to use try/catch to detect numbers in strings.  It's incredibly slow (like 500x slower than inspecting the characters).

having .toInt return Option[Int] would be a different (and more justifiable IMHO) change, but I recall there being a discussion some time back with good arguments against that, as well.

I would love to see that discussion, if anyone knows where it is. I also think being able to get Options would be very helpful.

I don't remember where the discussion was, but having toInt return Option would break all code everywhere that uses toInt, and, unless an extra unsafeToInt method was created, impose an unavoidable major performance decrease.
Adding methods that return an option, like toIntOption, are much more feasible.

Oh, I absolutely understand why changing its behaviour would break everything. Having other methods (or using an implicit to say whether it returns an Option or not?) was what I was thinking of.

I support adding toIntOption and others!

I see we've got discussion here:)
Reg, custom extractors, sure user can do that as well as many other things, its mostly matter of convenience.
I think modifying the behaviour of toInt is not an option, not only because it breaks everything but also it will increase learning curve for people coming from exception-based languages...
I was considering toIntOption at some point but abandoned the idea for some reason. Anyway, it looks like a really good alternative to isInt, a little more boilerplate (toIntOption.isDefined) but much more general. Moreover, there are precedences for similar implementations like headOption so it will be quite uniform.
If there will be no cons of toIntOption I can implement that.

The concern is, as @Ichoran mentioned, that using Try to convert toInt to an Option is very expensive for failure cases.

I was thinking about less trivial implementation. Try based was ok for this PR but for something as generic as Option I can try to make it more performant.

Check out https://github.com/mdedetrich/scalajson/issues/37 and related code.

this is https://github.com/scala/bug/issues/16 (yup, a double-digit bug number)

Semantically, Try(_).toOption is simple, straightforward, and accomplishes the goal well, and can also be easily wrapped up in a simple method like opt, as mentioned in scala/bug#16. And that actually works fine for cases where it's used infrequently. However, if you're parsing thousands of JSON requests per second, and a lot of them have invalid numbers, the exception construction will become a major cost.
scala/bug#16 doesn't really address the cost of exceptions, and I think it is legitimate to want an implementation which returns Options with reasonable cost.

If you want to be sure it's an Int, you're doing the same work as parsing, and could just as well return the success in an Option. In addition, the edge cases of numeric characters that are not 0-9 are a bit tricky, and having toInt and isInt disagree is really bad. Risking those getting out of sync for no real gain isn't a good idea.
To only option for a safe and fast isInt with accepts the same strings as toInt that makes sense is IMO to hand-roll a toIntOption and use that instead.

Let me know if following is correct:
Currently almost all the conversions are based on Java implementations like java.lang.Float.parseFloat. This leaves us with 3 options:

Try(f).toOption -  least efficient because of exception catching and intermediate object creation.
`try{ Some(f) } catch { case e => None } - still not perfect because of exceptions
Reimplement parsing(probably copy from java) so we can parametrize the way in which result is returned

Point 3 made me ask myself a question "how is this handled in scala-js and scala-native" and as far as I can see both of these projects implement java.lang from scratch. In the best case, we can see how it's done but it doesn't help much.
Anyway, I implemented very basic benchmark here. Its probably highly inaccurate, but may give some intuition anyway. Here are the results:
Benchmark                                  Mode  Cnt          Score          Error  Units
OptionBenchmark.checkWithReturn            thrpt<PHONE_NUMBER>03.054 ± 12354118.434  ops/s
OptionBenchmark.checkWithTry               thrpt<PHONE_NUMBER>01.113 ± 27783534.402  ops/s
OptionBenchmark.checkWithTryCatch          thrpt<PHONE_NUMBER>74.313 ± 27883958.369  ops/s

So according to this benchmark reimplementation gives us 2.5x speedup. Should we try to do that?

It's difficult to benchmark exceptions, because creation and unwinding depends on the stack depth. Benchmarking the "random" case isn't ideal either IMO. Separately benching the success and failure cases is IMO much better.
The reimplementation and benchmarks I did can be found at https://github.com/martijnhoekstra/numparsers/blob/master/src/main/scala/StringConversions.scala and an abbreviated benchmark result overview at https://docs.google.com/spreadsheets/d/1TohVfP_KDkEvVV2fvRMXYvSYTYNkntpkGdP-NSVcikg/edit#gid=0
The short of it is that parsing to Option from reimplementation takes roughly the same amount of time as .toInt and friends.
I still believe these reimplementations show reasonable performance, while handling the edge cases the same as toInt. I haven't taken a close look at the reimplementations scalajs or scalanative provide, so they could be better replacements. I also haven't reimplemented floating point, because I don't think I can get those right.

For reference, this is a good blog post about the costs of exceptions: https://shipilev.net/blog/2014/exceptional-performance/

Borrowing scala-native or scala-js's implementations (and possibly tweaking them to return Options) sounds like a decent, low-cost solution.

Borrowing from Scala.js (resp. Scala Native) is not possible, because the implementations of those functions rely on primitive JS (resp. C) functions.

production system brought to its knees by the expensiveness of Try(x.toInt).toOption: https://medium.com/@muuki88/follow-the-stacktraces-jvm-performance-profiling-3c371d323e5f

I'd forgotten about this until that blog post jogged my memory, but in 2011 I sped up a major component of a production system 10x simply by replacing exception-catching number-parsing code with hand-rolled code that handled the commonest cases directly. (To my own astonishment at the time at how big the speedup was.) It really is a performance trap.

So as far I understand there is a consensus on having toXOption. I have pushed an update to this branch. Trusting @sjrd comment I decided to go the simplest path and copy the code from java implementation of those methods. This is almost 1:1 copy as I don't have much time to work on it. We can use it for further discussion on how to proceed with it.

Should these methods be implemented in StringOps or in Int/Byte/etc.
I couldn't find any comprehensive test suite in the current codebase
Does current deduplication implementation have some performance implications? Should we go with full duplication of methods?
I have not copied Float/Double as they seem to be much more complicated. It should be a rather straightforward copy as well but with much more code.
Can we just copy the code from legal PoV?
Can we improve something in java impl?
Should we do some benchmarks to spot any potential performance regression?
I had some import troubles that I didn't have time to investigate.

If someone wants to pick this up and we want to keep the discussion record I can give full access to my fork to anyone.

I decided to go the simplest path and copy the code from java implementation of those methods

can we legally do that?

No. The Java implem is GPL and Scala's codebase is BSD.
I said there was nothing to be copied in Scala.js' or Scala Native's implem. I most definitely did not say you should copy it from Java's implementation instead.

@sjrd's is replying to a comment of mine I posted and then immediately deleted, realizing I was just repeating Krever's "Can we just copy the code from legal PoV" question

@sjrd I never claimed you said that :) I just assumed is the easiest way to go. I'm not a lawyer but even now this code is not literally copied. It was translated from java to scala, I introduced parameterized result handling and other changes so its far from a direct copy. Also if it helps I can admit under oath that I manually retyped every character and only took inspiration from java impl. Also, I don't think its in the state in which it could be considered ready for merge, so I think we can postpone this aspect of discussion.

Unfortunately, that's not how the GPL works. Even "taking inspiration" and "retyping every character" is considered a derivative work, and must therefore be released under the GPL as well.
In general, the only safe assumption is not to even look at any GPL code when contributing to a BSD- or MIT-licensed codebase, such as Scala. Any reimplementation must be completely clean-room.

@Krever - That isn't good enough either.  You have to do a clean reimplementation.  Typing the code over again, in a different language, with a few changes to the API is practically the definition of a "derivative work", and the GPL covers all derivative works (that is practically the point of the GPL).
You can find BSD-or-compatible-licensed implementations of integer parsing in ScalaJSON https://github.com/mdedetrich/scalajson, and in Jsonal in my "KSE" library, among other places.

My mistake, I did some research and this, in fact, seems to be derivative work. I still think there is no way to prove it once the refactoring is completed, but probably the way in which it was created still make it derivative work. Maybe I will find some time to rewrite this or use BSD-compatible implementation, but cant say for sure.
Still, if anyone has any comments regarding how this should be implemented its probably a good moment for it.

I removed the copyrighted code to take away the risk of being accused of inspiring by it. Signatures and implementation of derived parsers are my work completely.

@Krever - Three other comments.  (1) Unless you have benchmarked your code to be faster than the built-in exception-throwing flavor, you should not change from the original versions of toInt etc.; (2) You are going to pay a significant runtime penalty for the generic => T forms.  For code that can be incredibly performance-critical like this, code duplication is fine if it speeds things up.  (3) Parsing of floating-point numbers cannot fail so long as the number has the right form.  So you can just check that it's well-formed and defer to the exception-throwing version if it is.

@Krever I bet you didn't expect this might turn out to be so complicated :-)

I've looked at the implementations in scala-native, and the implementations of Long.parseLong, Integer.parseInt, Short.parseShort and Byte.parseByte seem pretty portable (though those for Double.parseDouble and Float.parseFloat do not).

Note that those implementations currently suffer from a bug in
Character.digit, but that wouldn't bother the JVM implementation that has
the correct behavior
On Sun, Mar 18, 2018, 07:13 Nth<EMAIL_ADDRESS>wrote:

I've looked at the implementations in scala-native, and the
implementations of Long.parseLong
https://github.com/scala-native/scala-native/blob/v0.3.6/javalib/src/main/scala/java/lang/Long.scala#L303-L348,
Integer.parseInt
https://github.com/scala-native/scala-native/blob/v0.3.6/javalib/src/main/scala/java/lang/Integer.scala#L289-L336,
Short.parseShort
https://github.com/scala-native/scala-native/blob/v0.3.6/javalib/src/main/scala/java/lang/Short.scala#L211-L217
and Byte.parseByte
https://github.com/scala-native/scala-native/blob/v0.3.6/javalib/src/main/scala/java/lang/Byte.scala#L211-L217
seem pretty portable (though those for Double.parseDouble and
Float.parseFloat do not).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/scala/collection-strawman/pull/431#issuecomment-373975542,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA13EWid8D2c6vzGyxWE9o2a6sDNQsE3ks5tffr7gaJpZM4R9Oig
.

I've changed the issue title to reflect the move away from returning Boolean as originally suggested.

https://github.com/scala/scala/pull/6538 follows up on this

I wish I had more time for this, but I'm extremely happy that someone picked this up. Thanks @martijnhoekstra !


[BUG] state dict loading issue when running an example in https://github.com/huggingface/transformers-bloom-inference/tree/main/bloom-inference-scripts#run

Describe the bug
see the following error message when running the example in https://github.com/huggingface/transformers-bloom-inference/tree/main/bloom-inference-scripts#run
deepspeed --num_gpus 8 bloom-inference-scripts/bloom-ds-inference.py --name microsoft/bloom-deepspeed-inference-fp16
│ /opt/conda/lib/python3.8/site-packages/deepspeed/inference/engine.py:388 in _load_checkpoint     │
│                                                                                │
│   385 │   │   else:                                                                              │
│   386 │   │   │   mp_rank = 0 if self.mpu is None else self.mpu.get_model_parallel_rank()        │
│   387 │   │   │                                                                                │
│ ❱ 388 │   │   │   load_path, checkpoint, quantize_config = sd_loader.load(self._config.tensor_   │
│   389 │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   mp_rank,               │
│   390 │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   is_pipe_parallel=is_   │
│   391 │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   │   quantize=(self._conf   │
╰──────────────────────────────────────────────────────────────────────────────────────────────────╯
AttributeError: 'dict' object has no attribute 'load'

To Reproduce
Steps to reproduce the behavior:

switch kernel_inject to False in https://github.com/huggingface/transformers-bloom-inference/blob/7bea3526d8270b4aeeefecc57d7d7d638e2bbe0e/bloom-inference-scripts/bloom-ds-inference.py#L122
run deepspeed --num_gpus 8 bloom-inference-scripts/bloom-ds-inference.py --name microsoft/bloom-deepspeed-inference-fp16 in  https://github.com/huggingface/transformers-bloom-inference/tree/main/bloom-inference-scripts

Docker context
rocm/pytorch:latest
Additional context
Running on ROCm, but this issue shouldn't be hardware-dependent. According to https://github.com/microsoft/DeepSpeed/blob/5f5cc82415b11ab2c9bf85969deb510fe8631446/deepspeed/inference/engine.py#L433 and https://github.com/microsoft/DeepSpeed/blob/5f5cc82415b11ab2c9bf85969deb510fe8631446/deepspeed/runtime/state_dict_factory.py#L37, sd_loader is a dict and has no load method.

@jeffra, would you please look at this issue? Thank you.

Hi @liligwu - following up on this issue, are you still hitting this?

Hi @loadams , It has been a while. Please give me some time to confirm if the issue persists.

Thanks @liligwu - no rush, just wanted to make sure if this needed reviews and completing that we would get this merged in, or otherwise closed.  Thanks again!

Hi @liligwu - following up on this, if you've had time to look at this.

@liligwu - closing this for now - if you have updates on this, please comment and we will re-open it.  Or if anyone else has a similar issue and sees this, please open a new issue and link this one and we would be happy to take a look.


Add JUnit tests for AddTaskCommand and AddTaskCommandParser classes

Codecov Report

Merging #249 (1ac7288) into master (3083bef) will increase coverage by 3.29%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #249      +/-   ##
============================================
+ Coverage     25.70%   29.00%   +3.29%
- Complexity      351      403      +52
============================================
  Files           160      160
  Lines          3186     3186
  Branches        413      413
============================================
+ Hits            819      924     +105
+ Misses         2329     2214     -115
- Partials         38       48      +10

Impacted Files
Coverage Δ

...in/java/seedu/address/logic/parser/ParserUtil.java
39.82% <0.00%> (+8.84%)
:arrow_up:

...c/main/java/seedu/address/model/module/Module.java
22.95% <0.00%> (+22.95%)
:arrow_up:

src/main/java/seedu/address/model/task/Task.java
33.33% <0.00%> (+33.33%)
:arrow_up:

...main/java/seedu/address/model/task/TaskStatus.java
52.94% <0.00%> (+52.94%)
:arrow_up:

...in/java/seedu/address/model/module/ModuleCode.java
60.00% <0.00%> (+60.00%)
:arrow_up:

...java/seedu/address/model/task/TaskDescription.java
72.72% <0.00%> (+72.72%)
:arrow_up:

...a/seedu/address/logic/commands/AddTaskCommand.java
100.00% <0.00%> (+100.00%)
:arrow_up:

...edu/address/logic/parser/AddTaskCommandParser.java
100.00% <0.00%> (+100.00%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


R.allPass strange behavior with missing parameters of a function inside the conditions

Hi,
Just found this weird behavior and thought it would help raising the issue:
const subject = [1, 2, 3];

filter(
  allPass([
    equals(1),
    propSatisfies
  ]),
  subject
 )

When passing propSatisfies with missing parameters, the whole condition gets evaluated to true, always.
The output for the snippet above is [1, 2, 3] instead of [1].
See repro: https://ramdajs.com/repl/?v=0.27.0#?const subject %3D [1%2C 2%2C 3]%3B

filter(
  allPass([
    equals(1)%2C
    propSatisfies
  ])%2C
  subject
 )
Sorry is if this is the expected, just found this in my session of functional drafting.

Hi @crash7 ,
I believe this is the expected behaviour...
In the above snippet R.propSatisfies gets called with only 1 argument, due to its curried nature this leads to the output of a new function. Under the hood happens something similar to:
if (propSatisfies(1)) {
  return true;
}

and, inside conditions, functions evaluate to true.

You might eventually expect propSatisfies to throw if its first argument isn't a function,
however, Ramda doesn't make any assumption if their api isn't consumed correctly...

Hi @hitmands,
Yes, I agree 100% with:

Ramda doesn't make any assumption if their api isn't consumed correctly.

But here is the interesting thing: when doing that, allPass behaves like all of the conditions were true, not filtering the array at all, but if I use another function:
const subject = [1, 2, 3];

filter(
  allPass([
    equals(1),
    always
  ]),
  subject
 )

It filters the array correctly.
Feels like is more a side-effect of curry, since this appears to happen with all the curried functions only.

You're right,
I'd expect b to match b1 in this example:
REPL

This is an expected side effect of how allPass determines the length of the function it returns.
From allPass docs:

The function returned is a curried function whose arity matches that of the highest-arity predicate.

always.length is 1, so allPass returns a function that takes 1 parameter. Then filter passes in 1 parameter, and thus allPass returns a result (even though always returns a function, because allPass is returning it can still work based on the equals(1)).
propSatisfies.length is 3, so allPass returns a function that takes 3 parameters. When filter calls that function with 1 parameter, it gets back a function of 2 parameters. Since any function is truthy, filter will return all results.

Thanks clarification @Bradcomp! Closing this as I agree this is a expected side-effect.
Thanks all!


Try Laravel UI with Auth

It finally needs to use Webpack 5.

Try Laravel build without laravel-mix (with webpack4).


Reverting a microoptimization.

Next function can be micro-optimized to (c & 0x30) == 0x30

Digits are 0x30..0x39, not sure how 0x3A..0x3F would get rejected.
as long as you're thinking about this... the swar check is doing too much work.
uint64_t is_eight_digits(uint64_t val){
  return !((((val + 0x4646464646464646) | (val - 0x3030303030303030)) &
     0x8080808080808080));
}

val - 0x3030303030303030 is also needed immediately after the check anyways (replaces val & 0x0F0F0F0F0F0F0F0F).
In parse_eight_digits_unrolled, I've been wondering if running the two imul instructions in parallel is worth it or not.
It costs a couple of instructions but reduces latency.
uint64_t parse_eight_digits(uint64_t val){
  const uint64_t mask = 0x000000FF000000FF;
  const uint64_t mul1 = 0x000F424000000064; // 100 + (1000000ULL << 32)
  const uint64_t mul2 = 0x0000271000000001; // 1 + (10000ULL << 32)

  val -= 0x3030303030303030;
  val = (val * 10) + (val >> 8); // val = (val * 2561) >> 8;
  val = (((val & mask) * mul1) + (((val >> 16) & mask) * mul2)) >> 32;
  return val;
}

@aqrit I'll merge this PR, after removing the possibly misleading comment, and then I will turn your comment into an issue.


Support for Text Styles: Bold, Italic, Underline

Hello @Hopding ,
I can't express how much I love this lib, although from time to time I bump into some obstacles when I try to achieve some basic things. Now it's the font styles. As far as I know there's no easy way to achieve bold, italic, nor underlined texts with this lib.
In theory I could load up a bold version of the font if I want to have bold. Also, I could load up an italic version if I want to have italic. But what if I want to have both of them at the same time? There's usually no "combined" versions, so I'd have to create my own. Even then, if someone wants to combine those things (eg.: bold-italic, italic-underlined, bold-italic-underlined, etc), we'd need to load 2^3 = 8 ttf files altogether for a single font-family, which is crazy.
I'm pretty sure there's a better way to do this. Ideally, we could pass some boolean arguments within the drawText's options object, and it would just work as it should.
I'd gladly take a deeper look, and try to come up with a PR, but first I just wanted to ask your opinion. And maybe if you could give me a direction of where I should start, that would be very helpful.
Thanks,
Peter

There is a workaround for bold and italic
Many fonts do have bold and italic versions of itself. You can generate a new font of this version and update the appearance.

Create the fonts you need

    pdfDoc.registerFontkit(fontkit);
    const fontBytes = fs.readFileSync(__dirname + "/MuseoSans-300.otf");
    const fontBytesBold = fs.readFileSync(__dirname + "/MuseoSans-900.otf");
    const font = await pdfDoc.embedFont(fontBytes);
    const fontBold = await pdfDoc.embedFont(fontBytesBold)

Update the appearance of all acro form text fields to get the default font
(this step is optional, but I want to share it, because it was hard to figure out and is not documented)

    const fields = form.getFields();
    fields.forEach((field) => {
      const type = field.constructor.name;
      const name = field.getName();
      console.log(`${type}`);
      if (type === "PDFTextField")
        form.getTextField(name).updateAppearances(font);
    })

Update the fields you want to styles with styled fonts

    form.getTextField("Fahrzeugnettopreis").updateAppearances(fontBold);

@tw1t611 Thanks for your ideas, although I believe I was already aware of such workarounds. But they're really not convenient/efficient. What do you do if you want to have bold AND italic fonts? See the second paragraph in my OP, starting with In theory I could load up...

@soadzoor You are right. It really only is a workaround for people how need bold or italic. I just wanted to share a solution, for I couldn't fine one in the docs. The problem itself remains. Sadly I am not very experienced with pdf.
This is something the devs would need to implement.
Personally I would add something like makeBold(), makeItalic(angle)... methods to TextField.
Page 10 of the specs show the options:

https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf
I could imagine, this would not be hard to implement. @Hopding seems to be inactive since January though and its hard to contact him.

@soadzoor I agree. Would definitely like to improve support for this type of thing. I need to spend some time researching options to figure out the best way to handle this. It's listed in the roadmap for tracking purposes https://github.com/Hopding/pdf-lib/discussions/998.

Is there an example for this in the docs? This issue is not linked to an MR and the roadmap just links back to the issue.

Sorry I read “closed as completed” thinking it was implemented.

@Hopding Is underline implemented? The issue is marked as completed but I cant find any option to do so.
For bold and italic the font needs to be change, I guess this is okay.

@MickL Underline is NOT generally a PDF construct it needs to be emulated one way or another

A font.ttf especially constructed by adding a line into the font or an especially unusual UTF emulation encoding like https://yaytext.com/underline/ these will be found in HTML files but exceptionally rare for a PDF.
A word processor draws a line across/under a text selection and that is exceptionally easy to do with PDF as you draw a graphic line from before A to after B but how to raise or lower the line is usually done in a GUI

I know it needs to be done manually. But without underline most usecases for PDFs like invoices are not possible and therefor the whole library is kinda useless innit?
Unfortunately I needed to switch back to pdfkit who does has an underline feature.


Wrong message "ambiguity between X and X" (which are the same)

Type: Bug
I'm working on a C# project for a while now and starting today, I repeatedly get the error that something would not be okay with my code. The message on the red underlined code tranlates as "Ambiguity between "MyClass.MyProperty" and "MyClass.MyProperty"". That class and property exists exactly once and shows no issue itself. The message is invalid. Rebuilding the code (Ctrl+Shift+B) does not resolve the error. Reloading the window does resolve it.
I can't show you the code. It's too much in its entirety and even just loading it would not reproduce, you have to actually edit it a lot to see the problem. You never know when it's going to happen. But I've had this 2 or 3 times within the last hour in different places. I assume you have your own projects to try this. My project type is .NET 7 for the Web SDK, but it's only a Web API, so no dangerous* file types like Razor, JavaScript or HTML. (* causing loads of problems on their own)
Somehow the source code analyser gets confused with an increasing size of code. It's already slightly overwhelmed with small code, when it shows errors that are not really there. Making any change to the document, or even just saving it to disk (Ctrl+S) immediately resolve such errors or warnings. It looks like the analyser is making a decision what messages to show, while I'm editing my code again (pressing another key) and then ignores my latest edit while it was busy. But only the last input resolved the warnings (previous text was incomplete, leading to the warnings/errors). It cannot keep up with normal typing speed.
It gets more and more annoying to see this code editor making so many errors. I think I'm switching back to Visual Studio as it turned out I'll have it available in this project.
Extension version: 1.25.2
VS Code version: Code 1.74.3 (97dec172d3256f8ca4bfb2143f3f76b503ca0534, 2023-01-09T16:59:02.252Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (8 x 3400)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
undefined

Memory (System)
15.71GB (5.92GB free)

Process Argv
--crash-reporter-id 1b00a758-578c-4b77-a258-fe145c18e004

Screen Reader
no

VM
29%

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
vscorecescf:30445987
pythondataviewer:30285071
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vsclangdf:30486550
c4g48928:30535728
dsvsc012cf:30540253
azure-dev_surveyone:30548225
pyindex848:30577860
nodejswelcome1cf:30587006
2e4cg342:30602488
pyind779cf:30647092
89544117:30613380
fim-prod:30623723

Possible steps to reproduce: (not tried, just describing what I did immediately before the error appeared again)

Create a class with a field and a constructor, assigning the field in the constructor (e.g. a service with an injected ILogger)
Create a new empty .cs file
In the new file, type the empty definition of a new class
Copy the field and constructor from the first class into the second file (now the constructor name is wrong)
Manually correct the constructor method name to the second class name

The field cannot be used in the second class because the code analyser is confused and still thinks that we're in the old class. The field name would be defined twice which is nonsense. After reloading the window, the problem disappears.

I am also encountering this issue, with the NCalc Library - specifically the EvaluateFunction event in the Expression class.
Diff for some code to peek at: https://github.com/kd8lvt/RimWorld-Math/commit/89070c59d8c6a156df8bf22f631692289bf14b1e#diff-249900a5f6507cd777e5382e9f42e7f28d62c512261bb4cedc1abaee8ed0d8f6
And NCalc's Expression class: https://github.com/ncalc/ncalc/blob/master/src/NCalc/Expression.cs

In my case this issue occurs when I open a razor pages project, the .cshtml gives me this errors "Ambiguity between X and X filea...

I also have this error for .razor files in a Blazor Server project. I can't use the C# DevKit (since I am working on a commercial project) so I have "Prefer C# Extension" checked. When I check "Use Omnisharp" and reload VS Code the error is gone, but Omnisharp has its problems with razor files (like missing autocomplete for properties and methods).
Is there anything I could provide to narrow down the cause of the problem?

interesting, I also have the problem where Go to definition does not work sometimes but I don't use any of the other framreworks mentioned there or in #6426 , instead I am using ASP.NET Core default DI framework.

@Kampfmoehre @tannmatter Indeed that issue would be a duplicate of #6426. It'll impact any use of an API that's using source generators, and Razor can be one of those in some scenarios. As best I can tell it's unrelated to the original conversation though.

Upvoting and also hoping this get resolved (can't believe this issue has been open for one year considering it's impact on editing any Razor pages).
And I also wonder why installing the closed-sourced C# Dev Kit resolved this issue. Can C# Dev Kit impact how Rosyln works?

A lot has changed with O# code analysis since this issue was opened. If you are still having problems, please open a new issue at https://github.com/omnisharp/omnisharp-roslyn/issues


Add schema update scripts for new columns to repo

Describe the Enhancement
Adding the most recent update scripts to the repo
Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
NONE
Define the Metadata
Assignee

[ ] Select engineer(s) or no engineer required
[ ] Select scientist(s) or no scientist required

Labels

[ ] Select component(s)
[ ] Select priority
[ ] Select requestor(s)

Projects and Milestone

[ ] Select Repository and/or Organization level Project(s) or add alert: NEED CYCLE ASSIGNMENT label
[ ] Select Milestone as the next official version or Future Versions

Define Related Issue(s)
Consider the impact to the other METplus components.

[ ] METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy

Enhancement Checklist
See the METplus Workflow for details.

[ ] Complete the issue definition above, including the Time Estimate and Funding Source.
[ ] Fork this repository or create a branch of develop.
Branch name: feature_<Issue Number>_<Description>
[ ] Complete the development and test your changes.
[ ] Add/update log messages for easier debugging.
[ ] Add/update unit tests.
[ ] Add/update documentation.
[ ] Push local changes to GitHub.
[ ] Submit a pull request to merge into develop.
Pull request: feature <Issue Number> <Description>
[ ] Define the pull request metadata, as permissions allow.
Select: Reviewer(s) and Development issues

Select: Repository level development cycle Project for the next official release
Select: Milestone as the next official version

[ ] Iterate until the reviewer(s) accept and merge your changes.
[ ] Delete your fork or branch.
[ ] Close this issue.

Closed by PR 209


[QUESTION] How to get array of request params

Thanks for great library.
My controller accepts request from client with format like this and it worked very well.
{
  "name": "John",
  "profile": {
    "age": 12
  }
}

My controller:
public async create(@BodyParams() user: User): any {
  console.log(user);
  return null;
}

But now, I want to receive array of user from client with json format is:
[
  {
    "name": "John",
    "profile": {
      "age": 12
    }
  },
  {
    "name": "Harry",
    "profile": {
      "age": 20
    }
  }
]

So that's why I changed my controller to (ref from doc: https://tsed.io/docs/controllers.html#request)
public async create(@BodyParams() users: User[]): any {
  console.log(users);
  return null;
}

But I always get this error:
{
    "message": "Conversion failed for class \"Array\" with object => [xxxx].\nCannot read property 'deserialize' of undefined"
}

This is my model
export class User {
  @IsNotEmpty()
  public name: string;
  @IsNotEmptyObject()
  public profile: object;

  public constructor(name: string, profile: object) {
    this.name = name;
    this.profile = profile;
  }

  public someFunctionHere() {
  }
}

Any help is welcome, thanks in advance!

Hello @Romakita
try this:
public async create(@BodyParams(User) users: User[]): any { // we need to give the baseType because typescript only set the Array as metadata type
  console.log(users);
  return null;
}

@Romakita Thanks for quick response.
I have tried with create(@BodyParams(User) users: User[]) but without success.
I even tried with:
public async create(@BodyParams("users", User) users: User[]): any { // we need to give the baseType because typescript only set the Array as metadata type
  console.log(users);
  return null;
}

{

  "users": [
    {
      "name": "John",
      "profile": {
        "age": 12
      }
    },
    {
      "name": "Harry",
      "profile": {
        "age": 20
      }
    }
  ]
}

My tsed version is 5.31.3

Ok I'll check the issue

Hello @TranBaVinhSon
I created a PR with more unit test: https://github.com/TypedProject/tsed/pull/846/files
The travis is Ok. So the BodyParams work as expected (in my context). It means, the problem is probably related on your server configuration (I also tried with your ts.ed version. Same result).
The error is weird.
    "message": "Conversion failed for class \"Array\" with object => [xxxx].\nCannot read property 'deserialize' of undefined"

It means the ArrayConverter loaded by Ts.ED is not defined. Have you the same version for all @tsed package? Have you tried to upgrade your Ts.ED version?
If the problem persist, maybe we can try to share screen in private session :) (gitter, slask or hangout).
See you
Romain

@Romakita Thank you so much for you work!
https://github.com/TypedProject/tsed/issues/748#issuecomment-643631463

@Romakita Thank you so much for your work!
I tested with the latest version of TsED, it seems to work well. But my current version on production is 5.31.3 so I tried with that version but got another error:
https://github.com/TypedProject/tsed/issues/748#issuecomment-643631463
I created a sample here. Please help me by taking a look at code
https://github.com/TranBaVinhSon/prometheus_express/tree/master/prometheus_tsed

Yep I seen your problem. There no solution excepted to upgrade tsed packages to higher version :/

[start:build] src/middlewares/ErrorHandlerMiddleware.ts(2,27): error TS2307: Cannot find module 'ts-httpexceptions'.
[start:build] src/middlewares/LogRequestMiddleware.ts(20,10): error TS2425: Class 'LogIncomingRequestMiddleware' defines instance member property '$onResponse', but extended class 'LogRequestMiddleware' defines it as instance member function.

@Romakita When I upgraded tsed from 5.31.3 to 5.57.5 (the newest version), I got many errors. I will try to fix all of them !

@Romakita Upgrading version seems like take a lot of time because I have to fix many things. So is there any way that I can still use 5.31.3 version ?
/node_modules/@tsed/core/lib/class/ProxyMap.d.ts:93:9 - error TS1086: An accessor cannot be declared in an ambient context.
93     get size(): number;
           ~~~~
/node_modules/@tsed/core/lib/class/Store.d.ts:17:9 - error TS1086: An accessor cannot be declared in an ambient context.
17     get size(): number;
           ~~~~
/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:41:9 - error TS1086: An accessor cannot be declared in an ambient context.
41     get target(): Type<any>;
           ~~~~~~
/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:46:9 - error TS1086: An accessor cannot be declared in an ambient context.
46     set target(target: Type<any>);
           ~~~~~~
/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:51:9 - error TS1086: An accessor cannot be declared in an ambient context.

51     get targetName(): string;
           ~~~~~~~~~~

/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:56:9 - error TS1086: An accessor cannot be declared in an ambient context.

56     get type(): Type<any>;
           ~~~~

/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:61:9 - error TS1086: An accessor cannot be declared in an ambient context.

61     set type(value: Type<any>);
           ~~~~

/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:66:9 - error TS1086: An accessor cannot be declared in an ambient context.

66     get typeName(): string;
           ~~~~~~~~

/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:71:9 - error TS1086: An accessor cannot be declared in an ambient context.

71     get collectionName(): string;
           ~~~~~~~~~~~~~~

/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:76:9 - error TS1086: An accessor cannot be declared in an ambient context.

76     get isCollection(): boolean;
           ~~~~~~~~~~~~

/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:81:9 - error TS1086: An accessor cannot be declared in an ambient context.

81     get isArray(): boolean;
           ~~~~~~~

/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:86:9 - error TS1086: An accessor cannot be declared in an ambient context.

86     get isPrimitive(): boolean;
           ~~~~~~~~~~~

/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:91:9 - error TS1086: An accessor cannot be declared in an ambient context.

91     get isDate(): boolean;
           ~~~~~~

/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:96:9 - error TS1086: An accessor cannot be declared in an ambient context.

96     get isObject(): boolean;
           ~~~~~~~~

/node_modules/@tsed/core/lib/class/EntityDescription.d.ts:101:9 - error TS1086: An accessor cannot be declared in an ambient context.

101     get isClass(): boolean;
            ~~~~~~~

/node_modules/@tsed/core/lib/class/Storable.d.ts:14:9 - error TS1086: An accessor cannot be declared in an ambient context.

14     get store(): Store;
           ~~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:22:9 - error TS1086: An accessor cannot be declared in an ambient context.

22     get token(): any;
           ~~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:23:9 - error TS1086: An accessor cannot be declared in an ambient context.

23     get provide(): TokenProvider;
           ~~~~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:24:9 - error TS1086: An accessor cannot be declared in an ambient context.

24     set provide(value: TokenProvider);
           ~~~~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:25:9 - error TS1086: An accessor cannot be declared in an ambient context.

25     get useClass(): Type<T>;
           ~~~~~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:30:9 - error TS1086: An accessor cannot be declared in an ambient context.

30     set useClass(value: Type<T>);
           ~~~~~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:31:9 - error TS1086: An accessor cannot be declared in an ambient context.

31     get className(): string;
           ~~~~~~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:32:9 - error TS1086: An accessor cannot be declared in an ambient context.

32     get name(): string;
           ~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:33:9 - error TS1086: An accessor cannot be declared in an ambient context.

33     get store(): Store;
           ~~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:43:9 - error TS1086: An accessor cannot be declared in an ambient context.

43     get scope(): ProviderScope;
           ~~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:48:9 - error TS1086: An accessor cannot be declared in an ambient context.

48     set scope(scope: ProviderScope);
           ~~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:49:9 - error TS1086: An accessor cannot be declared in an ambient context.

49     get configuration(): Partial<TsED.Configuration>;
           ~~~~~~~~~~~~~

/node_modules/@tsed/di/lib/class/Provider.d.ts:50:9 - error TS1086: An accessor cannot be declared in an ambient context.

50     set configuration(configuration: Partial<TsED.Configuration>);
           ~~~~~~~~~~~~~

/node_modules/@tsed/di/lib/services/DIConfiguration.d.ts:7:9 - error TS1086: An accessor cannot be declared in an ambient context.

7     get scopes(): {
          ~~~~~~

/node_modules/@tsed/di/lib/services/DIConfiguration.d.ts:10:9 - error TS1086: An accessor cannot be declared in an ambient context.

10     set scopes(value: {
           ~~~~~~

/node_modules/@tsed/di/lib/services/DIConfiguration.d.ts:13:9 - error TS1086: An accessor cannot be declared in an ambient context.

13     get resolvers(): IDIResolver[];
           ~~~~~~~~~

/node_modules/@tsed/di/lib/services/DIConfiguration.d.ts:14:9 - error TS1086: An accessor cannot be declared in an ambient context.

14     set resolvers(resolvers: IDIResolver[]);
           ~~~~~~~~~

/node_modules/@tsed/di/lib/services/DIConfiguration.d.ts:15:9 - error TS1086: An accessor cannot be declared in an ambient context.

15     get imports(): TokenProvider[];
           ~~~~~~~

/node_modules/@tsed/di/lib/services/DIConfiguration.d.ts:16:9 - error TS1086: An accessor cannot be declared in an ambient context.

16     set imports(imports: TokenProvider[]);
           ~~~~~~~

/node_modules/@tsed/di/lib/services/InjectorService.d.ts:32:9 - error TS1086: An accessor cannot be declared in an ambient context.

32     get resolvers(): import("../interfaces").IDIResolver[];
           ~~~~~~~~~

/node_modules/@tsed/di/lib/services/InjectorService.d.ts:33:9 - error TS1086: An accessor cannot be declared in an ambient context.

33     get scopes(): {
           ~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:12:9 - error TS1086: An accessor cannot be declared in an ambient context.

12     get version(): string;
           ~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:13:9 - error TS1086: An accessor cannot be declared in an ambient context.

13     set version(v: string);
           ~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:14:9 - error TS1086: An accessor cannot be declared in an ambient context.

14     get rootDir(): string;
           ~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:15:9 - error TS1086: An accessor cannot be declared in an ambient context.

15     set rootDir(value: string);
           ~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:16:9 - error TS1086: An accessor cannot be declared in an ambient context.

16     get port(): string | number | false;
           ~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:17:9 - error TS1086: An accessor cannot be declared in an ambient context.

17     set port(value: string | number | false);
           ~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:18:9 - error TS1086: An accessor cannot be declared in an ambient context.

18     get httpsOptions(): Https.ServerOptions;
           ~~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:19:9 - error TS1086: An accessor cannot be declared in an ambient context.

19     set httpsOptions(value: Https.ServerOptions);
           ~~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:20:9 - error TS1086: An accessor cannot be declared in an ambient context.

20     get httpPort(): string | number | false;
           ~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:21:9 - error TS1086: An accessor cannot be declared in an ambient context.

21     set httpPort(value: string | number | false);
           ~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:22:9 - error TS1086: An accessor cannot be declared in an ambient context.

22     get httpsPort(): string | number | false;
           ~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:23:9 - error TS1086: An accessor cannot be declared in an ambient context.

23     set httpsPort(value: string | number | false);
           ~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:24:9 - error TS1086: An accessor cannot be declared in an ambient context.

24     get uploadDir(): string;
           ~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:25:9 - error TS1086: An accessor cannot be declared in an ambient context.

25     set uploadDir(value: string);
           ~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:26:9 - error TS1086: An accessor cannot be declared in an ambient context.

26     get env(): Env;
           ~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:27:9 - error TS1086: An accessor cannot be declared in an ambient context.

27     set env(value: Env);
           ~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:28:9 - error TS1086: An accessor cannot be declared in an ambient context.

28     get mount(): IServerMountDirectories;
           ~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:29:9 - error TS1086: An accessor cannot be declared in an ambient context.

29     set mount(value: IServerMountDirectories);
           ~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:30:9 - error TS1086: An accessor cannot be declared in an ambient context.

30     get componentsScan(): string[];
           ~~~~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:31:9 - error TS1086: An accessor cannot be declared in an ambient context.

31     set componentsScan(value: string[]);
           ~~~~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:32:9 - error TS1086: An accessor cannot be declared in an ambient context.

32     get statics(): IServerMountDirectories;
           ~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:33:9 - error TS1086: An accessor cannot be declared in an ambient context.

33     set statics(value: IServerMountDirectories);
           ~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:37:9 - error TS1086: An accessor cannot be declared in an ambient context.

37     get serveStatics(): IServerMountDirectories;
           ~~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:41:9 - error TS1086: An accessor cannot be declared in an ambient context.

41     set serveStatics(value: IServerMountDirectories);
           ~~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:42:9 - error TS1086: An accessor cannot be declared in an ambient context.

42     get acceptMimes(): string[];
           ~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:43:9 - error TS1086: An accessor cannot be declared in an ambient context.

43     set acceptMimes(value: string[]);
           ~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:44:9 - error TS1086: An accessor cannot be declared in an ambient context.

44     get debug(): boolean;
           ~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:45:9 - error TS1086: An accessor cannot be declared in an ambient context.

45     set debug(debug: boolean);
           ~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:46:9 - error TS1086: An accessor cannot be declared in an ambient context.

46     get routers(): IRouterSettings;
           ~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:47:9 - error TS1086: An accessor cannot be declared in an ambient context.

47     set routers(options: IRouterSettings);
           ~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:51:9 - error TS1086: An accessor cannot be declared in an ambient context.

51     get validationModelStrict(): boolean;
           ~~~~~~~~~~~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:55:9 - error TS1086: An accessor cannot be declared in an ambient context.

55     set validationModelStrict(value: boolean);
           ~~~~~~~~~~~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:56:9 - error TS1086: An accessor cannot be declared in an ambient context.

56     get converter(): Partial<IConverterSettings>;
           ~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:57:9 - error TS1086: An accessor cannot be declared in an ambient context.

57     set converter(options: Partial<IConverterSettings>);
           ~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:58:9 - error TS1086: An accessor cannot be declared in an ambient context.

58     get logger(): Partial<ILoggerSettings>;
           ~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:59:9 - error TS1086: An accessor cannot be declared in an ambient context.

59     set logger(value: Partial<ILoggerSettings>);
           ~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:60:9 - error TS1086: An accessor cannot be declared in an ambient context.

60     get exclude(): string[];
           ~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:61:9 - error TS1086: An accessor cannot be declared in an ambient context.

61     set exclude(exclude: string[]);
           ~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:65:9 - error TS1086: An accessor cannot be declared in an ambient context.

65     get controllerScope(): ProviderScope;
           ~~~~~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:69:9 - error TS1086: An accessor cannot be declared in an ambient context.

69     set controllerScope(scope: ProviderScope);
           ~~~~~~~~~~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:74:9 - error TS1086: An accessor cannot be declared in an ambient context.

74     get errors(): IErrorsSettings;
           ~~~~~~

/node_modules/@tsed/common/lib/config/services/ServerSettingsService.d.ts:79:9 - error TS1086: An accessor cannot be declared in an ambient context.

79     set errors(options: IErrorsSettings);
           ~~~~~~

/node_modules/@tsed/common/lib/jsonschema/class/JsonSchema.d.ts:65:9 - error TS1086: An accessor cannot be declared in an ambient context.

65     get mapper(): JSONSchema6;
           ~~~~~~

/node_modules/@tsed/common/lib/jsonschema/class/JsonSchema.d.ts:70:9 - error TS1086: An accessor cannot be declared in an ambient context.

70     get type(): any | JSONSchema6TypeName | JSONSchema6TypeName[];
           ~~~~

/node_modules/@tsed/common/lib/jsonschema/class/JsonSchema.d.ts:75:9 - error TS1086: An accessor cannot be declared in an ambient context.

75     set type(value: any | JSONSchema6TypeName | JSONSchema6TypeName[]);
           ~~~~

/node_modules/@tsed/common/lib/jsonschema/class/JsonSchema.d.ts:80:9 - error TS1086: An accessor cannot be declared in an ambient context.

80     get refName(): string;
           ~~~~~~~

/node_modules/@tsed/common/lib/jsonschema/class/JsonSchema.d.ts:85:9 - error TS1086: An accessor cannot be declared in an ambient context.

85     get isCollection(): boolean;
           ~~~~~~~~~~~~

/node_modules/@tsed/common/lib/jsonschema/class/JsonSchema.d.ts:90:9 - error TS1086: An accessor cannot be declared in an ambient context.

90     get isArray(): boolean;
           ~~~~~~~

/node_modules/@tsed/common/lib/jsonschema/class/JsonSchema.d.ts:95:9 - error TS1086: An accessor cannot be declared in an ambient context.

95     get schemaType(): "collection" | JSONSchema6TypeName | JSONSchema6TypeName[];
           ~~~~~~~~~~

/node_modules/@tsed/common/lib/jsonschema/class/PropertyMetadata.d.ts:18:9 - error TS1086: An accessor cannot be declared in an ambient context.

18     get type(): Type<any>;
           ~~~~

/node_modules/@tsed/common/lib/jsonschema/class/PropertyMetadata.d.ts:23:9 - error TS1086: An accessor cannot be declared in an ambient context.

23     set type(value: Type<any>);
           ~~~~

/node_modules/@tsed/common/lib/jsonschema/class/PropertyMetadata.d.ts:28:9 - error TS1086: An accessor cannot be declared in an ambient context.

28     get schema(): JsonSchema;
           ~~~~~~

/node_modules/@tsed/common/lib/jsonschema/class/PropertyMetadata.d.ts:33:9 - error TS1086: An accessor cannot be declared in an ambient context.

33     get required(): boolean;
           ~~~~~~~~

/node_modules/@tsed/common/lib/jsonschema/class/PropertyMetadata.d.ts:38:9 - error TS1086: An accessor cannot be declared in an ambient context.

38     set required(value: boolean);
           ~~~~~~~~

/node_modules/@tsed/common/lib/mvc/models/ParamMetadata.d.ts:33:9 - error TS1086: An accessor cannot be declared in an ambient context.

33     get service(): string | Type<any> | ParamTypes;
           ~~~~~~~

/node_modules/@tsed/common/lib/mvc/models/ParamMetadata.d.ts:34:9 - error TS1086: An accessor cannot be declared in an ambient context.

34     set service(service: string | Type<any> | ParamTypes);
           ~~~~~~~

/node_modules/@tsed/common/lib/mvc/models/EndpointMetadata.d.ts:47:9 - error TS1086: An accessor cannot be declared in an ambient context.

47     get type(): Type<any>;
           ~~~~

/node_modules/@tsed/common/lib/mvc/models/EndpointMetadata.d.ts:48:9 - error TS1086: An accessor cannot be declared in an ambient context.

48     set type(type: Type<any>);
           ~~~~

/node_modules/@tsed/common/lib/mvc/models/EndpointMetadata.d.ts:52:9 - error TS1086: An accessor cannot be declared in an ambient context.

52     get methodClassName(): string;
           ~~~~~~~~~~~~~~~

/node_modules/@tsed/common/lib/mvc/models/EndpointMetadata.d.ts:57:9 - error TS1086: An accessor cannot be declared in an ambient context.

57     get store(): Store;
           ~~~~~

/node_modules/@tsed/common/lib/mvc/models/EndpointMetadata.d.ts:58:9 - error TS1086: An accessor cannot be declared in an ambient context.

58     get params(): import("./ParamMetadata").ParamMetadata[];
           ~~~~~~

/node_modules/@tsed/common/lib/mvc/models/EndpointMetadata.d.ts:59:9 - error TS1086: An accessor cannot be declared in an ambient context.

59     get response(): IResponseOptions;
           ~~~~~~~~

/node_modules/@tsed/common/lib/mvc/models/HandlerMetadata.d.ts:28:9 - error TS1086: An accessor cannot be declared in an ambient context.

28     get parameters(): ParamMetadata[];
           ~~~~~~~~~~

/node_modules/@tsed/common/lib/platform/domain/ControllerProvider.d.ts:26:9 - error TS1086: An accessor cannot be declared in an ambient context.

26     get endpoints(): EndpointMetadata[];
           ~~~~~~~~~

/node_modules/@tsed/common/lib/platform/domain/ControllerProvider.d.ts:31:9 - error TS1086: An accessor cannot be declared in an ambient context.

31     get children(): IChildrenController[];
           ~~~~~~~~

/node_modules/@tsed/common/lib/platform/domain/ControllerProvider.d.ts:36:9 - error TS1086: An accessor cannot be declared in an ambient context.

36     set children(children: IChildrenController[]);
           ~~~~~~~~

/node_modules/@tsed/common/lib/platform/domain/ControllerProvider.d.ts:41:9 - error TS1086: An accessor cannot be declared in an ambient context.
41     get routerOptions(): IRouterSettings;
           ~~~~~~~~~~~~~
/node_modules/@tsed/common/lib/platform/domain/ControllerProvider.d.ts:46:9 - error TS1086: An accessor cannot be declared in an ambient context.
46     set routerOptions(value: IRouterSettings);
           ~~~~~~~~~~~~~
/node_modules/@tsed/common/lib/platform/domain/ControllerProvider.d.ts:51:9 - error TS1086: An accessor cannot be declared in an ambient context.
51     get parent(): any;
           ~~~~~~
/node_modules/@tsed/common/lib/platform/domain/ControllerProvider.d.ts:56:9 - error TS1086: An accessor cannot be declared in an ambient context.
56     get middlewares(): IControllerMiddlewares;
           ~~~~~~~~~~~
/node_modules/@tsed/common/lib/platform/domain/ControllerProvider.d.ts:61:9 - error TS1086: An accessor cannot be declared in an ambient context.
61     set middlewares(middlewares: IControllerMiddlewares);
           ~~~~~~~~~~~
/node_modules/@tsed/common/lib/platform/domain/HandlerContext.d.ts:14:9 - error TS1086: An accessor cannot be declared in an ambient context.
14     get isDone(): boolean;
           ~~~~~~
/node_modules/@tsed/common/lib/platform/domain/HandlerContext.d.ts:15:9 - error TS1086: An accessor cannot be declared in an ambient context.
15     get container(): import("@tsed/di").LocalsContainer<any>;
           ~~~~~~~~~
/node_modules/@tsed/common/lib/platform/services/Platform.d.ts:16:9 - error TS1086: An accessor cannot be declared in an ambient context.
16     get app(): PlatformApplication;
           ~~~
/node_modules/@tsed/common/lib/platform/services/Platform.d.ts:17:9 - error TS1086: An accessor cannot be declared in an ambient context.
17     get routes(): IRouteController[];
           ~~~~~~
/node_modules/@tsed/common/lib/platform/services/RouteService.d.ts:11:9 - error TS1086: An accessor cannot be declared in an ambient context.
11     get routes(): IRouteController[];
           ~~~~~~
/node_modules/@tsed/common/lib/platform-builder/builder/PlatformBuilder.d.ts:8:9 - error TS1086: An accessor cannot be declared in an ambient context.
8     get injector(): InjectorService;
          ~~~~~~~~
/node_modules/@tsed/common/lib/platform-builder/builder/PlatformBuilder.d.ts:9:9 - error TS1086: An accessor cannot be declared in an ambient context.
9     get rootModule(): any;
          ~~~~~~~~~~
/node_modules/@tsed/common/lib/platform-builder/builder/PlatformBuilder.d.ts:10:9 - error TS1086: An accessor cannot be declared in an ambient context.
10     get app(): PlatformApplication;
           ~~~
/node_modules/@tsed/common/lib/platform-builder/builder/PlatformBuilder.d.ts:11:9 - error TS1086: An accessor cannot be declared in an ambient context.
11     get platform(): Platform;
           ~~~~~~~~
/node_modules/@tsed/common/lib/platform-builder/builder/PlatformBuilder.d.ts:33:9 - error TS1086: An accessor cannot be declared in an ambient context.
33     get settings(): TsED.Configuration & import("@tsed/di").DIConfiguration;
           ~~~~~~~~
/node_modules/@tsed/common/lib/platform-builder/builder/PlatformBuilder.d.ts:34:9 - error TS1086: An accessor cannot be declared in an ambient context.
34     get logger(): import("@tsed/di").IDILogger;
           ~~~~~~
/node_modules/@tsed/common/lib/platform-express/components/ServerLoader.d.ts:61:9 - error TS1086: An accessor cannot be declared in an ambient context.
61     get expressApp(): Express.Application;
           ~~~~~~~~~~
/node_modules/@tsed/common/lib/platform-express/components/ServerLoader.d.ts:67:9 - error TS1086: An accessor cannot be declared in an ambient context.
67     get injectorService(): InjectorService;
           ~~~~~~~~~~~~~~~
/node_modules/@tsed/common/lib/platform-express/components/ServerLoader.d.ts:72:9 - error TS1086: An accessor cannot be declared in an ambient context.
72     get httpServer(): Http.Server;
           ~~~~~~~~~~
/node_modules/@tsed/common/lib/platform-express/components/ServerLoader.d.ts:77:9 - error TS1086: An accessor cannot be declared in an ambient context.
77     get httpsServer(): Https.Server;
           ~~~~~~~~~~~
/node_modules/@tsed/common/lib/platform-test/components/PlatformTest.d.ts:12:16 - error TS1086: An accessor cannot be declared in an ambient context.
12     static get injector(): InjectorService;
                  ~~~~~~~~
/node_modules/@tsed/typeorm/lib/services/TypeORMService.d.ts:15:9 - error TS1086: An accessor cannot be declared in an ambient context.
15     get instances(): ConnectionManager;
           ~~~~~~~~~
Found 124 errors.

Have you upgraded all @tsed dependencies at the time ? Because this errors is clearly related to wrong package version.

Or maybe you have to upgrade your TypeScript version also :)

I think it will help someone if I write down what's a problem I faced:

First, my version of TsED (all dependencies) is 5.31.3, and I can't get an array from request params by @BodyParams(). And my index.ts looked like this:

import { Server } from "./Server";

new Server()
  .start()
  .then((): void => {
    console.log("Start server...");
  })
  .catch((err): void => {
  });

So I tried to upgrade TsED to newest version 5.57.5, but it seems like I need to change many files so it would be better to leave upgrade version for later and focus on get an array from request params
Then, I upgraded to 5.43.0 and changed my index.ts by using ServerLoader.bootstrap(Server)instead of Sever().start().

import { ServerLoader } from "@tsed/common";
import { Server } from "./Server";

async function bootstrap(): Promise<void> {
  try {
    console.log("Start server...");
    const server = await ServerLoader.bootstrap(Server);

    await server.listen();
    console.log("Server initialized");
  } catch (err) {
  }
}

bootstrap();

And I finally can get an array from request params but I see this bellow error in my terminal ?

{"url":"/__webpack_hmr/client","method":"GET","id":"41d5bf2d-5a44-4e77-a63b-16f251dabdca","error":"NOT_ACCEPTABLE: You must accept content-type application/json\n at GlobalAcceptMimesMiddleware

This is my Server.ts file. I don't see any problem with acceptMimes.
import { ServerLoader, ServerSettings, GlobalAcceptMimesMiddleware } from "@tsed/common";
import "reflect-metadata";
import dotenv from "dotenv";
import cookieParser = require("cookie-parser");
import bodyParser = require("body-parser");
import compress = require("compression");
import methodOverride = require("method-override");
import Prometheus from "prom-client";

import "./middlewares/ErrorHandlerMiddleware";
import "./middlewares/LogRequestMiddleware";
import "./middlewares/MetricsMiddleware";
import config from "./config";
export const rootDir = __dirname;

@ServerSettings({
  rootDir,
  acceptMimes: ["application/json"],
  httpPort: config.httpPort,
  httpsPort: false,
  // config typeorm
  typeorm: [
    {
    },
  ],
  // config swagger
  swagger: [
    {
      path: "/api-docs/v1",
      doc: "api-v1",
      showExplorer: true, // display search bar
    },
  ],
  // mount controller + routing
  mount: {
    "/api/v1": `${rootDir}/controllers/v1/*.ts`,
    "/healthz": `${rootDir}/controllers/healthcheck/*.ts`,
    "/metrics": `${rootDir}/controllers/metrics/*.ts`,
  },
})
export class Server extends ServerLoader {
  /**
   * This method let you configure the express middleware required by your application to works.
   * @returns {Server}
   */

  public $beforeRoutesInit(): void | Promise<any> {
    dotenv.config();
    this.use(GlobalAcceptMimesMiddleware)
      .use(cookieParser())
      .use(compress({}))
      .use(methodOverride());
    Prometheus.collectDefaultMetrics();
    return null;
  }

  public $afterInit(): void | Promise<any> {
    this.use(bodyParser.json({ limit: "100mb" })).use(
      bodyParser.urlencoded({
        extended: true,
        limit: "100mb",
      }),
    );
  }
}

What should I do now ?
Thanks in advance! @Romakita

Try npm dedup to be sure that is no twice version of @tsed/common resolved by npm. This error indicated that.

@Romakita
Yeah npm dedup solved testing problem but I still got an errorr about content-type when start server

{"url":"/__webpack_hmr/client","method":"GET","id":"41d5bf2d-5a44-4e77-a63b-16f251dabdca","error":"NOT_ACCEPTABLE: You must accept content-type application/json\n at GlobalAcceptMimesMiddleware

I changed $onResponse function of my custom LogMiddleware class which extends from LogIncomingRequestMiddleware of @tsed/common. Is this any problem about middleware ?
  public $onResponse = (request: any, response: any): void => {
    this.onLogEnd(request, response);
  };

  /**
   * The separate onLogStart() function will allow developer to overwrite the initial request log.
   * @param {e.Request} request
   */
  protected onLogStart(request: any): any {
    const info = this.requestToObject(request);
    const api = request.url.split("/");
    Logger.info("request.start", info);
  }

  /**
   * Called when the `$onResponse` is called by Ts.ED (through Express.end).
   * @param request
   * @param response
   */
  protected onLogEnd(request: any, response: any): any {
    const info = this.requestToObject(request);
    const api = info.url.split("/");
    info.status = response.statusCode;
    info.body = request.ctx.data;
    Logger.info("request.end", info);
  }

Your error is about GlobalAcceptMimesMiddleware. The content-type doesn’t satisfy you acceptMimes configuration.
Have overrided this middleware? If you comment this middleware, the error occurs?
There no issue or change on middleware feature. But you use an old version. There is 26 features + many fixes between your version and latest version so maybe something is wrong with your version and your code. I remember, I changed the logincomingrequest implementation. It could explain your problem. Overridle this middleware could be problematique ^^.
Tell me if your problem continue. We can plan a short hangout session ;)

@Romakita
I don't know why but when I upgrade to 5.43.0 (not the newest version 5.57.5), every few seconds these requests come to my server (on localhost). And I think these requests are the cause of "error":"NOT_ACCEPTABLE: You must accept content-type application/json\n at GlobalAcceptMimesMiddleware
Unnecessary requests:

[start:run] {"reqId":"845caee8-94b3-4926-a57f-3686ae0e7cf1","method":"GET","url":"/__webpack_hmr/client","duration":4,"params":"client","level":"info","message":"request.start"}

[start:run] {"reqId":"1804cae3-2c26-42d9-8010-6aaaa839a26b","method":"GET","url":"/_loading/sse","duration":15,"level":"info","message":"request.start"}

Apparently, this is your wepback front end app the responsible. The hot reload module try to reach the webpack dev server. Is not related to Ts.Ed version :)

Yeah, thanks for your response. Everything is working well now.
So about my primary problem about can get an array of request params. Upgrade to a newer version can help.
Again, thanks for your support!

Your welcome :)


Revise concept & reference docs for Services, Ingress & networking

Overall PR (changes have been split out).
Individual PRs:

#37385
#36668
#36669
#36670
#36671
#36672
#36673
#36675
#37386
#37442
#38054
#38055
#38561
#38562
#38563
#39499
#40227
#40671

The effect of this PR, overall:

Revise Services documentation [preview]

migrate reference details out of Concepts section
drop some vendor-specific details that don't fit well with our content guide
write “primary” in place of “master”
general tidying

Move Connecting Applications with Services (to tutorials section)
favor EndpointSlices over Endpoints
Reorganize the Services, Load Balancing, and Networking section

and add page descriptions [preview]

Remove enabling Service Topology
Update https://k8s.io/docs/concepts/policy/ to link to the NetworkPolicy docs

/language en
/label refactor
/sig network
Helps with https://github.com/kubernetes/website/issues/14770

May help with https://github.com/kubernetes/website/issues/32013

In service.md file under #services-in-kubernetes, wondering if micro-service term should be included. What about the abstraction? Isn't it just one piece of a service? A text suggestion:
In Kubernetes, a Service employs an abstraction which defines a logical set of Pods and a policy by which to access these pods.

Suggest a simple diagram in service.md under Services or services in Kubernetes. An example showing K8s-service running inside a cluster with frontend and backend pods.

live editor link

@chrismetz09 this PR is already bigger than it should be. With that in mind, I'm happy to see a diagram added but I recommend that we save it for a follow up PR.
If there's a case that merging this PR improves on the existing documentation, and there's no factual inaccuracies or other grounds not to merge it, I'd like it to go through with as few changes as possible from how the PR looks right now.
I can't make that case (I'm the author) but I do hope that somebody else can.

@sftim, SGTM. we can save new stuff for a future PR.

Folks, this is ready for another review.

/hold
I'd love to get some reviews, but I'm also wary of landing a big change before the v1.24 release. I'd unhold this provided that either:

v1.24 is released
the SIG Release docs team are happy to see this unheld

@kubernetes/sig-network-pr-reviews - does this set of changes improve on the existing docs without adding new technical inaccuracies?

v1.24 is out
/hold cancel

@kubernetes/sig-network-pr-reviews - does this set of changes improve on the existing docs without adding new technical inaccuracies?

👋 @sftim. Are the changes ready for review?

Ach, no. I do need to work on this more.

https://github.com/kubernetes/website/pull/30817#discussion_r873835990 is the point I still want to address. Then we can either merge this as-is, or I can try to carve out subsets of the changes from this and make smaller PRs that sum to the same outcome.

Ready for another review.
I recommend fresh and critical eyes on the last commit (an update to favor EndpointSlice). The previous commits have already been reviewed and I think are mostly OK. The EndpointSlice changes include some untested assumptions that I will call out in new comments.
This is a big PR and adding the EndpointSlice update to it only made it bigger. I do ask that reviews focus on whether or not there are:

any factual errors being added
any important details being removed that should by necessity be retained
other similar grounds for not merging this change - there might be some

If this PR makes the docs overall a bit better, and doesn't make them obviously worse, we can merge it and iterate. At least, I hope we can.

How am I supposed to review a PR that changes 30+ files (+1066 -1146 lines changes) without a clear hint where this is leading us to?

How am I supposed to review a PR that changes 30+ files (+1066 -1146 lines changes) without a clear hint where this is leading us to?

If I were reviewing this, I would:

look at the list of changed pages and compare the preview to the live site

as I have a dedicated monitor, I'll open both pages side-by-side in different GUI windows, to make comparison easier

decide if the new pages, in their entirety, look right
look for obvious slips, such as:

moving a page but not configuring the right redirect
typos and spelling mistakes
deleting a page but not explaining why in the PR description and commit message
broken hyperlinks

Most of the way I'd review a larger change like this is to think “what if this were a new writeup, would it be good enough”
and then also consider two related questions:

are there regressions from the existing docs

this is shared between the tech reviewers and SIG Docs. I look for each heading in the old doc and check to see if it is covered

if people have bookmarked existing pages, are we considerate of their user experience

In terms of intent, I hoped to capture all of that in the PR description. I'm happy to explain more if there are questions.
This is a big PR. It is a lot of work to review; if I split it into  (say) 10 smaller PRs, there will still be a lot of changes to review an, I suspect, a similar amount of overall review effort. I think this is reviewable, although that would take time and folks might need to plan in a slot to go through all the changes.

How's this looking? Folks that reviewed previously, please:

mark existing feedback as resolved, or
comment that you're happy, or
add new comment as a reminder that there's something we must fix before this can merge

I'm really concerned about the size and the scope of this PR. As it turned out, this PR is NOT a simple refactoring. It is a huge collection of disruptive changes to the website. It is NOT well planned or organized. The PR touches 30+ files for different reasons. Some sections are migrated, and some files are completely removed. We are NOT supposed to merge a huge change like this, despite the author is an experienced tech writer and member of the SIG Docs leadership team. We appreciate all heroic efforts that solve a big problem and we appreciate long term contribution to the community. It is up to the author to decide how to split this PR into smaller ones that are self-contained. The bottom line is that this PR cannot be merged as is. It is inappropriate and it is setting a really bad example for other contributors.
/hold

I split out several PRs from this one. If / when some of those have merged, I can rebase this PR against main to only retain the changes that still need to be included.

/retitle Revise concept & reference docs for Services, Ingress & networking

@chrismetz09 we're getting to a point where you might be able to open an issue, or PR, along the lines of https://github.com/kubernetes/website/pull/30817#issuecomment-1075444357

Hey Tim, whenever you've some free cycles please consider rebasing :) Thank you!

Helps with https://github.com/kubernetes/website/issues/39641

Also see https://github.com/kubernetes/website/issues/41173

/remove-label refactor

All split out PRs have merged or been superseded.
/close


Globed PC bugfixes & Android support

Hi dankmeme01! As I said from the title, yes you're right! PC bugfixes and android support with different versions of the mod! So here is the thing, call someone who use globed mod or supporter (or your friends) and join them to android playtester room on discord (or any DM apps u use). Then, it will help you to config the code, servers, versions etc.
But first, let's talk about versions!
V1.1.5 (PC): fixing bugs, servers, crashes, or any other bug fix...
Lastly...
V1.2.0: Android support! Added new features! Fixing bugs, etc..
That's for now.. did you get it? Challenge accepted? Well your question..
Qausar (From Malaysia)
Period.

Yeah close enough... No android releases, it's already 1.2.1


Update ssf.txt

Minor update to Polygonet Commanders and two example screencaps for README

Not sure if the captions are properly worded.
Can redo/adjust them as needed.
Would it be better to do screencaps showing the method currently mentioned in the README?

Go ahead and remove the images. I'm working on improving the readme. I can merge in the ssf.txt changes though. Also working on setting default values as you discussed.

I think I deleted the images and added some more updates for ssf.txt. :man_shrugging:
- LMK if I messed it up.
I imported ssf.txt into Excel, sorted by value, and added a column so I can keep track of what has been checked/changed and any problems loading games.
- I'm using a Frankenstein'd ROMset so some games won't work.
- Once the list of untested high-value games gets a bit longer, I'll probably post it in the BYOAC thread and ask for help.
The line that I deleted (bbprot) is an unplayable prototype.
So far, I've only found three games that I'm having trouble testing.
bosco - Don't have the right ROM.
blitz and blitz99 - Don't have the CHDs.


"Bad Image" error

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.

What problem did you encounter?
when attempting to play roblox alongside bloxstrap I was met with a "bad image" error. Could not launch or even uninstall bloxstrap so I had to find it within its file location and purge it. Can play roblox normally now but when attempting to launch anything bloxstrap related I am met with "C:\Program Files\dotnet\host\fxr\6.0.40\hostfxr.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support. Error status 0xc000012f.". My friend believed it was windows .NET framework and after numerous attempts at reinstalling and running command prompts to no avail. I really have no idea what the issue is and would appreciate some insight on how to fix this.

Are you sure you tried reinstalling the correct version? https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-6.0.30-windows-x64-installer?cid=getdotnetcore

Are you sure you tried reinstalling the correct version? https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-6.0.30-windows-x64-installer?cid=getdotnetcore

man i need to ask my friend about what he recommended and why it didn't work because i swear it was similar.
bottom line is i uninstalled then reinstalled what you provided and it is repaired now 🤠thanks!


Original Filename

Previously with Types.S3File the database also stored originalname, however this doesn't seem to be possible anymore. It would be nice to be able to continue doing this.
It's documented with the keystone File field type here, but there it says that the adapter can override these fields, so I assume it's this breaking it? If not, happy to close this and re-open against keystone itself.

@jstockwin not sure why that's not working, if you've got the schema set up to store the original filename it should do so, if there's a bug in there I don't think it is adapter specific but would need to do more testing to confirm.

@JedWatson I think maybe I'm missing something. Previously I didn't need to add anything to the schema, the originalname was just stored automatically... Do I now need to add an option to make this happen?

@jstockwin see the storage docs, I've just added a clarification on which schema paths are enabled by default. The change from originalname always being stored is something we need to note in the update guide when explaining how to update from LocalFile / S3File fields.

Alright, thanks for the clarification.


Add Carl-Miele-Berufskolleg für Technik

Carl-Miele-Berufskolleg für Technik
Domains:
cmb-gt.de
carl-miele-berufskolleg.de
Website:
https://cmb-gt.de
IT related courses offered by the school:
https://cmb-gt.de/bildungsangebot/
Proof of domain ownership:
https://cmb-gt.de/kontakt/
https://cmb-gt.de/wp-content/uploads/2023/08/Lehrerliste.pdf

@Lavandea First stage of verification passed, official domain is cmb-gt.de as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision. Proof of domain ownership: https://cmb-gt.de/wp-content/uploads/2015/12/Höhere-Berufsfachschule-Elektrotechnik-AUT-2015-12-14.pdf

@Lavandea Thank you for your patience while waiting for a review and processing your request. Pull request merged.


Add feature to suppress range-diff on /submit

This change intorduces support for a new pull request description
footer:
version-diff: no
This will bypass generation of the range-diff between patch versions.
The range-diff output will be replaced with instructions for
generating it locally.  The users of this feature should comment if
the range-diff is not relevant.
Random bits

choice of version-diff is trying to look at this from a user perspective
readme description could be expanded (usual developer lack of doc)
tests need to be developed.  Testing was done using webstech/gggmonitored repo.
change does not include mail-patch-series support using getFromTag.

Issue #1024 was the impetus for this.  @dscho suggested manual and code to decide.  This provides a manual implementation that can override future automation (bad) decisions.

Thanks for the review.

I am not a TypeScript user, but thanks to both of you! 👍


type/format not suitable to generate the original Java types

If you use the swagger api doc generated by springfox to generate a (feign-) client using swagger-code-gen, some of the generated types in the client does not match the original types. Since this leads to parse errors, you cannot use the spec for client generation. The following types hurt my case (there may be more):
BigInteger currently results in "type":"number", "format":"double", which gives you a Double in the generated code. It should be ``"type": "string", "format": "number"in order to generateBigInteger`.
byte[] currently results in "type":"array", "items":{ "type":"string", "format":"byte" } , which gives you a List<byte[]> in the generated code. It should be "type": "string", "format": "byte" in order to generate byte[]. (Spring internally converts the byte array to base64 encoded string, which is the preferred way to transport binary in json)
LocalDate currently results in "type":"string", "format":"date-time", which gives you a OffsetDateTime in the generated code. It should be "type": "string","format": "date" in order to generate LocalDate.
Map<String, Object> currently results in "type":"object", which gives you a Object in the generated code. It should be "type": "object", "additionalProperties": {"type": "object"} in order to generate Map<String, Object>.

Its not designed to reflect the same types over the wire.

 If you cannot generate a working client from the swagger spec, what is the point? I always expected swagger to be a valuable toolchain, not an academic idea.

I'm on with you, that it is out of scope to transport types over the wire, but the generated type/format should reflect the original language type. And at least using date-time for LocalDate is wrong, it is date.

And for good reason the swagger-code-gen guys use string/number for BigDecimal, since a Double cannot handle the arbitrary precision.

And Spring automagically converts a byte array (correctly) to a base64 encoded String, and due to the swagger spec the type/format of base 64 encoded String is string/byte, so this is also an issue.

So, I'm still on with you, that this' issues intention may be wrong, but the handling of LocalDate, BigDecimal and byte[] seems to be wrong, so I will open seperate issues for those, ok?

@ralfstuckert I responded to a couple of the new issues you created! There is room to improve for sure. Thanks for taking time to report the issues.

Since I've opened separate issues for the items above I am closing this one.

How to generate Long data type? Specifying type: number always ends up in BigDecimal.

where are you specifying type: number. Also if this is a new problem please open a new issue rather than commenting on closed issues


Netbox 2.0 API - no support for json_flat

After upgrading to version 2.0.x with the new API, it no longer supports the type json_flat. We use this format to sync the device and primary IP from Netbox in to Oxidized.
http://netbox/api/dcim/devices/?format=json_flat
{"detail":"Not found."}

This was a hack added a while back for reasons I don't entirely remember. We've ditched custom renderers entirely in the new API. Instead, you can either modify the API consumer to read regular (nested) JSON, or you can create an export template to generate data in whatever format you prefer. Here's an example:
{% for device in queryset %}{% if device.status == 1 and device.primary_ip %}{{ device.name }}:{{ device.device_type.manufacturer.slug}}
{% endif %}{% endfor %}

This will produce output like this:
abc-switch1:juniper
abc-switch2:juniper
xyz-switch1:cisco
...

OK. I'll need to bring this up with the Oxidized developer again to see if he will consider adding support for multi-tier json results.
The problem with Oxidized is that its JSON API is not able to read more than 1 level deep. Using the json_flat option allowed me to access the data set since its sometimes located 2 or more levels down. Since one maps the fields it receives from the returned information to a local variable, this functionality is lost.
    map:
      name: name
      ip: primary_ip4_address
      model: platform_slug
      group: tenant_slug

I did end up building a export template, which I used to manually get things up and running though but would prefer a more automated solution. I also don't want the template to necessary be available to all who use the system. I'll have to see what I can do to get around this.

Could you share the export template? I'm trying the same but can't get the template right. All my attempts result in a JSON::ParserError.


source build got a large exec file(Version: 1.6)

when i build from source,i got a 800+MB exec file,but i see it's only 44mb by install from yum(centos)

by yum ,ldd rippled
linux-vdso.so.1 =>  (0x00007ffe735c7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f912979c000)
librt.so.1 => /lib64/librt.so.1 (0x00007f9129594000)
libz.so.1 => /lib64/libz.so.1 (0x00007f912937e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f912917a000)
libm.so.6 => /lib64/libm.so.6 (0x00007f9128e78000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9128c62000)
libc.so.6 => /lib64/libc.so.6 (0x00007f9128894000)
/lib64/ld-linux-x86-64.so.2 (0x00007f91299b8000)
build self,
linux-vdso.so.1 =>  (0x00007fff1e933000)
libprotobuf.so.23 => not found
libboost_coroutine.so.1.70.0 => not found
libboost_filesystem.so.1.70.0 => not found
libboost_program_options.so.1.70.0 => not found
libboost_regex.so.1.70.0 => not found
libboost_thread.so.1.70.0 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007f3261183000)
librt.so.1 => /lib64/librt.so.1 (0x00007f3260f7b000)
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found
libz.so.1 => /lib64/libz.so.1 (0x00007f3260d65000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f3260a5e000)
libm.so.6 => /lib64/libm.so.6 (0x00007f326075c000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3260546000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f326032a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f325ff5c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3263d96000)

Maybe you did a debug build?

i commond cmake -DCMAKE_BUILD_TYPE= Release ..

I believe the default is to make a static build, which would explain this.

@maybeTomorrow: have you been able to produce a smaller binary file? If so, could we close this issue?


Similar Hash for Anonymous Functions

When i try the below code:
const hash = require("object-hash");
console.log(hash(function () {})); // Output: 4122c3af912b486962725f2aadb66af50ada646d
console.log(hash(function () {})); // Output: 4122c3af912b486962725f2aadb66af50ada646d

Outputs are same.

Right, the code uses .toString() to hash functions. What would your expected output be?
I don’t think object-hash has reliable means of turning object identity into hashable information, so even if you expect different hashes it might not be feasible to generate those. :/

I want to generate hash for functions to store them identically for example:
const exampleHash = require("example-hash");
let functionsContainer = {};

// This should be sample
function sample () {}
functionsContainer[ exampleHash(sample) ] = sample;
functionsContainer[ exampleHash(sample) ] = sample;

// This should be difference
let anon1 = function () {}
functionsContainer[ exampleHash(anon1 ) ] = anon1;
let anon2 = function () {}
functionsContainer[ exampleHash(anon2 ) ] = anon2;

Please visit the below address and check the "_wp_filter_build_unique_id" function.
https://github.com/WordPress/WordPress/blob/master/wp-includes/plugin.php#L874

Thanks. i get wrong. excuse me.

@EmpireWorld No problem. It would be possible to implement what Wordpress does there, but I’m really not sure how I’d feel about adding hidden properties to the function objects – if you think this is important, I can still look into it as an optional feature.

No there is no worry. i used the below answer:
http://stackoverflow.com/questions/1997661/unique-object-identifier-in-javascript


Fixes #604

Description of Change
Added configuration to the page, so it uses iOS "Safe Area" and the Slider moves up into an area where it can be moved horizontally.
Bugs Fixed

Fixes #604

Behavioral Changes
Now users on iOS devices that shows the "Home indicator" instead of having a home button, can move the Slider horizontally.
Before:

After:

PR Checklist

[ ] Has tests (if omitted, state reason in description)
[x] Has samples (if omitted, state reason in description)
[x] Rebased on top of main at time of PR
[x] Changes adhere to coding standard

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


feat: Initial changes for update to pydantic v2

Inital changes required for Pydantic v2 support, both hand updating + bump pydantic
Blockers

https://github.com/pydantic/pydantic/issues/6742

Causes test_openapi / test_properties to fail
Fix should be included in Pydantic v2.1.0

Currently 14 2 out of 449 tests are failing, all of which are due to the issue above.

Local tests seem to be mostly working, only tests failing are GeneratorErrors, since Error messages have changed since Pydantic V1.
So I went about a different approach to roughly match the content of the GeneratorError instead of exact match (Since the Pydantic version is included in GeneratorError.detail)

Did some minor fixes with missing default in Field & schema ordering. Running it on the project I'm using this tool for seems to work just fine as of this last commit!
Hoping someone else can test it as well to see if there's any issues I need to fix!

Thanks for this @KristinnVikar! Just wanted to drop a link to some thoughts I had written on another thread about the motivation for this change

https://github.com/openapi-generators/openapi-python-client/pull/776#issuecomment-1640252913


Browser history does not work sometimes

just noticed, it happens when I click in top navigation to show a collection, it does not "save" it into the browser history...

can't reproduce


Changing the layout of text and illustration on the Charts Wizard page

Description
Our design team asked us to change the layout of text and illustrations on the Chart Wizard page. We want to place the illustration above the text, and the text should be centered.
Motivation
Currently this design element is inconsistent throughout the service. On some pages the illustration is located above the text, and on others to the left of the text. So we want to unify it.
Before after
Before

After

What about connections and dashboard pages?

By the way, there is one more variant in QL: text under image, and image is smaller than in other similar pages

The empty states of workbooks and datasets are also horizontal

The same goes for error screens of dashboards

Hi,
We talked with Alexey and decided that he will discuss this issue about empty states in DataLens with Product Managers and then they will create the improvement task. The main idea is to make a common decision for all empty states in the project where there should be an image, title, and description. Also, he will check if they use an empty state component in the realization or not. From our side, we can push the changes on the Chart Wizard page and it will be enough for now.


Solution

Reference
A successful workflow execution can be viewed here:

Workflow Run: GitHub Actions Run #10971188470
Commit SHA: 60d9f3c1b58bbe2aff84ae1053d9f16deaf3c6c7

This conflict occurred because I forked the project quite a while ago, and I don’t have this block of code or tasks 15 and 16 in my assignment.


expose get_remote_static

HandshakeState has got a method called get_remote_static which isn't accessible from someone using this library because Session doesn't expose it. I think this should be exposed because protocol designs using Noise may well need to use this information for additional authentication steps. My use-case is well documented:
https://github.com/katzenpost/docs/blob/master/specs/wire-protocol.rst#handshake-authentication
Hopefully this sounds like a reasonable feature that you'd support. If so I can easily add the few lines this needs and submit a pull request.

Yep, this actually exists in my wireguard branch (for changes necessary to cleanly work on my wireguard implementation), but I'd happily take a clean PR for the master branch.

solved by @str4d in https://github.com/mcginty/snow/pull/13

Fixed :)