Negi

The Open Engineering Task Force is a bit like its real world counterpart, the IETF, if I recall correctly. This place is basically to discuss protocols and standards defined for communication between computers in OpenComputers, I'm guessing.

If I recall (I think it was) Lizzy's words, we can submit new RFCs here, comment and expand already existing ones, things like that.

The only way to use another language (unless you write the whole interpreter in Lua and use it as a boot script) as the core of OpenComputers is to make it yourself with Java or Scala, using this: http://ocdoc.cil.li/tutorial:modding_architecture (And wow I noticed it got easier).
Implementing an OS directly through this mechanism has little interest, and I'm not sure it can be done (Hint: It probably can.).

Someone had wrote a JavaScript architecture (Look in Addon Mods), and there were projects to implement both ARM and x86 architectures. (ARM has been dropped, and I'm not sure about x86 but I'm pretty sure it was.)

Sadly, I doubt machine code will ever be a thing as it's a really big task to emulate an actual CPU and have it run smoothly enough, load code from EEPROM, and have all APIs implemented and stuff. Maybe someone will take on the challenge some day, though. I'm shrugging heavily at whether or not there is a possibility.

What you're thinking about here is mistakenly called an "internet".

You don't need any protocol creation, OC manages transmission between computers fairly well. And addresses already are unique over every component.

What you're describing is an abstraction layer. You'd basically have access to multiple networks as if they were one. I'd say it's the place of services to handle this.

(I still doubt it would be useful, though, since most of network interfaces use APIs that look alike.)

Are you using a computer in the overworld or a tablet you are carrying with you to communicate with the nanomachines?

In the first case, this would be normal, wireless communication can't go through multiple dimensions.

You can't mount multiple devices at the same mountpoint, no. What you can do is be smart about it, like have them named floppy-<three first characters of address>/ or anything like that.

If things are done correctly, which I believe is the case, haven't tested it myself, it's in /bin. So you just need to write "xerox <number of copies>" as Michiyo explained.

Have you tried with an already-existing file ? And are you sure that your program is at the right work directory ? Programs start at the work directory of the shell, which by default is the root.

Making your system unbootable is always an issue with things that run on boot, no matter where you put them. Writing a rc script is the "proper" way to make something run on boot though - init.lua is the OpenOS "kernel", and the scripts in /boot set up the OpenOS environment. If you put your custom code there, you might be unable to use some of OpenOS' custom libraries and functionality. autorun.lua is an even worse place - it is run everytime the filesystem is mounted on any computer (not just if it's the boot filesystem) meaning that if you do bad things in your autorun you won't even be able to fix it by booting from another filesystem. Unless you disable autorun in /etc/filesystem.cfg, which you really should do.

I'll add that ALL rc.d services aren't started on boot, only those in the enabled table. You wouldn't enable a service which you aren't sure works as expected, right ?

Well that's why you should test the state of things with rc <service> start before enabling it for automatic starting at boot.

What I've wrote here is only a quick solution, so I didn't bother with details.

Isn't autorun.lua reserved to when a disk is mounted?

You could also use RC, you just have to take the aforementionned code, and throw it in a start function, then save the thing as /etc/rc.d/filename.lua.

-- /etc/rc.d/filename.lua

local gpu = require("component").gpu

function start(config)
  gpu.setResolution(10, 10)
end

