|
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 5hrs 20mins ago.
|
|
|
|
|
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;
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Hmm, I feel your pain. Complex code, varied data related interactions and no debugger.
In the past, I have integrated a logging function into the code. Usually as a compile time option so I don't have to dismantle it by hand (which I have had to do in the past when compile time options were not available). Usually start with simple module enter/exit logs and then progress to adding inputs and outputs and interesting working variables as the testing progresses. Had to make sure the log function opened, wrote log message and closed the log file to ensure the integrity of the log file should the application die rather than simply producing nonsense output.
|
|
|
|
|
Ah. I'd forgotten what platform you were currently working on. I'd be tempted to write a simple debugger in that case, assuming that there's even a breakpoint instruction and enough memory. If not possible, my way of working would need a reset!
|
|
|
|
|
You can actually connect to some of these widgets using JTAG and debug them but it's so slow it's really not worth it.
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
