payonel

yep, should always require("bit32"), it is not intended to be global (we aren't clearing it from _G in boot). I'll fix in dev. sorry

what openos bug?

1 hour ago, XyFreak said:

@Moobien Looks like you ran into an OpenOS bug. Please report it to the OpenComputer guys

One COULD do that but i won't. For now.

 

1. you'll have to calculate stretching math yourself

2. our graphics are text based, not pixel based

screens drain power if chars are visible, regardless of machine state -- though note that screens are turned off when a machine poweroff occurs

These types of questions are more likely to be seen by our developer team using our github: https://github.com/MightyPirates/OpenComputers/issues

To be honest, I'm fine leaving it the way it is. It's one of those things that has been that way for a long time and people have been using it. This would be a type of breaking change to anyone with existing scripts.

Over the next month or two I have hopes to migrate our gradle dependencies to a central and single server to make building the mod more reliable

I'll try to remember to update this post when that work is done.

I appreciate your help in translations.

Remember, we push to 1.7.10, 1.10, 1.11, and 1.12

When you are ready - I would need your translations for each version. There are changes in the label capitalization between those versions

@XyFreak what were you wanting from the thread library that it isn't doing?

@hron84I haven't tested the openos updater myself, but we haven't had a incompatibility change between the base mod and the OS for quite a while (some time in the 1.5 -> 1.6 time frame is the last time that happened)

local term = require("term")

term.clear()

print("text")

after you build a computer that can boot with the openos floopy in the disk drive, run `install` so that your rootfs isn't read only, it'll reboot, then you can write scripts

edit - a simple tool for editing files

simple script:

```

print("hello what is your name?")

local name = io.read()

print("hello", name)

```

we're on OC 1.7 these days, but the 1.4 tutorials are still helpful

also, to use term, you need to require (import, include) it

```

local term = require("term")

term.clear()

print("tada")

```

@thearhar Please, if you have specific feedback for ocdoc, add your suggestion to https://github.com/MightyPirates/OpenComputers/issues/2686

As for detach I can see that its explanation was a bit short. It would have been easier to understand if you read the entire doc. I have updated the explanation for detach in the docs

From the docs, it is explained that a thread is attached to the current process when created. An attached thread blocks the parent process from closing until that thread dies. A parent process can abort, which kills all attached threads.A detached thread blocks no process (technically, the init process is its parent, but it does not block reboot/shutdown)

great advice and explanation @Molinko thank you for supporting the community!

One small change I would recommend: When working with user programs or threads (as opposed to custom coroutines) don't use coroutine.yield() unless you SPECIFICALLY want your process to block until a SIGNAL is raised (e.g. key_down)

coroutine.yield() blocks until it receives a signal, even in threads

os.sleep(0) might be better

You would need a program that buffers the text and scrolls and redraws for you.

/bin/more can be used scroll down, but it doesn't scroll back

/bin/less does back scrolling

example

`cat large_file | less`

XyFreak: btw, if your setup docs, "Don't forget to add brgc_reactor, brgc_turbine and brgc_grid to your /etc/rc.cfg if you want to start the controller at boot time:"

You can also ask the user to run `rc brgc_reactor enable` to add it to the configs

30 minutes ago, XyFreak said:

if yielding after each component api call is the intended bebaviour i'd like to see that documented somewhere.

Read, "where the call takes at least one server tick"

Here: https://github.com/MightyPirates/OpenComputers/blob/f5c19e9e7e0006d3403c7bf0b44dfb970cee8a2f/src/main/java/li/cil/oc/api/machine/Callback.java#L43-L59

As to the delay in the shell, please see my comment in the github ticket

-edit-

I'll post here for  those that don't want to open more tabs:

First of all, if you are sleeping ( os.sleep ) in a service, that is going to block your shell. Use threads instead if you want to sleep without blocking other coroutines http://ocdoc.cil.li/api:thread

The list of versions affected show both good and bad for oc 1.6 and 1.7, while ER >= 0.4.5.41 (thus, including 44) is bad in both cases

So from that list alone it seems to be an issue with ER, and not a regression in oc 1.6 -> 1.7

Also, I had not realized the event handling delay with keyboard hits was so intense. Curious, when that is occurring, is the cursor blinking normally? (.5 second blink)

-edit-

It isn't by design to have such a delay in typing. The delay by design is to limit the number of direct api calls you can make within a tick

I've read the entire post. I've read your review of the system yielding longer than you'd like, but I haven't read about a yield bug.

Read my response to this github ticket: https://github.com/MightyPirates/OpenComputers/issues/2632

Is there something I'm missing?

There definitely isn't enough memory on 1 stick of tier 1 ram to run edit

The minimal amount of ram is enough to do some basic shell commands, but most things are going to fail

2 sticks of tier 1 ram is probably enough for most built in functions and tools

On 1/20/2018 at 5:32 AM, XyFreak said:

Since the yield bug we discovered in november is STILL not fixed

What yield bug?

This post gives me a few things to think about

First - @Molinko what is wrong about the documentation and the term library? I have a ticket on github to clean up the docs and I do plan to give the term doc page another review. But are there things specifically that you know to be wrong or confusing? If you do, please add your feedback to the github ticket: https://github.com/MightyPirates/OpenComputers/issues/2686

Second - I should have known that even if I put things in an `internal` sub table, people would still use them. Feel free to use the `term.internal.open` and `term.internal.run_in_window`, but you should also know these are not api - and can change without warning. They've now been around for a long time, but I may refactor them later.

Third - OpenOS does not have multiple window support. Our internal (again, internal) structures have future support built in to support multiple windows, but we do not have an API for this yet. Thus, the solution you build is going to feel a bit complex or hacked, and you'll likely be making internal calls. Because again, this is not officially supported.

The idea is this: term doesn't bind to a gpu, and tty doesn't bind to a gpu, the PROCESS is bound to a gpu. And the gpu is bound to a window. Child processes inherit their parent gpu and such. The internal workings of how this happens (in the term lib and in the tty lib) should not affect your user code. If you want to switch between screens, rebind the gpu. If you want to leave a gpu bound to a screen, and switch between gpus, then set the term gpu between the two. But I understand that this doesn't work with cursor positions and input buffers

Fourth - @Molinko holy crap, someone is using the devfs! Ha! I'm pretty excited by that nice. And yes, you have the code correct. The first ( /0 ) will be the primary.

Fifth - @joserobjr Changing the component primary device will not affect the kernel in any way. That only affects user code that is using the convenience method on the `component` library for quick access to the primary component of a type: `component[type]` In other words, for example changing the primary gpu changes the object returned by `component.gpu` but the kernel does not use this anywhere

I am happy to review the serialization code in openos, but not with a repro with your speciifc use case

Note  that the serialization library has been optimization since our last official release. Please retest with a latest dev build from: http://ci.cil.li/

for example:

1.7.10: http://ci.cil.li/job/OpenComputers-dev-MC1.7.10/

1.10: http://ci.cil.li/job/OpenComputers-dev-MC1.10/

yes - this is a bug in openos when users try to print to the screen before boot is finished

I have this fixed, you are running an older version of openos

Note that if you pull the latest code, it will fix your problem and you won't get a blue screen. However, you also won't get the text printed to the screen because the terminal isn't finished loading yet.

If you want to print to the screen in a script that runs automatically during boot, you need to add your programs to /home/.shrc

Things that run in /boot, or autoruns, or rc scripts, may be executing before the terminal has initialized

If you want to run your code before /home/.shrc is run (happens when the shell loads) then you'll have to wait for the terminal to become available, that is, you'll need to:

      if not term.isAvailable() do
        event.pull("term_available")
      end

you have to look at your code and think -- is there anywhere in this loop that could run for more than 5 seconds without sleep/yield? If so, add a os.sleep(0), perhaps once per loop, or use a timeout yourself and sleep every 2 seconds.

I have a similar sleep in the terminal code when printing out a very large file to the screen, i do this:

  local last_sleep = computer.uptime()
  while true do
    if uptime() - last_sleep > 1 then
      os.sleep(0)
      last_sleep = computer.uptime()
    end

can you link the updated code?