|
Nice! You live, you learn.
Mircea
|
|
|
|
|
Agreed, but I'm not sure all tokenizers would be happy with the lack of a space, which in this case might be considered as significant as a punctuation character. But then, I suppose when you see something starting with "#include", the next character really should not be part of that token. Especially when it's a reserved character such as < or ", so I suppose the situation is easy enough to detect and allow.
|
|
|
|
|
It wouldn't be part of the token in most tokenizer implementations.
"include" would be a preproc keyword.**
** or identifier if the tokenizer doesn't distinguish between idents and keywords as is often the case.
Most of the time, whitespace is hidden during tokenization before the parser gets to it so the parser wouldn't really care if there was no whitespace unless the developer put in extra effort for it to care.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
dandy72 wrote: Agreed, but I'm not sure all tokenizers would be happy with the lack of a space,
A C++ compiler is not compliant if it requires a space before the '<'
The spec defines a preprocessor id as a '#' followed by a 'token'
A token (section 2.1) must be one of the following
- Identifier
- keyword
- literal
- operator
- other separators
"...collectively 'white space')...are ignored except as they serve to separate tokens"
So in the context of this the following is valid
#include<io.h>
But the following would not be since the token in that case would be 'includeio'
#includeio.h
Keep in mind of course that this doesn't make 'includeio' valid. But just that as far as tokenization goes that is what would happen.
|
|
|
|
|
That was my assumption, but I didn't want to look it up because lazy. 
Thanks.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
jschell wrote: A C++ compiler is not compliant if it requires a space before the '<'
There ya go. End of discussion. Thanks for pointing that out.
|
|
|
|
|
A sampling of compilers at Compiler Explorer were happy without spaces. Have to admit that it just looks wrong to me. But then I'm an old fogey ...
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
k5054 wrote: Compiler Explorer
Of course that had to exist. So, this is the source code equivalent to VirusTotal...
Very neat. Thanks for that link.
|
|
|
|
|
While I'm trying to find a way to train my cards game this link to a nice book came up:
http://www.incompleteideas.net/book/RLbook2020.pdf
Does someone here has experience with Reinforcement Learning and is it helpful for a card game AI like Bridge or Schafkopf? In those card games there are two teams and it seems more complicate than RL for BlackJack or Hearts.
|
|
|
|
|
We just updated an industry leading tool from version 2019 to 2022 (the latest).
One new feature is a REST Web API, which is the main reason we're updating.
It works through Swagger in the browser, but calling the API from code proved to be more of a challenge.
Apparently, it authenticates using Kerberos or NTLM 
I wouldn't even think that was an option in 2022 (or even at all, for a Web API).
|
|
|
|
|
Sander Rossel wrote: Apparently, it authenticates using Kerberos or NTLM
I wouldn't even think that was an option in 2022 (or even at all, for a Web API).
Yeah, that is _interesting_.
I mean you're still passing a token to get authenticated, I'm guessing?
Do you (on the cient side) have to do something special or is it all done on the server side?
Is there a special process to generate a special Kerberos token on the client side?
I don't know how that works. It sounds confusing. 
|
|
|
|
|
Apparently, it works as follows:
var handler = new HttpClientHandler
{
Credentials = new NetworkCredential("username", "password", "domain")
};
var client = new HttpClient(handler);
You can do this using DI and use the IHttpClientFactory to create your clients.
You're not sending tokens, it's more like Basic Authentication.
|
|
|
|
|
I hope your experience with Swagger is better than mine! 
IIRC, the real challenge was dealing with intermittent (>50%) timeout errors likely caused by the huge amount of data I was requesting. (caused by the inability to get proper summarized results in the outdated odata service provider)
I emailed the vendor to ask for help and report the high occurrence of timeouts and got nowhere. That project was ultimately scrapped due to lack of support from the vendor/customer.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
That's not really Swagger's fault.
Swagger is just (generated) documentation of a web API with the ability to test the API.
If the API sucks, so will Swagger.
If anything, Swagger showed you the API sucked and that you didn't need to invest more time in it.
The only "bad experience" I've had with Swagger was it breaking when doing some non-standard API development (like having a single endpoint for all functionality, don't ask...).
I can't really expect Swagger to handle such weird edge cases.
|
|
|
|
|
Adam: I want a perfect soulmate
God: That will cost you an arm and a leg
Adam: ...
Adam: What can I get for a rib?
*hides*
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
"Barbeque Sauce?"
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Beware the ides of April, it may tax thy soul.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
(Caesar): The Ides of March are come.
(Soothsayer): Ay, Caesar; but not gone.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
People are losing the spirit of the Ides of March.
It's not about stabbing.
It's about coming together, to stab in groups.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
The Senators needed to get their point across.
|
|
|
|
|
I've just been reading a bit about the differences, and see some mentions of Display Port being more capable in multi-monitor applications. My last PC build included a video card (ASUS TUF RTX 3060Ti) includes both types of connector, as do my two monitors, but I assembled it all using HDMI simply because that was the type of cable I had on hand. I know that a lot of you use two or more monitors; which do you prefer? If I switch to Display Port will I see enough improvement, if any, to justify the fairly cheap cost of new cables?
Will Rogers never met me.
|
|
|
|
|
Quote: DisplayPort and HDMI are both widely used standards for connecting displays to computers, gaming consoles, and other devices. Each has its own advantages, and the choice between them depends on factors like your specific needs and the devices you're connecting. Here are some benefits of DisplayPort over HDMI:
1. Higher Bandwidth: DisplayPort typically offers higher bandwidth compared to HDMI. This means it can support higher resolutions, refresh rates, and color depths. For example, DisplayPort 1.4 supports 8K resolution at 60Hz, while HDMI 2.1 supports 8K at 30Hz.
2. Adaptability: DisplayPort is more adaptable to different types of displays and technologies. For instance, it can easily adapt to older VGA, DVI, and HDMI displays using simple passive adapters, while HDMI may require more complex converters for compatibility.
3. Multiple Display Support: DisplayPort supports daisy-chaining, allowing you to connect multiple monitors to a single DisplayPort output. This simplifies cable management, especially in multi-monitor setups, as it reduces the number of cables required to connect each display to the computer.
4. Longer Cable Lengths: DisplayPort cables can generally maintain signal integrity over longer distances compared to HDMI cables, especially at higher resolutions and refresh rates. This makes DisplayPort more suitable for setups where displays are located farther away from the source device.
5. Variable Refresh Rate (VRR) Support: DisplayPort has supported adaptive sync technologies like AMD FreeSync and NVIDIA G-Sync for longer than HDMI. This allows for smoother gaming experiences by synchronizing the refresh rate of the display with the output of the graphics card, reducing screen tearing and stuttering.
6. Audio and Video Separation: DisplayPort separates audio and video signals, which can be advantageous in professional setups where audio is handled separately from video. This allows for more flexibility in routing audio signals.
7. Future-Proofing: DisplayPort tends to adopt new technologies and standards earlier than HDMI. For example, DisplayPort 1.3 and 1.4 introduced support for higher resolutions and refresh rates before similar capabilities were available in HDMI.
Despite these advantages, HDMI remains popular due to its widespread adoption, compatibility with consumer electronics, and support for features like Consumer Electronics Control (CEC) and Audio Return Channel (ARC). Ultimately, the choice between DisplayPort and HDMI depends on your specific requirements, the devices you're connecting, and compatibility considerations.
If your monitor(s) support VRR then maybe it is worth your while. With HDMI, there are various grades and standards of cable, so not all HDMI cables are equal. If you are using HDMI, then make sure that you are using the correct standard required by your monitor(s) to get the best results.
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
Thank you, Graeme, that's really excellent information, and I appreciate you contributing it. I'm especially interested to learn that Display Port can be adapted to connect to a VGA monitor, as I fear that my friend who is getting a new Dell PC might have an older VGA monitor. I already know that the new PC is going to way outperform the video she has, but I'm having trouble getting her to let me get her a new display.
Will Rogers never met me.
|
|
|
|
|
Roger Wright wrote: I'm especially interested to learn that Display Port can be adapted to connect to a VGA monitor
Googling shows there are adapters available: Display port to VGA - Google Search[^]
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
