Xah Programing Blog Archive 2022-01
- Microsoft Windows 10 stuff.
- interesting discovery. if u magnify mouse cursor, but when vid streaming or recoding, mouse cursor size no change.
- however, mouse cursor color do show. and trail also shows.
split to multi pages
more updates
the incredible windows crap. when u empty trash, then u alt+f4 to close window, this mysterious fuck popus up.
updates
writing issue, true/false vs boolean
now i wonder, in my lang tutorials, those pages on boolean true/false, should i change the title from true/false to boolean.
- maybe “Boolean (true/false)”.
- My normal style is to use true/false.
- Because that's intuitive, and actual, actual in the sense that lang actually have true/false as keywords, and is what programers deals with.
- But been thinking to change, or add boolean in addition.
- Because, now i have search box.
- When in search, boolean tends to be what people would search.
- Example:
- Trying to find the page on powershell boolean, or python boolean, or wolfram lang, etc.
- Xah self analysis monolog: ok, this is interesting.
- When just a tutorial, true/false is more intuitive and proper.
- Because beginners have no idea what is boolean.
- And also for the above said reasons, true/false is more intuitive, actual.
- While the word boolean, is more for those who already knew the general structure of comp lang's layout and control and statement/expression/var/function etc.
- Now, in a search context, boolean is more proper.
- Because in a search context, it is generally expected, u have the knowledge of knowing the keyword for what u r searching.
- At least somewhat.
- Because for certain topics, if u don't know the "keyword" to search, u may not find it.
- Ok.
- The decision is to add both.
- Eg boolean (true/false) to the title.
result
major update
me on hackernews. thanks guys. https://news.ycombinator.com/item?id=30976337 (local copy hacker_news_xah_code_2022-04-10.txt )
added a topic box:
let me explain. Xah Master!
functional programing is rather advanced concept, many coders of 5+ year still struggle to understand. Also, as dion says, there's nuances and context. It is not a exact mathematical concept. But let me try!
suppose you have
x = 3
define f() { return x+1}
print(f()) #this calls f
# result is 4
now, this is C C++ bash and most others. (by the way, they are called imperative style/lang or procedural. again, not exact concept, and don't worry about them.)
the problem is, the function depends on the variable x outside of it. That means, if you move the function to other place, or change some code outside the f definition, its behavior changes.
now, here's a functional programing style to do the same:
define f(x) { return x+1}
print(f(3)) #this calls f
# result is 4
this way, the function now is a independent unit. you can move it to different position, or to different file, and it behaves the same.
this is the essence, of “functional programing”. Here, the “function”, take the math sense of function. It takes in a value, return a value. doesn't matter where function is called, or whatever outside of it is changed, it behaves the same. (since in math, it's abstract. function is a general abstract concept, not tied to a position, or a file location.)
- much improved. now can show UTF8 encoding. Unicode Search 🔎
updates
updates
updated
should i have a single blog, or merge the multiple? e.g. merge js blog, emacs blog, to programing blog, merge arts, music, writing, blogs to a generic non-tech blog?
updated or new.
much update, for phone.
and other updates
- PowerShell: Show File Attributes, new, and lots updates there.
lol. after all these years. 3 decades. linus torvalds, finally realized the unix line truncation is the worst faak.
From Linus Torvalds
Date Fri, 29 May 2020 12:19:02 -0700
Subject Re: clean up kernel_{read,write} & friends v2
On Fri, May 29, 2020 at 6:08 AM David Laight <David.Laight@aculab.com> wrote:
>
> A wide monitor is for looking at lots of files.
Not necessarily.
Excessive line breaks are BAD. They cause real and every-day problems.
They cause problems for things like "grep" both in the patterns and in
the output, since grep (and a lot of other very basic unix utilities)
is fundamentally line-based.
So the fact is, many of us have long long since skipped the whole
"80-column terminal" model, for the same reason that we have many more
lines than 25 lines visible at a time.
And honestly, I don't want to see patches that make the kernel reading
experience worse for me and likely for the vast majority of people,
based on the argument that some odd people have small terminal
windows.
If you or Christoph have 80 character lines, you'll get possibly ugly
wrapped output. Tough. That's _your_ choice. Your hardware limitations
shouldn't be a pain for the rest of us.
Longer lines are fundamentally useful. My monitor is not only a lot
wider than it is tall, my fonts are universally narrower than they are
tall. Long lines are natural.
When I tile my terminal windows on my display, I can have 6 terminals
visible at one time, and that's because I have them three wide. And I
could still fit 80% of a fourth one side-by-side.
And guess what? That's with my default "100x50" terminal window (go to
your gnome terminal settings, you'll find that the 80x25 thing is just
an initial default that you can change), not with some 80x25 one. And
that's with a font that has anti-aliasing and isn't some pixelated
mess.
And most of my terminals actually end up being dragged wider and
taller than that. I checked, and my main one is 142x76 characters
right now, because it turns out that wider (and taller) terminals are
useful not just for source code.
Have you looked at "ps ax" output lately? Or used "top"? Or done "git
diff --stat" or any number of things where it turns out that 80x25 is
really really limiting, and is simply NO LONGER RELEVANT to most of
us.
So no. I do not care about somebody with a 80x25 terminal window
getting line wrapping.
For exactly the same reason I find it completely irrelevant if
somebody says that their kernel compile takes 10 hours because they
are doing kernel development on a Raspberry PI with 4GB of RAM.
People with restrictive hardware shouldn't make it more inconvenient
for people who have better resources. Yes, we'll accommodate things to
within reasonable limits. But no, 80-column terminals in 2020 isn't
"reasonable" any more as far as I'm concerned. People commonly used
132-column terminals even back in the 80's, for chrissake, don't try
to make 80 columns some immovable standard.
If you choose to use a 80-column terminal, you can live with the line
wrapping. It's just that simple.
And longer lines are simply useful. Part of that is that we aren't
programming in the 80's any more, and our source code is fundamentally
wider as a result.
Yes, local iteration variables are still called 'i', because more
context just isn't helpful for some anonymous counter. Being concise
is still a good thing, and overly verbose names are not inherently
better.
But still - it's entirely reasonable to have variable names that are
10-15 characters and it makes the code more legible. Writing things
out instead of using abbreviations etc.
And yes, we do use wide tabs, because that makes indentation something
you can visually see in the structure at a glance and on a
whole-function basis, rather than something you have to try to
visually "line up" things for or count spaces.
So we have lots of fairly fundamental issues that fairly easily make
for longer lines in many circumstances.
And yes, we do line breaks at some point. But there really isn't any
reason to make that point be 80 columns any more.
Linus
updated or new
See also: Linux: Terminal Control Sequence Keys
great articles
- [XML is almost always misused By Hugo Landau. At https://www.devever.net/~hl/xml ]
- [XML is almost always misused By Hugo Landau. At https://www.devever.net/~hl/xhtml2 ]
the problem with nim
the problem with nim is that it's niche. I never looked into exactly because of that, and i probably will find it a great lang. But the thing is, for every nim user, there's ten thousand golang users. That is a very critical fact about programing lang, a social fact. For example, i'd highly recommend Scheme lisp otherwise. But scheme lisp stayed forever niche in past 20 years. Never gonna see the light of the day.
certain social factors of a lang can never change. And i think nim is gonna be forever niche, like Scheme Lisp.
golang on the other hand, has the big advantage, of invented by a well known coding god celeb of unix community fame, and from google, and massive backed by the biggest empire on earth, and already deployed massively in mission critical apps.
See also: Why I Love Golang
working on these for past hours
Gah. Need a drink, or something. Super complex. Dealing with paths and url. The main problem is this:. Suppose u have a file full path. U want to press a button in ur fav editor, and it becomes a html link. Now, suppose ur domain is xahlee . Info, and the path is ~/web/xahlee_info/x.html. Now theres 2 choices result.
<a href="http://xahlee.info/x.html">
or it can be
<a href="x.html"> <a href="./x.html"> <a href="../x.html"> <a href="../cat/x.html">
Immediately, several problems. Some is about user pref. E.g. Fully qualified url or relative path? And if relative path, relative to parent dir, or relative to web root dir? And there's the ./name.js issue. E.g. For js file link, if it is a js lib, it is required, to have dot slash in front.
Some of these issues, r user preference. So, u might now need a variable to specify that pref. E.g. Http or https? Prefer fully qualified url , or relative link? Relative to parent, or to web root dir? And do u want always begin with ./ or only for js lib link?
Now, suppose u have another domain, say, ergoemacs.org. Now, suppose, on a file in ergoemacs, u paste a path to a file in xahlee.info, and u want to make it a link. Now, obviously, the link cannot use relative path, since they r in diff domain. However, locally, on your local file system, relative links work just fine.
So, now, u have several problems. U need a way, to determine, if a path belongs to a given domain. And u need a function that determines, the path, and the dir the current file is in, are of the same domain. (If so, relative links works, else, need fully qualified url ).
Just the above, needs few days working out. And writing the above, aka the analysis of the problem, came from years of experience working with html.
The other issues are:.
- Sometimes, if user pasted in a local file path, and that came from the browser url field, u get something like file:///users/home/xah/some. That's the url protocol for localhost. Ur code, need to check if path is such a path.
- Also, another path, is called protocal relative url. Namely, the path starts with 2 slashes.
- And also, on windows, the path user paseted may be using backslashes, and may and may not start with a driver letter eg C:\Users\xah.
- And, u also of course want be able to handle, if the path user pasted, start with ~/some , namely the bash convention.
Ok. That pretty much summarize the main issues. Not trivial.