Wobbo

Your problem is is that the second argument to shell.execute is the environment to run the program in. You are probably looking for os.execute, which doesn't pull shenanigans like this. You give os.execute one string, which is the program name followed by the arguments, the same as in the shell.

os.execute("prgm_name arg1 arg2")

You won't have to worry about driver mode I guess (someone correct me if I'm wrong). 

At the end of the basic usage section on the wiki there is an example of using event.listen. It refers back to the example above. 

Instead of coroutines, you might want to use event.listen. You can find information about event.listen on the OC wiki. 

MOD EDIT: Wiki link http://ocdoc.cil.li

Since this has a shell, I guess it is more like a Desktop Environment than an OS, is this right? Or is it more like X.org? In any case, some pictures would be nice

Anyway, I might try this out later. When time is available. 

Why has nobody mentioned os.exit here yet? That should work just fine. 

Pipes are use to redirect the output of a program to a file or another program. So, lets say we have a program curl that downloads files from the internet, but doesn't save them. Then we could write the contents of the downloaded file to harddisk like this:

curl http://example.com > example.html

the > redirects the output to the file. We also have < which reads from a file. So if we take for example grep (oppm install grep should work):

grep 'local .- = .*' < file.lua

we give grep the contents of file.lua as input (grep is a kind of silly example, since it can already read files, but it works. 

We can use the | to give the output of one program to the next. So if we are for example looking for files with a specific extension, say .lua we could do this:

ls | grep '%.lua'

This should only print the lines that have .lua as extension. 

I would really reread that tutorial if I were you. Now your library cannot be unloaded, since it is placed into the global environment. That is why you need to use a table and return that at the end, like this:

local term = require("term")

local test = {}

function test.fred(text)
  term.write(text)
end

function test.george()
  term.write("should not see this unless george was called!")
end

return test

I would suggest you read a tutorial, like [shameless plug]mine[/shameless plug]. That should teach you everything you need to know about loading and writing libraries. 

You are using the timer correctly, that is not the problem. But when you go down, you never reset your height to 0. So the next time you call Harvest, you first go down the blocks you need to go down, but then you also go down for the previous trees. You can solve this by setting height to 0 just after the loop where you go down. 

Also, it is better if you place a local before your function definitions. Then you won't clutter the environment as much and you free up some RAM after your program finished running. 

Could you try your first version with the event, but extracting the address before you define the function? So like:

local address = ...
event.listen('init', function()
  ...
  fs.mount(address, "main") 
end

This should get rid of the varargs error. 

Would be the exact right way, again, oc networks are so different from real ones and will never ever communicate with them (expect for internet cards for which applying real world rules would make sense), so using the same concepts as for real network dont makes any thing better, its just more complicated and unoriginal.

Edit: does anyone want creepers in reallife?

I'm not saying the networks are the same, but only that it would make sense to reserve the port that is normally reserved for ssh would also be reserved for a ssh clone in OC, also since OpenOS is based on real life OSes and follows certain real life protocols and standards. So it is in the spirit of the rest of the mod.

And it doesn't make stuff complicated or unoriginal, it makes it so you can easily transport real life experience into the mod.

Actually, your program should take a command line argument to set the port, like this: prgm --port=41324 and use that port. This resolves all conflicts for custom settings and interaction with other programs. 

And I do agree with SKS about the real world port thingy. If I want to make a ssh for OpenComputers, it would be natural for most people to use port 22, not some arbitrary other port because someones multiplayer game already uses that port. The same goes for ftp, telnet and a whole other rage of programs that fit into the same category. This makes it easier for people that use those protocols irl to use the protocols in OC. And we are going for a real world UNIX style anyway. 

So, you want to know what this `require` thingy does? Or maybe you installed a library you can't load? You want to write your own library? Then we are here to help you. In this tutorial, we are going to explain how the `require` function and the `package` library works. So, lets get started!

Loading Libraries
In order to load a library, you can use the function `require`. But what does `require` do? Where does it pull these libraries from?

`require` needs the name of the library you want to load, but not the path to that file, so it needs to search the file system somehow. This is done by looking at the string in `package.path`. You can open up a lua prompt and try to print it now. The default value of `package.path` is `"/lib/?.lua;/usr/lib/?.lua;/home/lib/?.lua;./?.lua"`. Each string between the `;` is seen as a path and the name you provide is used to replace the `?`. Then require tries all the paths and sees if the file exists. If it exists, it is executed and the return value is stored and returned to the caller. The vaule is stored so `require` does not have to load the same library twice. This improves loading times and minimizes RAM usage!

So, lets say you installed a library in `/usr/local/lib` and `require` can't seem to find it. How do you tell `require` where it needs to look? This can be done by changing `package.path` to include the installation location of your new library. So you need to encode your new directory in the path. First you need to make the path to the new folder recognisable to `require`. First you need the path to the directory (`/usr/local/lib/`). This needs to be followed by the `?.lua` to do the substitution with the name. Then we get the following path: `/usr/local/lib/?.lua`. So now require knows where to find your library!


Writing Libraries
So, now you know how to load a library, but not how to write one, so that is what we are going to do now. The library will not do propererror checking, that is left as an exercise to the reader.

So, what will our library do? It will be a wrapper around the movement functions of the `robot` api, but it will move the robot multiple times. So `movebot.forward(10)` will try to move the robot ten times. So open a file called movebot.lua and we can start!

First we need to require the robot api. We can do this like you would do it in any other file, with `local robot = require 'robot'`. Now we get to the fun part.

At the end of the file, we need to return a table which will hold all the functions. I find it easiest to create this table beforehand, but you can also create it at the end. If you do, don't forget to localise your variables! So, lets create this table!

local movebot = {}

Now we can install our functions into it! As said before, these functions wil have no error checking, this is left as an exercise to the reader.

The functions will get a number and need to call the respective function from the robot library that many times.

function movebot.forward(x)
  x = x or 1
  for i = 1, x do
    robot.forward()
  end
end

function movebot.back(x)
  x = x or 1
  for i = 1, x do
    robot.back()
  end
end

function movebot.up(x)
  x = x or 1
  for i = 1, x do
    robot.up()
  end
end

function movebot.down(x)
  x = x or 1
  for i = 1, x do
    robot.down()
  end
end

Now we only need to return the table we just created and we are done!

return movebot

The whole file should now look like this:
 

local robot = require 'robot'

local movebot = {}

function movebot.forward(x)
  x = x or 1
  for i = 1, x do
    robot.forward()
  end
end

function movebot.back(x)
  x = x or 1
  for i = 1, x do
    robot.back()
  end
end

function movebot.up(x)
  x = x or 1
  for i = 1, x do
    robot.up()
  end
end

function movebot.down(x)
  x = x or 1
  for i = 1, x do
    robot.down()
  end
end

return movebot

Now, save the file and you are ready to require the file! In fact, you can try it out from the lua prompt. If it errors, make sure you try to `require` the right file and that it is in your `package.path`. 

And Now?

Now you should be ready to install and write your own libraries and make changes to the libraries of others. If you still have questions, feel free to ask them here!

No computers from 2015 onwards? What kind of horrible future is this?!D:

That means my education will only leave me a defunct psychologist! I don't have the skill sot build cognition without a machine to build it on :/

Do you mean attempt to index 'slots'? The value Inventory does not exist in your code. 

If this is the case, then the problem is that your library doesn't return the function you define. The module system in OpenComputers differs from that in ComputerCraft, where

this would be valid. In OpenComputers, the module is expected to either return something, or to place something in package.loaded[modulename]. This is then returned to the requiring file. If neither of this happens, require simply returns true, to indicate that the file was found and loaded, which results in the variable slots in your code being a boolean. 

There are two ways to fix this problem. The first way is to leave Invertory.lua(slots.lua if my guess is right) the same, and to call the function nextFull directly. This should be possible since you placed it in the global environment. This happens, but is in my opion a sloppy solution, since you dump all your variables in the global environment. 

A better approach would be to return the function nextFull from your module, either directly or in a table. That would lead to the following code:

local robot = require ("robot")

slot = 1

local function nextFull()
  if robot.count(slot) == 0 then
    slot = slot + 1
    robot.select(slot)
  end
end

return {nextFull = nextFull}

This way you can add new functions to the module later on. Now you won't have to change the way build.lua works, and your module can be extended with other functions later on. 

So this is kinda like cat, but for printers? Neat!

That geolyser sounds interesting! Will I be able to place that on robots?

Also, will the new set of robot events allow us to use non-blocking robot calls? Because then I really need to start working on my robotics framework. If I ever find the time :/

I want to elaborate on this answer a bit, because I guess we will get questions like this more often:

You have to require any library that is not mentioned on the page about standard libraries. The lua prompt tries to require libraries for you, so you won't have to do it yourself, this makes for easier testing. 

So if you have a similar problem with a different library, do with your library what pcman312 did for robot, because that is the correct way to load a library. 

Recently, I found a lisp to lua compiler. So this is a lisp compiler that instead of spewing out binary executables, it spews out Lua code. I had to change it a little to make it work for OC[1], but it does now!

You can find the compiler here. The programs it creates need at least 128 kb, so no Lisping robots yet. 

[1] Apparently, including deprecated functions, like table.maxn, is normal >.>

About luasocket, I know that you can install luarocks on OS X with both homebrew and macports, so you can run the server from OS X as well. 

Also, I don't really get what you mean with protocol. Is that what is returned by event.pull? 

I don't know. I don't dislike it, let me start with that, but I hope they won't break compatibility again. 

And apart from the bitwise operators, it doesn't really add that much. Unless I misunderstand the pack/unpack functions for numbers. 

What I would like to see are macros, those would be nice. And a __type metafield. 

Are the camera's fully implemented yet? Or are they only like sonar now?

Depends on what you perceive as feature-complete. They're definitely not complete, but the chance they'll get actual color information is unlikely due to the fact that only the client knows that.

I indeed meant the color. So the camera is actually a sonar? What features do you want to implement further?

I have not been able to play with it yet, but it does look nice.

Are the camera's fully implemented yet? Or are they only like sonar now?

This is pretty awesome.

I would love to know what your code does, but I have no clue how the sponge code works, would you mind explaining it?

energyd is a small program that creates a background program that installs a background program that keeps track of your energy level and sends an event each time it passes a set border. It can be found here. There is also a config file over there.