Molinko

I have an idea™... I think your error may be from the filesystem api file handle... It's just a hunch that when 

4 hours ago, 24KaratCarrot said:

infile:read()

is called passing(or not passing...) nil somehow results in a string being used hence the error..

bad argument #1 (number expected, got string)

The doc recommends using the 'io' library instead of the 'filesystem' lib because it has buffered streams. Perhaps some fuckery is afoot.. I'd say try this and report back .

 1 local manager = {}
 2 
 3 local fs = require("filesystem") -- # maybe you don't need this anymore?..
 4 local component = require("component")
 5 local event = require("event")
 6 
 7 local modem = component.modem
 8 local SENDPORT = 1
 9 
10 function manager.sendFile(fileName, address)
11 	 inFile = io.open(fileName, 'r')
12   modem.open(SENDPORT)
13   modem.send(address, SENDPORT, fileName)
14   os.sleep(2)
15   fileString = infile:read('*a')
16   modem.send(address, SENDPORT, fileString)
17   modem.close(SENDPORT)
18 end
19
20 -- ... The library goes on
21
22 return manager

This uses the 'io' lib instead. Also note the '*a'(readall from buffer) arg passed to infile:read.

Hope this helps  

2 hours ago, 24KaratCarrot said:

16 modem.send(addresss, SENDPORT, fileString)

address is misspelled as 'addresss'. too many s... That was surprisingly hard  

@BrisingrAerowing I have seen it. It's quite nice . I've had a hard time just understanding the way the shell and tty work together... Specifically viewports(windows? )... Would I be right in saying that in @Dustpuppy's version he is doing all the drawing to the screen himself? I'm having a hard time... lol

What I really want to do is intercept the gpu I think.. Id like to have new processes get their own window, under my control. Including the shell. Is there a way to bind the terminal to a fake gpu proxy? Perhaps I can mock(intercept) the gpu proxy and redirect stdout to my drawbuffer.. Am I even close to something that sounds reasonable? First time shell/window programmer here. I don't really no jacksh*t about OS's.. Thanks for your help.

Hello, and thank you in advance.

I'm building a windowing system for OpenOS and was wondering if somebody could help me understand OpenOS's tty system? Basically I would like some tips for hijacking the initial terminal window. My plan is to put the terminals 'viewport' into a window and any subsequent processes into their respective windows. Any tips on the 'best' or 'appropriate' way to claim control of the shell window specifically would be greatly appreciated.  

Please ask any questions if I wasn't clear.

Cheers!   - Molinko

On 12/1/2017 at 9:26 AM, applejag said:

Example solution:

th = thread.create(function()
  while true do
    pcall(os.sleep, 1)

    computer.beep()
  end
end):detach()

 

@applejag Gave what I think is the best answer to your question. OpenOS functions that yield for and event can interrupt when the OS see's the ctrl+alt+c keys pressed. Basically most OS(kernel?) methods can throw an error in the user level(your program), if they receive the "interrupted" signal. If you run @applejag's example above, and pressed ctrl+alt+c to interrupt then it would be os.sleep that would get the interrupted event and throw and error into your program. Using the 'pcall' function will 'swallow' this error and thus preserve your program. One unintended side effect of this is that now you have to define your own method to exit this loop. Also with the example above when trying to interrupt the process you will probably cause a beep even if the timer hasn't elapsed yet.

Basically my advice would be to not do this in actual programs.. Learn and use 'soft' and 'hard' interrupts as defined with OpenOS. 'Hard' interrupts are in the OS for a good reason. To force a program to stop, like when you(or I) do something stupid, so we're not forced to restart the computer. 'Soft' interrupts will use the event system and can be pulled like any other event, allowing the program author to define program exit and cleanup on command from the user.

I like your style

If you read the 'Interrupts' section I posted from the wiki it says that calls to computer.pullSignal, and thus event.pull* methods, will call error inside themselves to basically crash your program when ctrl alt c is held. Personally I don't know why you need an inescapable beeper not in foreground process but who am I to judge... I haven't tested this but I think you would simply call the raw coroutine.yield instead of computer or event methods, which really just wrap coroutine methods with some extra stuff.

th = thread.create(function()
  	while true do
      coroutine.yield(1) -- # This shouldn't recieve hard interrupts.. I could be wrong..
      computer.beep()
    end
  end)

th:detach()

EDIT:

If my above method works I'd stick with it. However @applejag  has a solution that should work nicely.

Its really hard to understand your question. What I think might be happening is that the program you're testing the thread library in, or rather the parent process the thread is attached to, is receiving the interrupted event. When a threads 'host process' exits(ends) the attached processes 'join'(die). So to answer what I think your question is, stop pulling the interrupted event in whatever 'host process' is running your threads. FYI 'interrupted' events are queued by the OpenOS kernel and they bubble. See

Interrupts

Basic event example

Virtual waypoints for the self are pretty useless. There's no reason you couldn't just navigate using script local variables. Navigation components deploying a discoverable waypoint isn't any weirder really than the nav component detecting normal waypoint blocks. I just figured if the nav component can detect them why not be able to spoof them within reasonable limits. Its not op because any navigation card would be limited to detecting virtual waypoints with the same proximity limitations of normal waypoints.

