AndresNavarro

Ah, but with a little practice (& patience!) you can dial complete numbers using this system. I used to call the 113 number (clock/time information) here in Argentina in this way just for fun.

I don't think he's missing the point. I also find the scissor type keyboards to be a better fit than the model M and derivatives. And I also touch type & spend hours a day typing.

I think he means too high with respect to the desktop/table surface.

I see the discussion revolving around the ideas of jamming the signal and alternative ways for prisoners to have access to cellphones.

I would prefer to have a discussion about whether it's a good idea to forbid cellphones in jail in the first place...

The problem here is actually trademark law not copyright. The idea behind trademarks is that customers know the source of the product, so names, logos, brands, etc. are protected by it.

Copyright only protects the actual content/expression of the work of the Choose Your Own Adventure, not the name of the series.

Stallman has a nice article about the conflation of the "intellectual property" laws here: https://www.gnu.org/philosophy/not-ipr.html

I use my thumbs for control and alt on a regular (scissor type) keyboard. I remap alt to control and super to alt and have had no problem since I switched, about 4 or 5 years ago.

I found this pretty funny and all but it also reminded me of something my dad always says: "Carpentry is a science of centimeters, not millimeters". Meaning no sane person would ask for a table 2m long and complain that it's 5 millimeters or even a whole cm short...

I suppose he meant Android is not what Stallman would call GNU/Linux (and could actually be called Android/Linux if you will). See http://www.gnu.org/gnu/gnu-linux-faq.html#linuxsyswithoutgnu

There's a difference between a development environment and the code that runs in a random device...

The problem is not just closed source software (which I don't like and try not to use) but a lack of documentation of the architecture and bitstream formats. I program for a living, but wouldn't for the life of me work with a closed source compiler for an unknown architecture with no/incomplete documentation. Many people may be ok with this though (see for example, some shader compilers for embedded GPUs).

There's a reason processor manufactures release all info about instructions sets and that in turn allows a lot of projects like gcc, llvm, v8, luajit, etc. to support them.

I would think that opening up the details of this technology would spur a lot of innovation regarding FPGAs and HDLs, both in academia and in the industry.

I think the last paragraph is key:

> We also need to revisit the approach of compiling a high-level language to VHDL/Verilog and then using vendor-specific synthesis tools to generate bitstreams. If FPGA vendors open up FPGA architecture details, third parties could develop new tools that compile a high-level description directly to a bitstream without going through the intermediate step of generating VHDL/Verilog. This is attractive because current synthesis times are too long to be acceptable in the mainstream.

This is both an ideological as well as a practical matter. Until the whole process INCLUDING bitstream generation is open, I don't see FPGAs as a viable alternative to general purpose processors.

It's not even that, this can be (and probably is) implemented with dynamic variables (or some similar mechanism). You can also implement exceptions with setjmp and longjmp in C.

I feel the most important thing is conventions, and having a weaker model of exceptions as a convention, affects all/most code in the platform. In Java most libraries throw exceptions and so you will probably use exceptions. In C most libraries return an int return value for error/success and you'll probably use that. In Common Lisp, people use conditions.

So, what I'm trying to say, is that when considering this kind of design decisions in a language, we have to take into account how it affects the whole platform (and not just see if it is possible to implement it any other way in our particular language of choice). The same reasoning should be applied for object orientated features, scoping rules, calling conventions, multiple-value returns, lazy evaluation, macros, continuations, modules, type systems, naming conventions, etc.

I don't think it's the same in US English, I think the parent is right. Here in Buenos Aires one can say "kill yourself" (which would be "matate" in the rioplatense dialect of Spanish) for almost anything and nobody would bat an eye. In English, it sounds/looks pretty harsh, at least to my non native ears/eyes.

I found about this problem when moving from gnome to a minimalistic window manager that had no task bar whatsoever. I now use cnetworkmanager which is a python cmd application that uses dbus to connect with the regular NetworkManager service in Ubuntu, but for a couple of minutes it was a weird feeling, not being able to do something this basic

A Kernel interpreter in C: http://www.bitbucket.org/AndresNavarro/klisp

Just this week I got my first fork and a bunch of nice contributions.

I think I'll use this opportunity for a shameless plug: https://bitbucket.org/AndresNavarro/klisp

This is my ongoing project for a Kernel interpreter. It's already functional and it even has documentation. It is still, however, a work in progress!

Indeed. Erlang has this feature, I didn't intend to imply otherwise. What I meant was that this mechanism would be more difficult to implement in Go.

I'm not very knowledgeable about either Erlang or Go. But from what I read, Erlang doesn't share objects between threads whereas Go does. This is a serious difference, because as the article mention you have to decide what to do if there are references from other threads. That's why the parallel with processes breaks in the case of Go. Cleaning up the resources of a share nothing (or little, and in a centralized place, see shared mem) process is easy and fast. Cleaning up the resources of a share most/everything thread... not so much.

As a c programmer I find it quite odd/unnerving actually. It may be simple to understand its structure and it may look clean, but that isn't much to say of a project this size, especially if you know what it does. I found the file division & include pattern quite strange actually, and don't get me started in the cascading "if/else if" for the instruction dispatch: Not only is it almost impossible to optimize for the compiler, it's also more difficult to read than the obvious switch. Also, if the instructions were enums instead of defines, the compiler could even generate warnings when there are unimplemented opcodes. I don't use github but I'm tempted to make a branch and a pull request because it's driving me crazy!

EDIT: I was about to fork it when I noticed that in the other two branches (fast & simple, default is master) the dispatch is implemented with a switch. Please somebody explain to me why this wasn't moved to the default branch...

While some of these are great examples of common pitfalls with 64 bits errors, I find it amusing that the first example has a deeper conceptual problem: You can't (shouldn't) use memset to assign NULL to a pointer variable. In many (maybe most) implementations the address 0 is used by the implementation for NULL pointers but the standard allow any number (that can't be a valid address). The compiler automatically converts both 0 and NULL to the proper number when assigned to a pointer; but setting all bytes to 0 (as with memset) only works in the implementations that actually use address 0 for NULL pointers.