|
Wordle 673 4/6*
⬜⬜⬜⬜⬜
🟩🟩🟨⬜⬜
🟩🟩⬜🟩⬜
🟩🟩🟩🟩🟩
Griff, as you can see, my pattern matches your exactly. I think I probably would have gotten it in 3 if Wordle hadn't conditioned me to generally ignore Q, V, X & Z except as choices of last resort.
I say Wordle conditioning because I think I unconciously put myself into a certain mode of strategic thinking, so to speak, to solve these.
Does anyone else feel it's Wordle conditioning? Or do you think it's just common sense because these letters are just normally used less in the English language?
|
|
|
|
|
It's doubles that throw me - I seem to have a mental reluctance to accept them ... 
"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!
|
|
|
|
|
Yes, me too. I hate guessing with a double because if it's wrong I only cross off 1 letter from the list of unused. It appears my strategy isn't so much "guess the answer" as it is "eliminate what isn't". 
|
|
|
|
|
Wordle 673 5/6
⬜⬜🟨⬜⬜
⬜🟨⬜🟩⬜
🟩🟩⬜🟩⬜
🟩🟩⬜🟩🟩
🟩🟩🟩🟩🟩
not so easy
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Wordle 673 4/6
⬛⬛⬛⬛⬛
🟨⬛🟨🟨⬛
⬛🟨🟨🟨🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
this afternoon I got two power outages within 10 minutes. my computer could not power on.
this post helped me. I tried twice and my computer powered on...
diligent hands rule....
|
|
|
|
|
#Worldle #456 2/6 (100%)
🟩🟩🟩⬜⬜↖️
🟩🟩🟩🟩🟩🎉
https://worldle.teuteuf.fr
sort of easy
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Sometime back I solicited opinions on a new keyboard.
I receive a number of recommendation for DAS brand
and similar clicky style keyboards. I want to thank those who provided me
inputs. Learned alot.
In Summary
My requirements:
wired
single USB cable to computer
USB port on keyboard that supported wire mouse
Goal: reduce a wired keyboard and mouse to single USB port on my computer
Many recommended the DAS brand of keyboard with clicky keys.
I tried
Das Keyboard Model S Professional Wired Mechanical Keyboard,
Cherry MX Brown Mechanical Switches,
2-Port USB Hub, Laser Etched Keycaps (104 Keys, Black) $117
Cable to computer supported both USB and PS2 (?)
Very nice keyboard but mouse and/or key board did not work properly.
went with
Perixx PERIBOARD-220H US, Wired Compact USB Keyboard with 2 Hubs -
Build-in Numeric Keypad - Black - US English Layout, (11506) $30
Keyboard was not as nice as DAS, but fulfilled my requirements.
Since this was a small investment, I will feel comfortable
upgrading in the future for the optimal keyboard.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
Cute
Seriously, I used Logitech wireless keyboard and mouse for year but they started to give me problems so went for wired.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
i would have chosen perixx Ergo[^] except i do not favor its macro implementation or its LEDs arrgnement . i will never understand why the LEDs are not made more prominent and _facing_ user instead of facing ceiling . unfortunately it does not come in pink or chartreuse . btw how anyone can tolerate those rectangular torture boxes i will never understand .
|
|
|
|
|
"To each is own".
I've tried the ergo-style and it doesn't work for me.
I prefer the traditional rectangular keyboard.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
? I don't get it.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
What is "entry" and why is it quoted?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Old assembly programmers often refer to a function's "entry point"- the code location where function execution is entered. The function name is the label assigned to this code location, often referred to as the "entry".
In assembler code it was not uncommon for a function to have multiple entry points. There were even high level languages allowing a function offering it. One use was to call the function first time at an entry doing a lot of initialization before the "real work". Later calls used an entry point right at the "real work" part. Obviously, you could do the same with an "if not initialized, then ...", or in an OO world using a constructor, but in the old days it was different.
In *nix, you may consider it a functional equivalent of multiple entry points if an executable inspects argument zero, the name given to the executable file, using it to switch to different parts of the code, often as different setups before going on to the same "real work" part for all alternatives.
Wikipedia discusses "Entry point" only as the entry point for the entire executable ("main" or its equivalent), not for a function. This is a restriction of the discussion; earlier, referring to the function's entry point was common, accepted terminology. (Googling for "function entry point" returns quite a few hits!)
"Entry" is (or was) used for any location you could jump to, not just the start of a function. Few programmers make use of labels today, but I guess the limitation on 32 char length applied to labels as well as functions. So the OP used "entry" as a common term for both, and as neither is really called "entry", the quoting (to mark that this is not the real term) is appropriate.
|
|
|
|
|
|
When I started, you could only have 8 "significant characters" in function or variable name. Nowadays that is not a problem but I still don't like long descriptive function names. I prefer short functions that you can understand with one look.
jhaga
|
|
|
|
|
I certainly would prefer two functions "Setup_Serial_Port" and "Activate_Serial_Port"  (I like short function bodies, too!).
In an OO environment, I would accept (even prefer) methods "Setup" and "Activate" on a Serial_Port object. But I would not accept "SSP" and "ASP" (or "SAASP"), even if that would save a few keystrokes when you make a call.
|
|
|
|
|
Many years ago (even years before Linux!) I worked with a company writing their own OS. A complete rewrite was made in a (proprietary) high level language, embraced by the old assembly programmers because "Now we don't have to write comments any more!"
It is at the same level as one introduction to COBOL-60 declaring that with this language, there is no longer a need for specially trained programmers; now anyone can write the solution in plain English language.
With a name like Setup_And_Activate_Serial_Port, there is no need for the comment to explain that this function will set up and activate a serial port. If the arguments have similarly descriptive names, you need not, in the comments, repeat what the name reveals. But I very rarely if ever see function definitions where all and everything of what the code maintainer ought to know can be expressed in the name alone (with a possible exception for 1-2 line bodies). So there is usually a need to document a lot of other aspects.
The comment associated with the function heading I prefer to keep short; it is for the user of the function, not the maintainer. And I love end-of-line comments: At the exact spot it applies to, and it won't cause the function body to spread over multiple screenfuls. (But with all EOL comments running from col 70 or 80, so they don't blur the code, you may need to widen your editor window or use the horizontal scroll bar to see them.) For some reason, most programmers disagree with me.
Generally speaking: These huge comment blocks above the function, essentially repeating information already present in (good) naming, and very little extra info, I think of as plain LOC boosters. They are no excuse whatsoever for not commenting non-obvious issues through the code (although they are often used for that purpose ). Two thirds of all the code comments I see have no value whatsoever, and at least two thirds of the issues that really could need an explanatory comment is left as plain, uncommented code. If I were to grade coders by their comments, very few would even reach a 'C'. Quite a few would flunk.
|
|
|
|
|
I used to work for a company that completely discarded the comments in the code on behalf of self-explanatory names and short functions(C++/C#). I also worked for another one where it was expected that we write a small novel on top of every function(C/Java). I like the former approach better.
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
Of course the second allows one to document things like expectations, current usage and unusual usages that come about when one ends up maintaining legacy code written by someone that left the company 10 years ago and figured keeping all that domain knowledge in their head was the sign of a professional.
|
|
|
|
|
trønderen wrote: you may need to widen your editor window or use the horizontal scroll bar to see them.) For some reason, most programmers disagree with me.
That is not an option on a VT screen.
Similarly, some systems such as Oracle's PRO*C put a limit on line lengths.
Personally, I prefer not to exceed 112 characters because that's how many I can fit on a page.
|
|
|
|
|
PIEBALDconsult wrote: That is not an option on a VT screen.
What year was the most recent VT terminal released? Wikipedia describes the 1993 VT520 (i.e. 30 years ago), discontinued 10 years later (20 years ago). I doubt that there were later VT screens.
According to Wikipedia, the 1987 VT320 (and its successors) could display 132 chars/line, leaving room for 62 chars of end-of-line comments starting at col 70. In the age of non-graphic, character oriented screens, it was commonplace for editors to provide a command to move the window to the right by, say, 20 or 40 characters. For the first generation of character screens, the entire screen had to be redrawn. More 'recent' models provided escape sequences for moving the contents in a line buffer (in the terminal) to the right or left, so only the new part had to be transmitted. Editors of the time fine-tuned their output to the terminal model in use, to reduce data transmitted.
Similarly, some systems such as Oracle's PRO*C put a limit on line lengths. They can't possibly have had a limit less than 132! I worked with editors having a 256 char limit, some time in the 1980s.
I googled 'Oracle PRO*C', and was sent to the documentation for version 12.1; it seems to be released in 2014. At that time, the 'Precompiler options' documentation for MAXLITERAL states
The maximum value of MAXLITERAL is compiler dependent. For example, some C compilers cannot handle string literals longer than 512 characters, so you would specify MAXLITERAL=512.
This is a (semi-)reasonable limit, but not one preventing you from using end-of-line comments! The limit may of course have been lower in earlier years (e.g. 256), but if a compiler couldn't process a source file that could be printed on
'any' line printer of the day, it must be classified as a toy compiler. (Besides, for EOL comments, the compiler sets no limits - the preprocessor strips off all comments, EOL or otherwise! So the limitation would be in the preprocessor, and I doubt very much that it had any limit affecting EOL comments.)
A note from modern times (5-6 years ago): The company I worked for was revising its C coding rules. The working group had suggested that all source files be limited to a maximum of 80 characters. At the meeting where this proposal was presented, my project leader immediately jumped up and declared that our project would have an exemption from this rule. The main reason: We had rules for generating names of #define constants that frequently lead to names exceeding 80 chars!
Personally, I would have preferred that no exemption were given, forcing us to revise those horrible name generating rules! That didn't happen; the entire 80-char limit was dropped, the name generating rules kept unchanged. The good thing is that I could continue writing EOL comments from col 70.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
