Jump to content




Gopher's APIs - Old, and broken, but still good. Yah. Still good.

api

83 replies to this topic

#41 MudkipTheEpic

  • Members
  • 639 posts
  • LocationWhere you'd least expect it.

Posted 21 January 2013 - 07:12 AM

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... ;)

#42 GopherAtl

  • Members
  • 888 posts

Posted 25 January 2013 - 08:24 AM

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...


#43 MudkipTheEpic

  • Members
  • 639 posts
  • LocationWhere you'd least expect it.

Posted 25 January 2013 - 11:57 AM

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

#44 brett122798

  • Members
  • 300 posts
  • LocationIn the TARDIS at an unknown place in time.

Posted 30 January 2013 - 06:33 PM

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

#45 Skullblade

  • Members
  • 470 posts
  • LocationThe Big Apple, NY

Posted 31 January 2013 - 01:32 AM

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

#46 GopherAtl

  • Members
  • 888 posts

Posted 05 February 2013 - 09:07 AM

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


#47 GopherAtl

  • Members
  • 888 posts

Posted 07 February 2013 - 08:54 AM

: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.

#48 Sxw

  • Members
  • 306 posts
  • LocationWhenever, Wherever!

Posted 10 February 2013 - 07:05 AM

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

#49 GopherAtl

  • Members
  • 888 posts

Posted 10 February 2013 - 10:04 PM

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.

#50 Sxw

  • Members
  • 306 posts
  • LocationWhenever, Wherever!

Posted 11 February 2013 - 05:10 AM

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...

#51 GopherAtl

  • Members
  • 888 posts

Posted 11 February 2013 - 08:49 AM

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.

#52 anonimo182

  • Members
  • 252 posts
  • LocationIn the universe

Posted 12 February 2013 - 11:21 AM

Nice program, gonna use it in a future program!

#53 FuuuAInfiniteLoop(F.A.I.L)

  • Banned
  • 435 posts
  • LocationThe left part of this post

Posted 17 February 2013 - 12:40 PM

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!

#54 GopherAtl

  • Members
  • 888 posts

Posted 17 February 2013 - 03:10 PM

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


#55 FuuuAInfiniteLoop(F.A.I.L)

  • Banned
  • 435 posts
  • LocationThe left part of this post

Posted 20 February 2013 - 03:10 PM

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

#56 GopherAtl

  • Members
  • 888 posts

Posted 20 February 2013 - 03:37 PM

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 :)

#57 GopherAtl

  • Members
  • 888 posts

Posted 13 March 2013 - 03:38 PM

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

#58 GopherAtl

  • Members
  • 888 posts

Posted 16 March 2013 - 07:59 AM

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.

#59 Jan

  • Members
  • 141 posts
  • Locationthe Netherlands

Posted 16 March 2013 - 11:00 PM

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.

#60 GopherAtl

  • Members
  • 888 posts

Posted 17 March 2013 - 03:00 AM

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.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users