WTF Bites
-
@TimeBandit said in WTF Bites:
In winter they can be anywhere.
You mean, there's another season beside winter?
In real countries, yes.
-
it's just sitting on its ass for over 15 minutes
That's the right attitude
-
@TimeBandit said in WTF Bites:
In winter they can be anywhere.
You mean, there's another season beside winter?
You don't need to worry about that.
-
@Applied-Mediocrity I would classify MSFS as a simulator, because it makes bona fide attempt to simulate the actual physics. The previous incarnation was good enough that it was bought by Lockheed and certified for flight training, but I have no idea about the current one, which is a new development.
Well, considering that they even simulate the bending of the wings ...
https://www.youtube.com/watch?v=UtAF1I_H01w
Actual flight begins at 2:30
-
@Applied-Mediocrity said in WTF Bites:
Suppose my observation is somewhat valid I wonder how big is the "middle class" that expects reasonably accurate representation, but aren't overly concerned with every eddy and tidbit being simulated.
I don't think it's a lot. Unless you have a very in-depth knowledge of how airplanes work and feel, you're not going to notice much difference between a super-simplistic model from the 90s and a hardcore simulation.
-
I have a
webpack.config.tsthat returns 3 configs (one for client-side JS, one for web worker JS, one for server-side JS). If I runwebpack-clito compile these, it takes like 20 minutes.I wrote a script to fork 3 processes and compile each config in parallel, hoping to cut that down by 66.6% (at most). In practice, I shaved off about 95%, as it now takes about a minute to finish all three configs.
So what the fuck is
webpack-clidoing with its multi-config processing? I ran the ProfilerPlugin and it seriously looks like it's just sitting on its ass for over 15 minutes.Something's still fucky because, in watch mode, each consecutive recompile takes a bit longer than the one before it.
-
I have a
webpack.config.tsthat returns 3 configs (one for client-side JS, one for web worker JS, one for server-side JS). If I runwebpack-clito compile these, it takes like 20 minutes.I wrote a script to fork 3 processes and compile each config in parallel, hoping to cut that down by 66.6% (at most). In practice, I shaved off about 95%, as it now takes about a minute to finish all three configs.
So what the fuck is
webpack-clidoing with its multi-config processing? I ran the ProfilerPlugin and it seriously looks like it's just sitting on its ass for over 15 minutes.Something's still fucky because, in watch mode, each consecutive recompile takes a bit longer than the one before it.
That's normal for node, it just gets more and more, and more, advanced. Making features to keep things the same speed takes work. Smart projects now just get worse linearly with time. Avoids up- front planning.
-
@Applied-Mediocrity said in WTF Bites:
Suppose my observation is somewhat valid I wonder how big is the "middle class" that expects reasonably accurate representation, but aren't overly concerned with every eddy and tidbit being simulated.
I don't think it's a lot. Unless you have a very in-depth knowledge of how airplanes work and feel, you're not going to notice much difference between a super-simplistic model from the 90s and a hardcore simulation.
Who knows, but I doubt one'd be able to describe much difference.
As long as that thing where Chuck Yeager makes fun of you when you die is accurate, at least.
-
Something's still fucky because, in watch mode, each consecutive recompile takes a bit longer than the one before it.
That's normal behavior.
I also work slower when someone is watching me
-
@Applied-Mediocrity I would classify MSFS as a simulator, because it makes bona fide attempt to simulate the actual physics. The previous incarnation was good enough that it was bought by Lockheed and certified for flight training, but I have no idea about the current one, which is a new development.
Well, considering that they even simulate the bending of the wings ...
I don't think they really do. Probably just drawing them bent in proportion to the vertical acceleration with some oscillation—just eye-candy, really. The load alleviation is a nibble more involved, but it's logic also just uses vertical acceleration (the spoilers extend a bit when sudden increase in upward acceleration is detected). Almost sure solid-body simulation only.
What does look involved is the simulation of turbulence though. That requires analysing the terrain features to guess what the wind would be doing around it.
-
@Bulb eh, the turbulence can probably be cheated at pretty well pretty fast.
-
@Gribnit You don't even need to cheat for it to be fast. It's all fairly simple maths and it's just a little bit of it, because it is only simulating one moving solid body and the terrain analysis can be pre-calculated. It can be recognized whether they are applying the turbulence in realistic places though.
-
But FP64 is extremely slow on Nvidia and AMD GPU, thanks to market segmentation: full performance with FP64 is enabled only on "professional" cards like Quadro. So for consumer hardware, we implemented FP64 emulation using two FP32 numbers. Performance is still not great, but it's much better than using hardware FP64.
When faking double precision is faster than actually using it
(from http://spaceengine.org/news/blog210611 or https://steamcommunity.com/games/SpaceEngine/announcements/detail/4443345038545592660)
-
When faking double precision is faster than actually using it
Welcome to the world of GPUs.
I find the solution a bit questionable (and 10cm resolution isn't that great). Seems like chopping up space into smaller bits that can be indexed with integers and just using FP32 inside each small bit would scale much better.
They mention ray tracing, so they want some sort of hierarchical acceleration structure anyway(*). Might as well use it to solve the precision issues while you're at it. If they're rasterizing, they're limited to at most 32bits float depth buffer anyway; having to use doubles just means that they're doing dumb stuff with their transformations.
(*) I mean, even if you're not ray tracing, you most likely want some sort of hierarchical data structure if you have more than a few 100 objects.
-
in watch mode, each consecutive recompile takes a bit longer than the one before it.
Is it holding logging in memory?
-
Tokens are separated from each other by what the parser calls a whitespace (as a shorthand for "one or more whitespaces"
"one or more" would make perfect sense.
But it wouldn't be nearly as useful. It must allow nothing as whitespace or else
{}becomes invalid JSON.My point is not that they should enforce whitespace-separation of tokens but that the grammar calls something whitespace that isn't.
@LaoC ["this","is","valid"]
Sure it is. There is no whitespace between the array elements though, even though the grammar says there was.
Make up your mind. Is it wrong for the grammar rule to allow zero whitespace there or not?
Nothing about that is wrong, except:
@LaoC said in WTF Bites:That's quite a special definition of whitespace.
Edit: only now I've noticed I've had "one or more" in my earlier post when I meant "zero or more". I swear, I wrote zero there, not one. I even remember double-checking it that it's definitely zero. I have no idea how this happened.
Your browser sent it to NodeBB in a JSON message, of course it would confuse zero and one
-
Tokens are separated from each other by what the parser calls a whitespace (as a shorthand for "one or more whitespaces"
"one or more" would make perfect sense.
But it wouldn't be nearly as useful. It must allow nothing as whitespace or else
{}becomes invalid JSON.My point is not that they should enforce whitespace-separation of tokens but that the grammar calls something whitespace that isn't.
They could call it something else, like "maybeWhitespace" or "optionalWhitespace", but since you end up using that token in basically every other rule, the verbosity adds up fast. Calling it "whitespace" really is the best choice, all things considered. At least they didn't call it "space" like every parser library does.
-
Tokens are separated from each other by what the parser calls a whitespace (as a shorthand for "one or more whitespaces"
"one or more" would make perfect sense.
But it wouldn't be nearly as useful. It must allow nothing as whitespace or else
{}becomes invalid JSON.My point is not that they should enforce whitespace-separation of tokens but that the grammar calls something whitespace that isn't.
They could call it something else, like "maybeWhitespace" or "optionalWhitespace", but since you end up using that token in basically every other rule, the verbosity adds up fast. Calling it "whitespace" really is the best choice, all things considered. At least they didn't call it "space" like every parser library does.
space*would be clear and shorter. As it is it's like saying "an identifier consists of one or more alphabetic characters followed by a number". Which is weird but technically correct (yeah, modulo "more alphabetic characters) if "number" means\d*.
-
Tokens are separated from each other by what the parser calls a whitespace (as a shorthand for "one or more whitespaces"
"one or more" would make perfect sense.
But it wouldn't be nearly as useful. It must allow nothing as whitespace or else
{}becomes invalid JSON.My point is not that they should enforce whitespace-separation of tokens but that the grammar calls something whitespace that isn't.
They could call it something else, like "maybeWhitespace" or "optionalWhitespace", but since you end up using that token in basically every other rule, the verbosity adds up fast. Calling it "whitespace" really is the best choice, all things considered. At least they didn't call it "space" like every parser library does.
space*would be clear and shorter.*usually isn't allowed in rule name. And if you meant to only have a single-character named space rule and use zero-or-many modifier on it whenever it's used - that's not how formal grammar works (as in this feature doesn't exist in the popular tools).As it is it's like saying "an identifier consists of one or more alphabetic characters followed by a number".
The identifier rule is usually written as "identifier is a single letter or a single letter followed by identifier suffix, where identifier suffix is a single alphanumeric or a single alphanumeric followed by identifier suffix".
Whitespace is defined as "nothing or 0x20 & co. followed by more whitespace" so you don't have to write every other rule as "X is either Y or Y followed by whitespace". You just write the latter.
Edit: there's also performance to consider. A single integrated zero-or-many-whitespace subparser is much faster than repeatedly running one-whitespace subparser. And you don't want your grammar documentation to differ from your implementation if you can help it
-
Tokens are separated from each other by what the parser calls a whitespace (as a shorthand for "one or more whitespaces"
"one or more" would make perfect sense.
But it wouldn't be nearly as useful. It must allow nothing as whitespace or else
{}becomes invalid JSON.My point is not that they should enforce whitespace-separation of tokens but that the grammar calls something whitespace that isn't.
They could call it something else, like "maybeWhitespace" or "optionalWhitespace", but since you end up using that token in basically every other rule, the verbosity adds up fast. Calling it "whitespace" really is the best choice, all things considered. At least they didn't call it "space" like every parser library does.
space*would be clear and shorter.*usually isn't allowed in rule name. And if you meant to only have a single-character named space rule and use zero-or-many modifier on it whenever it's used - that's not how formal grammar works (as in this feature doesn't exist in the popular tools).It's only called "whitespace" in the graphical representation that's not meant to be read by tools anyway. The textual one says "ws". So much for verbosity.
Whitespace is defined as "nothing or 0x20 & co. followed by more whitespace" so you don't have to write every other rule as "X is either Y or Y followed by whitespace". You just write the latter.
I know.
Edit: there's also performance to consider. A single integrated zero-or-many-whitespace subparser is much faster than repeatedly running one-whitespace subparser. And you don't want your grammar documentation to differ from your implementation if you can help it
Does any production-quality (production-performance particularly) parser actually use code that corresponds 1:1 to the grammar? What I've seen just calls something like
skipWhitespaceornextNonWhitespacein the relevant places that does what you'd think and doesn't give a damn how it's expressed in the grammar.
-
@Applied-Mediocrity I would classify MSFS as a simulator, because it makes bona fide attempt to simulate the actual physics. The previous incarnation was good enough that it was bought by Lockheed and certified for flight training, but I have no idea about the current one, which is a new development.
Well, considering that they even simulate the bending of the wings ...
I don't think they really do. Probably just drawing them bent in proportion to the vertical acceleration with some oscillation—just eye-candy, really. The load alleviation is a nibble more involved, but it's logic also just uses vertical acceleration (the spoilers extend a bit when sudden increase in upward acceleration is detected). Almost sure solid-body simulation only.
What does look involved is the simulation of turbulence though. That requires analysing the terrain features to guess what the wind would be doing around it.
Well, yeah, but they also simulate the other aspects of turbulence. In the video the guy clearly has to land at an angle due to shear winds. There's also downdrafts and other aspects.
So, close enough I guess.
-
@Rhywden Wind (he isn't crabbing due to any wind shear, just wind) is of course prerequisite for any turbulence, wind shear and similar.
What matters more is how accurate their coefficients are. And then for A320 specifically how well they modelled the normal law (which is hard mainly because the data for it is hard to get).
-
-
Tokens are separated from each other by what the parser calls a whitespace (as a shorthand for "one or more whitespaces"
"one or more" would make perfect sense.
But it wouldn't be nearly as useful. It must allow nothing as whitespace or else
{}becomes invalid JSON.My point is not that they should enforce whitespace-separation of tokens but that the grammar calls something whitespace that isn't.
They could call it something else, like "maybeWhitespace" or "optionalWhitespace", but since you end up using that token in basically every other rule, the verbosity adds up fast. Calling it "whitespace" really is the best choice, all things considered. At least they didn't call it "space" like every parser library does.
space*would be clear and shorter.*usually isn't allowed in rule name. And if you meant to only have a single-character named space rule and use zero-or-many modifier on it whenever it's used - that's not how formal grammar works (as in this feature doesn't exist in the popular tools).It's only called "whitespace" in the graphical representation that's not meant to be read by tools anyway. The textual one says "ws". So much for verbosity.
Wait, so you have a problem with "whitespace", but "ws" is fine?
Edit: there's also performance to consider. A single integrated zero-or-many-whitespace subparser is much faster than repeatedly running one-whitespace subparser. And you don't want your grammar documentation to differ from your implementation if you can help it
Does any production-quality (production-performance particularly) parser actually use code that corresponds 1:1 to the grammar?
Parser generators are still very much a thing, and they require you to write down the formal grammar.
What I've seen just calls something like
skipWhitespaceornextNonWhitespacein the relevant places that does what you'd think and doesn't give a damn how it's expressed in the grammar.What you've seen is ad-hoc hand-rolled parsers that blow up in the most spectacular says if you as much as look funny at them. All quality LALR parsers use parser generators and grammar files and all quality LL are written in a way that mirrors formal grammar almost 1 to 1.
The "skipWhitespace" function actually encodes the zero-or-more-whitespaces rule and is 1-to-1 match of the formal grammar.
-
Does any production-quality (production-performance particularly) parser actually use code that corresponds 1:1 to the grammar?
Yes, all of them. Those that do not are not production quality, someone just happens to use them in production.
-
Tokens are separated from each other by what the parser calls a whitespace (as a shorthand for "one or more whitespaces"
"one or more" would make perfect sense.
But it wouldn't be nearly as useful. It must allow nothing as whitespace or else
{}becomes invalid JSON.My point is not that they should enforce whitespace-separation of tokens but that the grammar calls something whitespace that isn't.
They could call it something else, like "maybeWhitespace" or "optionalWhitespace", but since you end up using that token in basically every other rule, the verbosity adds up fast. Calling it "whitespace" really is the best choice, all things considered. At least they didn't call it "space" like every parser library does.
space*would be clear and shorter. As it is it's like saying "an identifier consists of one or more alphabetic characters followed by a number". Which is weird but technically correct (yeah, modulo "more alphabetic characters) if "number" means\d*.The perceptual mismatch arises from a slight conflation between formal and regex grammar. The formal statement "one or more alphabetic characters followed by zero or more alphanumeric characters" is formally correct for a grammar excluding underscores, although it does imply a regex for the remainder that was be excessively greedy on its own.
Similarly, the whitespace description limit "zero or more" works fine in formal grammar but very badly as a regex search term.
-
The perceptual mismatch arises from a slight conflation between formal and regex grammar. The formal statement "one or more alphabetic characters followed by zero or more alphanumeric characters" is formally correct for a grammar excluding underscores, although it does imply a regex for the remainder that was be excessively greedy on its own.
You'll generally use a tokenizer that is greedy with alphanumerics. Early grammars didn't, which lead to SQL statements like
SELECTFOO FROMBAR WHEREX ISNOTYbeing accepted, and nobody wants confusing shit like that. That sort of thing isn't usually written in the parser itself though, but rather the lexer pre-stage.
-
Tokens are separated from each other by what the parser calls a whitespace (as a shorthand for "one or more whitespaces"
"one or more" would make perfect sense.
But it wouldn't be nearly as useful. It must allow nothing as whitespace or else
{}becomes invalid JSON.My point is not that they should enforce whitespace-separation of tokens but that the grammar calls something whitespace that isn't.
They could call it something else, like "maybeWhitespace" or "optionalWhitespace", but since you end up using that token in basically every other rule, the verbosity adds up fast. Calling it "whitespace" really is the best choice, all things considered. At least they didn't call it "space" like every parser library does.
space*would be clear and shorter.*usually isn't allowed in rule name. And if you meant to only have a single-character named space rule and use zero-or-many modifier on it whenever it's used - that's not how formal grammar works (as in this feature doesn't exist in the popular tools).It's only called "whitespace" in the graphical representation that's not meant to be read by tools anyway. The textual one says "ws". So much for verbosity.
Wait, so you have a problem with "whitespace", but "ws" is fine?
Yes. "Whitespace" is a thing with a well-known meaning. "ws" is an abbreviation without one. For any abbreviation I expect that I have to look up what it stands for.
Edit: there's also performance to consider. A single integrated zero-or-many-whitespace subparser is much faster than repeatedly running one-whitespace subparser. And you don't want your grammar documentation to differ from your implementation if you can help it
Does any production-quality (production-performance particularly) parser actually use code that corresponds 1:1 to the grammar?
Parser generators are still very much a thing, and they require you to write down the formal grammar.
I know. Neither of the representations on json.org is meant for one.
What I've seen just calls something like
skipWhitespaceornextNonWhitespacein the relevant places that does what you'd think and doesn't give a damn how it's expressed in the grammar.What you've seen is ad-hoc hand-rolled parsers that blow up in the most spectacular says if you as much as look funny at them. All quality LALR parsers use parser generators and grammar files and all quality LL are written in a way that mirrors formal grammar almost 1 to 1.
What I've seen are gson, jackson and json-c—I hear they're rather popular. Which one uses a parser generator?
The "skipWhitespace" function actually encodes the zero-or-more-whitespaces rule and is 1-to-1 match of the formal grammar.
The point is there's no such thing as a badly performing subparser used in practice anyway. This is the obvious implementation of either way to write the grammar, with "whitspace" including
εor an explicitε | wseverywhere.
Edit: no, I don't want to suggest they do the latter.
-
"Whitespace" is a thing with a well-known meaning.
False. You sit atop untold aeons of conflict and dishonor the dead.
ed. this seems excessive
OH HI Ed, the matching barometer has arrived!
-
"Whitespace" is a thing with a well-known meaning.
False. You sit atop untold aeons of conflict and dishonor the dead.
In the Unicode world we'd like to pretend EBCDIC never happened. Coming to terms with UTF16 is hard enough.
-
Yes. "Whitespace" is a thing with a well-known meaning. "ws" is an abbreviation without one.
I'd argue "ws" is well known to mean whitespace. At least no less common than "whitespace" meaning either a space or a new line (no one except programmers uses it like that).
What I've seen are gson, jackson and json-c—I hear they're rather popular. Which one uses a parser generator?
You've picked 3 libraries out of hundreds of parsers that exist in common use across the entirety of software industry (not counting tens of thousands niche ones). There are bound to be some exceptions. And those exceptions are likely to cluster around the JS ecosystem due to absolute disregard of the JS ecosystem of all the good practices developed over the last 50 years (such as "make your parser code resemble grammar so you don't have to scratch your head for two hours every time you have to change something").
-
In the Unicode world we'd like to pretend EBCDIC never happened.
I'm pretty sure everyone outside IBM would like to pretend that.
-
Yes. "Whitespace" is a thing with a well-known meaning. "ws" is an abbreviation without one.
I'd argue "ws" is well known to mean whitespace. At least no less common than "whitespace" meaning either a space or a new line (no one except programmers uses it like that).
- C:
isblank(),isspace_l(),iswspace() - C++:
isspace() - Java:
Character.isWhitespace() - Go:
IsSpace() - PHP:
ctype_space(and probably half a dozen more or less broken variants) - Rust:
char::is_whitespace
Now you for
ws.What I've seen are gson, jackson and json-c—I hear they're rather popular. Which one uses a parser generator?
You've picked 3 libraries out of hundreds of parsers that exist in common use across the entirety of software industry (not counting tens of thousands niche ones). There are bound to be some exceptions. And those exceptions are likely to cluster around the JS ecosystem due to absolute disregard of the JS ecosystem of all the good practices developed over the last 50 years (such as "make your parser code resemble grammar so you don't have to scratch your head for two hours every time you have to change something").
You have a complicated way of saying "I don't know any".
I picked json-c because I know it's one of the most popular C implementations; gson because it's an official Google project (I hear the guys know a thing or two about parsers) with close to 20k stars on Github, and jackson because it's one of the more frequently benchmarked ones so I guess it also sees quite some use.But just to be sure I now checked the reference implementation
org.json:/** * Get the next char in the string, skipping whitespace. * @throws JSONException Thrown if there is an error reading the source string. * @return A character, or 0 if there are no more characters. */ public char nextClean() throws JSONException { for (;;) { char c = this.next(); if (c == 0 || c > ' ') { return c; } } }Not only does it do things exactly the same way, just named a bit more obscurely, it also takes "be liberal in what you accept" to absurd extremes. Vertical tab, form feed, backspace, escape, XON/XOFF, EOT—all valid whitespace, who knew?!
Finally we're back on topic.
- C:
-
Yes. "Whitespace" is a thing with a well-known meaning. "ws" is an abbreviation without one.
I'd argue "ws" is well known to mean whitespace. At least no less common than "whitespace" meaning either a space or a new line (no one except programmers uses it like that).
- C:
isblank(),isspace_l(),iswspace() - C++:
isspace() - Java:
Character.isWhitespace() - Go:
IsSpace() - PHP:
ctype_space(and probably half a dozen more or less broken variants) - Rust:
char::is_whitespace
Now you for
ws.Find me one programmer who, when asked what "ws" could mean, doesn't say "whitespace".
You have a complicated way of saying "I don't know any".
I know dozens. Just none for JSON.
- C:
-
@Gąska
Web service.
-
You know you're on WDTWTF when...: you see people argue about whitespace.
-
Yes. "Whitespace" is a thing with a well-known meaning. "ws" is an abbreviation without one.
I'd argue "ws" is well known to mean whitespace. At least no less common than "whitespace" meaning either a space or a new line (no one except programmers uses it like that).
- C:
isblank(),isspace_l(),iswspace() - C++:
isspace() - Java:
Character.isWhitespace() - Go:
IsSpace() - PHP:
ctype_space(and probably half a dozen more or less broken variants) - Rust:
char::is_whitespace
Now you for
ws.Find me one programmer who, when asked what "ws" could mean, doesn't say "whitespace".
You have a complicated way of saying "I don't know any".
I know dozens. Just none for JSON.
Without context I'd say websocket, since ws://
- C:
-
@Zerosquare said in WTF Bites:
You know you're on WDTWTF when...: you see people argue about whitespace.
Take that racist shit to the Gara...
-
@Gąska websocket!
Edit:
but I blame pagination.
-
simulation of turbulence
As every airplane passenger should have learned:
serving coffee on aircraft causes turbulence
it is theoretically possible to reduce the occurence of turbulence.
But a different kind of turbulence might occur by not serving coffee at all.
-
I have a
webpack.config.tsthat returns 3 configs (one for client-side JS, one for web worker JS, one for server-side JS). If I runwebpack-clito compile these, it takes like 20 minutes.I wrote a script to fork 3 processes and compile each config in parallel, hoping to cut that down by 66.6% (at most). In practice, I shaved off about 95%, as it now takes about a minute to finish all three configs.
So what the fuck is
webpack-clidoing with its multi-config processing? I ran the ProfilerPlugin and it seriously looks like it's just sitting on its ass for over 15 minutes.What about some kind of "life lock" (as opposed to "dead lock") - i.e. it tries to do A, but sees that it cannot do it now. Hence tries to do B, and again sees that it cannot do it now. Etc.. Turning in circles for a lot of time, till by some random fluctuation in processor load, it can do what it wants to do.
-
Yes. "Whitespace" is a thing with a well-known meaning. "ws" is an abbreviation without one.
I'd argue "ws" is well known to mean whitespace. At least no less common than "whitespace" meaning either a space or a new line (no one except programmers uses it like that).
- C:
isblank(),isspace_l(),iswspace() - C++:
isspace() - Java:
Character.isWhitespace() - Go:
IsSpace() - PHP:
ctype_space(and probably half a dozen more or less broken variants) - Rust:
char::is_whitespace
Now you for
ws.What I've seen are gson, jackson and json-c—I hear they're rather popular. Which one uses a parser generator?
You've picked 3 libraries out of hundreds of parsers that exist in common use across the entirety of software industry (not counting tens of thousands niche ones). There are bound to be some exceptions. And those exceptions are likely to cluster around the JS ecosystem due to absolute disregard of the JS ecosystem of all the good practices developed over the last 50 years (such as "make your parser code resemble grammar so you don't have to scratch your head for two hours every time you have to change something").
You have a complicated way of saying "I don't know any".
I picked json-c because I know it's one of the most popular C implementations; gson because it's an official Google project (I hear the guys know a thing or two about parsers) with close to 20k stars on Github, and jackson because it's one of the more frequently benchmarked ones so I guess it also sees quite some use.But just to be sure I now checked the reference implementation
org.json:/** * Get the next char in the string, skipping whitespace. * @throws JSONException Thrown if there is an error reading the source string. * @return A character, or 0 if there are no more characters. */ public char nextClean() throws JSONException { for (;;) { char c = this.next(); if (c == 0 || c > ' ') { return c; } } }Not only does it do things exactly the same way, just named a bit more obscurely, it also takes "be liberal in what you accept" to absurd extremes. Vertical tab, form feed, backspace, escape, XON/XOFF, EOT—all valid whitespace, who knew?!
Finally we're back on topic.There is another problem with "white space" which most people here do not see: cultural background.
In the current alphabets of the west, white space is actually the most often used character at all. Though no one would say so (more likely claiming that "e" is the most common character of english, or also german).
In contrast, many eastern alphabets use whitespace much less often. It does not separate words, but sentences (or at least parts of sentences). Words are just written together in Sanskrit, Thai, Lao, ...
You and me know this eastern writing style plus the western writing style. But who else?
- C:
-
So what the fuck is
webpack-clidoing with its multi-config processing? I ran the ProfilerPlugin and it seriously looks like it's just sitting on its ass for over 15 minutes.Perhaps most of that time is spent on waiting for various DNS queries to time out. I shaved over 90% off the time for testing an app I'm working on at the moment by tweaking the local name of this computer to be one that doesn't require a DNS call to resolve. (Fucking idiotic macOS misconfiguration…)
-
Find me one programmer who, when asked what "ws" could mean, doesn't say "whitespace".
White Snow
-
@TimeBandit As long as it's not yellow.
-
Yes. "Whitespace" is a thing with a well-known meaning. "ws" is an abbreviation without one.
I'd argue "ws" is well known to mean whitespace. At least no less common than "whitespace" meaning either a space or a new line (no one except programmers uses it like that).
- C:
isblank(),isspace_l(),iswspace() - C++:
isspace() - Java:
Character.isWhitespace() - Go:
IsSpace() - PHP:
ctype_space(and probably half a dozen more or less broken variants) - Rust:
char::is_whitespace
Now you for
ws.Find me one programmer who, when asked what "ws" could mean, doesn't say "whitespace".
You have a complicated way of saying "I don't know any".
I know dozens. Just none for JSON.
Webservice programmers.
- C:
-
@HardwareGeek said in WTF Bites:
@TimeBandit As long as it's not yellow.
To not know that you need to be strictly from commercial.
-
@HardwareGeek said in WTF Bites:
@TimeBandit As long as it's not yellow.
The bad thing is: you never know for sure what a "yellow snow warning" is.
-
Yes. "Whitespace" is a thing with a well-known meaning. "ws" is an abbreviation without one.
I'd argue "ws" is well known to mean whitespace. At least no less common than "whitespace" meaning either a space or a new line (no one except programmers uses it like that).
- C:
isblank(),isspace_l(),iswspace() - C++:
isspace() - Java:
Character.isWhitespace() - Go:
IsSpace() - PHP:
ctype_space(and probably half a dozen more or less broken variants) - Rust:
char::is_whitespace
Now you for
ws.Find me one programmer who, when asked what "ws" could mean, doesn't say "whitespace".
You have a complicated way of saying "I don't know any".
I know dozens. Just none for JSON.
Without context I'd say websocket, since ws://
My anti-webdev bias shows again.
- C:
-
@BernieTheBernie said in WTF Bites:
Yes. "Whitespace" is a thing with a well-known meaning. "ws" is an abbreviation without one.
I'd argue "ws" is well known to mean whitespace. At least no less common than "whitespace" meaning either a space or a new line (no one except programmers uses it like that).
- C:
isblank(),isspace_l(),iswspace() - C++:
isspace() - Java:
Character.isWhitespace() - Go:
IsSpace() - PHP:
ctype_space(and probably half a dozen more or less broken variants) - Rust:
char::is_whitespace
Now you for
ws.What I've seen are gson, jackson and json-c—I hear they're rather popular. Which one uses a parser generator?
You've picked 3 libraries out of hundreds of parsers that exist in common use across the entirety of software industry (not counting tens of thousands niche ones). There are bound to be some exceptions. And those exceptions are likely to cluster around the JS ecosystem due to absolute disregard of the JS ecosystem of all the good practices developed over the last 50 years (such as "make your parser code resemble grammar so you don't have to scratch your head for two hours every time you have to change something").
You have a complicated way of saying "I don't know any".
I picked json-c because I know it's one of the most popular C implementations; gson because it's an official Google project (I hear the guys know a thing or two about parsers) with close to 20k stars on Github, and jackson because it's one of the more frequently benchmarked ones so I guess it also sees quite some use.But just to be sure I now checked the reference implementation
org.json:/** * Get the next char in the string, skipping whitespace. * @throws JSONException Thrown if there is an error reading the source string. * @return A character, or 0 if there are no more characters. */ public char nextClean() throws JSONException { for (;;) { char c = this.next(); if (c == 0 || c > ' ') { return c; } } }Not only does it do things exactly the same way, just named a bit more obscurely, it also takes "be liberal in what you accept" to absurd extremes. Vertical tab, form feed, backspace, escape, XON/XOFF, EOT—all valid whitespace, who knew?!
Finally we're back on topic.There is another problem with "white space" which most people here do not see: cultural background.
In the current alphabets of the west, white space is actually the most often used character at all. Though no one would say so (more likely claiming that "e" is the most common character of english, or also german).
In contrast, many eastern alphabets use whitespace much less often. It does not separate words, but sentences (or at least parts of sentences). Words are just written together in Sanskrit, Thai, Lao, ...
You and me know this eastern writing style plus the western writing style. But who else?
What's the word for when a language allows indefinite word formation via compounding and then one needs to respond to a statement by a user of such a language which seems to not account for this factor?
- C:
