BIOS equivalent of 'require'

[Fictitious Rotor 2]

I've been working on robots that don't have interfaces - and instead commune by wireless means.
Part of programming these robots has involved writing on an EEPROM

My problem lies with getting certain APIs.

I've previously encountered things such as

modem = component.proxy(component.list("modem")())

to get to an API, but FileSystem doesn't work this way.

The program here (ran on a computer) wouldn't work as I put

fs = require("component").filesystem

Where I should have put

fs = require("filesystem")

If I make this change, the program works.

But if I comment out the require statements, uncomment the proxy statements, write to an EEPROM and then insert into a robot, it doesn't work over there.

So what's the BIOS way to get the filesystem API?

(If you're wondering, the program is a recursive function designed to inform other devices of what's on the robot's filesystem)

[TYKUHN2 2]

All libraries that are required by "require" are generally part of OpenOS meaning if you're using an eeprom... good luck.

Also component.primary or component.filesystem are not native. They are part of OpenOS.

BIOS don't have libraries thus it doesn't have require.

What they do have is components. Everything plopped into your computer is a component, including that disk drive. OpenOS is not special it is something you can make from hand using what is given to you.

Also "require" is not much more than loading and executing a file.

[feldim2425 8]

Yeah. The "require" method is part of OpenOS.

But there are some ways around that.

1) I think the component-Library is native (At least for eeproms in a computer case) so you don't have to require it.

2) component.filesystem is a link to the first filesystem found by OpenOS when it starts. So you can find it yourself 

local fs = component.list("filesystem", true)();

3) Instead of using the filesystem-Library you should use the filesystem-Component (link to the docs)

[Molinko 43]

You could think about loading libraries remotely into memory from a network... As TYKUHN2 said..

On 3/26/2017 at 9:30 AM, TYKUHN2 said:

Also "require" is not much more than loading and executing a file.

With an extra step of requesting a file... require could be switched with a call to load or loadfile.