And you could then enable this that way (just add the filename in "enabled", you don't have to touch anything else) :

-- /etc/rc.conf

enabled = {"filename"}

The wireless redstone IO is usable when you have WR-CBE (maybe some other mod works too?) installed. The Tier 2 redstone card then becomes able to use WR-CBE's channels to transmit a redstone signal.

You'd just need to put an emitter/receiver near your sensors, tune them to the right channel, and regularly switch between their channels to check input/set output.

Ta liste n'est pas à jour. Ça c'est pour les anciennes versions d'OC. Si je me trompes pas, maintenant, OC supporte tout le jeu de caractères Unicode, ou du moins une grande partie.

Your list isn't up to date. That one is for older OC versions. If I recall correctly, OC now supports the whole Unicode set, or at least a major part of it.

The Computronics EEPROM reader is actually for Nedo Computers EEPROMs.

To read an EEPROM in a microcontroller you can just temporarily swap it out with another. (iirc that can be done, but I'm not sure).

Also, you're mixing up microcontrollers and development cards. Arduino are development cards with a specific language that is then compiled to AVR executables. The microcontroller which powers the Arduino is an ATMega, and if it were to be stripped from the card, it'd require some kind of adapter and some wiring to program. In-game microcontrollers are meant to be sort-of that way.

As for programming an EEPROM, you don't have access to most of the libraries, which are provided by OpenOS. For example, you won't have the event library, and you also don't have the require() function, although it's part of standard Lua, it calls for a filesystem. The accessible libraries are actually loaded in global space. I think that's all there is to say about it ?

Someone on the forums made a converter to convert MagicaVoxel ".vox" files to 3dm templates for the 3D Printer.

Please check it out and see if it fits your needs.

http://oc.cil.li/index.php?/topic/599-magicavoxel-vox-converter-for-print3d

If you're using the component.setPrimary() way, you'll also need to tell the gpu to draw on the right screen, i.e. component.gpu.bind("<Screen's address"),

your final code would look like that :

local component = require("component")
local screen = "<screen address>"

component.setPrimary("screen", screen)
component.gpu.bind(screen)

You can also enclose the two last lines in a function named start, and save that in the /etc/rc.d directory. Then edit rc.conf and add the file's name (minus the .lua) to the "enabled" table (Yes, rc.conf is a Lua file).

Hello ! 

1 ) You'll want to use driver mode (aka event.listen, a look in the event api's documentation will help you).

2 ) Well, your non-foreground program is still a program, so you define your callback function (it takes all the arguments of the signal, look in the signals page of the doc), and register it with event.listen("event_type", yourfunction).

3 ) Driver mode is a way for OpenOS to handle events, it uses event.listen(event, function) and event.ignore(event, function), the whole thing runs in background.

4 ) rc is just like a daemon manager...Or rather it starts things at boot if you configure it to do so, and it calls functions of that thing when you use rc. You can look at /etc/rc.d/example.lua, but basically you have a file with many functions, all of which represent a rc call (just like rc <service> <call>), one of these can be start(config), which will be called at boot if the name without the ".lua" of your file is in the "enabled" table of rc.cfg -that's a Lua file btw- and will be passed the variable that has the name of your service in rc.cfg as first argument.

Also, rc and driver mode aren't mutually exclusive, they work great together, actually.

I hope I've been clear, I'm not that great at explaining stuff.

1) The maximum resolution with a T3 card and a T3 screen is 160*50 characters. The smallest they can get depends on the actual size in blocks of your in-game screen.

2) The ratio for a character is of 1:2 afaik. But you can use half-block characters to make actual square pixels.

3) There are a few in the part of the forums made for that. And it's possible to write one. You can even use box-drawing characters for that.

I think that you should suggest that for OpenPrinter instead ? It belongs there more, and I hardly see how one would make a book-reader (if it's actually possible) without it being a scanner.

As far as I know, no one implemented any component for that yet, but yes that's the only way. (And I don't think the Debug Card has it either...)

I think that they're talking about vanilla name tags ?

I think it's an hexadecimal value, try to replace your numbers with 0xRRGGBB, where RR is the red composite, GG the green and BB the blue, ranging from 00 to FF (255).

Microcontrollers are computers intended to do a single simple/dumb task cheaply. You'll rarely need more than a network and a redstone card, or little things like that. Accessing components that aren't made into cards needs at least a bit of complex programming, I think.

I also think that was explained somewhere.

(And allowing them to access external components is sort of like, removing one of the two only differences with full-featured computers ?)

Here, have a look at the wiki page that talks about that. It should be explicit enough (and about up to date).

If that's about writing the documentation of an API, I can help. User-oriented documentation, I can try, but can't promise anything, really. :I