3 hours ago, LightningShock said:

Is your virtual waypoint supposed to be seen by navigation upgrades in range other that the one who created it?

Yes.

Here's an example.

1. drone 'A' (with a navigation upgrade) calls the 'setWaypoint' method, setting a waypoint relative to its current position.
2. drone 'B' (with a navigation upgrade) calls the 'getWaypoints' method, returning a list of waypoints (1 of these waypoints is drone 'A').

Considering that navigation upgrades are limited by the map they were created with, drone 'A's "real world" location would have to lie within the map bounds of drone 'B's navigation upgrade.

I hope this is clearer. Cheers.

The virtual waypoint is within the map boundaries of a navigation component. Really it's like a navigation upgrade can detect other navigation upgrades while the latter posts it's virtual waypoint.

I suggest that the Navigation component should be able to set and delete a virtual waypoint around itself. This would be useful for robot/drone to robot/drone navigation thus further extending the reusability of drone programs and setup of robot programs alike. Also, perhaps some logical limitations to this could be that while the virtual waypoint is deployed drone or robot movement is stopped. However, I don't think this is necessary.

Examples of le code..

nav = component.navigation
nav.setWaypoint('waypoint 1', 12, -1)
-- # waypoint label, redstone level, vertical offset of virtual waypoint from caller( -1 is below the robot/drone. nil or 0 for actual position, 1 is above)
nav.deleteWaypoint()

-- # This makes me imagine usecases such as refueling requests
nav.setWaypoint('[refuel:charcoal 10]', 0, 1) -- # bring me 10 charcoal so I can refuel & resume...
-- # some code to check for my darn charcoal delivery...

You could do other cool things too like set a waypoint to yourself from you tablet. This could be a nice simple and beginner-friendly way to do navigation that isn't a far stretch in my opinion from normal waypoints. I don't think this feels cheaty, and I think it would make a handy addition to the limited ability of the navigation component thus making it more appealing to use.

Thanks for reading,

  - Molinko a.k.a Fast Eddie

1 hour ago, InfinitiesLoop said:

There's no way for it to know that there's already air there, so it has to visit them all

May I suggest the Geolyzer component to scan the building area? This way the script could clear only the necessary areas before building. This could potentially speed up hollow builds by a lot. Maybe it could just scan the areas expected to be hollow and clear obstructions to the actual model in the build path, this way scanning would be limited too as opposed to scanning the entire build area. Just some thoughts on efficiency. Nice script btw  

Perhaps you could use a timeout callback that uses event.push to queue a "fake" key event with the enter key. Just an idea..

I really love how nice this looks .

Tables are like lists. Sometimes you want and ordered list. Sometimes the order doesn't really matter logically but the categories or types of things in your list matter.

Ordered tables uses indexes(numbers) as accessors to values in a list(table). Property tables use keys(strings) as accessors to values. Take these examples.

-- # An ordered list. (table)
local groceries = {
  [1] = 'apples', [2] = 'oranges', [3] = 'cereal', [4] = 'frozen pizza'
}

print( groceries[1], groceries[3] ) -- # output:>> 'apples'		'cereal'


-- # A table with properties. Usually a good reason to use properties is so we can describe objects of our own. i.e.
local Player = {
  name = 'Molinko',
  health = 75,
  isAdmin = false,
  inventory = {
  	'pickaxe', 'golden apple', 'keyboard', 'some other items...'
  }
}

print( Player.name, Player.health ) -- # output:>> 'Molinko'	'75'

20 hours ago, Exmax said:

I want to get somehow, that variable name will return me string "Player"

If I'm understanding you then what you're looking for is this...

-- # Assuming the table 'output' is the object with information..
print( output.name ) -- # print the value to console.

local player_name = output.name
print( player_name ) -- # Same as 'print( output.name )'

I believe @Gorzoid is probably right. In case he's not, have you tried using the duration parameter on the call to robot.use()?

robot.use(sides.front, nil, 1) -- # call the 'use' method for 1 second.

This is looking really cool!!! Great work. I couldn't tell which version of the ECMAScript/Javascript language is embedded here? ES4, ES5..???

I dig it mang. Nice job, this is really cool  

event.pullMultiple is a "blocking" call, meaning it waits until an event has happened. Supply it with a timeout in seconds as the first argument to resume every so often.

event.pullMultiple(1, 'interrupted', 'touch') -- # 1 is the number of second to wait for an event before resuming.

I imagine there is more to do than just printing a line so I'll assume the Thread library is what you're looking for.

term.read with dobreak option is in the later versions of OpenOS. It may have not been available to you yet. The older version of term.read takes a list of option arguments instead of an options table. It can be used like so..

term.read(nil, false)

Dobreak is the second arg here, set to false, nil will default to dobreak bring true.

term.read returns the input as a string with a newline character at the end. If you want to compare words after taking input without cleaning the string use io.read instead of term.read. Or with term.read({dobreak=false})

io.read and term.read both return a string. Use tonumber(a)==2

The screenshot resolution is hard to read. Could you post the full code in 'code' tags?