elderK

I agree with your posts.

I've been battling RSI and stuff for the past two years and am starting to make progress although it's required me to get both of my wrists fixed and potentially both of my elbows in the future.

It's easy to just say "Oh, do this workout" but it can be very difficult to do that if you either lack the time or have other health issues that prevent you from doing them.

For me, I have rods in my legs and fused ankles so even though I try to hit the treadmill regularly, doing so means I wind up in a lot of pain.

None of this has got in the way of my passion for building software, although for me there is a distinction between what I do (or want to do) in my own time vs. what I have to do for work.

It's a good day when I can really apply myself to a problem at work.

It's less great when for whatever reason, I'm prevented from being able to do a good job.

And the sad thing is that often, you're not prevented from doing a good job because of any technical or time constraint, it's usually all political.

That's the thing that sucks most :)

Thanks for answering, ggm.

I agree with you completely and have passed your advice on to my friend.

My view is that if it's something he's genuinely interested in, he should go for it.

You beat me to it!

I'd recommend checking out Chicken Scheme. Not only is it a kick-butt implementation but its community, #chicken on Freenode, is truly fantastic.

Give it a whirl :)

Man, does this bring back memories :)

Me too!

How about this? It's even freely available nowadays:

https://www.amazon.com/Common-LISP-Introduction-Computation-...

I've read many of the comments.

Lots of talk about removing the parenthesis, using things like Tree-Notation and such.

Really, all I can say is that you can pry the parens from my cold, dead, cantankerous hands. :P

Maybe it's because I've been playing with Lisp, in one form or another, on and off for several years.

But I never found the parens really all that bad.

It's no problem at all as long as you have basic paren matching support in whatever editor you use.

And if you happen to use an editor that supports the structured manipulation of S-expressions, well, it's a pretty neat experience.

I think the only time the parens bother me is if I print source code out. But even then, there are clear conventions on how Lisp source should be laid out and indented, so you adapt pretty quick, even in the "worst case."

shrug

As someone who has a pretty serious visual impairment, I find the attitude of so many of these comments really... disappointing.

You wouldn't believe how much effort people with poor vision have to go to, to consume the modern web.

You can't even take simple things for granted like being able to zoom. So many websites pollute their page with pointless navigation elements that block most of the content when the page is zoomed.

Or say pages that try to be elegant, centering everything with some margin. Sure, it looks "great" if no one zooms it. If you do, you wind up consuming the content in three or four word chunks...

Or even worse: Elements that have hardcoded minimum widths. When you zoom, nothing reflows and you wind up having tons of content "off screen."

At best, this is annoying because you have to constantly scroll horizontally.

At worst, you're screwed because for some bizarre reason, scroll bars never appear.

I'll wrap my rant up here but I'll leave this:

Do you really want the web to be like reality, where the needs of a few are so often ignored simply because of some trait?

"Oh, there are so few of them, why bother..." "Oh, they don't matter because <whatever>"

Sound familiar? I'm sure you can fill in the blanks.

The web gives us a unique opportunity to improve on the real world in so, so many ways.

Don't waste it.

Thanks for posting this.

I've been wondering about how assemblers handle this for a very long time :)

Drive-by poster here but I was wondering if you had spent any time looking into what IO scheduler you're using on Linux?

Some time ago I encountered issues similar to what you mention in your posts. I solved it selecting the "Deadline" IO scheduler when I built my kernel.

Hopefully this helps you solve the issue :)

~K

You're assuming everyone is able to read text at the same font size as you.

The font size will likely be increased during a code review, too, depending on how the code is presented to your team.

Man, I'll always have a soft spot in my heart for these visualizations.

Extremely useful learning aids :)

I remember back in the day when they were Java applets :)

A metric @!#$ton? :D

:) Care to elaborate?

I mean, as far as I see it, the directory is still a file, of a specific format.

How is that any different than an image file, say, of a particular format? You still need specialized programs in order to manipulate them in a meaningful way. But they're just bytes. Just like the directory is just bytes.

