|
Wordle 1,102 3/6
π¨β¬π¨β¬β¬
β¬π¨π¨π¨π¨
π©π©π©π©π©
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 1,102 3/6
π¨β¬β¬β¬π¨
π©β¬β¬π¨π©
π©π©π©π©π©
|
|
|
|
|
I've been getting junk E-mails from @message.fedex.com, which a low-level FedEx rep says is not legit (I'm waiting on someone higher up there to confirm this), and I don't want the legitimate messages from @fedex.com to be blocked if I block the messages from @message.fedex.com.
|
|
|
|
|
If an email falls in the forest when nobody is around, does it really make a sound?
Jeremy Falcon
|
|
|
|
|
It depends on the mail client you're using. In MS Outlook, I can block the sender (which should be host-specific) or the sender's domain (which should block all hosts and users from the same domain). I say "should" because Outlook has always been a bit flaky, and the latest version is not very predictable. I've never used Yahoo Mail, so I can't advise you, but you might try searching for some FAQs on their site.
Will Rogers never met me.
|
|
|
|
|
I don't know about Yahoo Mail, but every other e-mail client that I have used allows one to block both the user (abc@xyz.com) and the domain (@xyz.com). They also require separate rules for subdomains (@xyz.com vs @tuv.xyz.com).
I doubt that blocking @message.fedex.com will block @fedex.com.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
As others have said, you should be able to block individuals. We block access to yahoo mail. Source of Ransomware some years ago when employee checked her email and clicked on wrong thing. Ruined my weekend, but had air gapped backups. Good, but undesired, disaster plan test. Another way to test: port forwarding.
>64
Itβs weird being the same age as old people. Live every day like it is your last; one day, it will be.
|
|
|
|
|
So, I read this article: Easily navigate code delegates while debugging - Visual Studio Blog[^]
and I am so glad, I just don't give a flying f*** anymore. I started doing serious Windows development in 2003. I inherited a project that used ActiveX controls. Just local, no downloads - all embedded system work. I have to plow through the changing terminology of COM, DCOM, COM++, ActiveX, etc. After 3 years, I declared it utter bull****. MS renaming things just to rename things for marketing purposes.
So, I read this devblog article, and though delegates are somewhat different than function pointers, its the same old bs from Microsoft renaming stuff. Worse, I suspect it made it into the C++ standard. I don't know about that, nor do I care.
Starting next week, I'm moving to linux.
Charlie Gilley
βThey who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.β BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: So, I read this devblog article, and though delegates are somewhat different than function pointers, its the same old bs from Microsoft renaming stuff.
That's the difference between a senior and a junior dev. Juniors think they discovered fire half the time, but most things are rehash and rebranded with a tiny bit of newness. But, it's really the same ol' thing with a new bell and whistle.
I still use the example of XML and SGML. While XML was more strict with its DTDs, the concept of XML or a DTD was nothing new. About 10+ years ago during the XML craze, you'd hear a lot of peeps swear they discovered fire with it... even though SGML has been around for years prior. Just rehashed stuff with a bit of umph added.
charlieg wrote: Starting next week, I'm moving to linux.
You'll love it man. I've only done C and web dev on Linux, but the c lib at least has a surprising amount of functionality to it. A Linux box really does make a great dev box.
Jeremy Falcon
|
|
|
|
|
I think you're not noticing that managed code, to the extent of .NET and maybe Java, (I don't know much about Java except that I hate eclipse,) was revolutionary. It dumbed down programming on a scale even greater than the effect Visual Basic had on Windows application programming.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Not sure how you can draw that conclusion based off an SGML example. While I do concur the "rise" of XML and .NET were around the same time, that example stands independent of .NET, so I'm not sure what I failed to notice given the concept has nothing to do with managed code in and of itself and more to do with junior programmers of any generation knowing little of the past.
Jeremy Falcon
|
|
|
|
|
I just wanted to say that. Nothing personal.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Fair enough. 
Jeremy Falcon
|
|
|
|
|
We just happened to be scaling more in the time of .NET.
I don't think anything will ever dethrone VB/Office dev as making dev simpler, save maybe new AI things that don't yet exist but harken back to those "design by wizard" but with way way better wizards.
|
|
|
|
|
Managed code simply frees the programmer from having to deal with most memory management issues. You still need to understand how the management framework's runtime operates to make the best use of it.
|
|
|
|
|
My XML hype period started around 2002.
When ajax (x is for XML!) actually used XML on the wire.
Then JSON came along and the security analysts have not had a good nightβs sleep since.
I still appreciate how easy it is to write a quick XSLT to extract anything from an XML file.
|
|
|
|
|
Oh, and IMO it's a bit easier to do multithreaded work in C on Linux than Windows.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Oh, and IMO it's a bit easier to do multithreaded work in C on Linux than Windows.
I love thread handling in C#. I can go high level and just let the framework do what it thinks it's best, or I can go low level and take complete control. And threads (aka async tasks) with awaits, while it can be a bit of a hurdle to sometimes realize what I did wrong and to how to break the chain of, oh, this method is now async, so the parent has to be async, oh wait, the grandparent now has to be async..., yeah, how to do deal with that takes some finesse, but I still love how C# implements the whole mess. 
|
|
|
|
|
I do have to admit man, while I've done very, very, very little multi-threading in C#, from what I've seen it does make it nice. More recent versions of C++ do as well.
Jeremy Falcon
|
|
|
|
|
ConcurrentBag + Task.Waitxxx/WhenAll/Any
|
|
|
|
|
Marc Clifton wrote: this method is now async, so the parent has to be async, oh wait, the grandparent now has to be async...
So much this.
One of these days I'll have to actually sit down and take the time to study this and try to understand, once and for all, how to avoid getting yourself in that situation.
Because right now I find myself avoiding using async/await because I see it as having to "retroactively pollute the entire codebase". And that can't be right, that has to be just me misunderstanding and misusing it.
|
|
|
|
|
|
Thanks for that, it's been bookmarked and I'll go over it closely.
The very first response (upvoted 1096 times) starts with:
"Asynchronous programming does "grow" through the code base. It has been compared to a zombie virus. The best solution is to allow it to grow"
...which is exactly what I'm complaining about. You start polluting your libraries with those keywords, and then suddenly you have to modify everything that requires it, going completely against the very concept of encapsulation.
|
|
|
|
|
Mainly it grows because every async method has a state machine created by the compiler. Yes, partial async is a contradiction and at best leads to the same thread-blocking as fully synchronous code, while the usually worst outcome is deadlock. The fact that async is an all-or-nothing commitment is IMO the main reason for developers not embracing it, but there's no excuse to not use it for greenfield projects. If you do it right, you also pass a CancellationToken with every call; increasingly, I'm also becoming convinced of passing IProgress<t>, at least for certain public members.
There was recent interest in replicating the Go concept of green threads, which I think would have been a game changer had it been used instead of async/await. Green Thread Experiment Results Β· Issue #2398 Β· dotnet/runtimelab Β· GitHub[^]
|
|
|
|
|
They keep adding layers of lipstick, but it's still a pig!
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
