←  APIs and Utilities

ComputerCraft | Programmable Computers for Minecraft

»

Gopher's APIs - Old, and broken, but s...

MudkipTheEpic's Photo MudkipTheEpic 21 Jan 2013

View PostGopherAtl, on 21 January 2013 - 05:09 AM, said:

View PostGopherAtl, on 20 January 2013 - 05:40 AM, said:

show me your startup file?

I'm assuming you weren't checking if it was loaded already, though I'm rather surprised that would crash minecraft - just tried it myself, didn't do anything like that for me. Anywy, give the update a try.

Check if it is loaded before loading. the startup code in the OP gives you code to do this.



View PostGopherAtl, on 17 October 2012 - 01:41 AM, said:

goroutine

Usage
Spoiler

Still no clue why this crashes for you, tho, doesn't cause any problems at all for me even when I deliberately run it wrong, as you seem determined to do.

Ya, I like to look into programs and report bugs. Well, I was just trying to help report a bug... ;)
Quote

GopherAtl's Photo GopherAtl 25 Jan 2013

well, I've made a new version that is resistant to this sort of thing. Reloading the goroutine API now copies state over from the previous loaded instance, rather than clobbering it. So you can now legimitately launch it from startup in the background with this more trivial code at the beginning of your startup:

--these 2 lines should always be first - code before these will run twice.
os.loadAPI("goroutine")
goroutine.launch()

--normal startup here...
Quote

MudkipTheEpic's Photo MudkipTheEpic 25 Jan 2013

View PostGopherAtl, on 25 January 2013 - 08:24 AM, said:

well, I've made a new version that is resistant to this sort of thing. Reloading the goroutine API now copies state over from the previous loaded instance, rather than clobbering it. So you can now legimitately launch it from startup in the background with this more trivial code at the beginning of your startup:

--these 2 lines should always be first - code before these will run twice.
os.loadAPI("goroutine")
goroutine.launch()

--normal startup here...

Thank you, and have a good day. :P
Quote

brett122798's Photo brett122798 30 Jan 2013

Kinda realized, I was the one to bring this topic back to life! :P
Quote

Skullblade's Photo Skullblade 31 Jan 2013

Congratulations Brett you deserve a slow sarcastic clap...*le claps*
Quote

GopherAtl's Photo GopherAtl 05 Feb 2013

fixed some bugs in goroutines, proving I really need to test more; goroutine.kill() now actually works as intended, and the automatically-generated go.log file is more readable.

Just as importantly, I've added a set of utility programs to run from shell when goroutine is loaded in the background. Documentation is in the original post, under goroutine->shell utilities, but a quick summary:
ps - list the active coroutines
bg - run a program in the background, returning to shell
monitor - like the built-in monitor program, but runs monitor program in background and returns to the shell immediately, so you can continue to use the computer normally
kill - kill a coroutine
Quote

GopherAtl's Photo GopherAtl 07 Feb 2013

:bump:
added proper handling of term.redirect to goroutines, which was long-overdue, so coroutines can now call term.redirect without producing unexpected behavior.

Also, finally added one of those long-promised "advanced examples," my multishell program, which uses all three APIs: goroutine to handle multiple shell instances running at once, redirect to create and manage redirect buffers for each, and ctrlkeys to generate the ctrl_key events it uses to switch between shells. This is such a handy program, I find myself using it all the time lately, so I've also made a separate thread for it in programs, where an installer program can be downloaded to automatically download the program and all three APIs, but I list it here as well as example code showing how powerful these APIs can be when used together.
Quote

Sxw's Photo Sxw 10 Feb 2013

Just wanna tell you, i'm working on a project that uses these, ill be sure to credit you when its done :)
Quote

GopherAtl's Photo GopherAtl 10 Feb 2013

sxw: most excellent, glad to hear it, can't wait to see what you come up with!

Found & fixed some glitches in redirect and the new multishell example, now multishell is working in color, and added some checks to prevent certain things like textutils.tabulate that send fractional values to setCursorPos from causing text to become invisble - meaning you can actually see the full output of the ls command, and other tabulated output, now. Also fixed a conditional in redirect that was causing the last row not to display.

There remains an issue that multishell doesn't work properly when run after goroutines was launched in the background. Will be addressing that tomorrow, for now, no more code, sleeps.
Quote

Sxw's Photo Sxw 11 Feb 2013

Is there a way to make just 1 routine not receive a certain event? I'm building a multiuser ssh and using goroutine.spawnWithRedirect, but i need it to only receive key events from the remote client. It will run in the background and might have multiple users connected to different terminals at once...
Quote

GopherAtl's Photo GopherAtl 11 Feb 2013

hrm. No way to block a particular event to a single coroutine at present, closest thing is assigning the events to one particular coroutine, and that coroutine can decide which other coroutine, if any, to pass it to. What I do with my multishell program is assign all the user input events to a manager coroutine which then passes them to the coroutine that is currently active, so no other coroutines get key events. That system needs some love, as it needs to send the event to children of that coroutine as well; currently only the main coroutine, the one passed into goroutine.run(), can call goroutine.assignEvent to assign events a given coroutine.
Quote

anonimo182's Photo anonimo182 12 Feb 2013

Nice program, gonna use it in a future program!
Quote