The difference, of course, is that allowing the user to arbitrarily manipulate a directory entry at the byte-level could lead to filesystem corruption.

I'm aware I may be missing something really obvious here. Heck, even contradicting myself :)

Educate me :)

I don't see how providing specialized open/read/close calls for directories breaks the file abstraction.

Imagine byte-level access to a directory. You'd have to have some library in userspace that would correctly be able to manipulate that directory's metadata. Now imagine doing that for various filesystems.

Plan 9's namespaces and file-servers were pretty awesome and flexible. It really opened my eyes to the generality of the file abstraction.

That's not to say it's implemented as efficiently as it could be.

See here: https://linux.die.net/man/7/aio

AFAIK, system-specific APIs such as epoll or kqueue are the way to go if you're serious about performing asynchronous IO?

Hey Munificient, I just wanted to say that I'm a major fan of your book.

I find your writing extremely clear :)

I'm working on a bunch of lexer and parser related tools for personal use.

The reason they're cool is that it automates a lot of the tedious, error-prone stuff that I've been doing by hand as I experiment with grammars and the like.

Sure, there are a ton of tools out there to generate lexers and parse tables and such. But using them doesn't help me understand how they were built.

And using them doesn't produce the same sense of accomplishment or, at least for me, /depth/ of understanding.

I try to document the tools as best I can so that fellow students who are interested in such things can learn or make use of them. :)

This, exactly. :)

Wouldn't sbrk kind of get in the way of ASLR?

Raize FTW :)

Thanks for the response.

To clarify "module boundaries", I mean "separate shared objects."

As for Linux, I'm not too concerned with creating a single binary that works for all distributions.

I'm more concerned with someone being able to build a set of shared libraries on their distribution of choice and those shared libraries being able to interact naturally regardless of which compiler s/he uses to build each of them.

Say, LibA is built using LLVM. LibB is built using G++ and LibC is built using ICC.

LibA defines several classes. LibB creates some subtypes. LibC instantiates types from both LibA and LibB.

All the functions present in LibA, LibB, LibC make use of STL types such as std::string, std::vector, etc. Some may throw exceptions, whatever.

With respect to MSVC, I've read that compatibility between Debug and Release builds is kind of suspect, especially if you're using STL types. Not to mention differences in MSVC version. Is this still a concern?

Hey there Aidenn0,

I'm no expert on C++ and I've been considering using it for several projects.

An important thing for my needs is being able to define classes in one shared object and create new subtypes of those classes in another, possibly defining overrides on virtual methods and such.

A good friend of mine has said similar things as you - that the ABI issue has not been a major obstacle for some time.

And yet, as much as I search, I still find the same-old advice: Don't use STL types in your interfaces or throw exceptions across module boundaries.

If all the compilers used for a given platform follow the same ABI, would using a separate and specific STL implementation (say, STLport) instead alleviate that particular issue?

Sorry if this question seems a bit rambley but I'd really love to find out how to use C++ in the way I've mentioned.

I can only speak for myself here but I feel that belonging too strongly in either camp is a bad thing.

Ideally, you'd want to understand both worlds.

As such, I feel that the projects I work on in my own time and the crazy things I do in them help me to better understand what kind of things really do need to happen when working under tight deadlines in the workplace.

I.e. It's easier to produce an effective product quickly if you know from personal experience exactly which approaches or things really are essential.

Also, note I haven't read the actual article. I'm replying mostly in response to the comments :)

I use Crux.

It's a source-based distribution similar to Gentoo but far, far simpler.

And that's why I use it: It's simple.

It also has a great community. :)

Hey there Bjoern,

Would it be sufficient to have solved many different types of problems encountered while working on side projects?

Thank you!

I'll try and keep the faith :)

That's good to know.

I have an active BitBucket.

It doesn't contain everything I've ever done but it has the most recent stuff I've been working on.

Would it be worthwhile having a link to the BitBucket present on my CV?