-- # pseudo code.. this might work but isn't tested or even run...
function require(module)
  -- # do some checks n shit..
  local file, chunk = nil, ""
  modem.send(address, port, "get[file] " .. module)
  
  while true do
    local e, la, ra, p, d, ch, status = computer.pullSignal(2)
    
    if e == "modem_message" then
      if status:match("error") then -- # request failed somehow
        return nil, status
      elseif st == "chunk" or st == "start" then -- # first and subsequent chunks
        chunk = chunk .. ch
      elseif st == "done" then -- # we haz all the chunkz. time to load ze chunkz.
        file = chunk .. (#ch > 0 and ch or "")
        break
      end
    end
  end
  
  if file then
    local ret = {pcall(load, file, "=" .. module)}
    if not ret[1] then return nil, ret[2] end -- # ret[2] here is an error msg
    ret = {pcall(f)}
    return ret[1] and ret[2] or nil, ret[2]
  end
  
  return nil, "failed because reasons..."
end

 

[payonel 21]

In this response when I say "In EERPROM" I am referring to any code that is running without or before OpenOS. It doesn't necessarily have to be literally in EEPROM code. It could be your own custom OS, it could be literally code in an EEPROM.

So....

require("filesystem") ~= require("component").filesystem

We are dealing with some confusion here. I should make a wiki page specifically about the two weird+confusing things here

We need to understand what is a library and what is a proxy

1. require() returns libraries
2. component.proxy() and component[component_type_name] provide access to component proxies

Let's first talk about what is true BEFORE OpenOS boots, or in other words, what is true in EEPROM. Keep in mind, OpenOS doesn't do anything you can't do. OpenOS fully runs in the game environment

In EEPROM, The `component` object is available globally, in _G. From here on, let's refer to this component that is in _G in EEPROM as _G.component. The docs really need clarification on this object. This is partially true http://ocdoc.cil.li/api:component

The problem with the "api:component" page is that it describes OpenOS' version of component which is almost the same, but OpenOS adds a few methods and helpers. ocdoc pages that are named "api:" are referring to libraries. And like all other libraries, you need to call require("component") to use that api. So it looks like a library, and it has a library ocdoc page, BUT .. _G.component is available to your EEPROM code (i.e. before OpenOS loads). In truth _G.component and require("component") are the SAME object, but OpenOS adds a few methods to component and OpenOS removes it from _G, thus requiring that you require it.

Every filesystem component (e.g. hdds, floppies) have a GUID (let's call it fs_addr). As for other component types, you can acquire a proxy to that component by calling _G.component.proxy(fs_addr) (or require("component").proxy(fs_addr) when in OpenOS)

local fs_proxy = _G.component.proxy(fs_addr)

Yes I know it is not necessary to use _G but I am trying to make it clear I am referring to the _G.component that is available In EEPROM (or, before OpenOS loads or in any custom boot)

This fs_proxy is a proxy to the actual hdd or the actual floppy in your computer. See http://ocdoc.cil.li/component:filesystem

fs_proxy is a proxy to the component, in linux terms, it is the filesystem DEVICE.

## Libraries ##

OpenOS adds libraries. OpenOS provides a library named filesystem. It has been debated whether this was a good name, given that there is also a component with the SAME NAME.

require("filesystem") is the "filesystem" library api

require(lib_name) returns apis, code from /lib/${lib_name}.lua

and require("filesystem") loads the code from /lib/filesystem.lua, see http://ocdoc.cil.li/api:filesystem

This, the OpenOS filesystem library, can create mounts, can create symbolic links, can open/create/read/write files across all mounted filesystem components (devices).

 

Lastly, I want to mention that once inside OpenOS, you have NEW methods of acquiring the component proxies.

For example, component.filesystem is a proxy to the "primary" filesystem. This is NOT the rootfs, it is simply the first filesystem component that is detected during boot. Read more about primary components on the api:component page: http://ocdoc.cil.li/api:component

 

"primary" is an OpenOS idea. Because generally there are multiple filesystem components (even the tmp filesystem is its own filesystem), it is unclear which filesystem you are accessing when you use component.filesystem. I advice you DO NOT use component.filesystem unless you are certain there is only one filesystem. The same argument can be made against using component.proxy(component.list("filesystem")()) -- this is a simple way to get some random filesystem, but you don't know which filesystem.

[Fictitious Rotor 2]

On 6/28/2017 at 8:21 PM, payonel said:

In this response when I say "In EERPROM" I am referring to any code that is running without or before OpenOS. It doesn't necessarily have to be literally in EEPROM code. It could be your own custom OS, it could be literally code in an EEPROM.

So....

require("filesystem") ~= require("component").filesystem

We are dealing with some confusion here. I should make a wiki page specifically about the two weird+confusing things here

We need to understand what is a library and what is a proxy

1. require() returns libraries
2. component.proxy() and component[component_type_name] provide access to component proxies

Let's first talk about what is true BEFORE OpenOS boots, or in other words, what is true in EEPROM. Keep in mind, OpenOS doesn't do anything you can't do. OpenOS fully runs in the game environment

In EEPROM, The `component` object is available globally, in _G. From here on, let's refer to this component that is in _G in EEPROM as _G.component. The docs really need clarification on this object. This is partially true http://ocdoc.cil.li/api:component

The problem with the "api:component" page is that it describes OpenOS' version of component which is almost the same, but OpenOS adds a few methods and helpers. ocdoc pages that are named "api:" are referring to libraries. And like all other libraries, you need to call require("component") to use that api. So it looks like a library, and it has a library ocdoc page, BUT .. _G.component is available to your EEPROM code (i.e. before OpenOS loads). In truth _G.component and require("component") are the SAME object, but OpenOS adds a few methods to component and OpenOS removes it from _G, thus requiring that you require it.

Every filesystem component (e.g. hdds, floppies) have a GUID (let's call it fs_addr). As for other component types, you can acquire a proxy to that component by calling _G.component.proxy(fs_addr) (or require("component").proxy(fs_addr) when in OpenOS)

local fs_proxy = _G.component.proxy(fs_addr)

Yes I know it is not necessary to use _G but I am trying to make it clear I am referring to the _G.component that is available In EEPROM (or, before OpenOS loads or in any custom boot)

This fs_proxy is a proxy to the actual hdd or the actual floppy in your computer. See http://ocdoc.cil.li/component:filesystem

fs_proxy is a proxy to the component, in linux terms, it is the filesystem DEVICE.

## Libraries ##

OpenOS adds libraries. OpenOS provides a library named filesystem. It has been debated whether this was a good name, given that there is also a component with the SAME NAME.

require("filesystem") is the "filesystem" library api

require(lib_name) returns apis, code from /lib/${lib_name}.lua

and require("filesystem") loads the code from /lib/filesystem.lua, see http://ocdoc.cil.li/api:filesystem

This, the OpenOS filesystem library, can create mounts, can create symbolic links, can open/create/read/write files across all mounted filesystem components (devices).

 

Lastly, I want to mention that once inside OpenOS, you have NEW methods of acquiring the component proxies.

For example, component.filesystem is a proxy to the "primary" filesystem. This is NOT the rootfs, it is simply the first filesystem component that is detected during boot. Read more about primary components on the api:component page: http://ocdoc.cil.li/api:component

 

"primary" is an OpenOS idea. Because generally there are multiple filesystem components (even the tmp filesystem is its own filesystem), it is unclear which filesystem you are accessing when you use component.filesystem. I advice you DO NOT use component.filesystem unless you are certain there is only one filesystem. The same argument can be made against using component.proxy(component.list("filesystem")()) -- this is a simple way to get some random filesystem, but you don't know which filesystem.

Though all of the other answers were very informative and helpful, yours struck a chord with me in terms of clarity.

Thank all you very much for spending so much time helping me out!