FuuuAInfiniteLoop(F.A.I.L)'s Photo FuuuAInfiniteLoop(F.A.I.L) 17 Feb 2013

for redirect you should add the function to the buffers to run a program without need of redirect to the buffer and shell. run so we can create windows running at the same time!
Quote

GopherAtl's Photo GopherAtl 17 Feb 2013

by combining goroutine and redirect, you can already do this quite easily. If you call goroutine.spawnWithRedirect, and pass in a redirect buffer object, goroutines will automatically switch the redirects appropriately when swiching coroutines. If you set the dimensions right when creting the buffers and set the positions correctly when calling makeActive, you can even do split-screen systems (though currently there's some issues with the apparent cursor position when using read in one buffer while sharing the screen with other active buffers, which I hope to resolve in the next version)

:edit: here's an example that demonstrates having an input routine calling read() on the bottom line while another routine displays text to a scrolling area above it, as you might want in many applications, including chat clients and other programs that accept user commands while displaying updates based on external events.

Spoiler
Quote

FuuuAInfiniteLoop(F.A.I.L)'s Photo FuuuAInfiniteLoop(F.A.I.L) 20 Feb 2013

I want to use redirect and goroutine in my os(as part of the windows) if you allow me send me a PM
Quote

GopherAtl's Photo GopherAtl 20 Feb 2013

As I said at the end of the opening post, anyone is free to use these apis however they like. That's why I made, documented, and released them :)
Quote

GopherAtl's Photo GopherAtl 13 Mar 2013

Update bump!

I've added a new api, ggui. No documentation in the OP yet, but there are two sample programs with it that demonstrate (almost) all of the features.

current gui elements:
labels - just that. display text.
buttons - like labels, but can be selected and clicked, and generate events when they are.
text fields - basic, single-line text fields.
graphics - "pixel" image elements that import files made in cc paint

general features:
mouse and keyboard-based focus control - tab or arrow to cycle through focus-enabled elements (buttons and text fields currently), click or enter to activate buttons.

dynamic styles - built-in defaults that can be overridden and extended to alter the colors, decoration characters, alignment, and other behaviors of all elements, with the ability to define different styles for color or black-and-white computers for easy compatibility with both

graphic slicing - when creating graphic elements, can optionally specify source x, y, width, and height values, allowing only a portion of the image to be loaded and rendered. Caching of the original source allows multiple graphic elements to efficiently use different parts of a single graphic file, basically allowing a form of spritesheets.

event callback system - write functions to handle different events and then assign them as event handlers. Handlers can specify additional filters beyond just the event type, so all the ugly if-if-elseif-end-elseif-elseif-end nonsense you normaly go through to figure out what event you're dealing with is hidden away in the api, keeping your code cleaner.


The sample programs:
.
login - a sample login screen, that works on color or b/w computers. Demonstrates buttons, labels, text fields, graphics, styles, and event handlers. (note: this is not a secure login program, it is simply a demonstration of the gui system.)

redstone - a program for monitoring and setting redstone state on all sides of a computer. Demonstrates buttons, labels, styles, event handlers, and custom tab ordering.

Downloads

Installer pastebin get fq8SinNB gguisetup
Installer will download the api, the two sample programs, and the graphics files required by the samples. just download and run "guisetup <dir>" to install to a specified directory.

If you don't care about examples and just wanna poke through the api itself, here ya go...
The api pastebin get i0EyjZ2W ggui
Quote

GopherAtl's Photo GopherAtl 16 Mar 2013

update, still beta and still no documentation but ggui has been revised to include the first pass on implementing screens, which will be used for a lot of things, but for now are being used to let you write programs that run across multiple monitors at once. Particularly when combined with the new lan peripherals in cc 1.51, this will let you run a whole room full of interactive monitors off of a single computer with relative ease.

since people like pictures more than words, and the ggui beta is actually visual, unlike my other apis for which screenshots just don't make sense at all, some screenshots!

Posted Image
Same program, basic computer (actually, advanced computer I tricked into thinking it was a basic computer...)
Posted Image
aand the redstone program, running on monitors.
Posted Image

Links are the same as the last post, and can be found in the OP as well.
Quote

Jan's Photo Jan 16 Mar 2013

View PostGopherAtl, on 16 March 2013 - 07:59 AM, said:

...snip...
That looks very nice! But does it have keyboard support?
Best would be if you could be able to control the same program with a touch-monitor or a keyboard.
That an on-screen keyboard would show up if you are in a text-field, while the program is running on a monitor
And that you can use TAB or arrow keys to switch fields if you are running the same program on a grey computer

Maybe this hybrid-interface is not optimal for every type of program (paint i.e.), but it would be handy for the program-maker,
because he doesnt have to make a touch-monitor and keyboard version of his program.
Quote

GopherAtl's Photo GopherAtl 17 Mar 2013

But of course it has keyboard support! b&w support would be silly if it didn't :) And I actually plan on adding an on-screen keyboard for touch-screen monitors, but have not done so yet.

Focusable elements (currently buttons and text fields) are automatically added to a tab group in the order they're created, which you can cycle through with up/down, left/right (not with text fields, which capture these for cursor movement), and tab. You can also override this tab order, setting up a different tab order manually using functions - the redstone sample program demonstrates this.
Quote