This is pretty impressive! I can’t even find the time to do Linux From Scratch never mind write my own!
I’m tempted to make another attempt at getting our audio code to work with the Android NDK. The last one a few years ago failed miserably, but there’s more interest in the mobile side of things again, so maybe time to try it once more.
Just got back home after a week away to the Mothership in London. Wow, what a fantastic city! I had a blast despite having to work for 4 days. We had great weather, so that sure helped. Can’t wait to go thru the photos.
Back to the grind this morning. Big expansion plans and we need programmers, so I’ll wade thru some resumes. Interested? Careers at Visionable
This week I need to focus on our desktop client. We need to get it released and luckily, Qt 5.12.5 has been release too, so we can move to that and hope it fixes some of our more gnarly display bugs. If I can get this out, I can move back to the API DLL, which I am writing in D, which I am loving!
Get better a D! I’ve been using it (and loving it!) in a project at work and I want to get better at it.
Yay, D! I am enjoying it a lot too. If you wan to chat about it in irc, #d in Freenode has been pretty helpful to me.
I love D. Unfortunately, it’s still a rebel without cause.
I disagree. It’s the C++ I always wanted. Expressive, fast, unopinionated, flexible, easy to use. That’s its cause. Everyone is always like “but the GC…” and I’ve never cared about that. Maybe I’m not low-level enough or something, but the GC suits me just fine because I’ve never noticed it’s there.
I spent the day rewriting a lot of my personal scripts in D, and all I have to say is, “wow.” What a great language. Everything I struggled to do in C – strings, arrays, memory – doesn’t exist in D. It’s pretty expressive for a type-sensitive language. It reminds me a lot of Go.
To each their own I guess. I’m not freaked out by modern technology and new ways of presenting information. I thought it was a very interesting way to teach a fairly dry topic, esp. one I’m not too keen on but feel like i have to know better.
Great idea - time for a reread!
I remember enjoying the book but kind of upset that it talked so much about hardware and hardware design, giving the short shrift to the software guys.
Plugging away on an experimental interface to our conferencing app, one that places the windows into an MDI-like interface. We bringing on some UX “experts”, so we’ll see what they think. It can get confusing for folks when their video windows are scattered about the desktop. Maybe this will help.
If you wanted to know what I worked on in a past life, check out this insteresting and pretty accurate article on Looking Glass Technology and Ultima Underworld, my last game dev project:
Interesting and impressive! Would you be able to demonstrate what you mean with an MDI-like interface or the actual project?
It’s pretty easy with Qt. Our app, a video conferencing app, has a main UI window and, when in a meeting, creates a window for each video feed (which can be up to 32 or more - honestly!). I just created a new mainwindow with an QMdiArea widget in it and then just add all the others windows as QMdiSubWindows instead of right on the root window. Works pretty nice and keeps things easier to manage. I may experiments with leaving the main UI window outside and just create the MdiWIndow to contain video feeds when you join a meeting as well.
This is so peak C++, multiple memory allocations, #include <algorithm> which pulls in 17000 lines on my system, a 2500 word blog post, and a book advertisement to get nicer formatting when evaluating a boolean.
The solution he proposes is extremely bad on every axis, it’s glacially slow to compile and execute, requires the reader to understand a huge amount of the language vs understanding operators, and is completely inflexible.
bool good = true;
good = good && customer.purchasedGoodsValue()) >= 1000;
good = good && !customer.hasReturnedItems());
good = good && std::find(begin(surveyResponders), end(surveyResponders), customer) != end(surveyResponders);
bool bad = false;
bad = bad || customer.hasDefaulted();
good = good && !bad;
Except ‘bad’ will always be false …
Work: Trying to get our program up to at least Qt 5.9. Unfortunately, I don’t have time to make it a 64bit app, so 5.9 is as far as we can go for now, as QWebEngine is 64bit only on Windows after that.
In my free time, I’d love to get up to speed on Rust.
And there’s already a du replacement called ‘dup’: https://github.com/ritze/dup
That’s a wrapper that hasn’t been touched in years.
A busy, bittersweet time - closing the camper for the season. Clean the camper, pull in the dock, take down the deck awning, that sort of stuff. Then we wait until next May. Sigh.
Yes - thanks for the post! I’ve been using Emacs for 20+ years and I still love hearing / reading about it.
Woah, 20+ years, 67% of my life :)
Gee thanks :)
Oh crap, I didn’t mean it like that, haha :-)
But seriously, it’s pretty amazing, the fact that a software package is alive and keeps improving for decades and decades.
Very rarely can you hear someone is using a piece of software for 20+ years.
No worries! 20 years might be underestimating, actually :) There’s some stuff in my emacs config files even I don’t understand any more! This might even spur me on to cleaning it up - a once a decade occurrence.
Oh great - another pointless project I won’t be able to ignore!
I actually had to laugh when I saw this title. Was ed ever a “good” editor?
Yes, absolutely. Ed was a good editor in the 1970s, when 300 baud links were reasonably fast things and teletypes with printed output were common, and even significantly into the 1980s, when you might still be dealing with 300 baud serial links (1200 baud if you were lucky), heavily overloaded systems, very dumb CRT-based terminals, or some combination of all three. About its only significant limitation in those situations is that it’s a single file at a time editor, which makes some things more awkward. Using any visual editor in those situations is a frustrating exercise in patience (or outright impossible on hardcopy teletypes or sufficiently dumb terminals).
(I’m the author of the linked-to article.)
The ancestors of ed, such as CTSS QED and it’s descendants on Multics (QEDX, Ted) all worked on multiple buffers, but those (and other) features were not carried forward to the simpler UNIX ed.
Given that Ken Thompson was fully familiar with QED et al (cf), the omission of multiple buffer support in ed is clearly deliberate. I wonder if Thompson felt forced to do it by resource constraints on Unix or if he just decided that it wasn’t important enough and omitting it simplified the experience in ways he wanted.
(By the time of V7 I suspect that resource constraints weren’t a big enough issue, and the Bell Labs people certainly were willing to rewrite programs if they should be improved. And I believe that people did versions of QED for early Unix, too.)
I don’t think I’ve ever actually used ed. I grew up in the 90s, so by then it was pico/nano. Is edlin from the MS-DOS days similar? If so I did use edline quite a bit, but would not be able to tell you anything about how to use it today.
I never used edlin, but I’d guess that editor has more in common with CP/M ED than UNIX ed.
Based on the edlin Wikipedia page, edlin is kind of a relatively simplified take on ed (although that’s not necessarily its historical origins). Full ed is fairly powerful, with a lot of text manipulation commands that don’t require you to retype lines to modify them and a bunch of ways of specifying what lines you want to operate on (including ‘lines that match this regular expression’). Interested parties can see the GNU ed manual. It’s probably simplest to start with the commands list if you want to see what ed is capable of.
(GNU ed is a moderate superset of V7 ed in both commands and its regular expression support.)
Ed is the standard editor.
I’d have to say no - it was clearly inferior to the QED descendants QEDX (and it’s descendent, Ted), which preceded it.
In defense of ‘ed’, this simplification was a design decision, according to Ritchie.
When using Multics, I often find myself reaching for QEDX, especially for quick editing tasks.
Nice! I’ll have to make an Emacs template for when I first open a Makefile to insert that boilerplate. I’d also add the code to generate the header file dependency tree using the correct g++ flags.
Here’s the rule I use (GNUMake) to do the dependencies:
makedepend -Y -- $(CFLAGS) -- $(shell find . -name '*.c') 2>/dev/null
This will exclude the system header files, but include all local headerfiles. Remove the -Y to include system headers.
mkdep $(CFLAGS) $(SRCS)
Better than this crufty make command I’ve been carrying around for probably 20 years!
MAKEDEPS=@echo Making $*.d; \
set -e; rm -f $@; \
$(CXX) -MM $(CXXFLAGS) $< > $@.$$$$; \
sed 's,\(.*$(*F)\)\.o[ :]*,$(*D)/\1.o $@ : ,g' < $@.$$$$ > $@; \
rm -f $@.$$$$
Make already gets such overwhelmingly negative press so let’s not leave this as-is lest others think this is how things have to be. Here is mine:
$(CXX) -MM -MT "$(basename $@).d $(basename $@).o" $< > $@
Nice! I’m not even sure where I got mine, just a case of “leave it alone it works”.
Our code uses this terminology and if I had more time, I’d change it as well. Maybe just server / client?
If you want to keep all the terminology consistent with other apps, Travis CI seems to call them the “workers” and the “hub”. “Worker” is also used by TaskCluster, but they just call the central job thing “the queue.” Kubernetes calls its nodes the “master” and either “worker” or “minion”, and Docker Swarm has the “manager”, while the rest of them are just called “nodes”.
“Worker” seems like the standard almost everybody’s arrived at for that part of the architecture, while the name for the lazy bum in the middle is not really standardized. I’d go with “manager” or “hub”, though, if I were you.
I like the idea of Manager, because that’s what the main program does - manage all the other ones.
Server/client is already a term of art so that’s a bit loaded. I have always thought leader/follower is the most clear alternative.
thanks for the heads up! Just changed it for my sites.
the only complaint I have with arch is that pip install and npm install fuck the system up. the solution is you have to use them inside virtualenv, nvm.
Which is not a distro problem, but a problem with the defaults of these third party language package managers. Everyone assumes sudo pip install requests is a great idea while have these issues when installing the requests lib from the repository.
I’ve configured my npm to install in ~ for globals things, so it doesn’t mess up my system :)
The problem isn’t really an arch issue, it’s related to the defaults of pip and npm. I’ve never had an issue with either negatively affecting my system if I set it up as the arch wiki recommends.
For pip, use --user if you aren’t in a venv, for npm, set $npm_config_prefix to be located in ~.
You install pip or npm with the package manager
then you use them according to the man pages and it borks your system.
This is a fault
If special configuration should be done this should come when you install it with the distro package manager. That’s the whole point of a linux distribution. If you’re supposed to use the virtual env you should at least get a warning about that when you install the tool. UX matters.
If you’re supposed to use the virtual env you should at least get a warning about that when you install the tool.
If you’re supposed to use the virtual env you should at least get a warning about that when you install the tool.
Actually almost every popular Python package suggests using virtualenvs (or more recently, pipenv). AFAIK, sudo pip install is considered bad practice in the Python community.
sudo pip install
Yeah, my solution to the npm problem is to stay far far away from npm.
Not exactly a universally applicable solution.
As a society, however, we’d all be better off if we could.
I’ve always told my kids to find a job like I have - something I would do for free (shhh, but don’t tell my boss). If / when I finally retire, I’ll just code my way into the grave. IOW, I love it!
Tells your boss. 😂
That’s awesome to hear. How did you learn to like it or did it come naturally?
Just fell into it and learned it from the seat of my pants. Took a couple programming courses in college but it didn’t click until a friend hired me basically because I knew what a keyboard looked like (those were desperate days!). A co-worker and I dove into it and I’ve never come out.
Work: Think I may finally have finished my re-write of our iOS capture code, to split off the UI from the back end. Took a bit - I’m not really happy working in Objective C++, that’s for sure. Now for some more cleanup and get out of the iOS development business again.
Home: Finish cleaning up my various web sites and the providers. I am slowly consolidating on name server provider, DNS provider and VM provider. Maybe get some of the web sites updated even!