|
Wordle 1,088 5/6*
⬛⬛⬛🟩⬛
⬛⬛⬛🟩⬛
🟩🟨⬛🟩⬛
🟩⬛🟩🟩⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 1,088 6/6
🟩⬜⬜⬜⬜
🟩⬜⬜⬜🟨
🟩🟨⬜⬜⬜
🟩🟨⬜🟩⬜
🟩⬜🟩🟩⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 1,088 3/6*
⬜⬜⬜🟨⬜
🟩⬜🟩🟩⬜
🟩🟩🟩🟩🟩
"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!
|
|
|
|
|
Wordle 1,088 4/6
🟩⬜⬜⬜⬜
🟩⬜🟩🟩⬜
🟩⬜🟩🟩⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
⬜⬜⬜🟩⬜
⬜⬜⬜🟨🟨
🟩⬜🟩🟩⬜
🟩⬜🟩🟩⬜
🟩⬜🟩🟩🟩
🟩🟩🟩🟩🟩
thought I was going to fail
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 1,088 3/6*
⬜⬜⬜⬜⬜
🟨⬜🟩🟩⬜
🟩🟩🟩🟩🟩
Happiness will never come to those who fail to appreciate what they already have. -Anon
And those who were seen dancing were thought to be insane by those who could not hear the music. -Frederick Nietzsche
|
|
|
|
|
Wordle 1,088 3/6
⬛⬛⬛🟩⬛
🟩⬛⬛🟩🟩
🟩🟩🟩🟩🟩
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Update: https://cse.usf.edu/~kchriste/tools/udpClientNonblock.c[^] Pretty much what I needed. Yay.
Update 2: Much ado about nothing. Easier than I thought. Docs are just terrible.
Anyone remember the sockets layer from C and C++?
Seriously, the fact that someone actually designed them the way that they did, and it made its way through a standards committee just floors me. The blocking stuff is fine, but the non blocking stuff is incomprehensible, at least last time I looked at it.
It's absolutely the worst asynchronous API I've ever encountered.
I'm about ready to use them in blocking mode on a spawned thread just to avoid it, but the MCU doesn't have a lot of resources and threads are relatively expensive. 
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
modified yesterday.
|
|
|
|
|
I'd be curious to hear more specifically what is wrong about the asynchronous socket API. What is the incomprehensible part.
Communication is, in its very nature, asynchronous. So an asynchronous socket API should be the natural way to do it. Synchronous communication is a straitjacket; you can't work or think freely if you have to force yourself into a synchronous framework for communication.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
IBM Documentation[^]
It's anything but natural.
Adding, I took a liberty here. I'm using non-blocking and asynchronous interchangeably, but they may not always be in every context.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
And here I am, complaining about non-well-formed CSV files... 
|
|
|
|
|
Those are the bane of every programmer.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
My simple rule: I only read CSVs I wrote.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
honey the codewitch wrote: use them in blocking mode on a spawned thread
Works for us. We use blocking sockets for both hardware and inter-process communication. It separates threading concerns from communication concerns.
Software Zen: delete this;
|
|
|
|
|
Separating I/O threads from application threads is an excellent strategy. The I/O threads just do recvfrom/recv and queue messages as work for the application threads. When no message is waiting for an I/O thread, it's easiest to just let it block (with a timeout if it also has other things to do, like freeing TCP sockets that applications released after the I/O thread last blocked).
|
|
|
|
|
If I wasn't working on a system with a very primitive scheduler and a miserly amount of RAM I would have seriously considered it. It *did* cross my mind.
But in the end I got it to work without doing so, and it was actually a bit easier than the documentation seemed to suggest. Helped that I found example code.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it, because it's all interdependent. This often happens when I'm integrating something to an external API that itself is rather complicated, but it can come up in other situations as well. My SVG renderer for example - there are just so many moving interlocking parts that you're standing on a mountain of code before you even get to proof of life.
So if you've ever been in that situation, I imagine you hate it as much as I do.
It's stressful to me. I do not like coding a house of cards, and then having to go back and verify it after the fact. It feels shady. How do you deal with it?
Some kind of process management?
Some clever form of testing I'm not familiar with?
Tai chi?
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
honey the codewitch wrote: I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it
Rarely, but it's a PITA and I get pretty stressed. Usually for nothing but occasionally it proves to be a can of worms and I have to go back and try to debug the code, which causes more frustration until I get to the point where I post a stupid question here on CP that makes no sense to anyone but me then I get away from it for a while and behold I figure it out.
If you can't find time to do it right the first time, how are you going to find time to do it again?
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Okay, so basically same as me.  
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
1:Limit and validate input before attempting to process any further logic.
2:Handle any out of bounds input and/or dependency failures with effective error handling and comprehensive logging to allow forensics to show how and why the error was thrown and the inputs or dependency that caused it.
3:make sure the functionality of the new logic is well documented for allowable inputs, desired outputs, snf dependencies, with stakeholders responsible for the requirements well documented so there is no ambiguity about who wanted what, why, and when.
If for whatever reason you can't do all of those in your work, something is very wrong with the overall approach and you are in deep doo-doo.
I had to code "add-on" features and funcitonality to 3rd party business critical enterprise apps many times. 1,2, and 3 made it possible to do so with minimal stress because the proposed logic could be matched to what stakeholders agreed it was supposed to do (except for defects I created in the logic of course which is my own fault).
|
|
|
|
|
Completely abstract and perhaps not appropriate for your context: The first thought I have is to abstract with immutable objects. But maybe I'm only simply crazy
|
|
|
|
|
I'm trying to wrap my head around how that would work in my present situation, and nope. I am not clever enough to figure out how that would help me.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I'm pretty sure you are clever enough to solve it finally 
|
|
|
|
|
It's my usual way of working, whether coding something big from scratch or making a large change. The benefit is not having to plan stable waypoints that can be tested, which typically involves developing some code that will later disappear. The drawback is anticipating [blecch] several lengthy debug sessions when the code is done.
|
|
|
|
|
I don't have a debugger, so the debug sessions are .. interesting.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
